Popularne narzędzia

Motyw

Sprawdź rekordy DNS

Darmowy DNS lookup dla dowolnej domeny, hosta lub adresu IP: sprawdź wszystkie rekordy DNS prosto z serwerów nazw domeny, obok kopii, które trzymają Google i Cloudflare, i zobacz, kiedy zmiana dotrze do wszystkich.

Źródła: autorytatywne serwery nazw domeny, do których docieramy od serwera głównego · Google Public DNS · Cloudflare 1.1.1.1

3 źródła, pytamy od nowa

Domena, host, URL, adres e-mail lub IP. Każde sprawdzenie pyta serwery od nowa: nic nie pochodzi z naszego cache.

Typ rekordu
Wypróbuj

Jak to sprawdzamy 4 kroki · około 1 s

  1. Root13 serwerów głównych
  2. TLDserwery rejestru
  3. Serwer nazwserwery samej domeny
  4. Odpowiedźkażdy typ rekordu
  5. Google8.8.8.8
  6. Cloudflare1.1.1.1

Każde sprawdzenie samo przechodzi całą ścieżkę: od serwera głównego do rejestru TLD, potem do własnych serwerów nazw domeny po rekordy w aktualnej postaci, i pyta Google oraz Cloudflare, co jeszcze trzymają w cache.

Co pokazuje sprawdzenie rekordów DNS

DNS lookup, czyli sprawdzenie DNS, pyta system nazw domen (Domain Name System), co ma zapisane dla danej nazwy: adresy IP strony (A i AAAA), jej serwery poczty (MX), serwery nazw (NS), rekordy tekstowe (TXT) i inne. To sprawdzenie DNS pyta jednocześnie trzy miejsca: autorytatywne serwery nazw samej domeny, które mają aktualne dane, oraz dwa z najbardziej obciążonych publicznych resolverów na świecie, Google Public DNS i Cloudflare 1.1.1.1, które podają kopie z cache milionom ludzi.

Gdy te źródła się nie zgadzają, masz przed sobą typowy powód, dla którego zmiana w DNS „nie działa”: resolver wciąż ma starą odpowiedź i trzyma ją, dopóki nie minie TTL rekordu. Wynik pokazuje, który to resolver, co jeszcze podaje i ile zostało do odświeżenia.

Sprawdzanie rekordów DNS: rekordy z serwerów nazw domeny obok cache Google i Cloudflare, ścieżka od serwera głównego i DNSSECSprawdzanie rekordów DNS: rekordy z serwerów nazw domeny obok cache Google i Cloudflare, ścieżka od serwera głównego i DNSSECŚcieżkaOd serwera głównego przez TLD domeny do jej własnych serwerów nazw, z tym, co odpowiedział każdy z nich i jak szybko.Świeże czy z cacheKażdy typ rekordu z serwerów nazw domeny obok kopii Google i Cloudflare oraz czas, jaki tej kopii pozostał.Każdy rekord objaśnionyCo oznacza wartość, opisane słowami: priorytet poczty, timery SOA, reguły CAA, usługa stojąca za tokenem TXT.DNSSEC i pocztaCzy odpowiedzi są podpisane i zweryfikowane, oraz konfiguracja MX, SPF i DMARC domeny.
Sprawdzenie DNS dla github.com: ścieżka od serwera głównego, każdy typ rekordu i to, co podają Google i Cloudflare. Wybierz numer, aby zobaczyć, co pokazuje każda część.

Typy rekordów DNS i co oznaczają

Strefa domeny zawiera rekordy różnych typów, a każdy z nich ma nazwę, TTL i wartość. Oto te, które pokazuje sprawdzenie rekordów DNS:

