Czy dig + trace zawsze jest dokładne?

Gdy kwestionowana jest dokładność pamięci podręcznej DNS, jest to dig +tracezwykle zalecany sposób określania wiarygodnej odpowiedzi dla rekordu DNS z dostępem do Internetu. Wydaje się to szczególnie przydatne, gdy jest również w połączeniu z +additional, co pokazuje również zapisy kleju.

Czasami wydaje się, że istnieje spór w tym punkcie - niektórzy twierdzą, że wyszukiwanie adresów IP pośrednich serwerów nazw zależy od lokalnego resolvera, ale dane wyjściowe polecenia nie wskazują, że dzieje się to poza początkową listą root serwery nazw. Logiczne wydaje się założenie, że nie byłoby tak, gdyby celem +tracebyło uruchomienie na serwerach root i prześledzenie drogi w dół. (przynajmniej jeśli masz odpowiednią listę głównych serwerów nazw)

Czy dig +tracenaprawdę używa lokalnego resolvera do wszystkiego, co przeszło przez główne serwery nazw?

To oczywiście zainscenizowane pytania i odpowiedzi, ale często mylą ludzi i nie mogę znaleźć kanonicznego pytania na ten temat.

dig +tracejest doskonałym narzędziem diagnostycznym, ale jeden aspekt jego budowy jest powszechnie źle rozumiany: adres IP każdego serwera, który będzie pytany, jest uzyskiwany z biblioteki resolvera . Jest to bardzo łatwe do przeoczenia i często staje się problemem, gdy lokalna pamięć podręczna ma złą odpowiedź na buforowany serwer nazw.

Szczegółowa analiza

Łatwiej jest to rozbić na próbce danych wyjściowych; Pominę wszystko po pierwszej delegacji 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

• Początkowe zapytanie dla . IN NS(root nameservers) trafia do lokalnego resolvera, którym w tym przypadku jest Comcast. ( 75.75.75.75) Łatwo to zauważyć.
• Kolejne zapytanie dotyczy serverfault.com. IN Ai jest uruchamiane z e.root-servers.net.losowo wybranym z listy właśnie otrzymanych głównych serwerów nazw. Ma adres IP 192.203.230.10, a ponieważ +additionalwłączyliśmy, wydaje się, że pochodzi z kleju.
• Ponieważ nie jest autorytatywny dla serverfault.com, zostaje on przekazany do com.serwerów nazw TLD.
• To, co nie jest oczywiste na podstawie danych wyjściowych, to to, że dignie uzyskano adresu IP e.root-servers.net.z kleju.

W tle tak naprawdę się stało:

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)

+traceoszukał i skonsultował się z lokalnym tłumaczem, aby uzyskać adres IP serwera nazw następnego skoku zamiast sprawdzania kleju. Podstępny!

Zwykle jest to „wystarczająco dobre” i nie powoduje problemów dla większości ludzi. Niestety są przypadki skrajne. Jeśli z jakiegoś powodu twoja pamięć podręczna DNS podaje złą odpowiedź dla serwera nazw, ten model całkowicie się psuje.

Przykład ze świata rzeczywistego:

• domena wygasa
• klej jest ponownie wyznaczany na serwerach nazw przekierowań rejestratora
• fałszywe adresy IP są buforowane dla ns1 i ns2.twojadomena.com
• domena jest odnawiana z przywróconym klejem
• wszelkie pamięci podręczne z fałszywymi adresami IP serwerów nazw nadal wysyłają użytkowników do witryny internetowej z informacją, że domena jest na sprzedaż

W powyższym przypadku +tracezasugeruje, że źródłem problemu są własne serwery nazw właściciela domeny, a użytkownik ma problem z niepoprawnym poinformowaniem klienta, że ​​jego serwery są źle skonfigurowane. To, czy możesz coś zrobić (lub chcesz to zrobić), to inna historia, ale ważne jest, aby mieć odpowiednie informacje.

dig +trace to świetne narzędzie, ale jak każde narzędzie musisz wiedzieć, co robi, a czego nie, oraz jak ręcznie rozwiązać problem, gdy okaże się niewystarczający.

Edytować:

