Popularne narzędzia

Motyw

NS Lookup — sprawdź serwery nazw domeny

Sprawdź serwery nazw dowolnej domeny: rekordy NS, które wydaje jej rejestr, z glue i TTL, obok tego, co o sobie mówi każdy serwer nazw. Serwery lame, niezgodności i nieaktualne glue są nazwane, razem z poprawką.

Źródła: serwery rejestru, do których docieramy od serwera głównego · adresy IPv4 każdego serwera nazw, pytane bezpośrednio · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru · RDAP

Najpierw pytamy rejestr, potem każdy serwer nazw, który wskazuje. Może być URL, adres e-mail lub subdomena.

Wypróbuj

Czym jest rekord NS?

Rekord NS wskazuje serwer, który przechowuje strefę: miejsce, w którym żyją rekordy domeny. Strefa ma po jednym rekordzie NS na serwer, więc google.com ma ich cztery, od ns1 do ns4.google.com (RFC 1035 §3.3.11).

Te same rekordy NS istnieją dwa razy. Strefa nadrzędna, tu .com, trzyma kopię na granicy stref, żeby odsyłać resolvery dalej; ta kopia nie jest autorytatywna. Strefa trzyma własną kopię na swoim szczycie i to ona jest autorytatywna (RFC 1034 §4.2.1, RFC 2181 §6.1). Obie powinny być identyczne.

Wartością jest zawsze nazwa hosta, nigdy adres i nigdy alias: nazwa musi mieć własne rekordy A lub AAAA (RFC 2181 §10.3).

Rekord NS, część po częścigoogle.com · nagrano 2026-10-23
google.com.Właściciel345600TTLINKlasaNSTypns1.google.com.Wartość
WłaścicielStrefa, do której należy rekord.
TTL · 4 dniJak długo resolver może go trzymać. Kopia z .com podaje 2 dni.
NSTyp rekordu 2: serwer nazw dla tej strefy.
WartośćNazwa hosta z własnymi rekordami A lub AAAA.
Kopia strefy nadrzędnej · .comgoogle.com. 172800 NS ns1.google.com.ns1.google.com. 172800 A 216.239.32.10Nieautorytatywna: odesłanie z glue
Własna kopia strefygoogle.com. 345600 NS ns1.google.com.;; flags: qr aaAutorytatywna: to trzymają resolvery
ns1.google.com.Nazwa hosta z własnymi adresami
216.239.32.10Adres nie jest poprawną wartością
ns.example.com. → CNAMENigdy alias (RFC 2181 §10.3)
Obie kopie nagrane na żywo: odesłanie rejestru .com z l.gtld-servers.net i własna odpowiedź ns1.google.com.

Jak sprawdzić serwery nazw domeny

Wpisz domenę powyżej i naciśnij Sprawdź serwery nazw: pytamy rejestr, potem każdy wskazany przez niego serwer, do którego nasz serwer może dotrzeć. Z terminala: dig NS example.com na macOS i Linuksie, nslookup -type=ns example.com w Windows, Resolve-DnsName -Name example.com -Type NS w PowerShell.

Te trzy polecenia pytają twój własny resolver, więc pokazują kopię w cache. Aby zobaczyć listę z rejestru, zapytaj jego serwer z wyłączoną rekurencją: dig @a.gtld-servers.net example.com NS +norec. Aby przetestować jeden serwer nazw, zapytaj go o SOA z +norec i poszukaj aa we flagach. whois też pokazuje listę z rejestru, nie strefy.

dig NS example.com +short

Kopia twojego resolvera, jeden serwer nazw na wiersz. Dodaj @a.gtld-servers.net i +norec, aby dostać własną listę rejestru .com.

Jak czytać dwie odpowiedzi diggoogle.com · nagrano 2026-10-23
dig · macOS, Linux
$ dig @l.gtld-servers.net google.com NS +norec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 91
;; AUTHORITY SECTION:
google.com.       172800  IN  NS  ns2.google.com.2
google.com.       172800  IN  NS  ns1.google.com.
…
;; ADDITIONAL SECTION:
ns1.google.com.   172800  IN  A   216.239.32.103
…

