Dig + trace è sempre preciso?

Quando l'accuratezza di una cache DNS è in questione, dig +tracetende ad essere il modo consigliato di determinare la risposta autorevole per un record DNS Internet. Questo sembra essere particolarmente utile se abbinato anche +additional, il che mostra anche i record di colla.

A volte sembra esserci un disaccordo su questo punto - alcune persone dicono che si basa sul risolutore locale per cercare gli indirizzi IP dei nameserver intermedi, ma l'output del comando non fornisce alcuna indicazione che ciò sta accadendo oltre l'elenco iniziale di root nameserver. Sembra logico supporre che questo non sarebbe il caso se lo scopo di +traceè iniziare dai server di root e rintracciarti. (almeno se hai il giusto elenco di nameserver root)

Fa dig +tracedavvero usare il resolver locale per qualche cosa oltre i server dei nomi di root?

Questa è ovviamente una domanda e risposta graduale , ma tende a confondere spesso le persone e non riesco a trovare una domanda canonica che tratti l'argomento.

dig +traceè un ottimo strumento diagnostico, ma un aspetto del suo design è ampiamente frainteso: l'IP di ogni server su cui verrà eseguita la query viene ottenuto dalla libreria del resolver . Questo è molto facilmente trascurato e spesso finisce per diventare un problema solo quando la cache locale ha la risposta errata per un nameserver memorizzato nella cache.

Analisi dettagliata

Questo è più semplice da scomporre con un campione dell'output; Ometterò tutto oltre la prima delegazione NS.

; <<>> DiG 9.7.3 <<>> +trace +additional serverfault.com                                                                      

;; global options: +cmd
.                   121459  IN      NS      d.root-servers.net.
.                   121459  IN      NS      e.root-servers.net.
.                   121459  IN      NS      f.root-servers.net.
.                   121459  IN      NS      g.root-servers.net.
.                   121459  IN      NS      h.root-servers.net.
.                   121459  IN      NS      i.root-servers.net.
.                   121459  IN      NS      j.root-servers.net.
.                   121459  IN      NS      k.root-servers.net.
.                   121459  IN      NS      l.root-servers.net.
.                   121459  IN      NS      m.root-servers.net.
.                   121459  IN      NS      a.root-servers.net.
.                   121459  IN      NS      b.root-servers.net.
.                   121459  IN      NS      c.root-servers.net.
e.root-servers.net. 354907  IN      A       192.203.230.10
f.root-servers.net. 100300  IN      A       192.5.5.241
f.root-servers.net. 123073  IN      AAAA    2001:500:2f::f
g.root-servers.net. 354527  IN      A       192.112.36.4
h.root-servers.net. 354295  IN      A       128.63.2.53
h.root-servers.net. 108245  IN      AAAA    2001:500:1::803f:235
i.root-servers.net. 355208  IN      A       192.36.148.17
i.root-servers.net. 542090  IN      AAAA    2001:7fe::53
j.root-servers.net. 354526  IN      A       192.58.128.30
j.root-servers.net. 488036  IN      AAAA    2001:503:c27::2:30
k.root-servers.net. 354968  IN      A       193.0.14.129
k.root-servers.net. 431621  IN      AAAA    2001:7fd::1
l.root-servers.net. 354295  IN      A       199.7.83.42
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

