Jak mogę rozwiązać problemy z DNS gdzieś w trakcie rekurencji?

Mam naprawdę dziwny problem z moim DNS. Mojej nazwy domeny ( strugee.net) nie da się rozwiązać w niektórych sieciach, a w innych.

Na przykład w mojej sieci domowej (ta sama sieć, w której znajduje się serwer):

% dig strugee.net

; <<>> DiG 9.10.3-P4 <<>> strugee.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10086
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;strugee.net.           IN  A

;; ANSWER SECTION:
strugee.net.        1800    IN  A   216.160.72.225

;; Query time: 186 msec
;; SERVER: 205.171.3.65#53(205.171.3.65)
;; WHEN: Sat Apr 16 15:42:36 PDT 2016
;; MSG SIZE  rcvd: 56

Jednak jeśli zaloguję się na serwerze, który mam na Digital Ocean, domena nie rozwiąże:

% dig strugee.net      

; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> strugee.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58551
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;strugee.net.           IN  A

;; Query time: 110 msec
;; SERVER: 2001:4860:4860::8844#53(2001:4860:4860::8844)
;; WHEN: Sat Apr 16 18:44:25 EDT 2016
;; MSG SIZE  rcvd: 40

Ale przejście bezpośrednio do autorytatywnych serwerów nazw działa dobrze:

% dig @dns1.registrar-servers.com strugee.net   

; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> @dns1.registrar-servers.com strugee.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30856
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;strugee.net.           IN  A

;; ANSWER SECTION:
strugee.net.        1800    IN  A   216.160.72.225

;; AUTHORITY SECTION:
strugee.net.        1800    IN  NS  dns3.registrar-servers.com.
strugee.net.        1800    IN  NS  dns4.registrar-servers.com.
strugee.net.        1800    IN  NS  dns2.registrar-servers.com.
strugee.net.        1800    IN  NS  dns1.registrar-servers.com.
strugee.net.        1800    IN  NS  dns5.registrar-servers.com.

;; Query time: 3 msec
;; SERVER: 216.87.155.33#53(216.87.155.33)
;; WHEN: Sat Apr 16 18:46:36 EDT 2016
;; MSG SIZE  rcvd: 172

Jest całkiem jasne, że istnieje problem z jakąś dużą siecią, która nie rozwiązuje mojej domeny, ale wydaje mi się, że nie wiem, gdzie. Przejrzałem stronę digpodręczną w poszukiwaniu opcji, które mogą pomóc, ale nie znalazłem nic szczególnie przydatnego.

Jestem na Namecheap zarówno jako rejestrator domen, jak i hosting DNS. Mam włączoną opcję DNSSEC. Ostatnio nie wprowadziłem żadnych zmian w ustawieniach DNS.

Jak mogę debugować ten problem i znaleźć szkodliwy serwer nazw?

domain-name-system recursive

— strugee
źródło

Dziękujemy za podanie nazwy domeny. Problemy takie jak ten są niezwykle trudne do rozwiązania przez nas w usłudze Serverfault bez tych informacji.

— Andrew B

@AndrewB och, wiem. Nie ma za co, zaufaj mi :)

— strugee

@ Odpowiedź AndrewB ma sens i wydaje mi się poprawna. Zanim jednak to przeczytałem, zauważyłem, że twoje nieudane zapytanie używało serwera nazw IPV6, podczas gdy te, które zakończyły się sukcesem, używały IPV4. Często (oczywiście nie w tym przypadku) wskazuje to na złą konfigurację IPV6 i pomocne może być jawne użycie numerycznych adresów IPV [4/6] serwerów nazw zamiast aliasów.

— Guntram Blohm obsługuje Monikę

@Guntram Tak długo jak będziemy pamiętać, że mamy odpowiedź od do serwera nazw, co oznacza, że mamy połączenie do serwera DNS, przynajmniej. Chcę tylko upewnić się, że ludzie nie odejdą od tego z niewłaściwym wrażeniem ... SERVFAILmoże wskazywać na problem z nadrzędną wersją, ale nadal oznacza pakiet odpowiedzi.

— Andrew B,

@GuntramBlohm Jesteś na czymś. strugee.netma pięć rekordów NS, ale brak AAAAzapisów Akleju, tylko zapisy kleju. Co gorsza, te pięć Arekordów kleju wskazuje tylko na dwa różne adresy IP. To wydaje się dość kruche. Nawet jeśli nie jest to podstawowa przyczyna problemu, na który należy zwrócić uwagę.

— kasperd

Odpowiedzi:

Jak mogę debugować ten problem i znaleźć szkodliwy serwer nazw?

daxd5 oferuje kilka dobrych rad na początek, ale jedyną prawdziwą odpowiedzią jest to, że musisz wiedzieć, jak myśleć jak rekurencyjny serwer DNS. Ponieważ w autorytatywnej warstwie występuje wiele błędnych konfiguracji, które mogą powodować niespójność SERVFAIL, potrzebujesz profesjonalnych narzędzi DNS lub narzędzi do sprawdzania poprawności online.