$ dig @216.239.32.10 google.com NS +norec
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 04
google.com.       345600  IN  NS  ns1.google.com.5
…
  1. Brak aa: odesłanie. Rejestr nie obsługuje google.com; mówi, dokąd iść.
  2. Lista strefy nadrzędnej i jej TTL: 2 dni, ustawiony przez rejestr .com.
  3. Glue: ns1.google.com leży wewnątrz google.com, więc .com podaje jego adres.
  4. aa: sama strefa. Odpowiedź autorytatywna serwera.
  5. Własny TTL strefy: 4 dni, ustawiony przez Google, nie przez rejestr.
nslookup · pytanie do 8.8.8.8
$ nslookup -type=ns google.com 8.8.8.8
Server:   8.8.8.8
Address:  8.8.8.8#53

Non-authoritative answer:
google.com  nameserver = ns3.google.com.
google.com  nameserver = ns1.google.com.
…
PowerShell
# kopia twojego resolvera
PS> Resolve-DnsName -Name google.com -Type NS

# jeden serwer, rekurencja wyłączona
PS> Resolve-DnsName -Name google.com -Type SOA -Server ns1.google.com -NoRecursion
whois
$ whois google.com
Registrar: MarkMonitor Inc.
Name Server: NS1.GOOGLE.COM
…
DNSSEC: unsigned
Nagrano 2026-10-23. „Non-authoritative answer” oznacza kopię w cache resolvera, tu Google Public DNS, który trzyma rekordy NS najwyżej 6 godzin. whois wypisuje listę z rejestru. Żadne z nich nie pokazuje, co mówi każdy serwer.

Jak czytać wynik

Werdykt nazywa host DNS i rejestratora; widok Delegacja zestawia listę z rejestru z listą strefy, serwer po serwerze, z odpowiedzią każdego i jej czasem przez TCP (z nawiązaniem połączenia, czyli około dwóch rund).

Granatowa kolumna to droga, którą idzie resolver: root, rejestr z jego TTL i DS, potem każdy serwer nazw. Serwer, który nie obsługuje strefy, jest przerwany.

NS lookup github.com: osiem serwerów nazw w NS1 i Route 53, odpowiedź każdego serwera i delegacja z .comNS lookup github.com: osiem serwerów nazw w NS1 i Route 53, odpowiedź każdego serwera i delegacja z .comWerdyktKto obsługuje strefę, kto ją zarejestrował i czy rejestr oraz strefa się zgadzają.Rejestr obok strefyKażda nazwa z listy rejestru i z własnej listy strefy, z glue i odpowiedzią.Odpowiedź każdego serweraAA i jej czas przez TCP, kod wysłany przez serwer, który odmawia, albo przez 1.1.1.1 tam, gdzie nasz serwer nie może się połączyć.DelegacjaRoot, rejestr, potem własna odpowiedź każdego serwera, tak jak idzie resolver.
NS lookup dla github.com: werdykt, osiem serwerów nazw z rejestru obok własnej listy strefy, odpowiedź każdego serwera i delegacja z rejestru .com. Wybierz numer, aby zobaczyć, co pokazuje każda część.

Serwery nazw w strefie nadrzędnej i podrzędnej: dlaczego się różnią

Dwie listy trzymają dwie różne strony. Rejestr publikuje listę strefy nadrzędnej, gdy powie mu o tym twój rejestrator; twój host DNS obsługuje własną listę strefy. Zmień jedną bez drugiej, a rozjadą się.

Resolvery ufają własnej odpowiedzi strefy bardziej niż odesłaniu (RFC 2181 §5.4.1), więc gdy już zapytają strefę, zachowują jej listę i jej TTL. 2026-10-23 resolver Cloudflare trzymał zestaw NS google.com z 340 859 s do końca: więcej niż 172 800 z .com, więc kopia pochodziła z 4-dniowego TTL strefy.

Nazwa tylko na liście rejestru wciąż dostaje ruch od resolverów, które zaczynają od zera. Nazwa tylko w strefie jest dla nich niewidoczna. Obie warto naprawić; żadna sama nie jest awarią.

Lista rejestru obok listy strefynagrano 2026-10-23
xserver.ne.jp5 a 3

