¿Cómo funciona realmente dig + trace?

Cuando miro la página del manual para cavar, me sale lo siguiente:

+[no]trace
  Toggle tracing of the delegation path from the root name servers for the name
  being looked up. Tracing is disabled by default. When tracing is enabled, dig
  makes iterative queries to resolve the name being looked up. It will follow
  referrals from the root servers, showing the answer from each server that was
  used to resolve the lookup.

Entonces, ¿cómo funciona esto, en la práctica? ¿Cuál sería la serie equivalente de digcomandos (sin + trace) que serían funcionalmente equivalentes?

dig +trace funciona simulando que es un servidor de nombres y trabaja en el árbol del espacio de nombres utilizando consultas iterativas que comienzan en la raíz del árbol, siguiendo las referencias en el camino.

Lo primero que hace es pedirle al servidor DNS del sistema normal los registros NS para "."

Después de obtener una respuesta, que será la lista actual de servidores de nombres raíz, elegirá uno y luego solicitará el registro A para ese nombre si no lo obtuvo en la sección de registros adicionales la primera vez, por lo que tiene una dirección IP para enviar la siguiente consulta. Digamos que selecciona f.root-servers.net cuya dirección IP es 192.5.5.241.

En este punto, usemos dig +trace www.google.co.uk.como nuestro comando un nombre de dominio para el que queremos rastrear la ruta de resolución.

La siguiente consulta detrás de escena será esta:

$ dig +norecurse @192.5.5.241 www.google.co.uk

   ; <<>> DiG 9.9.4 <<>> +norecurse @192.5.5.241 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8962
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 15

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.co.uk.              IN      A

;; AUTHORITY SECTION:
uk.                     172800  IN      NS      ns5.nic.uk.
uk.                     172800  IN      NS      ns6.nic.uk.
uk.                     172800  IN      NS      ns4.nic.uk.
uk.                     172800  IN      NS      nsc.nic.uk.
uk.                     172800  IN      NS      ns2.nic.uk.
uk.                     172800  IN      NS      ns3.nic.uk.
uk.                     172800  IN      NS      nsd.nic.uk.
uk.                     172800  IN      NS      nsa.nic.uk.
uk.                     172800  IN      NS      ns7.nic.uk.
uk.                     172800  IN      NS      nsb.nic.uk.
uk.                     172800  IN      NS      ns1.nic.uk.

;; ADDITIONAL SECTION:
ns1.nic.uk.             172800  IN      A       195.66.240.130
ns2.nic.uk.             172800  IN      A       217.79.164.131
ns3.nic.uk.             172800  IN      A       213.219.13.131
ns4.nic.uk.             172800  IN      A       194.83.244.131
ns5.nic.uk.             172800  IN      A       213.246.167.131
ns6.nic.uk.             172800  IN      A       213.248.254.130
ns7.nic.uk.             172800  IN      A       212.121.40.130
nsa.nic.uk.             172800  IN      A       156.154.100.3
nsb.nic.uk.             172800  IN      A       156.154.101.3
nsc.nic.uk.             172800  IN      A       156.154.102.3
nsd.nic.uk.             172800  IN      A       156.154.103.3
ns1.nic.uk.             172800  IN      AAAA    2a01:40:1001:35::2
ns4.nic.uk.             172800  IN      AAAA    2001:630:181:35::83
nsa.nic.uk.             172800  IN      AAAA    2001:502:ad09::3

;; Query time: 45 msec
;; SERVER: 192.5.5.241#53(192.5.5.241)
;; WHEN: Tue Feb 11 19:19:14 MST 2014
;; MSG SIZE  rcvd: 507

Wow, ahora sabemos que hay servidores de nombres uky eso es lo único que sabe el servidor raíz. Esta es una referencia , porque no solicitamos recursividad ( +norecursela apaga).

Genial, enjuagamos y repetimos. Esta vez elegimos uno de los ukservidores de nombres y le hacemos la misma pregunta .

$ dig +norecurse @195.66.240.130 www.google.co.uk

