¿Cómo funciona realmente dig + trace?

Cuando miro la página de manual para excavar, obtengo 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 comandos dig (sin + trace) que sería funcionalmente equivalente?

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

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

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

En este punto, utilicemos dig +trace www.google.co.uk. Como nuestro comando con un nombre de dominio que queremos trazar la ruta de resolución para.

La siguiente consulta de detrás de las escenas será la siguiente:

 $ 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, así que ahora sabemos que hay servidores de nombres para uk y eso es lo único que sabe el servidor raíz. Esta es una referencia , porque no pedimos recursión ( +norecurse lo apaga).

Genial, nos aclaramos y repetimos. Esta vez escogemos uno de los servidores de nombres de uk y 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 servidor de nombres de nivel superior de uk sabe que hay una zona llamada google.co.uk y nos dice que vayamos a preguntar a los servidores de nombres nuestra pregunta. Esta es otra referencia.

Enjuagar, repetir.

Esta vez, sin embargo, no conseguimos registros A en la sección de registros adicionales de la respuesta, por lo que elegir uno, digamos ns2.google.com, y tenemos que ir a encontrar su dirección. Reiniciamos una consulta (en la raíz de nuevo) y perseguimos el árbol para encontrar la dirección IP de ns2.google.com. Voy a saltar esa parte de la brevedad, pero nos enteramos de que el IP para él es 216.239.34.10.

Así que nuestra siguiente pregunta 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? Tenemos una respuesta a nuestra consulta, que fue el registro A de http://www.google.co.uk. También se puede decir porque no es una referencia más, el bit aa se establece en la última respuesta que significa que esta es la respuesta autorizada para su consulta.

Así que eso es lo que está sucediendo cada paso a lo largo del camino cuando se utiliza dig +trace .

Tenga en cuenta que si tiene una versión DNSSEC-aware de dig y agrega +dnssec al comando, puede ver un montón más registros. Lo que esos registros extra se deja como un ejercicio para el lector … pero se pone en cómo funciona dig +sigchase .

Digamos que estabas buscando

 www.domain.co.uk 

DNS es una heirarchy, comenzando con los servidores raíz que saben qué servidores son autorizados para los TLD (la última parte del nombre de dominio). Así que el equivalente a

 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 de Reino Unido, así que les preguntamos quién tiene co.uk

 dig SOA @ns6.nic.uk co.uk 

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

Así que permite la consulta ns1.nic.uk para ver quién tiene domain.co.uk

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

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

Así que 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 
Intereting Posts