Se conoce con “Resolución de Nombres de Máquina” al procedimiento por el cual cuando una máquina quiere contactar a otra, usando el nombre de destino, debe resolver cuál es la dirección IP de la máquina de destino
La posible complicación, es que en realidad, y por omisión, cada máquina perteneciente a un Dominio Active Directory tiene dos nombres que pueden ser diferentes: el nombre NetBIOS, y el “Hostname” que forma parte del FQDN (“Fully Qualified Domain Name”)
Para aclarar y por las dudas, si el “Hostname” es servidor, el FQDN es servidor.dominio.sufijo
Además hay que tener en cuenta que hay métodos para resolución de nombres NetBIOS, y otros diferentes para resolver “Hostnames/FQDNs”; y cada uno tiene un orden en particular que ha cambiado en diferentes versiones del sistema operativo. Y como si fuera poca la complicación, independientemente del nombre que use la aplicación, el sistema si no puede resolver de una forma, intentará por la otra
Vamos a ver el tema, con explicación, de cómo se resuelven los nombres, inclusive con capturas del tráfico de red donde podemos ver realmente cómo trabaja
La infraestructura que utilizaré para esta demostración es muy sencilla:
- DC1.ad.guillermod.com.ar
Windows Server 2012 R2
Controlador de Dominio
Servicio DNS
Servicio WINS (para resolución NetBIOS)
IPv4: 192.168.2.201/24
IPv6: por omisión (Link-local) - CL1.ad.guillermod.com.ar
Windows 8.1
Cliente del Dominio
Configurado DNS a DC1
Configurado WINS a DC1
IPv4: 192.168.2.1/24
IPv6: por omisión (Link-local)
Agrego una captura de IPCONFIG /ALL de CL1 para mostrar además la dirección física (“MAC Address”) de la placa de red
En CL1 he instalado el analizador de protocolo (“Sniffer”) Microsoft Network Monitor 3.4 que es de descarga gratuita para hacer las capturas de red
Para forzar a que el sistema utilice todos los métodos de resolución posibles, ejecutaré un comando que acepta tanto nombre NetBIOS, como “Hostname” o FQDN, como es “PING” usando un nombre no-especificando de qué tipo es
Por lo tanto el comando será “PING NoExiste” y veremos qué formas de resolución utiliza sobre la red
Como la parte que hace en memoria no podremos verla en la red, vamos a aclararla:
- Cuando tiene que resolver un nombre de tipo “Hostname/FQDN” siempre lo primero que se revisa es si la información no está ya presente en memoria. Puede estar en memoria porque fue resuelta anteriormente y aún resta tiempo para tenerla “cacheada”, o porque está incluida en el archivo HOSTS ya que la implementación de Microsoft es mantener en este “cache” el contenido del archivo
Si de esta forma no consigue resolver el nombre, procederá como se muestra en las siguientes capturas - Cuando tiene que resolver un nombre de tipo NetBIOS, también lo primero que hace es ver si la información no está “cacheada” en memoria.
Puede estar en memoria por haber sido resuelta anteriormente, este tiempo es fijo de 10 minutos
Además, y para hacer la demostración llimpia y prolija el PING lo ejecutaré desde un archivo BAT que se encarga de borrar la información “cacheada” de “MAC Address”, cache NetBIOS y cache Hostnames/FQDNs
El contenido del BAT es:
arp -d *
nbtstat -R
ipconfig /flushdns
ping NoExiste
Bueno comencemos, y a no asustarse el que no esté familiarizado con las capturas de red 🙂
Recordemos que los “caches” no podremos verlos en las capturas
Utilizaré el término en inglés, que es habitual, para cada transmisión (“Frame”)
Los dos primeros “Frames” en realidad no son parte de la captura de red, sino que es información propia del Network Monitor, así que no las veremos
Como tiene que contactar a DC1 que es servidor tanto de DNS como de WINS, lo primero que debe hacer el cliente es resolver la “MAC Address” de DC1, que hace a través del protocolo ARP
Podemos observar en el “frame 3” que es un “Broadcast” a nivel Ethernet preguntando por la “MAC Address” de 192.168.2.201, y adjuntando su propia “MAC Address” para que la guarde DC1
Como DC1 ya conoce la “MAC Address” de CL1, le responde por ARP, pero esta vez con tráfico dirigido a nivel Ethernet en el “frame 4”
Ya pudiendo comunicarse en forma dirigida a nivel IP CL1 y DC1, el cliente pregunta al DNS por la resolución de “NoExiste.ad.guillermod.com.ar” (“frame 5”)
Y en el “frame 6” el servidor DNS le responde que ese nombre no existe (“Name error”)
El paso siguiente es tratar de resolver por WINS, como si se tratara de un nombre NetBIOS, para lo cual en el “frame 7” le envía a WINS un “Query request”
Y por supuesto también WINS le responderá que no tiene registrado a nadie con ese nombre. Pero observen que aún antes que WINS responda, va a intentar resolver por LLMNR. De todas formas podemos verificar en el “frame 9” la no resolución
No habiendo resolución por DNS ni WINS, CL1 trata de resolver a través del protocolo LLMNR (“Link-Local Multicast Name Resolution” – RFC 4795). Para ello utiliza utiliza tanto IPv6 como IPv4, y las direcciones de “Multicast” utilizadas por este protocolo (IPv6: FF02::1:3 – IPv4: 224.0.0.252)
Hace cuatro intentos por IPv6 como muestran los “frames 8, 11, 14 y 16”
Y simultánemanete hace el mismo intento por IPv4 como se observa en los “frames 10, 12, 15 y 17”
Finalmente, al no poder resolver el nombre ni por DNS, ni WINS, ni LLMNR tanto por IPv4 como por IPV6, prueba la última opción que es “Broadcast” por IPv4, aunque como se puede observar antes de finalizar con LLMNR
Acá hay una diferencia con anteriores versiones del sistema operativo pues antes utilizaba “Subnet Broadcast = 255.255.255.255”, y actualmente utiliza “Net Broadcast 192.168.2.255”
Esto se puede ver en los “frames 13, 18 y 19”
Resumiendo, al indicarle un nombre no calificado, siendo parte de un Dominio y teniendo configurado tanto DNS como WINS, el sistema utiliza varios métodos, tanto de resolución NetBIOS como de Hostname/FQDN
La resolución de nombres de red es algo que hay que prestarle mucha antención. Es habitual que cuando se experimenta un largo tiempo hasta poder conectarse a una máquina, pero luego todo funciona normalmente, se deba a un problema de resolución de nombres. Por ejemplo si no lo puede resolver por DNS y termine resolviendo por “Net Broadcasts”
Información adicional:
