O (Domain Name System Security Extensions, as extensões de segurança do DNS) assina os dados do DNS para que um resolver possa provar que a resposta não foi adulterada. Quando você consulta com +dnssec (que liga a flag do do ), os registros extras aparecem junto com os normais.

Os tipos de registro

  • RRSIG é a assinatura de um conjunto de registros do mesmo tipo (um RRset). O rdata, a parte de dados do registro, começa pelo tipo que a assinatura cobre, o número do algoritmo, a contagem de labels, o original, os horários de expiração e de início da validade da assinatura, o key tag e o nome de quem assinou; depois vem a assinatura propriamente dita. A janela de validade faz diferença na operação: um RRSIG expirado faz um resolver com validação devolver SERVFAIL, e assinaturas expiradas são uma causa comum daquele domínio que "de repente parou de resolver" para alguns usuários, mas não para outros.
  • é uma chave pública da zona. O validador usa essa chave para conferir os RRSIGs daquela zona. O rdata dela tem um campo de flags, um byte de protocolo (sempre 3), o algoritmo e o material da chave.
  • DS (Delegation Signer) é o elo entre a zona pai e a zona filha. É um hash da DNSKEY (DNS Public Key record, o registro da chave pública) da filha, publicado na zona pai. O rdata tem o key tag, o algoritmo, o tipo de digest e o digest. É esse o registro que você entrega ao seu registrar para ativar o DNSSEC numa delegação.
  • (Next Secure record) e fazem a negação de existência autenticada. Em vez de simplesmente dizer que o nome não existe, a zona assinada prova que ali há uma lacuna: o NSEC aponta para o próximo nome que existe, e o NSEC3 faz o mesmo com os nomes em hash, para dificultar a varredura da zona (zone walking). É assim que um NXDOMAIN ou um validado também se torna confiável.

A cadeia de confiança

A validação é uma cadeia que desce a partir da raiz. O resolver confia na chave da raiz, o único trust anchor (âncora de confiança) configurado, usa o DS que está na raiz para atestar a DNSKEY do (top-level domain, o domínio de topo), usa essa DNSKEY para validar o DS que o TLD publica para a zona seguinte, e assim por diante, até chegar ao nome que você consultou. Cada elo da cadeia é um DS na zona pai que bate com uma DNSKEY na zona filha, e cada RRset é coberto por um RRSIG. Basta uma quebra em qualquer ponto para romper a cadeia, e o resolver devolve SERVFAIL: um DS que falta numa delegação, um key rollover (a troca de chaves) que removeu a chave errada, uma assinatura expirada.

O que a flag ad significa de verdade

A flag ad (Authentic Data) no header (cabeçalho) é o veredito do resolver: quer dizer que aquele resolver, especificamente, validou a cadeia e ela se sustentou. Não é uma prova em que você possa confiar por conta própria, a não ser que confie no resolver e no caminho até ele, e não quer dizer que o cliente validou alguma coisa. Se você consultou com do ligado, recebeu dados reais e o ad não veio ligado, ou o resolver não validou, ou os dados não são assinados; quase sempre é essa diferença que vale a pena investigar.

A flag AD diz o que outra pessoa concluiu

O ad numa resposta significa que o resolver que você consultou validou a cadeia. Não traz uma assinatura que você possa conferir, nem significa que você validou alguma coisa.

Entre esse resolver e a sua aplicação existe um caminho que talvez você não controle. Uma resposta forjada com o bit ligado é idêntica a uma resposta validada para qualquer coisa que confie na flag sem validar; é por isso que o bit só tem valor num canal confiável até um resolver em que você confia.

Se a validação importa para você, valide: usar +dnssec e conferir o RRSIG você mesmo responde à sua pergunta. A flag AD responde à pergunta de outra pessoa.

Fontes