Rejestr .jp1 dzień

  • ns1.xserver.jp
  • ns2.xserver.jp
  • ns3.xserver.jp
  • ns4.xserver.jptylko w rejestrze
  • ns5.xserver.jptylko w rejestrze

Strefa1 godz.

  • ns1.xserver.jp
  • ns2.xserver.jp
  • ns3.xserver.jp

ns4.xserver.jp i ns5.xserver.jp są tylko w rejestrze. Oba odpowiadają autorytatywnie, więc nic się nie psuje; listy mimo to się różnią.

github.comte same 8

Rejestr .com2 dni

  • dns1.p08.nsone.net
  • dns2.p08.nsone.net
  • dns3.p08.nsone.net
  • dns4.p08.nsone.net
  • ns-1283.awsdns-32.org
  • ns-1707.awsdns-21.co.uk
  • ns-421.awsdns-52.com
  • ns-520.awsdns-01.net

Strefa15 min · 1 godz.

  • dns1.p08.nsone.net
  • dns2.p08.nsone.net
  • dns3.p08.nsone.net
  • dns4.p08.nsone.net
  • ns-1283.awsdns-32.org
  • ns-1707.awsdns-21.co.uk
  • ns-421.awsdns-52.com
  • ns-520.awsdns-01.net

Te same nazwy, różne zegary: kopia rejestru trwa 2 dni, Route 53 15 minut, NS1 1 godzina.

Domena .net(nazwa zatajona)brak wspólnej nazwy

Rejestr .net2 dni

  • ns1.domaindirect.comtylko w rejestrze
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.comtylko w rejestrze

Strefa15 min

  • ns1.hover.comtylko w strefie
  • ns2.hover.comtylko w strefie

Rejestr nadal podaje stare nazwy. Dwie z nich mają te same adresy co serwery Hover i odpowiadają; trzecia odmawia.

Linie łączą nazwy wspólne dla obu list; linia przerywana łączy dwie nazwy na jednym adresie. Trzeci przypadek to prawdziwa rejestracja znaleziona w losowym skanie; jej nazwa jest zatajona.

Czym są rekordy glue?

Glue to adres, który strefa nadrzędna podaje wraz z odesłaniem, aby resolver mógł dotrzeć do serwera nazw o nazwie leżącej wewnątrz strefy, którą ten serwer obsługuje. Bez niego znalezienie ns1.google.com wymagałoby zapytania serwerów google.com, czyli tego pytania, od którego zaczynasz (RFC 1034 §4.2.1).

RFC 9471 robi z tego regułę: odesłanie MUSI nieść glue każdego serwera w tej samej domenie (ns1.google.com dla google.com) i POWINNO je nieść dla serwerów siostrzanych pod tą samą strefą nadrzędną (ns-421.awsdns-52.com dla github.com). Nazwa niezwiązana, taka jak ns-520.awsdns-01.net, jest szukana osobno.

Glue ustawia się u rejestratora, jako rekordy hostów, serwery nazw podrzędne lub osobiste serwery DNS. Gdy serwer się przenosi, glue musi przenieść się razem z nim: nieaktualne glue kieruje resolvery pod adres, który już nie odpowiada.

Glue i kiedy jest potrzebnenagrano w .com, 2026-10-23

W tej samej domenie · google.com

  1. .com: zapytaj ns1.google.com
  2. Jego adres leży w samej domenie google.com
  3. bez glue wyszukiwanie zapętla się
  4. Dlatego .com dodaje ns1.google.com A 216.239.32.10 · MUSI: wymagane

Siostrzane i niezwiązane · github.com

  1. .com: zapytaj ns-421.awsdns-52.com, ns-520.awsdns-01.net, …
  2. awsdns-52.com też jest pod .com: glue 205.251.193.165 · POWINNO: dołączone
  3. awsdns-01.net jest gdzie indziej: resolver szuka go w .net · brak glue
Nieaktualne glue · na żywo64.69.208.141glue .com dla ns1.register.com · brak odpowiedzi, pytano dwa razy162.214.41.25jego rekord A dziś · odpowiada autorytatywnie
Obiekt hosta ns1.register.com w .com, odczytany przez rdap.verisign.com 2026-10-23: rejestr wciąż trzyma adres, który serwer opuścił, i podaje go jako glue.