TypCo zawieraPrzykładowa wartość
AAdres IPv4 dla nazwy: tam łączą się przeglądarki.203.0.113.20
AAAAAdres IPv6 dla nazwy.2001:db8::20
CNAMEAlias: ta nazwa jest inną nazwą, więc sprawdź zamiast niej tamtą. Nie może istnieć obok innych rekordów, dlatego nie na wierzchołku domeny (apex).www.example.com → example.com
MXSerwer poczty domeny z preferencją: najpierw próbowany jest najniższy numer. Pojedynczy MX z 0 i „.” oznacza, że domena nie przyjmuje poczty.10 mail.example.com
NSSerwery nazw, które przechowują rekordy domeny.ns1.example.net
TXTDowolny tekst: SPF, DMARC i DKIM dla poczty oraz tokeny potwierdzające domenę w Google, Microsofcie i innych usługach.v=spf1 include:_spf.example.net -all
SOAPoczątek strefy autorytatywnej (start of authority): jej główny serwer, kontakt, numer seryjny oraz liczniki odświeżania, ponawiania, wygaśnięcia i negatywnego cache.ns1.example.com hostmaster.example.com 2026102001 7200 3600 1209600 300
CAAKtóre urzędy certyfikacji mogą wydawać certyfikaty dla domeny.0 issue "letsencrypt.org"
HTTPSJak się połączyć przed pierwszym żądaniem: obsługa HTTP/3, porty i wskazówki adresów. Pytają o niego Chrome, Firefox i systemy Apple.1 . alpn=h3,h2
SRVGdzie działa usługa (priorytet, waga, port, host), pod nazwami takimi jak _sip._tcp.10 5 5060 sip.example.com
PTRNazwa stojąca za adresem IP: odwrotny DNS.20.113.0.203.in-addr.arpa → host.example.com
DSDNSKEYDNSSEC: klucze publiczne strefy (DNSKEY) i ich odcisk w strefie nadrzędnej (DS), które łączą podpisy w łańcuch aż do strefy głównej (root).2371 13 2 3299…

Jak działa DNS lookup?

Twoje urządzenie nie przeszukuje całego internetu. Pyta jeden resolver, zwykle twojego dostawcy internetu albo publiczny, np. Google lub Cloudflare, a resolver podąża za odesłaniami w dół nazwy, aż odpowie serwer, który ma odpowiedź:

  1. 1

    Zapytaj serwer główny

    Bez niczego w cache resolver zaczyna od jednego z 13 serwerów głównych (root), od a do m, prowadzonych przez 12 organizacji. Serwer główny nie zna example.com, ale wie, kto obsługuje .com. Intensywnie używany resolver już to wie i pomija ten krok.

  2. 2

    Podążaj za odesłaniem do TLD

    Serwery .com też nie mają rekordów example.com. Odsyłają resolver do własnych serwerów nazw domeny, tych z jej rekordów NS.

  3. 3

    Odbierz odpowiedź autorytatywną

    Serwery nazw domeny odpowiadają z ustawioną flagą AA (authoritative answer): to rekord w takiej postaci, w jakiej opublikował go właściciel.

  4. 4

    Zapisz w cache na czas TTL

    Resolver trzyma odpowiedź tak długo, jak mówi jej TTL, i podaje tę samą kopię, z odliczanym TTL, każdemu, kto zapyta, aż ten czas minie.

To narzędzie samo przechodzi tę ścieżkę z sieci Cloudflare, więc widzisz każdy krok. Potem pyta Google i Cloudflare, aby pokazać, co mają w cache.

Ścieżka od serwera głównego

  1. Roota.root-servers.net16 ms · odesłanie: serwery .com (13)
  2. .COMa.gtld-servers.netVerisign · 150 ms · odesłanie: ns1–ns2.example.com
  3. Serwer nazwns1.example.comexample.com · 203.0.113.53 · 20 msodpowiedź autorytatywna (AA) · 11 typów w jednym połączeniu TCP
  4. Odpowiedź8 rekordów (7 typów)NOERROR w 31 ms · puste: 4 (CNAME, HTTPS, DNSKEY, DS)
  1. Google Public DNS8.8.8.8te same rekordy · najstarsza kopia odświeży się za 2:58
  2. Cloudflare DNS1.1.1.1te same rekordy · najstarsza kopia odświeży się za 4:04
