Domínio principal
DNS
Na faceta Domínio principal, DNS grupos de inteligência são organizados por domínio principal para que os leitores possam acompanhar uma área de foco em infraestrutura da internet, governança, mercados de conectividade ou capital digital. A página reúne artigos relacionados, evidências públicas, instituições, empresas, pessoas, exposição regional, dependências operacionais e contexto de mercado que, de outra forma, poderiam estar espalhados por páginas de categorias separadas. Ela explica o domínio, a provável classe de atores, o contexto de mercado ou de governança e o material de origem que os leitores devem usar ao comparar sinais. Operadores, analistas e leitores de governança podem ver como o mesmo domínio aparece em eventos, perfis, mudanças de mercado, evidências de fontes públicas, dependências regionais e decisões de infraestrutura de ciclos mais longos ao longo do tempo.
Líderes
Dean Pemberton quis transformar IPv4 contaminado em endereço DNS. A APNIC disse sim e depois não.
A APNIC mantinha 1.2.3.0/24 em quarentena por causa de tráfego indesejado. Pemberton propôs usá-lo como endereço memorável para DNS anycast de alcance local. O grupo de políticas concordou numa quinta-feira; a assembleia de membros não chegou ao mesmo acordo na sexta.
Acadêmicos
Giovane Moura quer dados DNS comparáveis; o histórico IPv6 de .nl se perdeu
SIDN publica as métricas DNS de .nl no formato RSSAC-002. O próprio repositório registra um dia sem dados e contagens antigas de fontes IPv6 que não podem mais ser refeitas.
IETF
Joe Abley testou o DNSSEC pós-quântico: 1 ms na mediana, 1,405 s no p99
No teste inicial da Cloudflare, quase nada mudou na mediana. No 1% mais lento, o caminho com duas assinaturas registrou 1,405 segundos a mais que o controle clássico no p99. O gráfico de resolvedores validadores também chamou o resultado agregado de 6,0% de “net breakage”. A…
ICANN
Carlos Gañán separou a conta do abuso DNS: mais meses, campanhas 38% menores
Em 1.106 gTLDs, a probabilidade mensal de abuso foi 3,1 pontos percentuais maior na Categoria 1, enquanto a escala esperada das campanhas foi 38% menor depois que o abuso apareceu. O modelo combinado estimou 37% menos domínios maliciosamente registrados por gTLD-mês.
Acadêmicos
Ginevra Fabrizio poupou 11 bytes; NXDOMAIN continuou grande demais
Na RIPE 93, a pesquisadora da Universidade de Twente comparou dois formatos Falcon-512 ao reproduzir um dia de consultas `.nl`. A assinatura sem preenchimento teve mediana de 655 bytes, contra 666; todas as respostas NXDOMAIN testadas ainda ultrapassaram os dois limites de…
IETF
O algoritmo 18 já tinha número. Joe Abley encontrou a barreira do EPP.
A IANA lista o ML-DSA-44 como o algoritmo DNSSEC 18. Na RIPE 93, Joe Abley descreveu o obstáculo seguinte: um registro pode rejeitar os dados DS que o operador envia pelo EPP. Seu rascunho individual de outubro propõe alinhar essas regras de aceitação aos registros da IANA.
Acadêmicos
Martine Sophie Lenders encontrou o sinal que o DNS criptografado ainda deixa no pacote
O estudo dela sobre IoT com poucos recursos não tenta ler a consulta. Ele mede como o formato dos pacotes ainda pode revelar o tráfego DNS — e até onde a transferência em blocos e a compressão de cabeçalhos reduzem essa pista.
Institucional Global
Cinco versões corrigidas e uma palavra vaga: ler a CVE-2025-40778
Um relatório datado sobre uma falha de envenenamento de cache no BIND 9 enumera com exatidão quais compilações carregam a correção e deixa o lado afetado em «várias». Essa assimetria decide o que o registro consegue provar a quem assina a atualização — e o que ele discretamente…
Arquivo de Caso
A Dyn continuou respondendo. Nenhum texto impôs um dever à resolução.
Um provedor compartilhado de nomes absorveu tráfego de botnet em outubro de 2016, e o registro público guardou o episódio como uma história de queda. Os documentos que vieram depois são mais estranhos do que a história: um alerta federal sobre os aparelhos que geraram aquele…
Líderes
Ray Bellis e o limite entre o documento publicado e a rede em operação
Entre agosto de 2009 e março de 2019, o mesmo engenheiro assinou dois documentos que hoje servem a leitores muito diferentes: quem opera proxies de DNS em equipamentos de borda e quem implementa resolvedores que precisam manter estado entre consultas. A distância entre eles não é…
ICANN
A recusa do .org: uma porta de consentimento sem critério publicado
Em novembro de 2019, a Internet Society concordou em vender o Public Interest Registry, operador do domínio de primeiro nível .org, à firma de private equity Ethos Capital. Em 30 de abril de 2020, o Conselho Diretor da ICANN recusou seu consentimento à mudança de controle do…
IETF
O algoritmo ganhou um número. O resolvedor ainda pode recusá-lo
O RFC 9563 torna assinaturas SM2 e resumos SM3 identificáveis no DNSSEC. Isso resolve a ambiguidade de protocolo; não prova consenso do IETF, adequação criptográfica, suporte de validadores, aceitação de política ou o resultado visto pelo usuário.
IETF
O servidor de reserva respondeu. A chave em cache não serviu: RFC 8901
Um segundo provedor de DNS autoritativo pode continuar respondendo depois que o primeiro falha e ainda assim não entregar uma resposta aceitável a um resolvedor validador. A RFC 8901 trata a redundância DNSSEC como um contrato de sincronização entre signatários, não como contagem…
História
Gihan Dias e o dia em que duas escritas entraram na raiz
O Sri Lanka já trocava e-mails e operava redes quando surgiu outra fronteira: fazer com que o sistema global de nomes reconhecesse o país em cingalês e tâmil. Na trajetória de Gihan Dias, conexão, linguagem e responsabilidade institucional deixam de ser problemas separados.
Arquivo de Caso
Quando um patch não prova a recuperação: a cadeia de reparo do BIND diante do KeyTrap e da recursão excessiva
As vulnerabilidades CVE-2023-3341 e CVE-2023-50387 mostram um limite recorrente da segurança operacional do DNS: publicar uma correção encerra a divulgação técnica, mas não demonstra que os operadores encontraram sua exposição, instalaram o reparo ou recuperaram a resiliência do…
IETF
James Gould e o sinal de ocultação que não prova a política
Um campo ausente costuma chegar ao painel como uma resposta pronta: “não há dado”. No RDAP, essa leitura pode estar errada. O servidor talvez possua a informação e a tenha retirado apenas daquela visão. A RFC 9537, coassinada por James Gould, dá ao servidor um modo estruturado de…
Arquivo de Caso
O nome que a rede decidiu mostrar
Uma lista de serviços internos pode ficar fora do DNS público enquanto a autorização para resolvê-los continua verificável. No RFC 9704, porém, o nome do próprio resolvedor aparece. A privacidade depende tanto dessa escolha quanto do mecanismo que protege a lista.
IETF
Suzanne Woolf e o rótulo de servidor que não é a identidade da máquina
Quando uma resposta DNS traz um identificador do servidor, é fácil tratá-lo como o nome certo da máquina que respondeu. Anycast, balanceamento e valores definidos pelo operador tornam essa leitura excessiva. O RFC 4892, coautorado por Suzanne Woolf, propõe uma disciplina mais…
IETF
Sara Dickinson e a promessa do resolvedor que a criptografia não consegue provar
Trocar o DNS comum por uma conexão criptografada reduz uma exposição real, mas não elimina a pergunta principal: o que acontece quando a consulta chega ao resolvedor? O RFC 8932, que tem Sara Dickinson entre seus autores, abre essa caixa operacional. Logs, correlação, retenção…
ICANN
Allison Mankin e a amostra de colisão de nomes que não provava a causa
Uma reunião de aprovação pode receber um painel cheio de consultas DNS e ainda estar diante da pergunta errada. O volume mostra o que chegou à raiz; não revela sozinho qual aplicação montou o nome, quem deve corrigi-la ou qual dano uma delegação provocaria. A RFC 8023, coassinada…