Como o dig + trace realmente funciona?

12

Quando olho para a página de manual para digitaçã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 comandos dig (sem + trace) que seriam funcionalmente equivalentes?

    
por Doktor J 12.02.2014 / 01:28

2 respostas

30

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

A primeira coisa que ele faz é pedir ao servidor DNS do sistema normal por registros NS para "."

Depois de obter uma resposta, que será a lista atual de servidores de nomes raiz, ela selecionará uma e, em seguida, solicitará o registro A para esse nome, se não a tiver obtido na seção de registros adicionais na primeira vez então tem um endereço IP para enviar a próxima consulta. Digamos que ele escolha f.root-servers.net cujo endereço IP seja 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 de resolução.

A próxima consulta nos bastidores 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

Uau, agora sabemos que existem servidores de nomes para uk e essa é a única coisa que o servidor raiz conhece. Isso é uma referência , porque não solicitamos recursão ( +norecurse a desativa).

Ótimo, enxaguamos e repetimos. Dessa vez, escolhemos um dos uk nameservers 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

Incrível, agora descobrimos que o servidor de nomes de nível superior uk sabe que há uma zona chamada google.co.uk e nos diz para perguntar a esses servidores de nomes a nossa pergunta. Esta é outra referência.

Enxaguar, repita.

Desta 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 encontrá-lo. Nós reiniciamos uma consulta (na raiz novamente) e seguimos a árvore para encontrar o endereço IP para ns2.google.com. Vou pular essa parte por brevidade, mas aprendemos que o IP para ela é 216.239.34.10.

Então, 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 terminamos! (finalmente) Como sabemos que estamos prontos? Recebemos uma resposta para nossa consulta, que foi o registro A de www.google.co.uk. Você também pode dizer porque não é mais uma referência, o aa bit está definido na última resposta, o que significa essa é a resposta autoritativa para sua consulta.

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

Observe que, se você tiver uma versão de escavação compatível com DNSSEC e adicionar +dnssec ao comando, poderá ver mais registros. O que esses registros extras são deixados como um exercício para o leitor ... mas entra em como dig +sigchase funciona.

    
por 12.02.2014 / 03:33
1

Digamos que você esteja pesquisando

www.domain.co.uk

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

dig subdomain.domain.co.uk

O passo a passo seria:

dig SOA @g.root-servers.net uk

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

Isso responde com uma série de servidores britânicos de autoridade, então perguntamos a eles quem tem co.uk

dig SOA @ns6.nic.uk co.uk

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

Então vamos fazer uma consulta ns1.nic.uk para ver quem tem 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 solicitar 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
    
por 12.02.2014 / 01:52

Tags