{"id":20081,"date":"2023-03-02T18:07:22","date_gmt":"2023-03-02T18:07:22","guid":{"rendered":"https:\/\/news.lacnic.net\/?p=20081"},"modified":"2023-03-21T13:35:09","modified_gmt":"2023-03-21T13:35:09","slug":"dns-registros-ns-glue-e-ns-autoritativos","status":"publish","type":"post","link":"https:\/\/blog.lacnic.net\/pt-br\/dns-registros-ns-glue-e-ns-autoritativos\/","title":{"rendered":"DNS – Registros NS glue e NS autoritativos"},"content":{"rendered":"\n

Por Carlos Mart\u00ednez<\/a> – CTO do LACNIC<\/p>\n\n\n\n

Contexto do problema<\/strong><\/strong><\/p>\n\n\n\n

Um cliente nos relata que, ap\u00f3s uma modifica\u00e7\u00e3o em suas configura\u00e7\u00f5es de DNS, uma de suas zonas reversas n\u00e3o pode mais ser resolvida pelos clientes DNS na Internet.<\/p>\n\n\n\n

Para ilustrar o problema, usaremos um exemplo de zona DNS, a correspondente ao prefixo da documenta\u00e7\u00e3o do IPv6, o 2001:db8::\/32<\/strong>.<\/p>\n\n\n\n

Se usarmos a conven\u00e7\u00e3o usual para resolu\u00e7\u00e3o reversa para a zona DNS correspondente \u00e9 a \u201c8.b.d.0.1.0.0.2.ip6.arpa<\/strong>\u201d.<\/p>\n\n\n\n

Delega\u00e7\u00e3o de zonas<\/strong><\/strong><\/p>\n\n\n\n

A delega\u00e7\u00e3o de zonas \u00e9 o processo pelo qual uma zona \u201cpai\u201d transfere a responsabilidade de resolver uma parte do espa\u00e7o de nomes que ela abrange para um servidor \u201cfilho\u201d.<\/p>\n\n\n\n

A maneira de fazer isso \u00e9 criar um conjunto de registros na zona pai chamados \u201cregistros de delega\u00e7\u00e3o\u201d que servem como indicadores de que essa delega\u00e7\u00e3o est\u00e1 ocorrendo. Esses registros de delega\u00e7\u00e3o devem conter pelo menos um registro do tipo NS<\/em> (nameserver) e podem incluir adicionalmente registros do tipo A<\/em> ou AAAA<\/em> caso o nome indicado no registro NS n\u00e3o seja resolv\u00edvel por meio de outras zonas.<\/p>\n\n\n\n

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\u00e7\u00f5es at\u00e9 obter uma resposta autoritativa<\/em> ou encontrar um status de erro.<\/p>\n\n\n\n

Essa busca de delega\u00e7\u00f5es ocorre consultando os registros NS, primeiro \u00e0s zonas \u201cpai\u201d e depois \u00e0s mesmas zonas \u201cfilho\u201d. Os registros NS nas zonas pai, aqueles que correspondem aos \u201cregistros de delega\u00e7\u00e3o\u201d n\u00e3o s\u00e3o autoritativos<\/strong> e apenas s\u00e3o usados como uma \u201cdica\u201d para chegar aos verdadeiros NS, os autoritativos<\/strong>.<\/p>\n\n\n\n

\"\"
Fig. 1 \u2014 Exemplo de uma delega\u00e7\u00e3o correta. Os registros NS \u201cglue\u201d n\u00e3o autoritativos e os registros NS autoritativos coincidem, e os servidores respondem corretamente.<\/figcaption><\/figure>\n\n\n\n

Diagn\u00f3stico do problema<\/strong><\/strong><\/p>\n\n\n\n

A forma que eu prefiro identificar as causas desse tipo de problemas \u00e9 usar ferramentas como dig<\/strong> ou drill<\/strong> desde um terminal, tentando seguir manualmente os passos que um servidor recursivo percorre ao tentar obter uma resposta.<\/p>\n\n\n\n

Suponha que a zona \u201cpai\u201d daquela que apresenta problemas seja a 1.0.0.2.ip6.arpa<\/a> e que os servidores autoritativos para ela s\u00e3o ns1.rir.la<\/a> e ns2.rir.la<\/a>.<\/p>\n\n\n\n

Consultamos pelos “delegation records” da zona com problemas, para o que perguntamos \u00e0 zona pai pelos registos NS da zona filho com problemas:<\/p>\n\n\n\n

 $ dig @ns1.rir.la NS 8.b.d.0.1.0.0.2.ip6.arpa\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10148\n;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 5\n;; ANSWER SECTION:\n8.b.d.0.1.0.0.2.ip6.arpa. 86400\tIN\tNS\tNS1.emp1.com.\n8.b.d.0.1.0.0.2.ip6.arpa. 86400\tIN\tNS\tNS2.emp1.com.\n\n<\/code><\/pre>\n\n\n\n
Vemos que n\u00e3o temos registros na se\u00e7\u00e3o \u201cAUTHORITY\u201d da resposta, o que \u00e9 o comportamento esperado, uma vez que os registros NS da zona pai n\u00e3o s\u00e3o autoritativos; no entanto, obtemos uma resposta na se\u00e7\u00e3o \u201cANSWER\u201d.<\/p>\n\n\n\n
O passo seguinte \u00e9 usar essas informa\u00e7\u00f5es para consultar pelos mesmos registros NS, mas<\/strong> aos servidores que supomos serem autoritativos<\/strong> para essa zona.<\/p>\n\n\n\n
 $ dig @ns1.emp1.com. NS 8.b.d.0.1.0.0.2.ip6.arpa\n;; AUTHORITY SECTION:\n8.b.d.0.1.0.0.2.ip6.arpa. 86400\tIN\tNS\tservA.emp1.com.\n8.b.d.0.1.0.0.2.ip6.arpa. 86400\tIN\tNS\tservB.emp1.com.\n\n<\/code><\/pre>\n\n\n\n
Aqui come\u00e7am os problemas. Os registros na zona pai n\u00e3o correspondem aos registros na zona filho.<\/p>\n\n\n\n
Ainda temos mais:<\/p>\n\n\n\n
$ dig @servA.emp1.com NS 8.b.d.0.1.0.0.2.ip6.arpa\n;; Got answer:\n;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23423\n;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1\n;; WARNING: recursion requested but not available\n<\/code><\/pre>\n\n\n\n
Al\u00e9m do fato de que os servidores NS listados como autoritativos na zona s\u00e3o diferentes daqueles listados na zona pai, o servidor supostamente autoritativo n\u00e3o est\u00e1 configurado para resolver a zona para a qual \u00e9 supostamente autoritativo.<\/strong><\/p>\n\n\n\n
Por esse motivo, a resolu\u00e7\u00e3o de qualquer nome que passe pela zona “8.b.d.0.1.0.0.2.ip6.arpa<\/strong>” nunca poder\u00e1 ser conclu\u00edda com sucesso, apesar do<\/strong> fato de que os servidores listados nos registros de delega\u00e7\u00e3o conhecem a zona em quest\u00e3o.<\/p>\n\n\n\n
A Figura 2 ilustra esta situa\u00e7\u00e3o.<\/p>\n\n\n\n
\"\"
Fig. 2: Aparece a delega\u00e7\u00e3o \u201cquebrada\u201d, pois na primeira consulta o resolvedor obt\u00e9m registros NS autoritativos que apontam para um servidor que realmente n\u00e3o pode responder pela zona.<\/figcaption><\/figure>\n\n\n\n
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 \u200b\u200bpara testar porque est\u00e1 sempre presente) \u00e9 poss\u00edvel que o dig nos devolva uma resposta, mas qualquer consulta subsequente vai falhar.<\/p>\n\n\n\n
<\/a>Solu\u00e7\u00f5es poss\u00edveis<\/strong><\/strong><\/p>\n\n\n\n
Sem ter mais informa\u00e7\u00f5es sobre qual era a mudan\u00e7a de configura\u00e7\u00e3o que se queria alcan\u00e7ar, fica dif\u00edcil indicar qual \u00e9 a solu\u00e7\u00e3o ideal.<\/p>\n\n\n\n
No entanto, algumas coisas podem ser apontadas:<\/p>\n\n\n\n