Czym jest delegacja lame i jak ją naprawić

Delegacja jest lame, gdy strefa nadrzędna odsyła resolvery do serwera, który nie obsługuje strefy: odmawia, milczy albo odpowiada bez autorytetu. Jeśli każdy wymieniony serwer jest lame, domena przestaje się rozwiązywać; jeśli jest tak z jednym z kilku, wyszukiwania zwalniają, gdy resolvery ponawiają.

RFC 9499 zauważa, że „lame delegation” objęło kilka różnych usterek, więc narzędzie nazywa każdą z nich: odmawia strefy (REFUSED), brak odpowiedzi (pytano dwa razy), odpowiada bez autorytetu (brak aa), błąd serwera (SERVFAIL). Samo milczenie przez TCP nie jest nazywane lame, dopóki Google i Cloudflare wciąż rozwiązują domenę: nazywamy to brak odpowiedzi TCP, bo ten serwer może odpowiadać przez UDP.

Poprawka jest zawsze po jednej z dwóch stron: dodaj strefę u hosta DNS, na którego wskazuje rejestr, albo wskaż w rejestrze hosta, który ma strefę. Resolvery mogą pamiętać błąd do 5 minut po naprawie (RFC 9520).

Trzy serwery lame, nagrane2026-10-23 · domeny zatajone

Odmawia strefy

ns63 · ns64.domaincontrol.com

Oba serwery GoDaddy wskazane przez .com odpowiadają REFUSED: strefa nie jest tam skonfigurowana.

bash
$ dig @ns63.domaincontrol.com \
    example.com SOA +norec
;; … status: REFUSED
;; flags: qr; … ANSWER: 0

Przekroczenie czasu, potem REFUSED

ns1 · ns2.eftydns.com

Jeden serwer raz nie odpowiedział, a po ponownym pytaniu odpowiedział REFUSED. Jedno przekroczenie czasu to nie werdykt: narzędzie pyta jeszcze raz, zanim nazwie stan.

bash
$ dig @ns1.eftydns.com \
    example.com SOA +norec
;; connection timed out
# zapytano ponownie
;; … status: REFUSED

Jeden z trzech

ns1 · ns2 · ns3.domaindirect.com

Dwa serwery odpowiadają autorytatywnie; trzeci odmawia. Domena działa, tylko wolniej.

bash
$ dig @ns2.domaindirect.com \
    example.net SOA +norec
;; … status: REFUSED
# ns1, ns3: NOERROR, flags qr aa
  1. Zobacz, dokąd wskazuje rejestrWidok Delegacja podaje serwery rejestru i odpowiedź każdego z nich.
  2. Napraw jedną stronęDodaj strefę u tego hosta albo zmień serwery nazw u rejestratora.
  3. Sprawdź ponownieOdpowiedzi wracają od razu; błąd w cache trwa do 5 minut.

Co dostają odwiedzający, gdy każdy serwer jest lame:Google SERVFAILCloudflare SERVFAIL

Nagrane z rejestracji znalezionych w losowym skanie; ich nazwy są zatajone i pokazane jako example.com i example.net.

Ile serwerów nazw potrzeba?

Co najmniej dwa: „The DNS specification and domain name registration rules require at least two servers for every zone” (RFC 2182 §5, BCP 16). Ta sama sekcja zaleca trzy dla większości organizacji, z jednym dobrze oddalonym od pozostałych, oraz cztery lub pięć tam, gdzie niezawodność jest ważniejsza.

Licz sieci, nie nazwy. Serwery powinny stać tam, gdzie jedna awaria nie sięgnie wszystkich (RFC 2182 §3.1): sześć serwerów w jednej /22 dzieli jeden los routingu. Anycast rozkłada jeden adres na wiele miejsc i jest zwykłą odpowiedzią, ale to wciąż jeden operator; drugi dostawca przetrwa awarię tego operatora (RFC 8901).

Więcej też jest w porządku. Dawny limit siedmiu z RFC 1912 wynikał z 512-bajtowych odpowiedzi UDP; duże strefy mają dziś osiem (github.com, bbc.co.uk).

