O DNSSEC (DNS Security Extensions) adiciona assinaturas digitais aos registros DNS para que os resolvedores possam verificar se uma resposta realmente veio do dono do domínio e não foi alterada no caminho. Ele não criptografa nada; comprova a autenticidade por meio de uma cadeia de confiança que começa na raiz do DNS.
O DNS comum não tem como distinguir uma resposta genuína de uma forjada. O DNSSEC, padronizado nas RFCs 4033, 4034 e 4035, fecha essa brecha. Este guia explica os tipos de registro envolvidos, como funciona a validação e os erros que mais derrubam domínios assinados.
O problema que o DNSSEC resolve
Um resolvedor recursivo aceita a primeira resposta que corresponde à sua pergunta. Um atacante que consiga injetar uma resposta forjada, estando no caminho da rede ou vencendo uma corrida contra o servidor verdadeiro em um ataque de envenenamento de cache, pode redirecionar os usuários desse resolvedor para um endereço IP à sua escolha. Todos que compartilham esse resolvedor recebem a resposta falsa até a entrada em cache expirar.
O DNSSEC torna a falsificação detectável. Cada conjunto de registros é assinado com a chave privada da zona, e a chave pública correspondente é publicada no DNS. Um resolvedor com validação confere a assinatura e rejeita tudo o que não for verificado. Se você quiser antes uma revisão sobre resolvedores e servidores autoritativos, leia o que é DNS e como ele funciona.
Tipos de registro do DNSSEC
| Registro | Fica em | Finalidade |
|---|---|---|
DNSKEY | A zona assinada | Chaves públicas usadas para verificar as assinaturas da zona |
RRSIG | A zona assinada | Uma assinatura sobre um conjunto de registros (por exemplo, todos os registros A de um nome), com horários de início e fim de validade |
DS | A zona pai | Delegation Signer: um hash da chave de assinatura de chaves da zona filha, que liga o pai ao filho |
NSEC | A zona assinada | Comprova que um nome ou tipo de registro não existe, informando o próximo nome existente em ordem alfabética |
NSEC3 | A zona assinada | Igual ao NSEC, mas com nomes em hash (RFC 5155), o que dificulta listar todos os nomes da zona |
CDS / CDNSKEY | A zona assinada | Indica ao pai qual registro DS ele deve publicar, permitindo atualizações automáticas (RFC 7344) |
Nosso guia sobre tipos de registro DNS cobre os registros comuns, como A, MX e TXT, que essas assinaturas protegem.
Por que é preciso provar a inexistência
Sem NSEC ou NSEC3, um atacante poderia forjar uma resposta NXDOMAIN ("este nome não existe"), que não pode carregar uma assinatura própria porque não há registro para assinar. Os registros NSEC dão ao resolvedor uma declaração assinada de que não existe nada entre dois nomes, de modo que uma negação também pode ser verificada.
Chaves de assinatura de chaves e chaves de assinatura de zona
A maioria das zonas usa dois tipos de chave, ambos publicados como registros DNSKEY:
- Chave de assinatura de zona (ZSK), DNSKEY com flags
256: assina os conjuntos de registros comuns da zona. Pode ser trocada com frequência sem envolver mais ninguém. - Chave de assinatura de chaves (KSK), DNSKEY com flags
257: assina apenas o conjunto de registros DNSKEY. O hash dela é o que vai no registro DS da zona pai, então trocá-la exige atualizar o registrador.
Separar as funções faz com que as trocas de rotina de chaves fiquem dentro do seu provedor de DNS, enquanto a troca mais rara da KSK é a única que mexe na zona pai. Algumas configurações usam, em vez disso, uma única chave de assinatura combinada, que é mais simples e comum com algoritmos modernos de curva elíptica, como o algoritmo 13 (ECDSA P-256 com SHA-256).
A cadeia de confiança
Uma assinatura só ajuda se o resolvedor confiar na chave que a produziu. O DNSSEC constrói essa confiança passo a passo a partir da raiz, que foi assinada em 2010. Os resolvedores com validação já vêm com a KSK da zona raiz como âncora de confiança embutida. Para validar www.example.com, um resolvedor:
- Usa a âncora de confiança da raiz para verificar o conjunto DNSKEY da raiz.
- Verifica o registro DS assinado de
comna zona raiz e confere se ele corresponde à KSK do conjunto DNSKEY decom. - Verifica o registro DS assinado de
example.comna zonacome confere se ele corresponde à KSK publicada porexample.com. - Usa o conjunto DNSKEY de
example.compara verificar o RRSIG dos registros A dewww.example.com.
Se todos os elos forem verificados, a resposta é segura (secure). Se o pai não tem registro DS para uma zona, a zona é insegura (insecure, sem assinatura) e a resposta é devolvida normalmente. Se existe um DS mas as assinaturas não são verificadas, a resposta é falsa (bogus).
Como é a validação: AD e SERVFAIL
Quando um resolvedor com validação verifica uma resposta com sucesso, ele ativa a flag AD (Authenticated Data) na resposta. Você pode vê-la com o dig:
$ dig +dnssec www.example.com A @1.1.1.1
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
www.example.com. 300 IN A 192.0.2.10
www.example.com. 300 IN RRSIG A 13 3 300 20261101000000 20261011000000 12345 example.com. (signature data)Quando a validação falha, o resolvedor não devolve os dados possivelmente forjados. Ele retorna SERVFAIL, que para os usuários parece igual a um site que não existe ou a uma queda do DNS. Para confirmar que o DNSSEC é a causa, repita a consulta com a verificação desativada:
dig www.example.com A # status: SERVFAIL
dig +cd www.example.com A # status: NOERROR, resposta devolvidaSe a consulta com +cd (checking disabled, verificação desativada) funciona e a normal falha, o DNSSEC da zona está quebrado. Nosso Verificador de DNSSEC faz essas checagens por você e mostra o status do DS, da DNSKEY e das assinaturas.
Por que o DNSSEC quebra: os erros mais comuns
Trocar de provedor de DNS sem remover o registro DS
Esta é a falha clássica. O registro DS no registro de domínios (registry) ainda aponta para a KSK do provedor antigo. Depois que os servidores de nomes mudam, o novo provedor serve a zona sem assinatura ou a assina com chaves diferentes. Os resolvedores com validação encontram um DS sem chave correspondente, marcam a zona como falsa (bogus) e toda consulta retorna SERVFAIL.
Uma migração segura é assim:
- No registrador, exclua o registro DS.
- Espere o DS antigo expirar nos caches: pelo menos o TTL do registro DS na zona pai, que você pode ver com
dig example.com DS. Esperar um ou dois dias é uma margem de segurança comum. - Troque os servidores de nomes para o novo provedor e espere os registros NS antigos expirarem.
- Ative o DNSSEC no novo provedor e publique o novo registro DS dele no registrador.
Alguns provedores oferecem uma configuração multi-signer que evita o intervalo sem assinatura, mas ela exige cooperação entre os dois provedores.
Assinaturas expiradas
Todo RRSIG tem um horário de expiração. Se o processo de assinatura parar, por exemplo em um servidor próprio cuja tarefa de reassinatura falhou, as assinaturas acabam expirando e a zona fica falsa (bogus).
Trocas de chave feitas rápido demais
Remover uma chave antiga antes de os caches pegarem a nova causa falhas nos resolvedores que ainda guardam o conjunto DNSKEY ou o registro DS antigo. As trocas de chave precisam respeitar os TTLs envolvidos.
Como ativar o DNSSEC no seu domínio
- Confira se o seu TLD oferece suporte a DNSSEC; a maioria dos genéricos e muitos TLDs de países oferecem.
- Ative a assinatura DNSSEC no seu provedor de hospedagem de DNS. Ele vai gerar as chaves e assinar a zona.
- Copie os dados do registro DS (key tag, algoritmo, tipo de digest e digest) para as configurações de DNSSEC do seu registrador. Se o provedor e o registrador são a mesma empresa, isso costuma ser automático, e alguns registries leem os registros CDS automaticamente.
- Verifique o resultado com nosso Verificador de DNSSEC e confirme que as consultas comuns continuam funcionando com a Consulta de DNS.
Perguntas frequentes
O DNSSEC criptografa minhas consultas DNS?
Não. O DNSSEC oferece autenticidade e integridade, não privacidade. As consultas e respostas continuam visíveis na rede. A criptografia vem do DNS sobre TLS ou do DNS sobre HTTPS, que complementam o DNSSEC.
Preciso de DNSSEC se meu site usa HTTPS?
Os certificados HTTPS já impedem que uma resposta DNS forjada se passe silenciosamente pelo seu site, mas o DNSSEC também protege o roteamento de e-mail, os registros TXT usados para verificação e outros registros. Ele também é necessário para o DANE, que publica informações de certificados TLS no DNS.
Por que meu domínio funciona em algumas redes e em outras não?
Se o DNSSEC está quebrado, só os resolvedores com validação retornam SERVFAIL; os sem validação continuam respondendo. Isso faz a queda parecer depender da rede.
Como desativar o DNSSEC com segurança?
Remova primeiro o registro DS no registrador, espere ele expirar nos caches e só então pare de assinar a zona. Fazer na ordem inversa causa uma queda.