DNSSEC em linguagem simples

Módulo 8: Segurança e resolução de problemas · Tempo de leitura: 11 minutos

Objetivo de aprendizagem: Após esta lição, saberá explicar em linguagem simples o que o DNSSEC protege, como funciona a cadeia de confiança e porque pode correr mal numa transferência de domínio.

Conceitos-chave: DNSSEC, assinatura (RRSIG), chave (DNSKEY), registo DS, cadeia de confiança, resolver com validação, SERVFAIL

O problema: como sabe que uma resposta é verdadeira?

No módulo 1 viu que um resolver faz uma série de perguntas: à root, ao servidor de TLD e ao servidor de nomes autoritativo. A resposta que chega é aceite e colocada em cache. Mas o DNS normal não verifica se essa resposta vem mesmo do servidor de nomes correto. Um atacante que consiga enviar uma resposta falsa antes de a resposta verdadeira chegar pode fazer um resolver acreditar que example.com está em 203.0.113.66 em vez de em 192.0.2.10. Isto chama-se cache poisoning: a cache fica "envenenada" e todos os que usam esse resolver acabam no servidor errado.

O DNSSEC (DNS Security Extensions) resolve isto assinando as respostas. O resolver pode então verificar se uma resposta é verdadeira e se não foi alterada no caminho.

O que o DNSSEC faz e não faz

Isto é o mais importante a reter:

Uma assinatura funciona como um selo num envelope: todos podem ler a carta, mas vê-se logo se alguém a abriu.

Os três elementos

O DNSSEC acrescenta alguns tipos de registo. Não precisa de os criar você mesmo (isso é feito pelo seu gestor de DNS ou painel), mas vai encontrá-los:

• DNSKEY: a chave pública da zona. Com ela, qualquer pessoa pode verificar as assinaturas.
• RRSIG: a assinatura de um conjunto de registos. Cada resposta A, MX ou TXT recebe um RRSIG. Uma assinatura tem uma data de início e de fim: a zona tem de ser assinada novamente com regularidade.
• DS (Delegation Signer): uma "impressão digital" curta da chave da sua zona. Esta fica não na sua própria zona, mas no pai: para example.com fica na registry de .com (Verisign), para um domínio .nl fica na SIDN (a registry do .nl na Holanda).

É assim que se apresenta uma resposta assinada (resumida):

$ dig example.com A +dnssec +noall +answer
example.com.  3600  IN  A      192.0.2.10
example.com.  3600  IN  RRSIG  A 13 2 3600 20261119000000 20261029000000 30794 example.com. s7yJ5o...

No RRSIG vê, entre outras coisas, o algoritmo (13 = ECDSA P-256 com SHA-256), a data de fim (19 de novembro de 2026), a data de início e o número da chave (30794).

A cadeia de confiança

Porque está o DS no pai? Porque uma chave na sua própria zona não prova nada: um atacante também poderia enviar a sua própria chave. Por isso, a verificação decorre de cima para baixo:

1. O resolver confia na chave da root. Esta está incorporada em qualquer resolver com validação (a trust anchor).
2. A root tem um DS para .com, assinado com a chave da root. Com isto, o resolver sabe que chave o .com deve ter.
3. A zona .com tem um DS para example.com, assinado com a chave do .com.
4. A zona example.com tem um DNSKEY que corresponde a esse DS, e com isso todos os RRSIG podem ser verificados.

Cada elo prova o seguinte. Se um elo se partir, toda a cadeia deixa de ser fiável.

Um resolver com validação (a maioria dos grandes resolvers públicos, e cada vez mais fornecedores) percorre essa cadeia. Se estiver correta, recebe a resposta. Se não estiver correta, o resolver não dá resposta, mas sim o estado de erro SERVFAIL. Para o visitante, o site parece simplesmente "não existir", enquanto os seus registos podem estar perfeitamente corretos.

Pode ver isto você mesmo com um domínio que foi deliberadamente avariado:

$ dig dnssec-failed.org A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

Com +cd ("checking disabled") pede ao resolver para ignorar a verificação. Se mesmo assim obtiver uma resposta, sabe com certeza que o problema está no DNSSEC:

