¿Cómo resuelve traceroute los nombres?

Mientras escribía un script, quería hacer referencia a una máquina por el nombre de la computadora que le di (por ejemplo, "selenium-rc"). No pude hacer ping con "selenium-rc", así que probé los siguientes comandos para ver si se reconocía el nombre.

> traceroute 192.168.235.41
traceroute to 192.168.235.41 (192.168.235.41), 64 hops max, 52 byte packets
 1  selenium-rc (192.168.235.41)  0.545 ms  0.241 ms  0.124 ms

Ok, traceroute "encontró" el nombre. ¿Cómo? Próximo ...

> traceroute selenium-rc
traceroute: unknown host selenium-rc

Hmm ... el mecanismo de búsqueda aquí debe ser diferente porque el host es desconocido. Supongo que esto está usando un proceso de resolución de nombre del sistema, mientras que el primer ejemplo estaba usando un proceso específico para traceroute. ¿Correcto?

Luego, cuando volví un poco más tarde ...

> traceroute 192.168.235.41
traceroute to 192.168.235.41 (192.168.235.41), 64 hops max, 52 byte packets
 1  minint-q4e8i52.mycorp.net (192.168.235.41)  0.509 ms  0.206 ms  0.136 ms

Ok, resultado diferente. El nombre "selenium-rc" no cambió en la máquina en sí, pero el proceso de resolución de nombre de traceroute debe incluir algún tipo de prioridad y ahora da un resultado presumiblemente más autorizado asignado por otro sistema / servicio en la red. (Desafortunadamente, supongo que es un nombre dinámico que no controlo y, por lo tanto, no sería útil en un script).

¿Alguien puede explicar los resultados?

En general, en Linux y Unix, traceroute y ping usarían una llamada a gethostbyname () para buscar el nombre de un sistema. gethostbyname () a su vez usa los archivos de configuración del sistema para determinar el orden en el que consultar las bases de datos de nombres, es decir: / etc / hosts y DNS.

En Linux, la acción predeterminada es (o tal vez solía ser) consultar primero el DNS y luego / etc / hosts. Esto se puede cambiar o actualizar configurando el orden deseado en /etc/host.conf.

Para buscar / etc / hosts antes de DNS, configure el siguiente orden en /etc/host.conf:

order hosts,bind

En Solaris, este mismo orden se controla mediante el archivo /etc/nsswitch.conf, en la entrada de la base de datos de hosts.

hosts: archivos dns

Establece el orden de búsqueda para buscar en / etc / hosts antes de buscar DNS.

Traceroute y ping utilizarían estos métodos para buscar en todas las bases de datos de nombres configuradas. los comandos hosty nslookupambos usan solo DNS, por lo que no necesariamente duplicarán los resultados aparentemente inconsistentes que estás viendo.

Solaris tiene una herramienta de búsqueda getent, que se puede utilizar para identificar hosts o direcciones de la misma manera que lo hacen traceroute y ping, siguiendo el conjunto configurado de bases de datos de nombres para buscar.

getent hosts <hostname>

buscaría a través de cualquier base de datos listada para hosts, en /etc/nsswitch.conf.

Entonces. En su caso, para lograr resultados consistentes, agregue lo siguiente a / etc / hosts

192.168.235.41 selenium-rc

Y asegúrese de que /etc/host.conf tenga:

order hosts,bind

O asegúrese de que /etc/nsswitch.conf tenga:

hosts: files dns

Una vez hecho esto, debería ver resultados más consistentes con ping y traceroute, así como con otros comandos, como ssh, telnet, curl, wget, etc.

Parece que tiene una búsqueda inversa configurada correctamente, pero no hacia adelante.

Su sistema puede buscar la dirección IP 192.168.235.41 y reconocer que es así selenium-rc, pero cuando intenta buscarla selenium-rcfalla.

Te recomiendo comprobar /etc/hostsy /etc/resolv.conf; el comportamiento de la getaddrinfollamada al sistema está dictado por este último y hace referencia al primero.

Mi suposición: la invocación traceroute 192.168.235.41provocó que se enviara una solicitud de DNS para encontrar el nombre que acompaña a la dirección IP 192.168.235.41. traceroute -n 192.168.235.41es la forma de iniciar traceroute sin que realice búsquedas de DNS en cada dirección IP que encuentre. El servidor DNS tardó más en responder que lo que el sistema DNS quería esperar, por lo que al principio traceroute no proporcionó un nombre de host para 192.168.235.41. Para cuando traceroute envía y recibe paquetes desde 192.168.235.41, su servidor DNS ha respondido, por lo que traceroute puede proporcionarle un nombre de host.

Entonces, yo diría "problemas con el servidor DNS", con un momento muy conveniente que lo hizo sospechar de otras cosas. Piensa en la "Ley de Murphy" aquí. Cuando volviste un poco más tarde, obtienes un nombre diferente para la misma dirección IP, lo que también me hace pensar que tal vez alguien estaba jugando con la configuración del servidor DNS durante el tiempo que estabas haciendo tus traceroutes.