DNS – Registros NS glue e NS autoritativos
2 de março de 2023
Por Carlos Martínez – CTO do LACNIC
Contexto do problema
Um cliente nos relata que, após uma modificação em suas configurações de DNS, uma de suas zonas reversas não pode mais ser resolvida pelos clientes DNS na Internet.
Para ilustrar o problema, usaremos um exemplo de zona DNS, a correspondente ao prefixo da documentação do IPv6, o 2001:db8::/32.
(Acesso livre, não requer assinatura)
Se usarmos a convenção usual para resolução reversa para a zona DNS correspondente é a “8.b.d.0.1.0.0.2.ip6.arpa”.
Delegação de zonas
A delegação de zonas é o processo pelo qual uma zona “pai” transfere a responsabilidade de resolver uma parte do espaço de nomes que ela abrange para um servidor “filho”.
Se usarmos a convenção usual para resolução reversa para a zona DNS correspondente é a “8.b.d.0.1.0.0.2.ip6.arpa”.
Delegação de zonas
A delegação de zonas é o processo pelo qual uma zona “pai” transfere a responsabilidade de resolver uma parte do espaço de nomes que ela abrange para um servidor “filho”.
A maneira de fazer isso é criar um conjunto de registros na zona pai chamados “registros de delegação” que servem como indicadores de que essa delegação está ocorrendo. Esses registros de delegação devem conter pelo menos um registro do tipo NS (nameserver) e podem incluir adicionalmente registros do tipo A ou AAAA caso o nome indicado no registro NS não seja resolvível por meio de outras zonas.
Quando um servidor recursivo recebe um pedido para resolver um nome, ele inicia um processo de consultas onde inicialmente consulta a raiz do DNS e de alguma forma “procura” as delegações até obter uma resposta autoritativa ou encontrar um status de erro.
Essa busca de delegações ocorre consultando os registros NS, primeiro às zonas “pai” e depois às mesmas zonas “filho”. Os registros NS nas zonas pai, aqueles que correspondem aos “registros de delegação” não são autoritativos e apenas são usados como uma “dica” para chegar aos verdadeiros NS, os autoritativos.
Diagnóstico do problema
A forma que eu prefiro identificar as causas desse tipo de problemas é usar ferramentas como dig ou drill desde um terminal, tentando seguir manualmente os passos que um servidor recursivo percorre ao tentar obter uma resposta.
Suponha que a zona “pai” daquela que apresenta problemas seja a 1.0.0.2.ip6.arpa e que os servidores autoritativos para ela são ns1.rir.la e ns2.rir.la.
Consultamos pelos “delegation records” da zona com problemas, para o que perguntamos à zona pai pelos registos NS da zona filho com problemas:
$ dig @ns1.rir.la NS 8.b.d.0.1.0.0.2.ip6.arpa
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10148
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 5
;; ANSWER SECTION:
8.b.d.0.1.0.0.2.ip6.arpa. 86400 IN NS NS1.emp1.com.
8.b.d.0.1.0.0.2.ip6.arpa. 86400 IN NS NS2.emp1.com.
Vemos que não temos registros na seção “AUTHORITY” da resposta, o que é o comportamento esperado, uma vez que os registros NS da zona pai não são autoritativos; no entanto, obtemos uma resposta na seção “ANSWER”.
O passo seguinte é usar essas informações para consultar pelos mesmos registros NS, mas aos servidores que supomos serem autoritativos para essa zona.
$ dig @ns1.emp1.com. NS 8.b.d.0.1.0.0.2.ip6.arpa
;; AUTHORITY SECTION:
8.b.d.0.1.0.0.2.ip6.arpa. 86400 IN NS servA.emp1.com.
8.b.d.0.1.0.0.2.ip6.arpa. 86400 IN NS servB.emp1.com.
Aqui começam os problemas. Os registros na zona pai não correspondem aos registros na zona filho.
Ainda temos mais:
$ dig @servA.emp1.com NS 8.b.d.0.1.0.0.2.ip6.arpa
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23423
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
Além do fato de que os servidores NS listados como autoritativos na zona são diferentes daqueles listados na zona pai, o servidor supostamente autoritativo não está configurado para resolver a zona para a qual é supostamente autoritativo.
Por esse motivo, a resolução de qualquer nome que passe pela zona “8.b.d.0.1.0.0.2.ip6.arpa” nunca poderá ser concluída com sucesso, apesar do fato de que os servidores listados nos registros de delegação conhecem a zona em questão.
A Figura 2 ilustra esta situação.
Esse problema pode ser insidioso de diagnosticar, uma vez que fazendo uma consulta com dig sem cuidados especiais, perguntando pelo SOA da zona (um dos registros mais usados para testar porque está sempre presente) é possível que o dig nos devolva uma resposta, mas qualquer consulta subsequente vai falhar.
Sem ter mais informações sobre qual era a mudança de configuração que se queria alcançar, fica difícil indicar qual é a solução ideal.
No entanto, algumas coisas podem ser apontadas:
- Os registros NS listados na zona pai e na zona filho devem coincidir
- Depois, ou devemos configurar a zona com problemas nos servidores “servA” e “servB” ou os NS autoritativos listados na própria zona devem se tornar ns1 e ns2.emp1.com.
Comentários finais
É importante entender corretamente o mecanismo pelo qual um servidor de nomes percorre uma delegação de zona. Devemos levar em conta o processo pelo qual os registros NS encontrados na zona pai são “verificados” na zona filho.
O erro de configuração que encontramos nessas zonas reversas não é exclusivo da árvore reversa do DNS, nem é exclusivo dos registros reversos para o IPv6. Esse mesmo erro pode ser cometido em áreas diretas do estilo “empresa.com.tld”.
É fundamental também saber aproveitar ao máximo ferramentas como o dig ou drill. Existem também algumas ferramentas gráficas que podem ser úteis como DnsViz e ZoneMaster.
As opiniões expressas pelos autores deste blog são próprias e não refletem necessariamente as opiniões de LACNIC.