$ dig +cd dnssec-failed.org A @1.1.1.1 +short
96.99.227.255

Um domínio sem DNSSEC (sem DS no pai) não dá SERVFAIL: simplesmente não está assinado e é deixado passar como "não protegido".

Onde as coisas correm mal: transferências e trocas de chaves

O DNSSEC em si quase nunca falha. O problema surge quando o DS na registry deixa de corresponder à chave na zona. Isto acontece sobretudo:

• Numa transferência de servidores de nomes ou de fornecedor de DNS. O novo fornecedor assina com uma chave própria, mas na registry continua o DS do fornecedor antigo. Consequência: SERVFAIL para todos os que usam um resolver com validação. Este é o erro clássico após uma transferência.
• Numa troca de chaves em que o novo DS não foi enviado (a tempo) para a registry.
• Quando as assinaturas expiram, porque a zona deixou de ser assinada novamente.

A ordem segura numa transferência é, por isso:

1. Retirar o DS na registry (ou pedir ao novo fornecedor que forneça um DS que você acrescenta).
2. Esperar que a TTL do DS antigo expire.
3. Trocar os servidores de nomes.
4. Ativar o DNSSEC no novo fornecedor e colocar o novo DS na registry.

Muitos registrars e painéis tratam disto automaticamente hoje em dia, desde que o domínio e o DNS estejam no mesmo fornecedor. Se estiverem em fornecedores diferentes, tem de transferir o DS você mesmo.

Verificar você mesmo: DNSViz, Zonemaster e internet.nl

Não precisa de percorrer a cadeia com o dig. Existem ferramentas gratuitas que o fazem por si e mostram o resultado.

