Como o dig + trace realmente funciona?

Quando olho para a página de manual para escavação, obtenho o seguinte:

+[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.

Então, como isso funciona, na prática? Qual seria a série equivalente de digcomandos (sem + rastreio) que seria funcionalmente equivalente?

dig +trace funciona fingindo que é um servidor de nomes e trabalha na árvore do namespace usando consultas iterativas que começam na raiz da árvore, seguindo as referências ao longo do caminho.

A primeira coisa a fazer é solicitar ao servidor DNS do sistema normal registros NS para "."

Depois de receber uma resposta, que será a lista atual de servidores de nomes raiz, ele escolherá um e solicitará o registro A para esse nome, se não o obteve na seção de registros adicionais na primeira vez, para que um endereço IP para o qual enviar a próxima consulta. Digamos que escolha f.root-servers.net cujo endereço IP é 192.5.5.241.

Neste ponto, vamos usar dig +trace www.google.co.uk.como nosso comando com um nome de domínio para o qual queremos rastrear o caminho da resolução.

A próxima consulta dos bastidores será a seguinte:

$ 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

Uau, agora sabemos que existem servidores de nomes uke essa é a única coisa que o servidor raiz conhece. Esta é uma referência , porque não pedimos recursão ( +norecursedesativa).

Ótimo, enxaguamos e repetimos. Desta vez, escolhemos um dos ukservidores de nomes e fazemos a mesma pergunta .

$ 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

Impressionante, agora descobrimos que o ukservidor de nomes de nível superior sabe que existe uma zona chamada google.co.uke nos diz para fazermos a pergunta a esses servidores de nomes. Esta é outra referência.

Enxágüe, repita.

Dessa vez, no entanto, não obtivemos registros A na seção de registros adicionais da resposta. Por isso, escolhemos um, digamos ns2.google.com, e precisamos procurar o endereço. Nós reiniciar uma consulta (na raiz novamente) e de perseguição baixo da árvore para encontrar o endereço IP para ns2.google.com. Vou pular essa parte por questões de brevidade, mas aprendemos que o IP é 216.239.34.10.

Portanto, nossa próxima consulta é:

$ 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

E nós terminamos! (finalmente) Como sabemos que terminamos? Recebemos uma resposta para nossa consulta, que era o registro A para www.google.com.br. Você também pode dizer que, como não é mais uma referência, o aabit está definido na última resposta, o que significa que esta é a resposta autorizada para sua consulta.

Então é isso que está acontecendo a cada passo do caminho quando você usa dig +trace.

Observe que, se você possui uma versão do dig digitada para DNSSEC e adiciona +dnssecao comando, poderá ver muitos outros registros. O que são esses registros extras é deixado como um exercício para o leitor ... mas explica como dig +sigchasefunciona.

Vamos dizer que você estava olhando para cima

www.domain.co.uk

O DNS é uma hierarquia, começando com servidores raiz que sabem quais servidores têm autoridade para os TLDs (a última parte do nome de domínio). Então, o equivalente a

dig subdomain.domain.co.uk

Passo a passo seria:

dig SOA @g.root-servers.net uk

(ou seja, consulte um dos servidores raiz para descobrir quem é autoritário para .uk)

Isso responde com uma série de servidores oficiais do Reino Unido, por isso perguntamos a eles quem tem co.uk

dig SOA @ns6.nic.uk co.uk

E nos dizem que a SOA (autoridade) está nos mesmos servidores

Então, vamos consultar ns1.nic.uk para ver quem possui domain.co.uk

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

Isso volta e diz que a autoridade para o domínio está em dns.dns1.de (mais backups);

Então agora podemos pedir o 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