Verificação de DNSSEC

A brecha que o DNSSEC fecha

Quando o seu computador pergunta “qual é o endereço de example.com?”, a resposta volta num pequeno pacote sem proteção. O DNS original não dá a quem recebe nenhum meio de verificar quem a escreveu. Alguém posicionado entre você e o servidor de nomes, ou alguém que injeta uma resposta falsa na memória de um resolvedor, pode mandar visitantes e e-mails para uma máquina de sua escolha.

O DNSSEC acrescenta assinaturas. O dono de uma zona assina cada conjunto de registros com uma chave privada e publica a chave pública correspondente na zona, num registro DNSKEY. Um resolvedor que recebe uma resposta também recebe a assinatura dela (RRSIG) e pode verificar se os registros são exatamente os que o dono publicou. O DNSSEC não criptografa nada e não esconde quais nomes você consulta. A única coisa que ele faz é provar que uma resposta é autêntica.

Uma cadeia de impressões digitais

Uma chave pública guardada no mesmo lugar que os dados não prova muita coisa, já que um falsificador poderia trocar as duas. Por isso cada zona pede à zona de cima que responda por ela. A zona pai publica um registro DS, uma impressão digital curta (digest) da chave da zona filha, e assina esse registro com a própria chave. A chave da zona pai é garantida da mesma forma pela zona acima dela, e assim por diante até a zona raiz. A chave raiz é a única coisa que um resolvedor precisa conhecer de antemão, e ela vem junto com o software do resolvedor.

Para example.com o caminho é este: chave raiz, DS de com na raiz, chaves de com, DS de example.com em com, chaves de example.com, registros assinados. Um elo faltando ou errado e a prova falha.

O registro DS é a parte que fica fora do seu provedor de DNS. Ele é entregue ao registro por meio do seu registrador, e a maioria das falhas vem dessa divisão.

O que esta verificação faz

Para a raiz, para a zona de primeiro nível e para cada zona até o seu domínio, nosso servidor lê os registros DS na zona pai e os registros DNSKEY da zona. Ele os lê por resolvedores públicos com a validação desligada (a flag “checking disabled”), para conseguir inspecionar mesmo uma zona quebrada. Para cada chave ele calcula o key tag, e para cada DS recalcula o digest a partir da chave com a mesma função de hash (RFC 4034) e compara os dois byte a byte.

Depois ele pede o registro SOA do domínio a três resolvedores públicos que validam (Cloudflare, Google e Quad9), desta vez com a validação ligada. Um resolvedor que validou a resposta marca a flag AD (“authenticated data”). Um que encontrou um defeito responde SERVFAIL. Nosso servidor confere as impressões digitais por conta própria, mas não verifica as assinaturas. Esse veredito cabe aos resolvedores.

A verificação também aponta algoritmos aposentados ou fracos (RSA/MD5, DSA, RSA/SHA-1, digests SHA-1 num DS), um DS que sobrou de uma chave antiga, assinaturas a menos de três dias do vencimento, e se a zona usa NSEC ou NSEC3 para provar que um nome não existe.

Consertando uma cadeia quebrada

Uma cadeia quebrada é pior do que nenhum DNSSEC, porque os resolvedores que validam se recusam a responder. Geralmente acontece assim: o domínio mudou para um novo provedor de DNS, o registro DS antigo ficou no registrador e agora aponta para uma chave que não existe mais.

1. Para voltar ao ar rápido, apague o registro DS no registrador. O domínio passa a não ser assinado e funciona para todos assim que os caches expirarem, normalmente em um dia.
2. Para manter o DNSSEC, abra a página de DNSSEC do seu provedor de DNS atual, copie o registro DS que ela mostra (key tag, algoritmo, tipo de digest, digest) e cadastre-o no registrador no lugar do antigo.
3. Antes da próxima mudança, remova primeiro o registro DS, espere um dia, troque os servidores de nomes, depois assine e publique o novo DS.

Para “configurado pela metade”, termine o trabalho publicando o registro DS ou desligue a assinatura no provedor de DNS.