Ta sama ścieżka, którą rysuje wynik: sprawdzenie example.com

Dlaczego wciąż widzę stary rekord DNS?

Bo resolver zapisał go w pamięci podręcznej (cache). Każdy rekord ma TTL (time to live, czas życia) w sekundach, a resolver, który pobrał rekord, podaje swoją kopię, dopóki ten czas nie minie, a potem pyta ponownie. Zmiana rekordu u dostawcy DNS od razu zmienia odpowiedź autorytatywną; resolvery, które mają już starą wersję, trzymają ją, aż wygaśnie.

Zmiana trwa więc tyle, ile TTL starego rekordu, a nie sztywne 24 do 48 godzin, i często krócej: TTL to maksimum, a Google Public DNS trzyma rekordy najwyżej przez około sześć godzin. Brak rekordu też trafia do cache: „taka nazwa nie istnieje” albo „brak rekordu tego typu” jest pamiętane przez mniejszą z dwóch wartości: TTL rekordu SOA i jego ostatnie pole, MINIMUM. Nawet błąd trafia do cache, na maksymalnie 5 minut.

Co możesz zrobić

  • Sprawdź tutaj odpowiedź autorytatywną. Jeśli serwery nazw domeny pokazują nową wartość, zmiana jest gotowa; opóźnione są tylko kopie w cache.
  • Obniż TTL przed planowaną zmianą, co najmniej o jeden stary TTL wcześniej, aby cache szybko porzuciły starą wartość. Potem podnieś go z powrotem.
  • Poproś Google i Cloudflare o usunięcie ich kopii: oba mają publiczną stronę, która odświeża nazwę w ich cache (Google, Cloudflare).
  • Wyczyść cache swojego komputera: w Windows uruchom ipconfig /flushdns.
  • Autorytatywnyns1.example.com · flaga AA

    Własny serwer nazw domeny. To, co odpowiada, jest aktualnym rekordem: zmień go tutaj, a reszta pójdzie za nim.

  • Cache8.8.8.8 · TTL odlicza w dół

    Kopia resolvera, podawana, dopóki nie minie jej TTL. To widzi większość świata i dlatego wydaje się, że zmiana „nie działa”.

  • Twój własny cachetwój komputer · twój router

    Twój komputer i router też trzymają kopie. Opróżnienie cache czyści tę pierwszą; kopia w routerze wygasa sama.

nslookup i dig: polecenia do sprawdzania DNS

Te same zapytania z terminala: nslookup jest w Windows, macOS i Linuksie, dig w macOS i większości systemów Linux, a Resolve-DnsName w PowerShellu w Windows. Wynik powyżej podaje polecenia dokładnie dla twojego sprawdzenia.

Co sprawdzićnslookupdig
Rekordy Anslookup example.comdig example.com
Serwery pocztynslookup -type=MX example.comdig example.com MX
Rekordy tekstowenslookup -type=TXT example.comdig example.com TXT
Zapytanie do jednego resolveranslookup example.com 8.8.8.8dig @8.8.8.8 example.com
Odwrotny DNSnslookup 8.8.8.8dig -x 8.8.8.8
Same wartości—dig +short example.com
Ścieżka od serwera głównego—dig +trace example.com

„Non-authoritative answer” w wyniku nslookup oznacza, że odpowiedź przyszła z resolvera, a nie z serwerów nazw domeny. Aby dostać odpowiedź autorytatywną, podaj jako serwer jeden z serwerów nazw domeny: nslookup example.com ns1.example.net.

ANY nie oznacza wszystkich rekordów: serwer może odpowiedzieć jednym typem albo odpowiedzią zastępczą z samym „RFC8482”, a 1.1.1.1 w ogóle takiego zapytania odmawia. To narzędzie pyta o każdy typ osobno. dig dołączony do macOS nie zna rekordów HTTPS: zapytaj zamiast tego o TYPE65.