; <<>> DiG 9.9.4 <<>> +norecurse @195.66.240.130 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 618
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.co.uk.              IN      A

;; AUTHORITY SECTION:
google.co.uk.           172800  IN      NS      ns1.google.com.
google.co.uk.           172800  IN      NS      ns3.google.com.
google.co.uk.           172800  IN      NS      ns2.google.com.
google.co.uk.           172800  IN      NS      ns4.google.com.

;; Query time: 354 msec
;; SERVER: 195.66.240.130#53(195.66.240.130)
;; WHEN: Tue Feb 11 19:22:47 MST 2014
;; MSG SIZE  rcvd: 127

Impresionante, ahora hemos descubierto que el ukservidor de nombres de nivel superior sabe que hay una zona llamada google.co.uky nos dice que hagamos nuestra pregunta a esos servidores de nombres. Esta es otra referencia.

Enjuague, repita.

Esta vez, sin embargo, no obtuvimos registros A en la sección de registros adicionales de la respuesta, por lo que elegimos uno, digamos ns2.google.com, y tenemos que ir a buscar su dirección. Nos reiniciamos una consulta (en la raíz de nuevo) y persecución por el árbol para encontrar la dirección IP para ns2.google.com. Omitiré esa parte por brevedad, pero aprendemos que la IP es 216.239.34.10.

Entonces nuestra siguiente consulta es:

$ dig +norecurse @216.239.34.10 www.google.co.uk

; <<>> DiG 9.9.4 <<>> +norecurse @216.239.34.10 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33404
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.co.uk.              IN      A

;; ANSWER SECTION:
www.google.co.uk.       300     IN      A       74.125.225.216
www.google.co.uk.       300     IN      A       74.125.225.223
www.google.co.uk.       300     IN      A       74.125.225.215

;; Query time: 207 msec
;; SERVER: 216.239.34.10#53(216.239.34.10)
;; WHEN: Tue Feb 11 19:26:43 MST 2014
;; MSG SIZE  rcvd: 82

¡Y hemos terminado! (finalmente) ¿Cómo sabemos que hemos terminado? Recibimos una respuesta a nuestra consulta, que era el registro A de www.google.co.uk. También puede saberlo porque ya no es una referencia, el aabit se establece en la última respuesta, lo que significa que esta es la respuesta autorizada para su consulta.

Entonces, eso es lo que sucede en cada paso del camino cuando lo usas dig +trace.

Tenga en cuenta que si tiene una versión de dig compatible con DNSSEC y agrega +dnssecal comando, es posible que vea muchos más registros. Lo que esos registros adicionales son se deja como un ejercicio para el lector ... pero se explica cómo dig +sigchasefunciona.

Digamos que estabas mirando hacia arriba

www.domain.co.uk

DNS es una jerarquía, que comienza con servidores raíz que saben qué servidores tienen autoridad para los TLD (la última parte del nombre de dominio). Entonces, el privilegiado para

dig subdomain.domain.co.uk

Paso a paso sería:

dig SOA @g.root-servers.net uk

(es decir, consulta uno de los servidores raíz para encontrar quién tiene autoridad para .uk)

Esto responde con una serie de servidores autorizados del Reino Unido, por lo que les preguntamos quién tiene co.uk

dig SOA @ns6.nic.uk co.uk

Y nos dicen que la SOA (autoridad) está en los mismos servidores

Entonces consultemos ns1.nic.uk para ver quién tiene domain.co.uk

dig SOA @ns1.nic.uk domain.co.uk

Esto vuelve y dice que la autoridad para el dominio está en dns.dns1.de (más copias de seguridad);

Entonces ahora podemos pedir el registro A:

dig  A @dns.dns2.de www.domain.co.uk

;; QUESTION SECTION:
;www.domain.co.uk.              IN      A

;; ANSWER SECTION:
www.domain.co.uk.       86400   IN      CNAME   domain.co.uk.
domain.co.uk.           86400   IN      A       95.130.17.36