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 uk
y eso es lo único que sabe el servidor raíz. Esta es una referencia , porque no solicitamos recursividad ( +norecurse
la apaga).
Genial, enjuagamos y repetimos. Esta vez elegimos uno de los uk
servidores 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 uk
servidor de nombres de nivel superior sabe que hay una zona llamada google.co.uk
y 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 aa
bit 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 +dnssec
al 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 +sigchase
funciona.