Błędy DNS: NXDOMAIN, SERVFAIL i REFUSED

Każda odpowiedź DNS zawiera kod odpowiedzi. Pusty wynik nie zawsze oznacza błąd, a kod mówi, gdzie szukać:

OdpowiedźCo oznaczaCo sprawdzić
NOERRORNazwa istnieje i wróciły rekordy danego typu.Nic; porównaj wartości.
NODATANazwa istnieje, ale nie ma rekordu tego typu: NOERROR z pustą odpowiedzią, a nie osobny kod.Dodaj rekord u dostawcy DNS, jeśli powinien istnieć.
NXDOMAINNazwa w ogóle nie istnieje, a żadna nazwa pod nią też nie.Pisownię, czy domena jest zarejestrowana i nie wygasła, a w przypadku subdomeny, czy ją utworzono.
SERVFAILResolver nie dostał poprawnej odpowiedzi: zawiodły serwery nazw albo weryfikacja DNSSEC.Werdykt DNSSEC i to, czy serwery nazw domeny odpowiadają.
REFUSEDSerwer nie odpowie na to pytanie: nie jest autorytatywny dla domeny i nie wykonuje dla ciebie zapytań rekurencyjnych.Czy rekordy NS wskazują na serwery, które obsługują strefę.
TimeoutBrak jakiejkolwiek odpowiedzi.Serwery nazw nie działają, są zablokowane albo mają zły adres.

DNSSEC: bezpieczny, niepodpisany czy uszkodzony?

DNSSEC podpisuje rekordy strefy, aby resolver mógł udowodnić, że nie zostały sfałszowane. Strefa nadrzędna publikuje rekord DS, czyli odcisk klucza domeny, a domena publikuje swoje klucze w rekordach DNSKEY, więc podpisy łączą się w łańcuch aż do strefy głównej. Google Public DNS i Cloudflare 1.1.1.1 weryfikują DNSSEC.

  • DNSSEC: bezpieczny

    Bezpieczny

    Podpisany, a weryfikujący resolver Google sprawdził podpisy: jego odpowiedź miała bit AD (authenticated data), czyli jego potwierdzenie, że odpowiedź przeszła weryfikację.

  • DNSSEC: niepodpisany

    Niepodpisany

    Brak rekordu DS w strefie nadrzędnej: strefa nie jest podpisana. Działa normalnie; po prostu nie da się udowodnić, że jej odpowiedzi są prawdziwe.

  • DNSSEC: uszkodzony

    Uszkodzony

    Weryfikacja się nie udaje, więc resolvery weryfikujące odpowiadają SERVFAIL i domena jest niedostępna dla ich użytkowników, choć przy wyłączonym sprawdzaniu dane są na miejscu. Typowa przyczyna to DS w strefie nadrzędnej, który po przeniesieniu do nowego dostawcy DNS nie pasuje do żadnego klucza strefy.

Rekordy poczty w sprawdzeniu DNS

Poczta dla domeny trafia do jej serwerów MX, a odbiorcy, zanim jej zaufają, sprawdzają rekordy TXT: SPF wymienia serwery, które mogą wysyłać pocztę w imieniu domeny, w jednym rekordzie, który może wywołać najwyżej 10 zapytań DNS; DMARC pod _dmarc mówi, co zrobić z pocztą, która nie przejdzie sprawdzeń, a gdy subdomena nie ma własnego, szuka się go wyżej w nazwie (RFC 9989, od maja 2026 r.); MTA-STS pod _mta-sts prosi nadawców o dostarczanie przez TLS. Wynik odczytuje je wszystkie i podaje dostawcę poczty stojącego za hostami MX.

Aby dokładniej sprawdzić jeden rekord, użyj sprawdzania MX, sprawdzania SPF i sprawdzania DMARC.