O DNSViz (https://dnsviz.net/) desenha toda a cadeia num esquema. É assim que se usa:

1. Escreva na página inicial o nome de domínio na caixa de pesquisa (apenas o nome, sem https:// e sem www) e clique em Go.
2. O DNSViz mostra a última análise. Se estiver desatualizada, ou se acabou de alterar algo, clique em Update now. Após alguns segundos verá o esquema.
3. Leia o esquema de cima para baixo: no topo a root (.), por baixo o TLD (por exemplo, nl), no fundo o seu domínio. Cada zona é um quadro.

O que vê no esquema:

Segue-se a cadeia assim: o DS (no pai) aponta para o DNSKEY (na sua zona), e esse DNSKEY coloca com um RRSIG a sua assinatura nos registos. É exatamente a cadeia desta lição, mas desenhada.

As cores indicam se está correto:

• Azul: seguro (secure). A cadeia decorre ininterruptamente da root até este elemento.
• Preto: não assinado (insecure). Não há DS, por isso não há nada para verificar. Não é um erro, o domínio simplesmente não usa DNSSEC.
• Vermelho: avariado (bogus). Um DS não corresponde a uma chave, ou uma assinatura está incorreta. Um resolver com validação dá então SERVFAIL.
• Roxo (numa assinatura): a assinatura expirou ou ainda não é válida. A zona deixou de ser assinada novamente.
• Amarelo: um aviso, por exemplo um servidor de nomes que não responde corretamente, ou um algoritmo que a ferramenta não reconhece.
• Cinzento e pontilhado: refere-se a uma chave que não existe. Se vir um DNSKEY pontilhado sob um DS, há na registry ainda um DS de uma chave antiga: o erro clássico após uma transferência.

Ao lado de um elemento pode aparecer um triângulo (aviso) ou um sinal de erro redondo. Passe o rato por cima, ou veja a lista por baixo do esquema: aí está explicado por palavras o que está errado.

Experimente com sidn.nl (tudo azul) e com dnssec-failed.org (vermelho, com uma chave pontilhada sob o DS).

Outras ferramentas que analisam o mesmo a partir de outro ângulo:

• Zonemaster (https://zonemaster.net/): verifica toda a sua zona como uma registry faria, incluindo o DNSSEC. O resultado é uma lista com verde (bom), laranja (aviso) e vermelho (erro).
• internet.nl (https://internet.nl/): o teste de website e de e-mail mostram, entre outras coisas, se o DNSSEC está correto para o seu domínio e para os seus servidores de e-mail, com vistos verdes ou cruzes vermelhas.
• Verisign DNSSEC Debugger (https://dnssec-debugger.verisignlabs.com/): percorre a cadeia passo a passo e coloca em cada passo um visto verde ou uma cruz vermelha. Útil se procura um erro concreto.

Use-as após cada alteração ao DNSSEC, e sobretudo antes e depois de uma transferência. Deixe a ferramenta analisar novamente com calma: também estas ferramentas trabalham com caches e TTL.

Na prática: assim aparece num painel

No O meu WebOké, ativa o DNSSEC num domínio em DNSSEC/DANE; o painel cria as chaves e envia o DS para a registry. No DirectAdmin e em fornecedores externos como o Cloudflare, chama-se geralmente "ativar DNSSEC"; o Cloudflare mostra-lhe então um registo DS que tem de introduzir você mesmo junto do seu registrar. Outros painéis funcionam de forma semelhante: há sempre um passo "criar chaves" (junto do fornecedor de DNS) e um passo "DS na registry" (junto do registrar).

Resumo

• O DNSSEC assina as respostas DNS para que um resolver possa verificar que são verdadeiras. Não encripta nada.
• O DNSKEY é a chave, o RRSIG a assinatura, o DS a impressão digital no pai.
• A verificação decorre como uma cadeia da root até ao seu domínio. Se um elo se partir, um resolver com validação dá SERVFAIL.
• Quase todos os problemas surgem porque o DS na registry deixou de corresponder, muitas vezes após uma transferência.
• Com dig +cd vê se um problema vem do DNSSEC.
• O DNSViz desenha a cadeia: azul é seguro, preto é não assinado, vermelho é avariado. O Zonemaster, o internet.nl e o Verisign DNSSEC Debugger são boas segundas opiniões.

Quiz

Exercício

Exercício Z8.1: Ver o DNSSEC. Descubra qual destes dois domínios tem o DNSSEC correto e qual foi deliberadamente avariado: sidn.nl e dnssec-failed.org. Consulte, para ambos, o registo DS e o registo A através de um resolver com validação (por exemplo 1.1.1.1 ou 9.9.9.9), com o dig ou uma ferramenta online. Preencha: o número da chave (key tag, o primeiro número) do DS de sidn.nl, e o estado que obtém para dnssec-failed.org.

Exercício Z8.1b: Ler o DNSViz. Analise nlnetlabs.nl no DNSViz (https://dnsviz.net/, escreva o nome e clique em Go; clique em Update now se a análise estiver desatualizada). Leia o esquema e preencha: (1) o estado de nlnetlabs.nl (seguro, não assinado ou avariado), (2) o número do algoritmo dos registos DNSKEY (está em cada oval como alg=), (3) quantos ovais DNSKEY existem na zona de nlnetlabs.nl, (4) o número da chave (id=) do DNSKEY preenchido a cinzento para onde o DS aponta, e (5) o estado que o DNSViz dá para dnssec-failed.org. A verificação consulta os mesmos dados em tempo real.

Exercício O8.1: Avaliar três zonas de demonstração de DNSSEC. Preparámos três zonas de demonstração: signed-demo.dnspractice.com (cadeia correta), broken-demo.dnspractice.com (deliberadamente avariada) e unsigned-demo.dnspractice.com (não assinada). Descubra, para cada zona, se está segura, avariada ou não assinada, por exemplo com o DNSViz ou com dig +dnssec (preste atenção à flag AD, e experimente também +cd em caso de SERVFAIL). Escolha abaixo a sua resposta para cada zona.

Para saber mais

Estes artigos descrevem os passos nos painéis do WebOké; noutros fornecedores os botões têm nomes diferentes.

• Manual do WebOké 5.8: DNSSEC e DANE
• O que é o DNSSEC?
• Ativar DNSSEC
• O seu site ou e-mail não funciona após uma migração ou alteração de DNS: verifique o seu domínio