A 11 de outubro, a raiz do DNS passa a usar uma nova chave de assinatura, chamada KSK-2024. É só a segunda vez que isto acontece. A primeira foi em outubro de 2018.
Em palavras simples: o DNSSEC permite a um resolver verificar se uma resposta DNS é verdadeira. Todas as verificações partem de uma chave lá no topo, a chave da raiz. Os resolvers guardam uma cópia dela, chamada âncora de confiança (trust anchor). Se um resolver que valida não tiver a nova chave a 11 de outubro, não falha em algumas consultas. Falha em todas (SERVFAIL, para os leitores mais técnicos).
Quem tem de agir: quem corre o seu próprio resolver com validação, como o BIND, o Unbound ou o PowerDNS Recursor.
Quem pode ficar descansado: quem usa o resolver do seu fornecedor ou um público. É o meu caso. Os meus servidores usam o Google (8.8.8.8) e a Cloudflare (1.1.1.1), e são esses operadores que tratam da nova chave. Os meus próprios servidores DNS correm PowerDNS, mas são servidores autoritativos. Respondem pelos meus domínios e não validam os dos outros, por isso a chave da raiz não lhes toca. Em 2018 também usava resolvers públicos, e também não tive de fazer nada.
Se corre o seu próprio resolver, confirme que a nova chave, com a key tag 38696, está no ficheiro da âncora de confiança. O BIND guarda-a em bind.keys, e o comando rndc managed-keys status mostra o estado atual. O Unbound e o PowerDNS Recursor guardam-na em root.key. Se a chave não estiver lá, confirme que as atualizações automáticas da âncora estão ligadas e que o resolver pode escrever na sua pasta de armazenamento, e depois siga as instruções do fabricante. Não assuma que a atualização automática funcionou. Verifique.
Para uma verificação rápida, a equipa de DNS da Cloudflare criou uma página de teste em dnstest.dev/ksk-2024. E se depois do dia 11 todas as consultas começarem a falhar com SERVFAIL, a âncora de confiança é o primeiro sítio onde procurar.
Para a maioria das pessoas, 11 de outubro vai ser um domingo como os outros.