API do sprawdzania DNS

Dwa darmowe endpointy z CORS dla przeglądarek. /api/dns-query pyta jeden resolver o jeden typ i zachowuje pola naszego starszego API; /api/dns-lookup przesyła strumieniowo pełne sprawdzenie z tej strony jako linie JSON.

Jeden typ z jednego resolvera
$ curl -X POST https://dnsrobot.net/api/dns-query \
    -H "Content-Type: application/json" \
    -d '{"domain": "google.com", "recordType": "MX", "dnsServer": "8.8.8.8"}'
{
  "status": "success", "responseTime": 4,
  "resolvedIPs": ["10 smtp.google.com"],
  "dnsServer": "8.8.8.8", "recordType": "MX", "domain": "google.com", …
}
Pełne sprawdzenie, strumieniowo
$ curl "https://dnsrobot.net/api/dns-lookup?domain=google.com"
{"t":"start","name":"google.com","kind":"name","types":["A","AAAA","CNAME","MX",…]}
{"t":"hop","hop":{"zone":".","server":"a.root-servers.net","ms":16,"outcome":"referral",…}}
{"t":"answers","source":"google","server":"dns.google","sets":[{"type":"A",…}]}
{"t":"answers","source":"auth","server":"ns1.google.com","sets":[…]}
{"t":"dnssec","verdict":"unsigned",…}
{"t":"done","ms":57}

Pytania o sprawdzanie DNS

Czym jest DNS lookup?

DNS lookup to zapytanie do systemu nazw domen o rekordy danej nazwy: adresy IP strony, jej serwery poczty, serwery nazw, rekordy tekstowe i inne. Twoje urządzenie robi to za każdym razem, gdy otwierasz stronę. To narzędzie pokazuje naraz każdy typ rekordu, z serwerów nazw samej domeny oraz z publicznych resolverów Google i Cloudflare.

Jak sprawdzić rekordy DNS domeny?

Wpisz domenę powyżej i wybierz Wszystkie: narzędzie zapyta autorytatywne serwery nazw domeny o każdy typ rekordu (A, AAAA, CNAME, MX, NS, TXT, SOA, CAA, HTTPS, DNSKEY i DS) i obok każdego pokaże kopię z cache Google i Cloudflare. Wybierz jeden typ, aby zobaczyć tylko jego, albo skopiuj polecenia dig i nslookup, aby samodzielnie wykonać to samo sprawdzenie.

Czy można użyć nslookup online?

Tak: ta strona to nslookup online z dodatkowymi szczegółami. nslookup pyta jeden serwer o jeden typ rekordu; tutaj dostajesz naraz wszystkie typy, odpowiedź autorytatywną i kopie z cache dwóch resolverów, wartości TTL oraz ścieżkę od serwera głównego. Wynik pokazuje też dokładne polecenia nslookup, dig i Resolve-DnsName dla twojego sprawdzenia, do uruchomienia w terminalu.

Ile trwa, zanim zmiana w DNS będzie widoczna?

Tyle, ile TTL starego rekordu. Serwery nazw domeny od razu podają nową wartość, ale resolvery, które zapisały w cache starą, trzymają ją, aż minie jej TTL: 300 sekund to pięć minut, 86400 to doba. Wynik pokazuje czas, jaki pozostał kopiom Google i Cloudflare. Obniż TTL dzień przed planowaną zmianą.

Co to jest odpowiedź nieautorytatywna (Non-authoritative answer)?

To odpowiedź z cache resolvera, a nie z serwerów nazw samej domeny. nslookup wypisuje „Non-authoritative answer” za każdym razem, gdy pytasz resolver, czyli prawie zawsze. Zwykle jest poprawna, ale może być nieaktualna, dopóki nie minie jej TTL. Odpowiedź autorytatywna pochodzi z serwerów nazw strefy i ma ustawioną flagę AA; to narzędzie zdobywa ją, schodząc w dół od serwera głównego.

