Nombres Duplicados en DNS – Name Devolution
por Sebastian del Rio y Juan Carlos Albert
Problema
Al hacer una consulta DNS utilizando la herramienta nslookup a un host interno podemos recibir respuestas no deseadas, como por ejemplo la siguiente.
Escenario : Estamos en un “subdominio” del dominio “dominio.com.co”, desde ahora nuestro dominio sera “subdominio.dominio.com.co”
C:\Documents and Settings\usuario>nslookup
Default Server: host.subdominio.dominio.com.co
Address: 192.168.0.1
>host.subdominio.dominio.com.co
Non-authoritative answer:
Name: host.subdominio.dominio.com.co.com.co
Address: 74.53.50.168 <Tenemos una respuesta a un recurso interno , resuelta hacia una IP publica .
Lo bueno es que esto es un comportamiento default :) . Lo malo es que no debería pasar vamos a tratar de explicar esto un poco mejor.
Que es lo que sucede ?
Nslookup utiliza el mecanismo de devolution para realizar búsquedas en el DNS.
Devolution es el mecanismo mediante el cual los clientes DNS de Windows construyen los sufijos cuando la maquina no tiene configurado un listado explicito de sufijos de búsqueda.
Específicamente, la resolución envía una consulta DNS para el nombre que se ha solicitado resolver. Si la consulta fue realizada para un nombre de host de etiqueta única, se concatena al nombre del host el sufijo principal DNS del equipo local. Si esa consulta no se resuelve correctamente, la consulta se reintenta repetidamente quitando la parte izquierda del nombre de sufijo DNS principal restante hasta que la consulta o bien se ha resuelto o se alcanza el límite de descomposiciones recursivas. Este límite es dos por default, lo que quiere decir que si nuestro dominio es subdominio.dominio.com, el mecanismo de devolution hará que las búsquedas se hagan con los sufijos:
subdominio.dominio.com
dominio.com
Este límite es perfectamente válido para dominios de segundo nivel, tal como microsoft.com porque al llegar al sufijo de segundo nivel (microsoft.com) todavía estaremos bajo la autoridad del DNS interno.
En el caso de dominios de tercer nivel, sin embargo, el límite en dos resulta inapropiado porque devolution nos dará un sufijo de dos niveles que no está bajo la autoridad de nuestro DNS interno. Si este sufijo corresponde a un ccSLD (country code second-level domain), la consulta será enviada a la Internet para su resolución.
En nuestro ejemplo la lista de búsqueda provista por el mecanismo de devolution estará compuesta de la siguiente manera:
subdominio.dominio.com.co
dominio.com.co
com.co
La última consulta será eventualmente enviada a la Internet porque el sufijo que se anexa, com.co, no corresponde con ninguna zona en nuestro DNS.
Veamos lo que sucede al hacer la consulta a host.subdominio.dominio.com.co. Nslookup intenta primero resolver mediante su lista de búsqueda, agregando los sufijos uno por uno. Para chequear la lista de búsqueda que será utilizada, podemos hacerlo ingresando a nslookup y ejecutando “set all”
De manera que las consultas quedarían de la siguiente manera
C:\Documents and Settings\usuario>nslookup
Default Server: host.subdominio.dominio.com.co
Address: 192.168.0.1
> set debug
> host.subdominio.dominio.com.co
Server: host.subdominio.dominio.com.co
Address: 192.168.0.1
------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
host.subdominio.dominio.com.co.subdominio.dominio.com.co, type = A, class = IN
AUTHORITY RECORDS:
-> subdominio.dominio.com.co
ttl = 3600 (1 hour)
primary name server = host.subdominio.dominio.com.co
responsible mail addr = admin
serial = 611275
refresh = 900 (15 mins)
retry = 600 (10 mins)
expire = 86400 (1 day)
default TTL = 3600 (1 hour)
host.subdominio.dominio.com.co.subdominio.dominio.com.co -> No hay respuesta ya que el registro host.subdominio.dominio.com.co no existe en la zona subdominio.dominio.com.co. (Ver Questions = 1 answers = 0)
------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 3, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
host.subdominio.dominio.com.co.dominio.com.co, type = A, class = IN
AUTHORITY RECORDS:
-> dominio.com.co
ttl = 3600 (1 hour)
primary name server = host.subdominio.dominio.com.co
serial = 417
refresh = 3600 (1 hour)
retry = 600 (10 mins)
expire = 86400 (1 day)
default TTL = 3600 (1 hour)
host.subdominio.dominio.com.co.dominio.com.co -> No hay respuesta ya que el registro host.subdominio.dominio.com.co no existe en la zona dominio.com.co (Ver Questions = 1 answers = 0)
------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 4, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS:
host.subdominio.dominio.com.co.com.co, type = A, class = IN
ANSWERS:
-> host.subdominio.dominio.com.co.com.co
internet address = 74.53.50.168
ttl = 86400 (1 day)
host.subdominio.dominio.com.co.com.co -> En el tercer caso estamos consultando el registro host.subdominio.dominio.com.co en la zona .com.co y será posible obtener una respuesta no autoritativa de nuestro servidor.
------------
Non-authoritative answer:
Name: host.subdominio.dominio.com.co.com.co
Address: 74.53.50.168 - > Y aquí tenemos la respuesta.
Al esa zona no existir localmente (Ya que nuestra zona es subdominio.dominio.com.co ) y de acuerdo a la configuración de nuestro DNS utilizaremos los Fowarders o bien Root Hints para que otro servidor DNS resuelva nuestra consulta, lo que pasa aquí es que la zona .com.co se encuentra registrada en internet por lo cual la respuesta de este ultimo query existe. En este punto NSLOOKUP ya obtuvo su respuesta y no sigue haciendo queries.
El problema parece manifestarse con más frecuencia porque muchos DNS que resuelven zonas de segundo nivel (como com.co) están utilizando mecanismos de “catch all” para recoger todas las consultas no resueltas y retornar direcciones validas con fines comerciales o informativos. Intenten, por ejemplo, acceder a https://74.53.50.168
Cabe aclarar que luego del ejecutar el query solicitado y nslookup no haya obtenido ninguna respuesta utilizando su search list, se haría la consulta solicitada. Como en nuestro caso utilizando la search list ya tenemos una respuesta nunca se llega a solicitar el recurso que nosotros estamos intentando ubicar.
También es interesante considerar el hecho que devolution solo interviene si la consulta no es una completamente calificada (fully qualified). Afortunadamente podemos hacer la consulta FQDN utilizando un “.” al final del nombre de nuestro dominio.
Solución
Sabiendo que el problema se causa al consultar la Search List default de Nslookup las opciones que tendríamos serian las siguientes.
1 – Utilizar el sufijo “.” ( Sin comillas ) asignado mediante GPO , o bien localmente en la placa de red. De esta manera la search list quedaría compuesta por los sufijos que utilizemos en esta configuración.
NOTA : Para asignar la lista de sufijos DNS mediante GPO puede utilizar la siguiente nota
2 – Desactivar la opción de Name Devolution (Mediante esta opción Nslookup no armaria su propia lista de Search list), este cambio debería habilitarse localmente en cada una de las maquinas mediante la modificación del registro según indica la siguiente nota https://technet.microsoft.com/en-us/library/cc959477.aspx.
3 – Utilizar el paramentro nosearch en la consulta mediante nslookup.
Esperamos haber aclarado algunas dudas que últimamente se dieron de acuerdo a este tema.
Happy Networking y hasta pronto!