On 11 October the root of the DNS switches to a new signing key, called KSK-2024. It's only the second time this has happened. The first was in October 2018.
In plain words: DNSSEC lets a resolver check that a DNS answer is real. Every check starts from one key at the top, the root key. Resolvers keep a copy of it, called the trust anchor. If a validating resolver doesn't have the new key on 11 October, it won't fail on a few lookups. It will fail on all of them (SERVFAIL, for the technical readers).
Who has to act: anyone running their own validating resolver, like BIND, Unbound or PowerDNS Recursor.Who can relax: anyone using their provider's resolver or a public one. That includes me. My servers use Google (8.8.8.8) and Cloudflare (1.1.1.1), and those operators take care of the new key. My own DNS servers run PowerDNS, but they are authoritative servers. They answer for my domains and don't validate anyone else's, so the root key doesn't touch them. In 2018 I also used public resolvers, and I didn't have to do anything then either.
If you do run your own resolver, check that the new key, key tag 38696, is in your trust anchor file. BIND keeps it in bind.keys, and rndc managed-keys status shows the live state. Unbound and PowerDNS Recursor keep it in root.key. If the key is missing, make sure automatic trust anchor updates are on and that the resolver can write to its storage directory, then follow your vendor's guidance. Don't assume the automatic update worked. Check it.
For a quick visual check, the DNS team at Cloudflare put up a test page at dnstest.dev/ksk-2024. And if every lookup starts failing with SERVFAIL after the 11th, the trust anchor is the first place to look.
For most people, 11 October will be an ordinary Sunday.
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.