DNS_PROBE_FINISHED_NXDOMAIN zwykle oznacza, że resolver otrzymał informację, iż pytana nazwa domenowa nie istnieje. Przyczyną może być brak rekordu lub całej nazwy w aktywnej strefie, korzystanie ze starej delegacji prowadzącej do niewłaściwej strefy albo zapisana wcześniej negatywna odpowiedź DNS. Inne błędy delegacji mogą natomiast kończyć się również SERVFAIL albo brakiem odpowiedzi.
Nie jest to błąd WordPressa ani samego serwera WWW. Jeżeli przeglądarka nie potrafi rozwiązać nazwy domenowej, żądanie HTTP może w ogóle nie dotrzeć do hostingu.
Przy NXDOMAIN najpierw ustal, na którym poziomie DNS znika odpowiedź: aktywna delegacja, publikowana strefa, konkretna nazwa czy resolver używany przez użytkownika.
Co oznacza NXDOMAIN?
NXDOMAIN oznacza odpowiedź DNS informującą, że pytana nazwa domenowa nie istnieje. To coś innego niż sytuacja, w której domena istnieje, ale nie ma konkretnego typu rekordu oczekiwanego przez aplikację.
| Sytuacja | Co sprawdzić |
|---|---|
| Cała domena zwraca NXDOMAIN | Jakie NS są aktualnie delegowane i czy właściwe serwery autorytatywne rzeczywiście publikują tę nazwę lub strefę |
| Działa domena główna, ale nie działa subdomena | Rekord dla konkretnej nazwy |
| Domena działa u części użytkowników | Cache resolverów i niedawną zmianę DNS |
| DNS działa, ale strona nadal się nie otwiera | Hosting, HTTP/HTTPS i aplikację — to już inna warstwa |
Dlatego sam komunikat przeglądarki nie wystarcza. Trzeba sprawdzić rzeczywistą odpowiedź DNS dla nazwy, która nie działa.
Po migracji najpierw sprawdź delegację domeny
Strefa DNS może być skonfigurowana poprawnie na nowym hostingu, ale internet nie będzie z niej korzystał, jeśli domena nadal jest delegowana na inne serwery nazw.
Delegacja określa, które serwery DNS są autorytatywne dla domeny. Przy zmianie operatora łatwo pomylić dwie osobne czynności:
- dodanie strefy DNS u nowego dostawcy,
- zmianę serwerów nazw domeny u rejestratora.
Samo wykonanie pierwszej czynności nie przełącza ruchu DNS.
W drugą stronę problem jest równie możliwy: delegacja została już zmieniona, ale na nowych serwerach nazw nie istnieje kompletna strefa. W zależności od konfiguracji i rodzaju problemu efektem może być NXDOMAIN, SERVFAIL albo brak użytecznej odpowiedzi, dlatego trzeba sprawdzać faktyczny wynik zapytania, a nie tylko zakładać „błąd delegacji”.
Strefa istnieje, ale konkretnego rekordu może brakować
Jeżeli domena główna działa, a problem dotyczy tylko www.example.pl, panel.example.pl albo innej subdomeny, delegacja prawdopodobnie nie jest pierwszym miejscem do diagnozy.
Trzeba wtedy sprawdzić rekord dotyczący dokładnie tej nazwy. Dla witryny mogą to być na przykład:
A— adres IPv4,AAAA— adres IPv6,CNAME— alias prowadzący do innej nazwy.
Ważny jest dokładny hostname. Rekord dla domeny głównej nie tworzy automatycznie rekordu www, a rekord www nie oznacza, że każda inna subdomena również istnieje.
Przy migracji warto więc sprawdzać nazwy używane rzeczywiście przez stronę, pocztę, panel czy API, zamiast ograniczać test do samej domeny głównej.
NXDOMAIN może pozostać w cache — porównaj authoritative DNS z resolverem
Cache DNS dotyczy nie tylko poprawnych odpowiedzi. Resolver może przechowywać również informację, że dana nazwa nie istnieje. Jest to tzw. negative caching.
Możliwy jest więc taki scenariusz:
- użytkownik pyta o subdomenę, zanim zostanie utworzony jej rekord,
- DNS odpowiada NXDOMAIN,
- administrator dodaje poprawny rekord,
- część resolverów nadal przez pewien czas korzysta z zapisanej odpowiedzi negatywnej.
Czas przechowywania NXDOMAIN nie wynika z TTL nieistniejącego rekordu. Resolver wykorzystuje parametr odpowiedzi negatywnej pochodzący z rekordu SOA strefy.
TTL zwykłego rekordu nadal określa, jak długo resolver może przechowywać pozytywną odpowiedź w cache. Nie istnieje jednak jeden globalny zegar odliczający „propagację DNS”: różne resolvery mogą mieć wpisy pobrane w innym momencie, a odpowiedzi negatywne mają własny mechanizm cache.
Najbardziej użyteczne jest porównanie odpowiedzi serwera autorytatywnego i resolvera rekursywnego. Serwer autorytatywny powinien odpowiadać zgodnie z aktualną strefą administratora domeny, natomiast resolver może przez pewien czas korzystać z odpowiedzi zapisanej wcześniej.
Jeżeli oba zwracają NXDOMAIN, trzeba wrócić do aktywnej delegacji lub samej strefy. Jeżeli authoritative DNS zwraca już poprawny rekord, a pojedynczy resolver nadal NXDOMAIN, problem jest znacznie lepiej zawężony i nie ma sensu ponownie zmieniać rekordu tylko po to, aby „wymusić propagację”.
Warto też porównać więcej niż jeden publiczny resolver. Zmiana DNS w komputerze może pomóc w teście, jeśli jeden konkretny resolver ma starą odpowiedź, ale nie naprawi błędnej delegacji ani brakującego rekordu na serwerze autorytatywnym.
Jeżeli przygotowujesz zmianę hostingu, można wcześniej sprawdzić domenę narzędziem Diagnostyka domeny przed migracją.
DNS może być już poprawny, a strona nadal nie działać
Jeżeli domena zwraca właściwy adres IP lub poprawny CNAME, etap rozwiązywania nazwy został zakończony. Następny problem może występować już w innej warstwie.
Przykładowo:
- serwer WWW nie ma skonfigurowanej domeny,
- certyfikat TLS jest nieprawidłowy,
- WordPress przekierowuje na zły adres,
- po migracji występuje pętla redirectów,
- hosting odpowiada błędem HTTP.
Wtedy dalsze zmiany DNS mogą tylko zaciemnić diagnozę. Przy pętli przekierowań przejdź do poradnika ERR_TOO_MANY_REDIRECTS w WordPressie, a nie do kolejnej edycji rekordów.
Bezpieczna procedura diagnozy NXDOMAIN
- Zapisz dokładną nazwę, która nie działa. Domena główna czy konkretna subdomena?
- Sprawdź aktualną delegację NS.
- Potwierdź, że na serwerach autorytatywnych istnieje właściwa strefa.
- Sprawdź konkretny rekord A, AAAA lub CNAME dla problematycznej nazwy.
- Porównaj odpowiedź authoritative DNS z jednym lub kilkoma resolverami rekursywnymi.
- Jeżeli authoritative odpowiada poprawnie, uwzględnij cache i negative caching.
- Nie zmieniaj ponownie rekordu tylko dlatego, że jeden resolver ma jeszcze stary wynik.
- Gdy DNS zwraca już właściwy adres, przenieś diagnozę do warstwy HTTP/TLS/aplikacji.
Przy zgłoszeniu do rejestratora lub hostingu warto podać dokładną nazwę, oczekiwany rekord, aktualne serwery NS oraz wynik otrzymywany z serwera autorytatywnego. To daje znacznie więcej informacji niż samo „domena u mnie nie działa”.
Najważniejsze wnioski
- NXDOMAIN oznacza, że DNS informuje o nieistnieniu pytanej nazwy;
- nie każdy problem delegacji kończy się NXDOMAIN — możliwy jest również
SERVFAILalbo brak odpowiedzi; - utworzenie strefy na nowym hostingu i zmiana delegacji u rejestratora to dwie oddzielne czynności;
- rekord domeny głównej nie tworzy automatycznie rekordów wszystkich subdomen;
- odpowiedzi NXDOMAIN mogą być przechowywane w cache;
- czas cache'owania NXDOMAIN wynika z informacji SOA, a nie z TTL nieistniejącego rekordu;
- warto rozdzielić odpowiedź serwera autorytatywnego od odpowiedzi resolvera rekursywnego;
- zmiana lokalnego DNS może pomóc w teście, ale nie naprawi błędnej strefy;
- jeśli DNS jest już prawidłowy, dalszego problemu trzeba szukać w kolejnej warstwie.
Źródła
- RFC 2308 — Negative Caching of DNS Queries — NXDOMAIN, NODATA i cache odpowiedzi negatywnych.
- RFC 9499 — DNS Terminology — aktualna terminologia DNS, w tym pojęcia związane z delegacją i rolami serwerów.
- RFC 9520 — Negative Caching of DNS Resolution Failures — cache innych błędów rozwiązywania DNS niż NXDOMAIN/NODATA.
- RFC 1034 — Domain Names: Concepts and Facilities — hierarchia DNS, strefy i serwery nazw.
- RFC 1035 — Domain Names: Implementation and Specification — rekordy i działanie protokołu DNS.
- Cloudflare Learning Center — DNS servers — resolver rekursywny i authoritative DNS.
- Cloudflare Learning Center — DNS A record — rekord A.
- Cloudflare Learning Center — CNAME record — aliasy DNS.