com.                        172800  IN      NS      m.gtld-servers.net.
com.                        172800  IN      NS      k.gtld-servers.net.
com.                        172800  IN      NS      f.gtld-servers.net.
com.                        172800  IN      NS      g.gtld-servers.net.
com.                        172800  IN      NS      b.gtld-servers.net.
com.                        172800  IN      NS      e.gtld-servers.net.
com.                        172800  IN      NS      j.gtld-servers.net.
com.                        172800  IN      NS      c.gtld-servers.net.
com.                        172800  IN      NS      l.gtld-servers.net.
com.                        172800  IN      NS      d.gtld-servers.net.
com.                        172800  IN      NS      i.gtld-servers.net.
com.                        172800  IN      NS      h.gtld-servers.net.
com.                        172800  IN      NS      a.gtld-servers.net.
a.gtld-servers.net. 172800  IN      A       192.5.6.30
a.gtld-servers.net. 172800  IN      AAAA    2001:503:a83e::2:30
b.gtld-servers.net. 172800  IN      A       192.33.14.30
b.gtld-servers.net. 172800  IN      AAAA    2001:503:231d::2:30
c.gtld-servers.net. 172800  IN      A       192.26.92.30
d.gtld-servers.net. 172800  IN      A       192.31.80.30
e.gtld-servers.net. 172800  IN      A       192.12.94.30
f.gtld-servers.net. 172800  IN      A       192.35.51.30
g.gtld-servers.net. 172800  IN      A       192.42.93.30
h.gtld-servers.net. 172800  IN      A       192.54.112.30
i.gtld-servers.net. 172800  IN      A       192.43.172.30
j.gtld-servers.net. 172800  IN      A       192.48.79.30
k.gtld-servers.net. 172800  IN      A       192.52.178.30
l.gtld-servers.net. 172800  IN      A       192.41.162.30
;; Received 505 bytes from 192.203.230.10#53(e.root-servers.net) in 13 ms

• La query iniziale per . IN NS(nameserver root) colpisce il resolver locale, che in questo caso è Comcast. ( 75.75.75.75) Questo è facile da individuare.
• La query successiva è pro serverfault.com. IN Ae contro e.root-servers.net., selezionata casualmente dall'elenco dei nameserver di root che abbiamo appena ricevuto. Ha un indirizzo IP di 192.203.230.10e, poiché abbiamo +additionalabilitato, sembra provenire dalla colla.
• Poiché non è autorevole per serverfault.com, questo viene delegato ai com.nameserver TLD.
• Ciò che non è ovvio dall'output qui è che dignon deriva l'indirizzo IP della e.root-servers.net.colla.

Sullo sfondo, questo è ciò che è realmente accaduto:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
02:03:43.301022 IP 192.0.2.1.59900 > 75.75.75.75.53: 63418 NS? . (17)
02:03:43.327327 IP 75.75.75.75.53 > 192.0.2.1.59900: 63418 13/0/14 NS k.root-servers.net., NS l.root-servers.net., NS m.root-servers.net., NS a.root-servers.net., NS b.root-servers.net., NS c.root-servers.net., NS d.root-servers.net., NS e.root-servers.net., NS f.root-servers.net., NS g.root-servers.net., NS h.root-servers.net., NS i.root-servers.net., NS j.root-servers.net. (512)
02:03:43.333047 IP 192.0.2.1.33120 > 75.75.75.75.53: 41110+ A? e.root-servers.net. (36)
02:03:43.333096 IP 192.0.2.1.33120 > 75.75.75.75.53: 5696+ AAAA? e.root-servers.net. (36)
02:03:43.344301 IP 75.75.75.75.53 > 192.0.2.1.33120: 41110 1/0/0 A 192.203.230.10 (52)
02:03:43.344348 IP 75.75.75.75.53 > 192.0.2.1.33120: 5696 0/1/0 (96)
02:03:43.344723 IP 192.0.2.1.37085 > 192.203.230.10.53: 28583 A? serverfault.com. (33)
02:03:43.423299 IP 192.203.230.10.53 > 192.0.2.1.37085: 28583- 0/13/14 (493)

+traceingannato e consultato il resolver locale per ottenere l'indirizzo IP del server dei nomi hop successivo invece di consultare la colla. Subdolo!

Questo di solito è "abbastanza buono" e non causerà un problema per la maggior parte delle persone. Sfortunatamente, ci sono casi limite. Se per qualsiasi motivo la cache DNS upstream fornisce la risposta errata per il nameserver, questo modello si interrompe completamente.

Esempio nel mondo reale:

• il dominio scade
• la colla viene rimandata ai server dei nomi di reindirizzamento del registrar
• IP falsi vengono memorizzati nella cache per ns1 e ns2.tuodominio.com
• il dominio si rinnova con la colla restaurata
• eventuali cache con IP di nameserver fasulli continuano a inviare persone a un sito Web che afferma che il dominio è in vendita

Nel caso sopra, +tracesuggerirai che i nameserver del proprietario del dominio sono la fonte del problema e sei a una chiamata dal dire erroneamente a un cliente che i loro server sono configurati male. Se è qualcosa su cui puoi (o sei disposto a) fare qualcosa è un'altra storia, ma è importante avere le informazioni giuste.

