¿Cuál es la diferencia entre `dig` y` host` cuando se consulta un servidor de nombres específico?

Estaba usando este comando para verificar si había configurado correctamente las cosas con un proveedor de DNS:

host hostname.example.com ns1.example-nameserver.com

Por lo que puedo decir, esto pide ns1.example-nameserver.commirar hacia arriba hostname.example.come informa la respuesta. Estaba recibiendo una respuesta de host no encontrado, así que pensé que lo había hecho mal. Sin embargo, sin especificar su servidor de nombres (permitiendo así que el servidor de nombres de mi ISP lo busque) obtuve la respuesta correcta ( hostnamees un CNAMEsi es importante). No pude entender esto, así que busqué y encontré el digcomando:

dig @ns1.example-nameserver.com hostname.example.com

Por lo que puedo decir, esto hace lo mismo que el hostcomando: pide a un servidor de nombres específico que busque un host. Por lo tanto, concluyo que deben hacerlo de alguna manera diferente, y que los servidores de nombres de almacenamiento en caché deben usar el mismo método que dig.

Mi conclusión es correcta o incorrecta, si es correcta:

¿Cuál es la diferencia entre estos dos métodos de búsqueda?

Si está mal:

¿Cuáles son mis malentendidos sobre DNS y los comandos hosty digque me han llevado a esta conclusión?

Salida de ejemplo:

$ host cardiff.tzmchapters.org ns1.livedns.co.uk
Using domain server:
Name: ns1.livedns.co.uk
Address: 213.171.192.250#53
Aliases: 

Host cardiff.tzmchapters.org not found: 3(NXDOMAIN)

$ dig @ns1.livedns.co.uk cardiff.tzmchapters.org

; <<>> DiG 9.8.3-P1 <<>> @ns1.livedns.co.uk cardiff.tzmchapters.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23620
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;cardiff.tzmchapters.org.   IN  A

;; ANSWER SECTION:
cardiff.tzmchapters.org. 3600   IN  CNAME   ghs.google.com.

;; AUTHORITY SECTION:
google.com.     3600    IN  SOA ns1.livedns.co.uk. admin.google.com. 1354213742 10800 3600 604800 3600

;; Query time: 27 msec
;; SERVER: 213.171.192.250#53(213.171.192.250)
;; WHEN: Mon Apr 22 23:47:05 2013
;; MSG SIZE  rcvd: 128

— jhabbott
fuente

ambos comandos deberían funcionar de la misma manera en este caso. ¿Puedes mostrar la salida completa de cada comando?

— Renan

Observe cómo ambos dige hostinforme NXDOMAIN. Con digusted puede verlo en el encabezado (quinta línea no en blanco de la salida) y con hostesto es más obvio. NXDOMAINsignifica que el dominio no existe. Sin embargo, a CNAMEse devuelve en la sección de respuestas. ¡Creo que es un error en el servidor DNS!

— Celada

Entonces, en ese caso, ¿ digy hostambos envían exactamente el mismo paquete de consulta, obtienen exactamente el mismo paquete de respuesta (aparte de las marcas de tiempo), pero lo interpretan de manera diferente? ¿Se hostrescata tan pronto como ve NXDOMAIN?

— jhabbott

FWIW Tengo exactamente el problema opuesto en un subdominio específico. El uso de host en este subdominio específico proporciona el registro esperado que muestra que este subdominio en particular se resuelve en un nombre de host canónico esperado. Sin embargo, cuando uso cavar en este subdominio en particular, recibo una respuesta de que el registro no existe. Además, navegar a este subdominio con un navegador no funciona. Lo he intentado varias veces, verificando errores de ortografía, etc. Los comandos claramente NO funcionan de la misma manera.

— user12345

Respuestas:

host, digy nslookuptodos comparten la mayor parte de la misma funcionalidad. En el caso de que esté preguntando (hacer una pregunta de DNS en particular a un servidor de nombres en particular) digy host(y de hecho nslookup) se comporten exactamente igual.

Para la resolución de problemas de DNS, digse prefiere porque su formato de salida es más "en bruto": en su salida muestra directamente el contenido de los 4 campos en la respuesta de DNS: pregunta, respuesta, autoridad y secciones adicionales (además de las banderas en el encabezado) , y también tiene más opciones. host, por otro lado, tiene un formato de salida más fácil de usar.

Si no necesita una opción que uno de los comandos tiene y los otros no, o una información que uno de ellos emite y los otros no, entonces se trata de una cuestión de preferencia.

— Celada
fuente

Si hacen lo mismo en el lado de la red (la consulta real), ¿cómo puedo obtener un host que no se encuentra al usar hostpero la respuesta correcta al usar dig? Incluso si el servidor está configurado con una configuración particular (ya sea por elección o por accidente) para causar esto, debe poder diferenciar las solicitudes.

— jhabbott

No! ¡Los dos comandos que das en tu pregunta son equivalentes y deberían producir la misma respuesta! ¿Está seguro de que digle dio una respuesta real y no un registro en la sección adicional o de autoridad? Como sugiere Renan , podría ayudar mostrar el resultado.

— Celada

Ok, agregué algunos resultados de ejemplo. Obtengo el mismo resultado en casa y en el trabajo. Cuando no especifico un servidor de nombres para usar y mi ISP maneja la consulta, hostfunciona bien. Pruébelo usted mismo y hágame saber los resultados.

— jhabbott

Solo revisando esto: el ISP finalmente me dijo que su servidor estaba configurado para no responder a las consultas directas de los clientes, solo a otros servidores de nombres que solicitaban transferencias de información, ¿las digconsultas de una manera diferente, como lo haría un servidor de nombres?

— jhabbott

dig puede hacer preguntas regulares (todos los tipos excepto AXFR) y transferencias de zona (tipo AXFR), pero los operadores de DNS generalmente restringen las transferencias de zona a esclavos autorizados, por lo que es muy probable que desee usar preguntas regulares

— Celada

Si está utilizando el nombre de host que no es FQDN, los resultados pueden ser diferentes porque hostutilizará los dominios de búsqueda resolv.conf, mientras digque no lo hará de manera predeterminada.

Debe usar la +searchopción si desea digusarla resolv.conf(o agregarla a ~/.digrc).

Por ejemplo:

$ host foo
foo.myfqdn.com has address 10.1.2.3

$ dig +short foo
# (no result)

$ dig +short +search foo
10.1.2.3

— wisbucky
fuente