W każdym razie celem nie jest wyrzucenie cię z pomocy, ale chciałem upewnić się, że rozumiesz, że nie ma rozstrzygającej odpowiedzi na to pytanie.

W twoim konkretnym przypadku zauważyłem, że strugee.netwygląda na strefę podpisaną za pomocą DNSSEC. Widać to po obecności DSi RRSIGzapisów w łańcuchu poleceń:

# dig +trace +additional strugee.net
<snip>
strugee.net.            172800  IN      NS      dns2.registrar-servers.com.
strugee.net.            172800  IN      NS      dns1.registrar-servers.com.
strugee.net.            172800  IN      NS      dns3.registrar-servers.com.
strugee.net.            172800  IN      NS      dns4.registrar-servers.com.
strugee.net.            172800  IN      NS      dns5.registrar-servers.com.
strugee.net.            86400   IN      DS      16517 8 1 B08CDBF73B89CCEB2FD3280087D880F062A454C2
strugee.net.            86400   IN      RRSIG   DS 8 2 86400 20160423051619 20160416040619 50762 net. w76PbsjxgmKAIzJmklqKN2rofq1e+TfzorN+LBQVO4+1Qs9Gadu1OrPf XXgt/AmelameSMkEOQTVqzriGSB21azTjY/lLXBa553C7fSgNNaEXVaZ xyQ1W/K5OALXzkDLmjcljyEt4GLfcA+M3VsQyuWI4tJOng184rGuVvJO RuI=
dns2.registrar-servers.com. 172800 IN   A       216.87.152.33
dns1.registrar-servers.com. 172800 IN   A       216.87.155.33
dns3.registrar-servers.com. 172800 IN   A       216.87.155.33
dns4.registrar-servers.com. 172800 IN   A       216.87.152.33
dns5.registrar-servers.com. 172800 IN   A       216.87.155.33
;; Received 435 bytes from 192.41.162.30#53(l.gtld-servers.net) in 30 ms

Zanim przejdziemy dalej, musimy sprawdzić, czy podpisanie jest prawidłowe. DNSViz jest narzędziem często używanym do tego celu i potwierdza, że rzeczywiście istnieją problemy . Wściekła czerwień na obrazie sugeruje, że masz problem, ale zamiast rozmyślać nad wszystkim, możemy po prostu rozwinąć Powiadomienia na lewym pasku bocznym:

RRSIG strugee.net/A alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/DNSKEY alg 8, id 16517: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/DNSKEY alg 8, id 16517: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/MX alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/NS alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/SOA alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/TXT alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
net to strugee.net: No valid RRSIGs made by a key corresponding to a DS RR were found covering the DNSKEY RRset, resulting in no secure entry point (SEP) into the zone. (216.87.152.33, 216.87.155.33, UDP_0_EDNS0_32768_4096)

Problem jest jasny: podpis w Twojej strefie wygasł i klucze muszą zostać odświeżone. Powodem, dla którego widzisz niespójne wyniki, jest to, że nie wszystkie serwery rekurencyjne mają włączoną weryfikację DNSSEC. Jedni, którzy się sprawdzają, opuszczają domenę, a ci, którzy tego nie robią, działają jak zwykle.

Edycja: infrastruktura DNS Comcast jest znana z implementacji sprawdzania poprawności DNSSEC i jako jeden z ich klientów mogę potwierdzić, że również ją widzę SERVFAIL.

$ dig @75.75.75.75 strugee.net | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2011

— Andrew B.
źródło

Ups, miałem stugee.netw wyjściu dig, co oczywiście jest literówką. Część DNSSEC tej analizy została przeprowadzona dla poprawnej nazwy.

— Andrew B

Chociaż rzeczywiście widzisz, że autorytatywne serwery nazw odpowiadają poprawnie, musisz śledzić cały łańcuch rozwiązywania DNS. To jest, przejdź całą hierarchię DNS od serwerów głównych w górę.

$ dig net NS
;; ANSWER SECTION:
net.            172800  IN  NS  c.gtld-servers.net.
net.            172800  IN  NS  f.gtld-servers.net.
net.            172800  IN  NS  k.gtld-servers.net.
;; snipped extra servers given
$ dig @c.gtld-servers.net strugee.net NS
;; AUTHORITY SECTION:
strugee.net.        172800  IN  NS  dns2.registrar-servers.com.
strugee.net.        172800  IN  NS  dns1.registrar-servers.com.
;; snipped extra servers again

To w zasadzie sprawdza, czy publiczne serwery DNS działają, a ty robisz to samo, co powinien być twój resolver DNS. Powinieneś więc otrzymywać takie same odpowiedzi jak powyżej na serwerze Digital Ocean, chyba że coś jest nie tak z ich usługą rozpoznawania nazw DNS:

$ dig net NS
$ dig strugee.net NS
$ dig strugee.net

Jeśli dwa pierwsze zapytania zawiodą, oznacza to awarię DNS po stronie Digital Ocean. Sprawdź swój /etc/resolv.confi spróbuj wykonać zapytanie do dodatkowego serwera DNS. Jeśli drugi działa, po prostu zmień kolejność na resolwery i spróbuj ponownie.

— daxd5
źródło