Co oznacza NXDOMAIN?

NXDOMAIN oznacza, że nazwa nie istnieje w DNS. W przypadku domeny sprawdź pisownię oraz to, czy jest zarejestrowana i nie wygasła; jej status pokaże sprawdzenie WHOIS. W przypadku subdomeny rekordu nigdy nie utworzono albo go usunięto. Nazwa, która istnieje, ale nie ma rekordu żądanego typu, dostaje zamiast tego NOERROR z pustą odpowiedzią, często nazywane NODATA.

Co oznacza SERVFAIL?

SERVFAIL oznacza, że resolver nie dostał poprawnej odpowiedzi. Albo serwery nazw domeny nie działają lub są źle skonfigurowane, albo nie powiodła się weryfikacja DNSSEC, przez co resolvery weryfikujące, takie jak Google i Cloudflare, odrzucają odpowiedź. To narzędzie odróżnia te dwa przypadki: gdy dane wracają przy wyłączonym sprawdzaniu, werdykt DNSSEC brzmi „uszkodzony”.

Co to jest TTL w DNS?

TTL (time to live, czas życia) to liczba sekund, przez którą resolver może trzymać rekord w cache, zanim zapyta ponownie. Każdy rekord ma własny. Krótki TTL, np. 300 sekund, sprawia, że zmiany szybko się rozchodzą, ale kosztuje więcej zapytań; długi, np. 86400 sekund, czyli doba, jest tańszy, ale zmiany trwają dłużej. Kopie w cache odliczają czas, dlatego TTL u Google i Cloudflare jest tu niższy.

Jak sprawdzić odwrotny DNS (rekord PTR)?

Wpisz adres IP powyżej. Narzędzie zamieni go na nazwę odwrotną (8.8.8.8 staje się 8.8.8.8.in-addr.arpa), zapyta o rekord PTR, a potem sprawdzi tę nazwę w przód: gdy wskazuje z powrotem na ten sam adres IP, odwrotny DNS jest potwierdzony, a tego właśnie szukają serwery poczty. Z terminala: nslookup 8.8.8.8 lub dig -x 8.8.8.8.

Czym jest rekord NS i jak znaleźć serwery nazw domeny?

Rekord NS wskazuje serwery nazw, które przechowują rekordy domeny. Sprawdź domenę i odczytaj jej rekordy NS albo ścieżkę po prawej: pokazuje serwery nazw, do których odsyła TLD domeny, i oznacza je, jeśli własne rekordy NS domeny wymieniają inne. Wynik podaje też firmę, która je obsługuje, np. Cloudflare, AWS Route 53 albo rejestratora domeny.

Czym różni się DNS lookup od sprawdzenia propagacji DNS?

DNS lookup pokazuje wszystkie rekordy domeny ze szczegółami, z jej własnych serwerów nazw i dwóch dużych resolverów. Sprawdzenie propagacji pyta o jeden typ rekordu dziesiątki resolverów na całym świecie, aby zobaczyć, gdzie zmiana już dotarła. Zacznij tutaj, by zobaczyć stan faktyczny i cache, a potem użyj sprawdzania propagacji DNS na naszej stronie głównej, by zobaczyć obraz globalny.

Czy to sprawdzanie DNS jest darmowe i czy zapisujecie, co sprawdzam?

Jest darmowe, bez konta i bez CAPTCHA; aby chronić odpytywane serwery, jedna sieć może wykonać 20 sprawdzeń na minutę. Sprawdzenie działa na naszym serwerze w sieci Cloudflare, więc serwery nazw domeny widzą nasz adres, a nie twój. Nic nie trafia do cache: każde sprawdzenie pyta od nowa. Nie zapisujemy, kto co sprawdzał.

Czegoś brakuje?Zaproponuj funkcję lub nowe narzędzie

Więcej narzędzi DNS