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.
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…
Arquivo de Caso
A chave era conhecida. Ainda não era confiável
Receber uma chave nova e verificar sua assinatura não responde à pergunta mais importante: quem autorizou o portador a mudar a delegação? No encerramento previsto da última chamada do DNSOP em 7 de setembro, o rascunho sobre DDNS torna essa diferença operacional ao separar uma…
Arquivo de Caso
O ponto final sumiu — e a fronteira de confiança mudou
No DNS, `example.co.uk` e `example.co.uk.` podem chegar ao mesmo nó. Dentro de uma aplicação, porém, as duas formas podem abrir perímetros diferentes. No dia em que termina a Última Chamada do grupo DNSOP, uma falha recente do curl deixa uma pergunta concreta: o nome foi…
IETF
A minimização de QNAME é um contrato de sequência, não um botão de privacidade
Um resolvedor pode informar que a minimização está ativa e ainda assim expor nomes, custos e falhas diferentes conforme o estado do cache. A evidência não é um sinal binário: é a sequência limitada produzida por delegações conhecidas, respostas negativas e eventuais fallbacks.
Arquivo de Caso
O DNS recebeu o aviso. O pai ainda precisava decidir: o limite de delegação da RFC 9859
A RFC 9859 antecipa a análise de manutenção de delegação. Ela não transforma um aviso em consentimento do lado pai nem uma resposta em prova de DS publicado.