Un asociado de LACNIC nos reporta que, luego de una modificación en sus configuraciones de DNS, una de sus zonas reversas ha dejado de ser resoluble por los clientes DNS en Internet.
Para ilustrar el problema utilizaremos una zona DNS reversa como ejemplo, la correspondiente al prefijo de documentación de IPv6, el 2001:db8::/32.
Utilizando la convención usual dada por la RFC 3596 para resolución reversa, la zona DNS correspondiente al prefijo de documentación de IPv6 es la “8.b.d.0.1.0.0.2.ip6.arpa”. El nombre de la zona se obtiene anotando los nibbles de la dirección IPv6 en orden inverso al que aparecen en el prefijo y agregando la zona base ip6.arpa.
Delegación de zonas
La delegación de zonas es el proceso por el cual una zona “padre” transfiere o delega la responsabilidad por la resolución de una porción del espacio de nombres que esta abarca a otra entidad. Por ejemplo, la zona “.net” delega la zona “.lacnic.net” a los servidores DNS de LACNIC. De esta forma, las consultas por cualquier nombre que termine en “.lacnic.net” (www.lacnic.net, mail.lacnic.net, etc.) son dirigidas a los servidores DNS de LACNIC y no a los de la zona “.net”.
(Acceso libre, no requiere suscripción)
La forma de indicar una delegación consiste en crear un conjunto de registros en la zona padre llamados “registros de delegación”, que sirven como indicadores de que esta delegación está ocurriendo. Estos registros de delegación deben contener al menos un registro de tipo NS (nameserver) y, adicionalmente, pueden incluir registros de tipo A o AAAA en caso de que el nombre indicado en el registro NS no sea resoluble a través de otras zonas.
Cuando un servidor recursivo recibe un pedido para resolver un nombre, comienza un proceso de consultas donde inicialmente consulta a la raíz del DNS, y de alguna forma “busca” las delegaciones hasta llegar a obtener una respuesta autoritativa o encontrar un estado de error.
Esta búsqueda de delegaciones ocurre a través de la consulta de los registros NS, primero a las zonas “padre” y luego a las mismas zonas hijas. Los registros NS en las zonas padre- los que corresponden a los “registros de delegación”-, no son autoritativos y son únicamente utilizados como una “pista” para llegar a los verdaderos NS, los autoritativos.
La forma de indicar una delegación consiste en crear un conjunto de registros en la zona padre llamados “registros de delegación”, que sirven como indicadores de que esta delegación está ocurriendo. Estos registros de delegación deben contener al menos un registro de tipo NS (nameserver) y, adicionalmente, pueden incluir registros de tipo A o AAAA en caso de que el nombre indicado en el registro NS no sea resoluble a través de otras zonas.
Cuando un servidor recursivo recibe un pedido para resolver un nombre, comienza un proceso de consultas donde inicialmente consulta a la raíz del DNS, y de alguna forma “busca” las delegaciones hasta llegar a obtener una respuesta autoritativa o encontrar un estado de error.
Esta búsqueda de delegaciones ocurre a través de la consulta de los registros NS, primero a las zonas “padre” y luego a las mismas zonas hijas. Los registros NS en las zonas padre- los que corresponden a los “registros de delegación”-, no son autoritativos y son únicamente utilizados como una “pista” para llegar a los verdaderos NS, los autoritativos.
Fig. 1 — Ejemplo de una delegación correcta. Los registros NS “glue” no autoritarios y los registros NS autoritativos coinciden y los servidores responden correctamente.
Diagnóstico del problema
La forma que prefiero para identificar las causas de este tipo de problemas es utilizar herramientas como dig o drill desde una terminal, tratando de seguir de forma manual los pasos que sigue un servidor recursivo al intentar obtener una respuesta.
Supongamos que la zona “padre” de la que presenta problemas es la 1.0.0.2.ip6.arpa y que los servidores autoritativos para ella son ns1.rir.la y ns2.rir.la.
Consultamos por los “delegation records” de la zona con problemas, para lo cual le preguntamos por los registros NS de la zona hija con problemas a la zona padre:
$ 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 no tenemos registros en la sección “AUTHORITY” de la respuesta, lo cual es el comportamiento esperado ya que los registros NS de la zona padre no son autoritativos. Sin embargo, sí obtenemos una respuesta en el “ANSWER” section.
El siguiente paso es utilizar esta información para consultar por los mismos registros NS pero a los servidores que suponemos deben ser autoritativos para esta 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.
Aquí comienzan los problemas. Los registros en la zona padre no coinciden con los registros en la zona hija.
Pero hay más:
$ 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
Además de que los servidores NS listados como autoritativos en la zona son diferentes de los listados en la zona padre, el servidor supuestamente autoritario no está configurado para resolver la zona para la que supuestamente es autoritativo.
Por esta razón, la resolución de cualquier nombre paso la zona “8.b.d.0.1.0.0.2.ip6.arpa” nunca podrá concluir exitosamente a pesar de que los servidores listados en los delegation records si conocen a la zona en cuestión.
En la figura 2 vemos ilustrada esta situación.
Fig. 2 : Se ve la delegación “quebrada”, ya que en la primera consulta quien resuelve obtiene registros NS autoritativos que apuntan a un servidor que en realidad no puede responder por la zona.
Este problema puede ser insidioso de diagnosticar, ya que haciendo una consulta con dig sin especial cuidado, preguntando por el SOA de la zona (una de los registros más comúnmente utilizados para probar porque siempre está presente) es posible que dig nos devuelva una respuesta, pero cualquier consulta posterior va a fallar.
Posibles soluciones
Sin contar con más información acerca de cuál era el cambio de configuración que se quería lograr es difícil indicar cuál es la solución ideal.
Sin embargo, algunas cosas se pueden indicar:
Los registros NS listados en la zona padre y en la zona hija deben coincidir
Luego, o bien debemos configurar la zona con problemas en los servidores “servA” y “servB” o bien los NS autoritativos listados en la propia zona deben pasar a ser ns1 y ns2.emp1.com.
Comentarios finales
Es importante entender bien el mecanismo por el cual un servidor de nombres recorre una delegación de zonas. Debemos tener presente el proceso por el cual los registros NS encontrados en la zona padre son “verificados” en la zona hija.
El error de configuración que encontramos en estas zonas reversas no es exclusivo del árbol reverso del DNS ni exclusivo de los registros reversos para IPv6. Se puede cometer este mismo error en zonas directas del estilo “empresa.com.tld”.
Es fundamental también saber cómo utilizar al máximo herramientas como dig o drill. Existen también algunas herramientas gráficas que pueden ser útiles como DnsViz y ZoneMaster.
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.