Należy również zauważyć, że dig +tracenie ostrzeże Cię przed NSrekordami wskazującymi na CNAMEaliasy. Jest to naruszenie RFC, którego ISC BIND (i ewentualnie inne) nie będzie próbował naprawić. +tracez przyjemnością przyjmie Arekord, który otrzymuje z lokalnie skonfigurowanego serwera nazw, natomiast jeśli BIND wykona pełną rekurencję, odrzuci całą strefę za pomocą SERVFAIL.

Problem może być trudny do rozwiązania, jeśli klej jest obecny; będzie to działać dobrze, dopóki rekordy NS nie zostaną odświeżone , a następnie nagle się zepsują. Delegacje bez kleju zawsze przerywają rekurencję BIND, gdy NSrekord wskazuje na alias.

Innym sposobem śledzenia rozdzielczości DNS bez użycia lokalnego resolvera do niczego poza znalezieniem głównych serwerów nazw, jest użycie dnsgraph (pełne ujawnienie: napisałem to). Ma narzędzie wiersza polecenia i wersję internetową, której instancję można znaleźć na stronie http://ip.seveas.net/dnsgraph/

Przykład dla serverfault.com, który obecnie ma problem z DNS:

Bardzo późno do tego wątku, ale myślę, że część pytania, dlaczego dig + trace używa rekurencyjnych zapytań do lokalnych resolverów, nie została bezpośrednio wyjaśniona, a to wyjaśnienie jest istotne dla dokładności wyników dig + trace.

Po początkowym rekurencyjnym zapytaniu o rekordy NS strefy głównej, kopanie może wydawać kolejne zapytania lokalnym tłumaczom, pod następującymi warunkami:

1. odpowiedź na polecenie jest obcinana ze względu na rozmiar odpowiedzi przekraczający 512 bajtów dla następnego zapytania iteracyjnego

2. dig wybiera rekord NS z sekcji AUTHORITY odpowiedzi na polecenie, dla której brakuje odpowiedniego rekordu A (kleju) w sekcji DODATKOWEJ

Ponieważ dig ma tylko nazwę domeny z rekordu NS, dig musi przekształcić nazwę na adres IP poprzez zapytanie do lokalnego serwera DNS. To jest podstawowa przyczyna (gra słów zamierzona, przepraszam).

AndrewB ma przykład, który nie jest w pełni zgodny z tym, co właśnie opisałem, w tym, że wybrano rekord strefy głównej strefy NS:

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

ma odpowiedni rekord A:

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

Należy jednak pamiętać, że nie ma odpowiedniego rekordu AAAA dla e-root, a także żadnego rekordu AAAA dla niektórych innych serwerów root.

Zwróć również uwagę na rozmiar odpowiedzi:

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

496 bajtów to wspólny rozmiar odpowiedzi, które zostały obcięte (tzn. Następny rekord kleju miałby> 16 bajtów, co daje odpowiedź ponad 512 bajtów). Innymi słowy, w zapytaniu o rekordy NS root, pełny AUTORYZACJA i kompletny DODATKOWY (zarówno rekordy A, jak i AAAA) przekroczy 512 bajtów, więc każde zapytanie oparte na UDP, które nie określi większego rozmiaru zapytania za pomocą opcji EDNS0, będzie uzyskaj odpowiedź, która jest odcięta gdzieś w sekcji DODATKOWE, jak pokazuje powyższy ślad (tylko f, h, i, j oraz k mają rekordy kleju A i AAAA).

Brak rekordu AAAA dla e.root-servers.net i rozmiar odpowiedzi na „NS”. zapytanie zdecydowanie sugeruje, że następne zapytanie rekurencyjne zostało wykonane z powodu, dla którego twierdzę. Być może system operacyjny klienta obsługuje protokół IPv6 i woli zapisy AAAA - lub z innego powodu.

Ale w każdym razie, po przeczytaniu tego wątku, przyjrzałem się zjawisku dig + trace wykonując zapytania rekurencyjne po pierwszym dla roota. Z mojego doświadczenia wynika, że ​​korespondencja pomiędzy wyborem rekordu NS bez odpowiedniego rekordu A / AAAA z klejem a wykopaniem, a następnie wysłaniem rekursywnego zapytania do tego rekordu do lokalnego DNS jest 100%. I jest odwrotnie - nie widziałem zapytań rekurencyjnych, gdy rekord NS wybrany z polecenia ma odpowiedni rekord kleju.