Serwery pogrupowane według siecinagrano 2026-10-23
DomenaSerwery według sieciNSSieciOcena
google.comGoogle · AS15169 · anycast41Anycast, jeden operator
github.comNS1 · AS62597Route 53 · AS16509 · anycast82Dwóch dostawców
bbc.co.ukNetActuate · AS63911NS1 · AS6259782Dwie sieci
xserver.ne.jpXserver · AS131965Amazon · AS1650952Dwie sieci
craigslist.orgcraigslist · AS2241461Jedna /22

„It is recommended that three servers be provided for most organisation level zones, with at least one which must be well removed from the others.”

RFC 2182 §5 · BCP 16, lipiec 1997 · dwa wymagane, trzy zalecane
Ramka to jedna sieć (AS); zabarwiona ramka to dostawca anycast: wiele miejsc, jeden operator. Druga sieć xserver.ne.jp to ns2.xserver.jp w sieci Amazon; sześć serwerów craigslist.org dzieli jedną /22.

Jak zmienić serwery nazw i ile to trwa

Zmień je tam, gdzie domena jest zarejestrowana, nie u hosta DNS: rejestrator wysyła nową listę do rejestru, a rejestr ją publikuje. Najpierw dodaj strefę u nowego hosta, ze wszystkimi rekordami, aby nowe serwery odpowiadały od chwili, gdy zostaną wskazane.

Potem biegną dwa zegary. Resolvery, które zapisały odesłanie rejestru, trzymają starą listę do TTL strefy nadrzędnej: 2 dni w .com, 1 dzień w .de i .jp, 1 godzina w .org. Resolvery, które już zapytały strefę, trzymają stary zestaw NS strefy przez jej TTL, który może być dłuższy: dla google.com to 4 dni. Google Public DNS trzyma NS najwyżej 6 godzin.

Nigdy więc nie jest to stałe „24–48 godzin”. Niech stary host DNS odpowiada tymi samymi rekordami, aż skończy się dłuższy zegar, a w domenie podpisanej usuń DS przed przeprowadzką (RFC 6781).

Gdzie je zmienić i zegaryTTL zmierzone 2026-10-23

U rejestratora: własna instrukcja każdego z nich

Jak długo trwa kopia rejestru (TTL NS strefy nadrzędnej)

  • .ru4 dni345 600 s
  • .com2 dni172 800 s
  • .uk2 dni172 800 s
  • .de1 dzień86 400 s
  • .jp1 dzień86 400 s
  • .pl1 dzień86 400 s
  • .tr12 godzin43 200 s
  • .dev3 godziny10 800 s
  • .org1 godzina3600 s
  • .io1 godzina3600 s
  • .in15 minut900 s

Zegary po zmianie

  • Stare odesłanie w cacheTTL strefy nadrzędnej.com: do 2 dni
  • Stary zestaw NS strefy w cacheTTL starej strefygoogle.com: do 4 dni
  • Google Public DNSjego limit dla NSnajwyżej 6 godzin
TTL stref nadrzędnych z własnych serwerów każdego rejestru (dig +norec); .io odpowiedziało 3600 s, a nie często cytowane 300 s. Rejestratorzy wciąż podają stałe czasy: GoDaddy „up to 48 hours”, Namecheap „up to 24 hours”.

NS, SOA i rekordy glue: różnice

Na delegacji spotykają się trzy rekordy. NS wskazuje serwery: kopia strefy nadrzędnej pokazuje drogę, kopia strefy jest autorytetem. Glue to rekord A lub AAAA, który strefa nadrzędna trzyma tylko dla serwerów nazwanych wewnątrz strefy. SOA jest jeden na strefę, na jej szczycie: serwer główny, adres kontaktowy, numer seryjny i liczniki.

Serwer, który odpowiada na SOA z flagą aa, trzyma strefę, dlatego narzędzie pyta o nie każdy serwer. Numer seryjny mówi, czy serwery mają tę samą wersję; Route 53 zaczyna od 1 i sam go nie zmienia, a strefa u dwóch dostawców ma dwa numery seryjne, oba normalne.

Dwie strefy, jedna granicagoogle.com · nagrano 2026-10-23

