Uma migração de servidores de nomes pode parecer bem-sucedida em todos os painéis de controlo e, ainda assim, deixar um site inacessível. O domínio está ativo, os novos servidores de nomes autoritativos devolvem o endereço esperado e o servidor web não foi alterado. No entanto, os resolvedores DNS que efetuam validação devolvem SERVFAIL. A causa está frequentemente numa delegação DNSSEC que ainda confia na chave de assinatura do fornecedor DNS anterior.
No incidente analisado, as consultas normais falhavam, enquanto as mesmas consultas eram bem-sucedidas quando a validação DNSSEC era ignorada. A zona superior continuava a publicar um registo DS antigo, mas a nova zona autoritativa não estava inicialmente assinada. A publicação de uma chave correspondente e a assinatura da nova zona restabeleceram as respostas validadas nos resolvedores testados. A principal lição não é que se deva desativar o DNSSEC, mas sim que alterar os servidores de nomes e migrar a cadeia de confiança do DNSSEC são operações distintas.
Por que razão registos A corretos podem continuar a provocar SERVFAIL
O DNS responde a duas perguntas diferentes. Um registo A indica a um resolvedor qual o endereço IPv4 associado a um nome. O DNSSEC permite que um resolvedor com validação determine se a resposta é fiável. A existência de dados de endereço corretos não implica automaticamente uma cadeia de confiança DNSSEC válida.
Num domínio assinado, a cadeia começa numa zona superior considerada fiável, passa por um registo DS (Delegation Signer) e chega a uma DNSKEY na zona filha. Esta publica assinaturas (registos RRSIG) sobre os seus dados DNS. O registo DS contém um resumo criptográfico que identifica uma DNSKEY autorizada; não é um registo A, uma cópia da chave privada nem uma opção de configuração num editor habitual de ficheiros de zona.
Após uma alteração dos servidores de nomes autoritativos, a zona superior pode continuar a publicar um registo DS associado à entidade que assinava a zona anteriormente. Se a nova zona não tiver a DNSKEY correspondente nem as assinaturas necessárias, um resolvedor com validação não consegue completar a cadeia de confiança. Normalmente, considera a resposta inválida e devolve SERVFAIL em vez de um endereço não verificado.
Esta situação é diferente de uma indisponibilidade HTTP. O pedido pode nem sequer chegar ao servidor web. Também é diferente de um certificado TLS expirado: o DNSSEC valida os dados DNS, enquanto o HTTPS protege uma ligação posterior entre o navegador e o servidor.
O teste que distingue um problema de DNSSEC de um registo inexistente
O teste mais revelador consiste em consultar duas vezes o mesmo nome através do mesmo resolvedor. Primeiro, faça uma consulta normal e examine o estado, não apenas a resposta:
dig example.com A +noall +comments +answerDepois, repita a consulta com o bit CD (Checking Disabled, desativação da verificação DNSSEC) ativado:
dig example.com A +cdflag +noall +comments +answerNa falha observada, a consulta normal devolvia SERVFAIL, enquanto a consulta com o bit CD devolvia o registo A esperado. Esta diferença apontava fortemente para um problema de validação DNSSEC, em vez de um registo DNS inexistente ou de uma aplicação que não respondia. A opção +cdflag solicita a um resolvedor recursivo compatível que não execute a validação DNSSEC habitual para esse pedido. É uma ferramenta de diagnóstico, não uma correção aplicável no navegador nem uma forma de desativar o DNSSEC para os visitantes.
Não retire conclusões precipitadas de uma resposta vazia obtida com +short. Tanto a ausência de uma resposta como um erro SERVFAIL podem aparecer como uma saída vazia nesse formato. Durante o diagnóstico, mantenha +comments para que estados como status: SERVFAIL e status: NOERROR continuem visíveis.
A comparação com o bit CD não identifica, por si só, qual a parte do DNSSEC que falhou; indica onde investigar a seguir. Um resolvedor também pode sofrer um erro transitório num servidor anterior da cadeia de resolução, pelo que convém repetir o teste quando necessário e inspecionar a delegação da zona superior.
Inspecione o registo DS da zona superior, não apenas o editor DNS
Verifique se existem registos DS para o domínio:
dig example.com DS +noall +comments +answerPara obter uma visão mais completa do percurso de delegação, consulte diretamente a hierarquia DNS:
dig +trace example.com DSO servidor de nomes autoritativo exato da zona superior depende do domínio de topo. O que importa é o conjunto de registos DS publicado pela zona superior, não apenas o resumo apresentado no painel de alojamento DNS. Uma transferência de registrador pode manter os servidores de nomes inalterados, e uma alteração dos servidores de nomes pode ocorrer sem mudar de registrador. Em qualquer dos casos, os registos DS da zona superior devem permanecer compatíveis com a zona autoritativa ativa.
Um registo DS contém quatro campos relevantes: identificador da chave, algoritmo, tipo de resumo criptográfico e resumo criptográfico. O identificador da chave é uma referência útil para o diagnóstico, mas não prova, por si só, que uma DNSKEY corresponda ao registo. As informações do resumo e do algoritmo também têm de corresponder a uma chave efetivamente disponibilizada pela zona autoritativa.
O estado decisivo neste caso era simples: a zona superior continuava a anunciar a informação de confiança DNSSEC anterior, enquanto a nova zona autoritativa indicava que a assinatura estava desativada. Os registos A existiam e podiam ser obtidos quando a validação era ignorada. Alterar a configuração da aplicação ou editar repetidamente o mesmo registo A não corrigiria essa incompatibilidade.
Duas formas de restaurar uma delegação DNSSEC incorreta
Existem duas estratégias legítimas de recuperação. Ambas resolvem a mesma incompatibilidade na cadeia de confiança, mas têm consequências operacionais diferentes. Escolha uma de forma deliberada e evite alternar entre elas sem um critério definido.
Opção 1: remover o DS obsoleto e manter temporariamente a zona sem assinatura
Solicite ao registrador atual, ou utilize a respetiva interface de gestão DNSSEC compatível, a remoção do registo DS obsoleto da zona superior. Quando esta deixa de declarar uma delegação segura, os resolvedores com validação podem tratar uma zona filha sem assinatura como insegura, em vez de inválida. O DNS continua a funcionar, mas a autenticação DNSSEC do domínio fica temporariamente indisponível.
Esta é frequentemente a opção de emergência mais simples, desde que exista uma forma fiável de alterar o conjunto de registos DS da zona superior. Mantenha estável a configuração de assinatura existente até que o DS antigo expire nas caches dos resolvedores recursivos. Remover o DS num painel de controlo não constitui, por si só, prova suficiente: verifique externamente o registo da zona superior e tenha em conta o seu TTL. O HTTPS continua independente da configuração DNSSEC. A transição temporária para uma zona sem assinatura também está descrita na RFC 8078.
Opção 2: assinar a nova zona e publicar um DS correspondente
A alternativa consiste em ativar o DNSSEC no novo fornecedor de DNS autoritativo, gerar o material criptográfico DNSKEY, assinar a zona e publicar o registo DS correspondente na zona superior. Um resolvedor com validação pode então estabelecer um percurso de confiança até à nova DNSKEY e validar o registo A.
Esta foi a estratégia de recuperação efetivamente observada. A interface de gestão DNS indicou que tinha gerado chaves, assinado a zona e publicado um novo DS. Posteriormente, uma consulta à zona superior mostrou o novo DS juntamente com o anterior. As consultas recursivas com validação começaram a devolver o registo A esperado; um teste posterior também devolveu NOERROR com o indicador ad ativo, indicando que aquele resolvedor tinha autenticado os dados.
A ordem é importante: um DS publicado só é útil se a DNSKEY correspondente e as assinaturas válidas já estiverem disponíveis no serviço DNS autoritativo. A indicação «publicado» num painel de controlo não substitui uma verificação externa. Os registos DS, DNSKEY, RRSIG e NS armazenados em cache podem fazer com que diferentes resolvedores recuperem em momentos distintos.
Por que razão dois registos DS não mantinham necessariamente o site inacessível
Um resultado surpreendente foi que a zona superior continha temporariamente um DS obsoleto e outro novo e válido, mas a validação DNSSEC era bem-sucedida. Não há contradição. Um conjunto de registos DS pode conter vários registos, como acontece frequentemente durante transições de chaves. Um validador não exige que todos os registos DS identifiquem uma chave ainda utilizável; precisa de um percurso de autenticação válido através de um DS aplicável até uma DNSKEY e assinaturas válidas. A RFC 6840 esclarece que os validadores devem aceitar um único percurso válido.
Isso não significa que seja desejável manter chaves obsoletas indefinidamente. Um DS antigo aumenta a ambiguidade operacional e deverá ser removido quando a nova cadeia de confiança estiver verificada. No entanto, essa limpeza é uma tarefa de manutenção, não uma justificação para executar outra reposição arriscada do DNSSEC enquanto as consultas validadas já estão a funcionar.
Existe aqui uma armadilha particularmente perigosa nos painéis de controlo: uma ação denominada «cancelar a publicação de DS em emergência» pode significar remover todos os registos DS, incluindo o novo que está a funcionar. Da mesma forma, desativar a assinatura da zona enquanto um DS continua publicado pode reproduzir imediatamente a indisponibilidade. Nenhuma destas ações equivale a eliminar um único registo DS obsoleto. Se a interface não permitir selecionar um registo específico, utilize um procedimento de alteração seletiva suportado pelo registrador, em vez de uma reposição geral.
Como alterar os servidores de nomes autoritativos em segurança
A sequência mais segura depende da possibilidade de os fornecedores DNS antigo e novo coordenarem as chaves. Numa migração convencional que utilize um intervalo temporário sem assinatura, a seguinte ordem evita a incompatibilidade observada neste incidente:
- Prepare primeiro a zona de destino. Copie os registos A, AAAA, CNAME, MX, TXT e quaisquer outros necessários. Teste diretamente os novos servidores de nomes autoritativos antes de alterar a delegação.
- Inspecione o DNSSEC na zona superior. Verifique se existem registos DS e identifique quem os pode atualizar. Faça isto mesmo que nunca tenha ativado o DNSSEC manualmente, pois alguns serviços DNS automatizam a assinatura.
- Remova o DS antigo enquanto a zona anterior assinada ainda está em funcionamento. Confirme a alteração na zona superior autoritativa e aguarde o tempo suficiente para que os dados DS anteriormente armazenados em cache expirem. O tempo de espera depende dos TTL observados, não de um número fixo e universal de minutos.
- Altere a delegação dos servidores de nomes. Mantenha disponível o serviço autoritativo anterior enquanto as delegações NS em cache ainda puderem apontar para ele. Considere os TTL dos registos NS da zona superior e verifique quais os servidores que os diferentes resolvedores estão efetivamente a utilizar.
- Decida se pretende reativar o DNSSEC. Se o novo serviço tiver de permanecer sem assinatura, não publique um DS. Se tiver de ser assinado, verifique se a nova DNSKEY e as assinaturas estão a ser disponibilizadas corretamente antes de publicar o DS correspondente. Coordene este passo com as caches que ainda possam conter os servidores NS antigos para evitar uma nova incompatibilidade de validação.
- Valide de forma independente. Verifique o DS da zona superior, a DNSKEY autoritativa, a resolução recursiva normal e o resultado de autenticação dos resolvedores com validação.
Se for necessário manter a proteção DNSSEC continuamente, é preferível uma rotação de chaves explicitamente coordenada ou uma transição com vários signatários, em vez de um intervalo sem assinatura. Isso exige que ambos os fornecedores DNS suportem a configuração necessária de chaves e assinaturas; copiar simplesmente o resumo do DS antigo para um novo fornecedor não constitui uma rotação de chaves.
Lista breve de verificações após a migração
Após qualquer alteração relacionada com o DNSSEC, verifique tanto os registos DNS como a prova de que os resolvedores os aceitam:
dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answerUtilize um resolvedor recursivo com validação para verificar as respostas autenticadas. Na resposta, NOERROR juntamente com o registo A esperado significa que a resolução foi bem-sucedida; a presença adicional do indicador ad assinala que o resolvedor autenticou a resposta de acordo com a sua política DNSSEC. A ausência do indicador ad não prova, por si só, a existência de uma falha, porque as capacidades, políticas e indicadores de consulta dos resolvedores podem variar. Se as consultas DNSKEY falharem através de um resolvedor com validação durante uma indisponibilidade, consulte diretamente o serviço DNS autoritativo ativo como parte da investigação.
Não termine a verificação depois de obter uma única resposta correta de um resolvedor. Durante algum tempo, diferentes caches podem conter delegações e chaves distintas. Atualize também qualquer pedido de assistência técnica que continue aberto: uma instrução anterior para remover todos os registos DS torna-se perigosa depois de ter sido publicado um novo DS funcional. A comunicação de acompanhamento deve indicar explicitamente que a chave ativa deve ser preservada e, se necessário, solicitar a remoção apenas do registo obsoleto.
A falha não foi causada por um endereço incorreto do servidor web. Resultou da alteração do local onde as respostas DNS eram disponibilizadas sem primeiro alinhar a informação de confiança que indicava aos resolvedores quais as respostas em que deviam confiar. Por isso, a pergunta fundamental antes de qualquer alteração da delegação dos servidores de nomes é: Que registos DS publica a zona superior e serão as DNSKEY e assinaturas do serviço de destino capazes de os satisfazer?