Jest to często spowodowane problemami z tą domeną lub jej sprawdzonymi serwerami nazw. Podane niżej czynności mogą pomóc w ustaleniu przyczyny problemu, dzięki czemu administratorzy domeny będą mogli samodzielnie rozwiązać problem.
Zanim wykonasz te czynności, sprawdź domenę na stronie dns.google, zgodnie z opisem na stronie głównej rozwiązywania problemów, która zawiera konkretny krok diagnostyczny poniżej. W przeciwnym razie wykonaj wszystkie poniższe kroki, aż znajdziesz przyczynę.
Krok 1. Sprawdź problemy z weryfikacją DNSSEC
Jeśli w wynikach wyszukiwania w domenie dns.google widoczna jest domena "Status": 2 (SERVFAIL) i zapytania bez DNSSEC, możliwe, że występuje problem z serwerami nazw DNSSSEC lub rejestrem domeny najwyższego poziomu (TLD), który publikuje rekordy DS na potrzeby weryfikacji zarejestrowanych domen DNSSEC.
- Zmiany w rejestratorze lub usłudze DNS
Problemy z DNSSEC mogą wystąpić po przełączeniu domeny z rejestratora lub usługi DNS, która obsługuje DNSSEC na taką, która nie jest obsługiwana. Jeśli poprzednia usługa pozostawia w rejestrze TLD nieaktualne rekordy
DS, a nowa usługa nie utworzy nowych rekordówDNSKEYz pasującymi rekordamiDSw rejestrze najwyższego poziomu, weryfikacja resolverów takich jak publiczny serwer DNS Google nie rozpozna domeny.W takim przypadku poproś rejestratora domeny o usunięcie nieaktualnych rekordów DS z rejestru TLD.
- Odpowiedzi DNSSEC są za duże
Inną przyczyną problemów z DNSSEC może być odpowiedź DNSSEC, która jest zbyt duża i nie mieści się w jednym pakiecie IP. Może to spowodować pofragmentowane odpowiedzi, które mogą zostać pominięte. Jeśli DNSViz nie pokazuje odpowiedzi, dopóki rozmiar ładunku UDP nie zostanie zmniejszony, przyczyną awarii mogą być bardzo duże odpowiedzi. Rozmiary odpowiedzi można zmniejszyć o co najmniej jedną z tych czynności:
- Skonfiguruj &minimalną liczbę odpowiedzi dla wiarygodnych serwerów nazw
- Zmniejsz liczbę aktywnych rekordów
DNSKEYdo 2 lub 3 - Używaj 1280- lub 2048-bitowych rekordów
DNSKEY(RFC 6781, StackExchange) - Przechodzenie z podpisów RSA na mniejsze podpisy ECDSA (RFC 8624)
Sprawdź też, czy nie wystąpiły inne problemy z DNSSEC zgłoszone przez narzędzia opisane w kroku 2. Mogą to być na przykład nieprawidłowe rekordy odmowy NSEC lub NSEC3 potwierdzające, że nie ma ich w subdomenach (PowerDNS ze strefami przechowywanymi w zewnętrznych bazach danych może je zawierać) lub wygasłe podpisy RRSIG (z uszkodzonymi ręcznie skonfigurowanymi procesami podpisywania).
Krok 2. Sprawdź wiarygodne serwery nazw
Jeśli w Google Public DNS (lub dowolnym otwartym resolverze) pojawi się problem z rozpoznaniem domeny, DNSViz pokazuje problemy z domeną i serwerem nazw, które go powodują. Otwórz stronę internetową DNSViz i wpisz problematyczną nazwę domeny. Jeśli DNSViz nie ma danych historycznych lub zawiera tylko dane sprzed ponad 1 dnia (np. widać na tej stronie), kliknij duży przycisk Analizuj, aby wyświetlić mniejszy przycisk Analizuj (jeśli nie jest jeszcze widoczny) i kliknij go. Po zakończeniu analizy kliknij „Dalej”, aby zobaczyć wyniki. Kliknij czerwone błędy i żółte ostrzeżenia na lewym pasku bocznym, aby wyświetlić szczegóły. Możesz też najechać kursorem na obiekty na diagramie, aby wyświetlić je w kontekście.
Jeśli wcześniejsza diagnostyka wykazała możliwe problemy z DNSSEC w domenie, przejdź na stronę internetową Analizatora DNS i wpisz nazwę domeny. Jeśli ten analizator zgłosi błędy lub ostrzeżenia DNSSEC, najedź kursorem na czerwone ikony
Strona intoDNS zawiera informacje o problemach niezwiązanych z DNSSEC z domeną podaną na stronie głównej oraz wskazówki dotyczące ich rozwiązywania.
Administratorzy domeny powinni naprawić większość błędów zgłaszanych przez te narzędzia, ponieważ mogą one powodować problemy nie tylko w przypadku publicznych serwerów DNS Google, ale także innych problemów.
Krok 3. Sprawdź, czy nie występują problemy z przekazaniem dostępu
Publiczny serwer DNS Google to resolver &specyficzny dla rodziców, który używa tylko serwerów nazw zwróconych w odesłaniach z domeny nadrzędnej. Jeśli nazwy serwerów nazw i adresy glue w domenie TLD są nieaktualne lub nieprawidłowe, może to spowodować problemy z przekazywaniem dostępu.
Jeśli DNSViz lub DNS zgłaszają ostrzeżenia o niespójnościach między serwerami nazw przekazanymi w domenie najwyższego poziomu i tymi występującymi w samej domenie podrzędnej, być może trzeba rozwiązać te problemy, zanim Google Public DNS rozpozna domenę. Jeśli te narzędzia informują, że zarejestrowana domena nie istnieje (NXDOMAIN), sprawdź, czy domena nie wygasła i czy z jakiegoś powodu domena nie została wstrzymana.
Problemy z przekazywaniem dostępu mogą być też spowodowane tym, że nie udało się znaleźć nazw serwerów nazw domeny. Sprawdź w rekordach A i AAAA serwery nazw na dns.google, czy nie występują problemy z serwerami nazw.
Krok 4. Sprawdź, czy nie ma dużych odpowiedzi
Większość ruchu pochodzi z serwera UDP. Duże Gramy UDP są fragmentowane, a fragmenty UDP z nieprawidłowym dostarczaniem są nieciekawe. Było to głównym tematem Dzień Flagi DNS 2020, którego celem było zwiększenie niezawodności DNS na całym świecie. Publiczny serwer DNS Google brał udział w tych działaniach i ogranicza rozmiar odpowiedzi UDP akceptowanych przez UDP. Spróbuj wpisać zapytanie podobne do poniższego, używając własnego polecenia lub Google Cloud Shell:
$ dig +short example.com NS ns1.example.com ns2.example.com $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY ...
Te zapytania dotyczące różnych typów rekordów określają:
+dnssec- Włącz DNSSEC, w szczególności zwróć rekordy wymagane do weryfikacji zabezpieczeń DNSSEC, gdy są dostępne. Dzięki temu wyniki mogą się znacznie zwiększyć. Naśladuje to działanie publicznego systemu DNS Google.
+bufsize=1400- Ogranicz dozwolony rozmiar bufora UDP. Naśladuje to zachowanie Google związane z publicznym DNS-em z dnia flagi DNS 2020.
+timeout=1- Ustaw czas oczekiwania na jedną sekundę. Naśladuje to działanie publicznego systemu DNS Google.
@ns1.example.com- Który autoryzowany serwer powinien wykonać zapytanie – zachowaj znak
@, ale zastąp go wiarygodnym serwerem własnej domeny, tak jak w pierwszym poleceniu.
Obserwuj dane wyjściowe. Czy widzisz wiersz:
;; Truncated, retrying in TCP mode.- Oznacza to, że odpowiedź była większa niż żądany rozmiar bufora UDP, więc została obcięta i w odpowiedzi klient przełączył się na port TCP. Twoje wiarygodne serwery powinny obsługiwać ruch DNS na porcie 53 TCP. (zobacz RFC 7766, który wymaga, aby implementacje MUSZĄ obsługiwać transport zarówno UDP, jak i TCP).
;; MSG SIZE rcvd: 2198- W przypadku liczby większej niż 1400? Wskazuje to na dużą odpowiedź.
;; Query time: 727 msec- W przypadku liczby większej niż 500? Powolne odpowiedzi (zwłaszcza te znajdujące się w pobliżu sekundy lub później) mogą zostać odrzucone przez publiczny serwer DNS Google. Jest to szczególnie prawdopodobne, jeśli spędziliśmy trochę czasu na próbie UDP, po której następuje próba TCP. Położenie geograficzne serwera i klienta może mieć duży wpływ na czas oczekiwania.
;; connection timed out; no servers could be reached- Zwłaszcza w przypadku niektórych zapytań oznacza problem, który sprawia, że Twój serwer nie może szybko odpowiadać na zapytania DNS.
Możesz wypróbować te odmiany zapytań:
- Dodaję parametr
+tcp. - Wymaga to od razu protokołu
dig, aby sprawdzić, czy serwer autoryzacyjny obsługuje zapytania TCP bezpośrednio w ten sposób. - Usuwam parametr
+bufsize=1400. - Spowoduje to przywrócenie domyślnego działania
dig– (obraz 4096). Jeśli zapytania nie działają z tym ustawieniem, ale bez niego nie działa, oznacza to, że serwer nie obsługuje dobrze przełączania awaryjnego TCP. Oferowanie dużych odpowiedzi tylko przy użyciu protokołu UDP działa tylko czasami. Najlepszym sposobem jest obsługa transportu TCP przez DNS. - Powtórzenie na każdym serwerze nazw.
- W powyższym przykładzie są 2 wiarygodne serwery nazw (
ns1ins2). Niektóre problemy są spowodowane przez różne serwery, które zwracają różne odpowiedzi. Sprawdź, czy wszystkie odpowiedzi są spójne, powtarzając te same zapytania na wszystkich wiarygodnych serwerach.
Jeśli odpowiedzi na wszystkie zapytania są małe (1400 bajtów lub mniej), szybko (najlepiej 500 milisekund lub mniej) i niezawodnie (działasz przez spójny protokół TCP i UDP), nie przejmuj się rozmiarem odpowiedzi – przeczytaj inne sekcje dotyczące rozwiązywania problemów. Nawet jeśli Twoje odpowiedzi są szybkie, zapytania z dalekiej lokalizacji mogą być wolniejsze.
Jeśli któraś z tych kontroli nie powiedzie się (duży? Wolne? Niezawodny?), Podstawowym krokiem jest wykonanie czynności A. Zadbaj o to, aby serwer odpowiadał skracaniem UDP, gdy jego odpowiedź przekracza żądany rozmiar bufora UDP i B), że może on wykonać ponawianie próby TCP. Kilka narzędzi pomaga w diagnozowaniu problemów z niezawodnością systemu DNS:
- DNSViz
- Debuger DNSSEC
- Tester zgodności EDNS
- Tester DNS – odznacz pole "CD" (wyłącz sprawdzanie zabezpieczeń DNSSEC).
Jeśli te narzędzia ujawnią błędy lub ostrzeżenia, pamiętaj, by je usunąć. Pamiętaj, aby zapoznać się też ze wszystkimi innymi instrukcjami rozwiązywania problemów na tej stronie.
Krok 5. Sprawdź, czy inne osoby publiczne rozpoznają domenę
Jeśli po wykonaniu tych czynności nie udało Ci się znaleźć przyczyny problemu, uruchom następujące polecenia w wierszu poleceń, zastępując example.test. odpowiednią domeną (i zachowując kropki):
Windows
nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.
macOS lub Linux
dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'
Te polecenia korzystają z resolverów DNS w OpenDNS, Quad9 i Cloudflare 1.1.1.1. Jeśli w przypadku 2 z nich i publicznego DNS Google wystąpią błędy, prawdopodobnie problem dotyczy domeny lub serwerów jej nazw.
Jeśli uzyskasz wynik w wielu innych resolverach publicznych, może to oznaczać, że wystąpił problem z publicznym DNS Google. Jeśli w narzędziu do śledzenia problemów nie zgłoszono podobnych problemów z domeną (lub jej domeną najwyższego poziomu), zgłoś nam ten problem, w tym dane wyjściowe poleceń i tekst strony diagnostycznej lub zrzuty ekranu.