Strefa .comprowadzi Verisign

  • NSgoogle.com. 172800 NS ns1.google.com.Delegacja: dokąd iść dalej · nieautorytatywna
  • Ans1.google.com. 172800 A 216.239.32.10Glue: adres serwera, aby można było do niego dotrzeć
  • DSbrak DS: google.com jest niepodpisanaDS: wskazuje klucz podpisujący strefy podrzędnej; tylko strefy podpisane (cloudflare.com DS 2371 13 2)

granica stref · google.com

Strefa google.comprowadzi Google

  • NSgoogle.com. 345600 NS ns1.google.com.Własna lista strefy · autorytatywna
  • SOAns1.google.com. dns-admin.google.com. 1003797344 900 900 1800 60Jeden na strefę: serwer główny, kontakt, numer seryjny, liczniki
  • Ans1.google.com. 345600 A 216.239.32.10Własny adres serwera: glue powinno się z nim zgadzać
Glue i własny rekord A serwera to dwie kopie jednego faktu; gdy się różnią, glue jest nieaktualne.

NS lookup a polecenie nslookup

Ludzie szukają „ns lookup” w dwóch sprawach: serwerów nazw domeny i polecenia nslookup, które jest w Windows, macOS i Linuksie. nslookup pyta twój resolver i wypisuje to, co ma w cache; z -type=ns podaje zestaw NS strefy tak, jak ma go twój resolver.

Ta kopia może mieć godziny, a nigdy nie pokazuje listy z rejestru, glue ani tego, czy każdy serwer trzyma strefę. Ta strona pyta bezpośrednio każdy serwer, do którego może dotrzeć.

Trzy sposoby sprawdzenia serwerów nazw
Ten NS Lookupdnsrobot.netnslookup-type=nsdigNS · +norec
Pytarejestr, potem każdy serwertwój resolverdowolny jeden wskazany serwer
Rejestr a strefaoba, nazwa po nazwiekopię w cachejedna lista na polecenie
aa każdego serwerakażdy adres IPv4 (A i glue)Niejeden serwer na polecenie
Glue i TTLoba TTLz -debugw wyniku
Diagnozanazwana, z poprawkąNieNie
Działaw każdej przeglądarceWindowsmacOSLinuxmacOSLinux

NS lookup: najczęstsze pytania

Czym jest NS lookup?

NS lookup pyta DNS, które serwery nazw trzymają strefę domeny. To narzędzie pyta najpierw rejestr o listę strefy nadrzędnej z glue i TTL, potem adresy IPv4 każdego serwera nazw bezpośrednio przez TCP o SOA strefy i jej własny zestaw NS, i porównuje obie listy. Widzisz, kto hostuje DNS, które serwery odpowiadają autorytatywnie i co sprawi, że resolvery zawodzą lub zwalniają.

Jak sprawdzić, kto jest moim dostawcą DNS?

Spójrz na nazwy serwerów nazw: ns1.google.com to Google, *.ns.cloudflare.com to Cloudflare, ns-*.awsdns-* to Amazon Route 53, 01.dnsv.jp to Onamae.com. Ten lookup nazywa host DNS po udokumentowanym wzorcu nazw każdego dostawcy i osobno pokazuje sieć za każdym adresem, bo część hostów działa w sieci innej firmy: Porkbun i Hostinger w sieci Cloudflare, Vercel w sieci NS1.

Dlaczego rejestr i strefa podają różne serwery nazw?

Lista rejestru, ustawiana u rejestratora, i własne rekordy NS strefy, ustawiane u hosta DNS, to dwie osobne kopie, a RFC 1034 mówi, że powinny być identyczne. Rozjeżdżają się, gdy ktoś zmieni jedną, a drugiej nie, często po przeprowadzce między hostami DNS. Resolvery, które zaczynają od rejestru, używają jego listy, a te, które zapytały strefę, trzymają listę strefy.

Czym jest delegacja lame?

Delegacja lame to serwer nazw podany przez rejestr, który nie obsługuje strefy: odpowiada REFUSED lub SERVFAIL, odpowiada bez autorytetu albo wcale. Jeśli każdy wymieniony serwer jest lame, domena przestaje się rozwiązywać, a Google i Cloudflare odpowiadają SERVFAIL. Napraw to, dodając strefę u tego hosta DNS albo zmieniając serwery nazw u rejestratora na hosta, który ją ma.