dig +trace è un ottimo strumento, ma come qualsiasi strumento, devi sapere cosa fa e cosa non fa e come risolvere manualmente il problema quando si rivela insufficiente.

Modificare:

Va anche notato che dig +tracenon ti avvertirà dei NSrecord che indicano CNAMEalias. Questa è una violazione di RFC che ISC BIND (e forse altri) non tenterà di correggere. +tracesarà completamente felice di accettare il Arecord che ottiene dal nameserver configurato localmente, mentre se BIND dovesse eseguire la ricorsione completa, rifiuterebbe l'intera zona con un SERVFAIL.

Questo può essere difficile da risolvere se è presente la colla; questo funzionerà bene fino a quando i record NS non verranno aggiornati , per poi rompersi improvvisamente. Le delegazioni senza colla interromperanno sempre la ricorsione di BIND quando un NSrecord indica un alias.

Un altro modo per tracciare la risoluzione DNS senza usare il resolver locale per nulla, tranne trovare i nameserver di root, è usare dnsgraph ( Informativa completa: ho scritto questo). Ha uno strumento da riga di comando e una versione web, di cui puoi trovare un'istanza su http://ip.seveas.net/dnsgraph/

Esempio per serverfault.com, che attualmente presenta un problema DNS:

Molto tardi a questo thread, ma penso che la parte della domanda sul perché una dig + trace utilizza query ricorsive per i resolver locali non è stata spiegata direttamente, e questa spiegazione è rilevante per l'accuratezza dei risultati di dig + trace.

Dopo la query ricorsiva iniziale per i record NS della zona radice, quindi scavare può inviare successive query ai resolver locali nelle seguenti condizioni:

1. una risposta di riferimento viene troncata a causa della dimensione della risposta superiore a 512 byte per la successiva query iterativa

2. dig seleziona un record NS dalla sezione AUTHORITY della risposta di riferimento per la quale manca il corrispondente record A (colla) nella sezione SUPPLEMENTARE

Poiché dig ha solo un nome di dominio dal record NS, dig deve risolvere il nome in un indirizzo IP interrogando il server DNS locale. Questa è la causa principale (gioco di parole, scusate).

AndrewB ha un esempio che non è del tutto coerente con ciò che ho appena descritto, in quanto il record NS della zona radice scelto:

. 121459 IN NS e.root-servers.net.

ha un record A corrispondente:

e.root-servers.net. 354907 IN A 192.203.230.10

Si noti tuttavia che non esiste un record AAAA corrispondente per e-root, né un record AAAA per alcuni altri server root.

Inoltre, nota la dimensione della risposta:

;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

496 byte è una dimensione comune per le risposte che sono state troncate (ovvero il successivo record di colla sarebbe stato> 16 byte, ponendo la risposta oltre 512 byte). In altre parole, in una query per i record NS di root, un'AUTORITÀ completa e un AGGIUNTIVO completo (entrambi i record A e AAAA) supereranno i 512 byte, quindi qualsiasi query basata su UDP che non specifica una dimensione di query più grande tramite le opzioni EDNS0 ottenere una risposta che viene interrotta da qualche parte nella sezione AGGIUNTIVA, come mostra la traccia sopra (solo f, h, i, j e k hanno record di colla A e AAAA).

La mancanza di un record AAAA per e.root-servers.net e la dimensione della risposta al "NS". query suggerisce fortemente che la successiva query ricorsiva è stata eseguita per il motivo che sto rivendicando. Forse il client O / S è compatibile con IPv6 e preferisce i record AAAA - o qualche altra ragione.

Ma in ogni caso, dopo aver letto questo thread, ho esaminato il fenomeno di dig + trace eseguendo query ricorsive successive a quella iniziale per root. Nella mia esperienza, la corrispondenza tra la selezione di un record NS senza un corrispondente record A / AAAA di colla e lo scavo, quindi l'invio di una query ricorsiva per quel record al DNS locale è del 100%. E il contrario è vero: non ho visto query ricorsive quando il record NS selezionato dal riferimento ha un record di colla corrispondente.