Ile trwa propagacja zmiany serwerów nazw?

Do dłuższego z dwóch zegarów: TTL NS rejestru (2 dni dla .com i .net, 4 dni dla .ru, 1 dzień dla .de i .jp, 1 godzina dla .org i .io, 15 minut dla .in) oraz własnego TTL NS starej strefy, który trzymają resolvery, które pytały starego hosta. Google Public DNS ogranicza to do około 6 godzin. Stałe „24–48 godzin” jest błędne w obie strony.

Ile serwerów nazw powinna mieć domena?

Co najmniej dwa: RFC 2182 wymaga dwóch, zaleca trzy dla większości organizacji, z jednym dobrze oddalonym od pozostałych, oraz cztery lub pięć dla wyższej niezawodności. Ważniejsza od liczby jest odporność: żeby jedna awaria nie sięgnęła wszystkich, czyli różne sieci lub dostawcy. Serwery anycast jednego operatora, jak Cloudflare czy Route 53, to wiele miejsc, ale wciąż jeden operator.

Czym są rekordy glue i kiedy ich potrzebuję?

Glue to adres, który rejestr podaje wraz z odesłaniem dla serwera nazw o nazwie wewnątrz strefy, jak ns1.example.com dla example.com: bez niego resolver potrzebowałby adresu serwera, żeby znaleźć serwer. RFC 9471 czyni glue wymaganym dla takich nazw w tej samej domenie. Ustaw je u rejestratora, gdzie nazywa się rekordami hostów, serwerami nazw podrzędnymi lub osobistymi serwerami DNS.

Dlaczego różne narzędzia pokazują różne serwery nazw?

Większość sprawdzaczy pyta resolver, który pokazuje kopię w cache, nawet kilkudniową po zmianie, podczas gdy rejestr i strefa odpowiadają za siebie. Niektóre narzędzia pokazują tylko własną listę strefy. Ten lookup pokazuje listę z rejestru, własną odpowiedź każdego serwera oraz kopie w cache Google i Cloudflare obok siebie, z czasem, jaki każdej z nich zostało.

Co znaczy „bez bezpośredniego sprawdzenia”?

Nasz serwer działa w sieci Cloudflare, a Cloudflare Worker nie może otworzyć połączenia z adresem w tej sieci. Serwery nazw tam, własne Cloudflare i hostów, które na niej działają, jak Porkbun, Hostinger i DigitalOcean, czytamy więc przez resolver Cloudflare 1.1.1.1: zestaw NS i jego TTL, ale nie bit AA, numer seryjny ani czas każdego serwera.

Czy NS lookup to to samo co nslookup?

Nie. nslookup to narzędzie wiersza poleceń w Windows, macOS i Linuksie, które pyta resolver o dowolny typ rekordu, także NS (nslookup -type=ns example.com). NS lookup to samo pytanie: które serwery nazw obsługują domenę. Jak dig NS, nslookup pokazuje kopię w cache twojego resolvera; pytanie rejestru i każdego serwera bezpośrednio, jak robi to to narzędzie, pokazuje, czy się zgadzają.

Dlaczego moja zmiana serwerów nazw jeszcze się nie pokazuje?

Sprawdź trzy miejsca: czy rejestr podaje nowe serwery (jeśli nie, zmiana nie opuściła jeszcze twojego rejestratora), czy nowa strefa odpowiada autorytatywnie i jak długo stare kopie trwają w resolverach. Tryb „Zmieniłem serwery nazw” bierze twoje nowe serwery, porównuje z nimi każdą kopię i odlicza do chwili, gdy każdy resolver je ma.

Czy przed zmianą serwerów nazw usunąć DNSSEC?

Tak, chyba że stary i nowy host DNS współpracują. Jeśli rejestr trzyma rekord DS, do którego nie pasują klucze nowego hosta, resolvery walidujące, jak Google i Cloudflare, odpowiadają SERVFAIL i domena znika dla ich użytkowników. Usuń DS u rejestratora, poczekaj na jego TTL, zmień serwery nazw, potem opublikuj DS nowego hosta.

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

Powiązane narzędzia DNS