Popüler araçlar

Tema

NS Sorgulama — Ad Sunucusu Kontrolü

Her alan adı için NS sorgulama ve NS kontrolü: kayıt kuruluşunun verdiği NS kayıtlarını glue ve TTL ile, her ad sunucusunun kendi söylediğinin yanında görün. Lame sunucular, uyuşmazlıklar ve eski glue kayıtları çözümüyle birlikte belirtilir.

Kaynaklar: kayıt kuruluşunun sunucuları (bir kök sunucudan başlanarak ulaşılır) · her ad sunucusunun IPv4 adresleri, doğrudan sorulur · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru · RDAP

Önce kayıt kuruluşuna, sonra onun adını verdiği her ad sunucusuna sorar. URL, e-posta adresi veya alt alan adı da olur.

Deneyin

NS kaydı nedir?

NS kaydı, bir bölgeyi tutan sunucunun adını verir: alan adının kayıtlarının bulunduğu yer. Bir bölge, her sunucu için bir NS kaydı listeler; bu yüzden google.com alan adının dört kaydı vardır: ns1'den ns4.google.com'a (RFC 1035 §3.3.11).

Aynı NS kayıtları iki kez bulunur. Üst bölge, burada .com, yönlendirme noktasında bir kopya tutar ve çözümleyicileri yönlendirmek için kullanır; bu kopya yetkili değildir. Bölge kendi kopyasını en üstünde tutar ve yetkili olan odur (RFC 1034 §4.2.1, RFC 2181 §6.1). İkisinin tamamen aynı olması gerekir.

Değer her zaman bir host adıdır; asla bir adres, asla bir takma ad değildir: adın kendi A veya AAAA kayıtları olmalıdır (RFC 2181 §10.3).

Bir NS kaydı, parça parçagoogle.com · kaydedildi 2026-10-23
google.com.Sahip345600TTLINSınıfNSTürns1.google.com.Değer
SahipKaydın ait olduğu bölge.
TTL · 4 günBir çözümleyicinin onu ne kadar tutabileceği. .com kopyası 2 gün diyor.
NSKayıt türü 2: bu bölge için bir ad sunucusu.
DeğerKendi A veya AAAA kayıtları olan bir host adı.
Üst bölgenin kopyası · .comgoogle.com. 172800 NS ns1.google.com.ns1.google.com. 172800 A 216.239.32.10Yetkili değil: glue'lu bir yönlendirme
Bölgenin kendi kopyasıgoogle.com. 345600 NS ns1.google.com.;; flags: qr aaYetkili: çözümleyicilerin tuttuğu
ns1.google.com.Kendi adresleri olan bir host adı
216.239.32.10Bir adres geçerli bir değer değildir
ns.example.com. → CNAMEAsla takma ad olmaz (RFC 2181 §10.3)
İki kopya da canlı kaydedildi: .com kayıt kuruluşunun l.gtld-servers.net üzerinden yönlendirmesi ve ns1.google.com'un kendi yanıtı.

NS kontrolü: bir alan adının ad sunucuları nasıl kontrol edilir

Yukarıya alan adını yazın ve Ad sunucularını kontrol et düğmesine basın: önce kayıt kuruluşuna, sonra onun adını verdiği ve sunucumuzun ulaşabildiği her sunucuya sorarız. Terminalden: macOS ve Linux'ta dig NS example.com, Windows'ta nslookup -type=ns example.com, PowerShell'de Resolve-DnsName -Name example.com -Type NS.

Bu üçü kendi çözümleyicinize sorar, bu yüzden önbellekteki bir kopyayı gösterir. Kayıt kuruluşunun listesini görmek için sunucusuna özyineleme kapalıyken sorun: dig @a.gtld-servers.net example.com NS +norec. Tek bir ad sunucusunu test etmek için ondan +norec ile SOA isteyin ve bayraklarda aa arayın. whois de bölgenin değil, kayıt kuruluşunun listesini gösterir.

dig NS example.com +short

Çözümleyicinizin kopyası, her satırda bir ad sunucusu. .com kayıt kuruluşunun kendi listesi için @a.gtld-servers.net ve +norec ekleyin.

dig'in iki yanıtını okumakgoogle.com · kaydedildi 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. aa yok: bir yönlendirme. Kayıt kuruluşu google.com alan adına hizmet vermez; nereye gidileceğini söyler.
  2. Üst bölgenin listesi ve TTL'i: 2 gün, .com kayıt kuruluşu tarafından belirlenir.
  3. Glue: ns1.google.com sunucusu google.com içinde olduğundan .com onun adresini verir.
  4. aa: bölgenin kendisi. Sunucudan yetkili bir yanıt.
  5. Bölgenin kendi TTL'i: 4 gün, kayıt kuruluşu değil Google tarafından belirlenir.
nslookup · 8.8.8.8'e soruluyor
$ 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
# çözümleyicinizin kopyası
PS> Resolve-DnsName -Name google.com -Type NS

# tek sunucu, özyineleme kapalı
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
2026-10-23 tarihinde kaydedildi. "Non-authoritative answer" bir çözümleyicinin önbellekteki kopyası demektir; burada NS kayıtlarını en fazla 6 saat tutan Google Public DNS. whois kayıt kuruluşunun listesini yazdırır. İkisi de her sunucunun ne söylediğini göstermez.

NS sorgulama sonucunu okumak

Karar, DNS host'unu ve kayıt şirketini belirtir; Yetki devri görünümü kayıt kuruluşunun listesini bölgeninkiyle sunucu sunucu yan yana koyar, her birinin yanıtı ve TCP üzerindeki süresiyle (bağlantı kurulumu dahil, yani yaklaşık iki gidiş-dönüş).

Lacivert sütun, bir çözümleyicinin izlediği yoldur: kök, TTL ve DS'iyle kayıt kuruluşu, ardından her ad sunucusu. Bölgeye hizmet vermeyen bir sunucu kopuk gösterilir.

github.com için NS sorgulama: NS1 ve Route 53 üzerinde sekiz ad sunucusu, her sunucunun yanıtı ve .com'dan yetki devrigithub.com için NS sorgulama: NS1 ve Route 53 üzerinde sekiz ad sunucusu, her sunucunun yanıtı ve .com'dan yetki devriKararBölgeye kimin hizmet verdiği, kimin kaydettiği ve kayıt kuruluşuyla bölgenin uyuşup uyuşmadığı.Kayıt kuruluşu ve bölge yan yanaKayıt kuruluşunun listesindeki ve bölgenin kendi listesindeki her ad, glue ve yanıtla.Her sunucunun yanıtıAA ve TCP üzerindeki süresi, reddeden bir sunucunun gönderdiği kod ya da sunucumuzun bağlanamadığı yerlerde 1.1.1.1 üzerinden.Yetki devriKök, kayıt kuruluşu, ardından her sunucunun kendi yanıtı; bir çözümleyicinin yürüdüğü gibi.
github.com için bir NS sorgusu: karar, kayıt kuruluşunun sekiz ad sunucusu ile bölgenin kendi listesi yan yana, her sunucunun yanıtı ve .com kayıt kuruluşundan yetki devri. Her bölümün neyi gösterdiğini görmek için bir numara seçin.

Üst bölge ve alt bölge ad sunucuları: neden farklılar

İki listeyi iki farklı taraf tutar. Kayıt kuruluşu, kayıt şirketiniz söylediğinde üst bölgenin listesini yayımlar; DNS host'unuz bölgenin kendi listesini sunar. Birini diğerinden bağımsız değiştirirseniz ikisi birbirinden ayrışır.

Çözümleyiciler bölgenin kendi yanıtına yönlendirmeden daha çok güvenir (RFC 2181 §5.4.1); bu yüzden bölgeye bir kez sorduktan sonra onun listesini ve TTL'ini tutarlar. 2026-10-23 tarihinde Cloudflare'in çözümleyicisi google.com'un NS kümesini 340.859 sn kalmış olarak tutuyordu: .com'un 172.800 değerinden fazla, yani kopya bölgenin 4 günlük TTL'inden geliyordu.

Yalnızca kayıt kuruluşunun listesinde olan bir ad, sıfırdan başlayan çözümleyicilerden yine trafik alır. Yalnızca bölgede olan ad onlara görünmez. İkisi de düzeltilmeye değer; hiçbiri tek başına bir kesinti değildir.

Kayıt kuruluşunun listesi, bölgeninkinin yanındakaydedildi 2026-10-23
xserver.ne.jp5 / 3

Kayıt kuruluşu .jp1 gün

  • ns1.xserver.jp
  • ns2.xserver.jp
  • ns3.xserver.jp
  • ns4.xserver.jpyalnızca kayıt kuruluşunda
  • ns5.xserver.jpyalnızca kayıt kuruluşunda

Bölge1 sa.

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

ns4.xserver.jp ve ns5.xserver.jp yalnızca kayıt kuruluşunda. İkisi de yetkili yanıt veriyor, bu yüzden bir şey bozulmuyor; listeler yine de farklı.

github.comaynı 8 sunucu

Kayıt kuruluşu .com2 gün

  • 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

Bölge15 dk. · 1 sa.

  • 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

Aynı adlar, farklı saatler: kayıt kuruluşunun kopyası 2 gün, Route 53'ünki 15 dakika, NS1'inki 1 saat sürüyor.

Bir .net alan adı(ad gizlendi)ortak ad yok

Kayıt kuruluşu .net2 gün

  • ns1.domaindirect.comyalnızca kayıt kuruluşunda
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.comyalnızca kayıt kuruluşunda

Bölge15 dk.

  • ns1.hover.comyalnızca bölgede
  • ns2.hover.comyalnızca bölgede

Kayıt kuruluşu hâlâ eski adları listeliyor. Bunlardan ikisi Hover'ın sunucularıyla adres paylaşıyor ve yanıt veriyor; üçüncüsü reddediyor.

Çizgiler iki listenin paylaştığı adları bağlar; kesikli çizgi tek adresteki iki adı bağlar. Üçüncü olay rastgele bir taramada bulunan gerçek bir kayıt; adı gizlendi.

Glue kaydı nedir?

Glue, üst bölgenin yönlendirmesiyle birlikte verdiği bir adrestir; böylece bir çözümleyici, adı hizmet verdiği bölgenin içinde olan bir ad sunucusuna ulaşabilir. Glue olmasaydı ns1.google.com sunucusunu bulmak için google.com'un sunucularına sormak gerekirdi; bu da başladığınız sorunun ta kendisi (RFC 1034 §4.2.1).

RFC 9471 bunu kural yapar: bir yönlendirme her alan içi sunucunun glue kaydını taşımalıdır (MUST; google.com için ns1.google.com), aynı üst bölgenin altındaki kardeş sunucular için de taşıması önerilir (SHOULD; github.com için ns-421.awsdns-52.com). ns-520.awsdns-01.net gibi ilgisiz bir ad ise kendi başına sorgulanır.

Glue kayıt şirketinde host kayıtları, alt ad sunucuları veya kişisel DNS sunucuları olarak ayarlanır. Bir sunucu taşındığında glue da taşınmalıdır: eski glue, çözümleyicileri artık yanıt vermeyen bir adrese gönderir.

Glue ve ne zaman gerektiği.com üzerinde kaydedildi, 2026-10-23

Alan içi · google.com

  1. .com: ns1.google.com sunucularına sor
  2. Adresi google.com içinde bulunuyor
  3. glue olmadan arama döngüye girer
  4. Bu yüzden .com şunu ekler: ns1.google.com A 216.239.32.10 · MUST: zorunlu

Kardeş ve ilgisiz · github.com

  1. .com: ns-421.awsdns-52.com, ns-520.awsdns-01.net, … sunucularına sor
  2. awsdns-52.com da .com altında: glue 205.251.193.165 · SHOULD: eklenir
  3. awsdns-01.net başka bir yerde: çözümleyici onu .net içinde arar · glue yok
Eski glue · canlı64.69.208.141.com üzerindeki ns1.register.com glue kaydı · yanıt yok, iki kez soruldu162.214.41.25bugünkü A kaydı · yetkili yanıt veriyor
ns1.register.com'un .com üzerindeki host nesnesi, 2026-10-23 tarihinde rdap.verisign.com üzerinden okundu: kayıt kuruluşu sunucunun bıraktığı bir adresi hâlâ tutuyor ve glue olarak veriyor.

Lame delegation nedir ve nasıl düzeltilir

Üst bölge çözümleyicileri bölgeye hizmet vermeyen bir sunucuya gönderiyorsa yetki devri lame'dir: sunucu reddeder, hiçbir şey söylemez ya da yetkisiz yanıt verir. Listelenen her sunucu lame ise alan adı çözümlenmez; birkaçından biri lame ise çözümleyiciler yeniden denerken sorgular yavaşlar.

RFC 9499, "lame delegation" teriminin birkaç farklı arızayı kapsar hale geldiğini belirtir; bu yüzden araç her birini adlandırır: bölgeyi reddediyor (REFUSED), yanıt yok (iki kez soruldu), yetkisiz yanıt veriyor (aa yok), sunucu hatası (SERVFAIL). Yalnızca TCP üzerindeki sessizlik, Google ve Cloudflare alan adını hâlâ çözümlüyorsa lame sayılmaz: sunucu UDP üzerinden yanıt verebileceği için TCP yanıtı yok olarak adlandırılır.

Çözüm her zaman iki taraftan birindedir: bölgeyi kayıt kuruluşunun işaret ettiği DNS host'unda ekleyin ya da kayıt kuruluşunu bölgeye sahip host'a yönlendirin. Çözümleyiciler düzeltmeden sonra hatayı 5 dakikaya kadar hatırlayabilir (RFC 9520).

Üç lame sunucu, kaydedildi2026-10-23 · alan adları gizlendi

Bölgeyi reddediyor

ns63 · ns64.domaincontrol.com

.com tarafından adı verilen iki GoDaddy sunucusu da REFUSED yanıtı veriyor: bölge orada kurulu değil.

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

Zaman aşımı, sonra REFUSED

ns1 · ns2.eftydns.com

Bir sunucu bir kez zaman aşımına uğradı, yeniden sorulunca REFUSED yanıtı verdi. Tek bir zaman aşımı hüküm değildir: araç bir durum adlandırmadan önce yeniden sorar.

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

Üçten biri

ns1 · ns2 · ns3.domaindirect.com

İki sunucu yetkili yanıt veriyor; üçüncüsü reddediyor. Alan adı çalışıyor, ama daha yavaş.

bash
$ dig @ns2.domaindirect.com \
    example.net SOA +norec
;; … status: REFUSED
# ns1, ns3: NOERROR, flags qr aa
  1. Kayıt kuruluşunun nereyi işaret ettiğine bakınYetki devri görünümü kayıt kuruluşunun sunucularını ve her birinin yanıtını listeler.
  2. Bir tarafı düzeltinBölgeyi o host'ta ekleyin ya da ad sunucularını kayıt şirketinde değiştirin.
  3. Yeniden kontrol edinYanıtlar hemen döner; önbellekteki bir hata 5 dakika kadar sürebilir.

Her sunucu lame olduğunda ziyaretçilerin gördüğü:Google SERVFAILCloudflare SERVFAIL

Rastgele bir taramada bulunan kayıtlardan kaydedildi; adları gizlendi ve example.com ile example.net olarak gösteriliyor.

Kaç ad sunucusu gerekir?

En az iki: "DNS belirtimi ve alan adı kayıt kuralları her bölge için en az iki sunucu gerektirir" (RFC 2182 §5, BCP 16). Aynı bölüm çoğu kuruluş için üç sunucu önerir, bunlardan biri diğerlerinden iyice uzakta olmalı; güvenilirliğin daha önemli olduğu yerlerde dört veya beş.

Adları değil, ağları sayın. Sunucular tek bir arızanın hepsine ulaşamayacağı yerlere konmalıdır (RFC 2182 §3.1): tek bir /22 içindeki altı sunucu aynı yönlendirme kaderini paylaşır. Anycast tek bir adresi birçok noktaya yayar ve olağan çözümdür, ama yine de tek işletmecidir; ikinci bir sağlayıcı o işletmecinin kesintisinden sağ çıkar (RFC 8901).

Daha fazlası sorun değil. RFC 1912'nin eski yedi sınırı 512 baytlık UDP yanıtlarından geliyordu; büyük bölgeler bugün sekiz sunucu çalıştırıyor (github.com, bbc.co.uk).

Sunucular, ağa göre gruplanmışkaydedildi 2026-10-23
Alan adıAğa göre sunucularNSAğlarDeğerlendirme
google.comGoogle · AS15169 · anycast41Anycast, tek işletmeci
github.comNS1 · AS62597Route 53 · AS16509 · anycast82İki sağlayıcı
bbc.co.ukNetActuate · AS63911NS1 · AS6259782İki ağ
xserver.ne.jpXserver · AS131965Amazon · AS1650952İki ağ
craigslist.orgcraigslist · AS2241461Tek /22

"Çoğu kuruluş düzeyindeki bölge için üç sunucu sağlanması önerilir; bunlardan en az biri diğerlerinden iyice uzakta olmalıdır."

RFC 2182 §5 · BCP 16, Temmuz 1997 · ikisi zorunlu, üçü önerilir
Bir kutu bir ağdır (AS); renkli kutu bir anycast sağlayıcısıdır: birçok nokta, tek işletmeci. xserver.ne.jp'nin ikinci ağı, Amazon'daki ns2.xserver.jp; craigslist.org'un altı sunucusu tek bir /22 paylaşıyor.

Ad sunucuları nasıl değiştirilir ve ne kadar sürer

Alan adının kayıtlı olduğu yerde değiştirin, DNS host'unda değil: kayıt şirketi yeni listeyi kayıt kuruluşuna gönderir, kayıt kuruluşu da yayımlar. Önce bölgeyi yeni host'ta tüm kayıtlarıyla ekleyin; böylece yeni sunucular adı verildiği anda yanıt verir.

Sonra iki saat işler. Kayıt kuruluşunun yönlendirmesini önbelleğe almış çözümleyiciler eski listeyi üst bölge TTL'ine kadar tutar: .com'da 2 gün, .de ve .jp'de 1 gün, .org'da 1 saat. Bölgeye zaten sormuş çözümleyiciler eski bölgenin kendi NS kümesini onun TTL'i kadar tutar; bu daha uzun olabilir: google.com'unki 4 gün. Google Public DNS NS'i en fazla 6 saat tutar.

Yani bu hiçbir zaman sabit bir "24–48 saat" değildir. Eski DNS host'unu, uzun olan saat bitene kadar aynı kayıtları yanıtlar halde tutun; imzalı bir alan adında taşımadan önce DS'i kaldırın (RFC 6781).

Nerede değiştirilir ve saatlerTTL'ler 2026-10-23 tarihinde ölçüldü

Kayıt şirketinde: her birinin kendi rehberi

Kayıt kuruluşunun kopyası ne kadar sürer (üst bölge NS TTL'i)

  • .ru4 gün345.600 s
  • .com2 gün172.800 s
  • .uk2 gün172.800 s
  • .de1 gün86.400 s
  • .jp1 gün86.400 s
  • .tr12 saat43.200 s
  • .dev3 saat10.800 s
  • .org1 saat3.600 s
  • .io1 saat3.600 s
  • .in15 dakika900 s

Değişiklikten sonraki saatler

  • Önbelleklerdeki eski yönlendirmeüst bölge TTL'i.com: en fazla 2 gün
  • Önbelleklerdeki eski bölge NS kümesieski bölgenin TTL'igoogle.com: en fazla 4 gün
  • Google Public DNSNS için üst sınırıen fazla 6 saat
Üst bölge TTL'leri her kayıt kuruluşunun kendi sunucularından (dig +norec); .io sıkça anılan 300 sn değil, 3.600 sn yanıt verdi. Kayıt şirketleri hâlâ sabit süreler söylüyor: GoDaddy "up to 48 hours", Namecheap "up to 24 hours".

NS, SOA ve glue kayıtları

Üç kayıt bir yetki devri noktasında buluşur. NS sunucuları adlandırır: üst bölgenin kopyası yolu gösterir, bölgenin kopyası yetkidir. Glue, üst bölgenin yalnızca bölgenin içinde adlandırılmış sunucular için tuttuğu bir A veya AAAA kaydıdır. SOA her bölgede bir kez, en üstte bulunur: birincil sunucu, bir iletişim adresi, seri numarası ve süreler.

SOA'yı aa bayrağıyla yanıtlayan bir sunucu bölgeyi tutuyordur; araç bu yüzden her sunucudan onu ister. Seri numarası, sunucuların aynı sürüme sahip olup olmadığını söyler; Route 53 1'den başlar ve kendiliğinden hiç değiştirmez, iki sağlayıcıdaki bir bölge de iki seri numarası taşır; ikisi de normaldir.

İki bölge, tek kesit noktasıgoogle.com · kaydedildi 2026-10-23

.com bölgesiişleten: Verisign

  • NSgoogle.com. 172800 NS ns1.google.com.Yetki devri: sonraki durak · yetkili değil
  • Ans1.google.com. 172800 A 216.239.32.10Glue: sunucunun adresi, ona ulaşılabilsin diye
  • DSDS yok: google.com imzasızDS: alt bölgenin imza anahtarını gösterir; yalnızca imzalı bölgelerde (cloudflare.com DS 2371 13 2)

bölge kesiti · google.com

google.com bölgesiişleten: Google

  • NSgoogle.com. 345600 NS ns1.google.com.Bölgenin kendi listesi · yetkili
  • SOAns1.google.com. dns-admin.google.com. 1003797344 900 900 1800 60Bölge başına bir tane: birincil sunucu, iletişim, seri numarası, süreler
  • Ans1.google.com. 345600 A 216.239.32.10Sunucunun kendi adresi: glue ile eşleşmeli
Glue ve sunucunun kendi A kaydı tek bir gerçeğin iki kopyasıdır; uyuşmadıklarında glue eskidir.

NS sorgulama ve nslookup komutu

İnsanlar "ns lookup" ifadesini iki şey için arar: bir alan adının ad sunucuları ve Windows, macOS ve Linux ile gelen nslookup komutu. nslookup çözümleyicinize sorar ve onun önbelleğinde olanı yazdırır; -type=ns ile bölgenin NS kümesini çözümleyicinizin tuttuğu haliyle listeler.

Bu kopya saatlerce eski olabilir ve kayıt kuruluşunun listesini, glue kayıtlarını ya da her sunucunun bölgeyi tutup tutmadığını hiçbir zaman göstermez. Bu sayfa, ulaşabildiği her birine doğrudan sorar.

Ad sunucularını sorgulamanın üç yolu
Bu NS Sorgulamadnsrobot.netnslookup-type=nsdigNS · +norec
Sorduğu yerkayıt kuruluşu, sonra her sunucuçözümleyicinizadını verdiğiniz herhangi bir sunucu
Kayıt kuruluşu ve bölgeikisi de, ad adönbellekteki kopyakomut başına bir liste
Her sunucunun aa'sıher IPv4 adresi (A ve glue)Hayırkomut başına bir sunucu
Glue ve TTL'leriki TTL de-debug ileçıktıda
Teşhisadlandırılmış, çözümüyleHayırHayır
Çalıştığı yerherhangi bir tarayıcıWindowsmacOSLinuxmacOSLinux

NS sorgulama: sık sorulan sorular

NS sorgulama nedir?

NS sorgulama, DNS'e bir alan adının bölgesini hangi ad sunucularının tuttuğunu sorar. Bu araç önce kayıt kuruluşuna sorar: glue ve TTL'li üst bölge listesi için. Ardından her ad sunucusunun IPv4 adreslerine doğrudan TCP üzerinden bölgenin SOA'sını ve kendi NS kümesini sorar, ikisini karşılaştırır. DNS'i kimin barındırdığını, hangi sunucuların yetkili yanıt verdiğini ve çözümleyicilerin hata vermesine ya da yavaşlamasına yol açacak sorunları görürsünüz.

DNS sağlayıcımın kim olduğunu nasıl öğrenirim?

Ad sunucularının adlarına bakın: ns1.google.com Google, *.ns.cloudflare.com Cloudflare, ns-*.awsdns-* Amazon Route 53, 01.dnsv.jp ise Onamae.com. Bu sorgulama DNS host'unu her sağlayıcının belgelenmiş ad desenine göre adlandırır ve her adresin ardındaki ağı ayrıca gösterir, çünkü bazı host'lar başka bir şirketin ağında çalışır: Porkbun ve Hostinger Cloudflare'inkinde, Vercel NS1'inkinde.

Kayıt kuruluşu ve bölge neden farklı ad sunucuları listeliyor?

Kayıt şirketinizde ayarlanan kayıt kuruluşunun listesi ile DNS host'unuzda ayarlanan bölgenin kendi NS kayıtları iki ayrı kopyadır ve RFC 1034 tamamen aynı olmaları gerektiğini söyler. Biri değiştirilip diğeri değiştirilmediğinde, çoğu zaman DNS host'ları arasında taşınmadan sonra, ayrışırlar. Kayıt kuruluşundan başlayan çözümleyiciler onun listesini kullanır; bölgeye sormuş olanlar bölgeninkini tutar.

Lame delegation nedir?

Lame delegation, kayıt kuruluşunun listelediği ama bölgeye hizmet vermeyen bir ad sunucusudur: REFUSED veya SERVFAIL yanıtı verir, yetkisiz yanıt verir ya da hiç yanıt vermez. Listelenen her sunucu lame ise alan adı çözümlenmez ve Google ile Cloudflare SERVFAIL yanıtı verir. Bölgeyi o DNS host'unda ekleyerek ya da kayıt şirketinde ad sunucularını bölgeye sahip host'a çevirerek düzeltin.

Ad sunucusu değişiklikleri yayılmak ne kadar sürer?

İki saatin uzun olanı kadar: kayıt kuruluşunun NS TTL'i (.com ve .net için 2 gün, .ru için 4 gün, .de ve .jp için 1 gün, .org ve .io için 1 saat, .in için 15 dakika) ve eski host'a sormuş çözümleyicilerin tuttuğu eski bölgenin kendi NS TTL'i. Google Public DNS bunu yaklaşık 6 saatle sınırlar. Sabit bir "24–48 saat" iki yönde de yanlıştır.

Bir alan adının kaç ad sunucusu olmalı?

En az iki: RFC 2182 iki sunucu şart koşar, çoğu kuruluş için üç önerir (en az biri diğerlerinden iyice uzakta), daha yüksek güvenilirlik için dört veya beş. Sayıdan daha önemlisi tek bir arızanın hepsine ulaşamamasıdır: farklı ağlar veya sağlayıcılar. Cloudflare ya da Route 53 gibi tek işletmecinin anycast sunucuları birçok noktadır, ama yine de tek işletmecidir.

Glue kayıtları nedir ve ne zaman gerekir?

Glue, kayıt kuruluşunun yönlendirmesiyle birlikte verdiği adrestir: example.com için ns1.example.com gibi bölgenin içinde adlandırılmış bir ad sunucusu için. Onsuz bir çözümleyici, sunucuyu bulmak için sunucunun adresine ihtiyaç duyardı. RFC 9471 bu tür alan içi adlar için glue'yu zorunlu kılar. Kayıt şirketinizde host kayıtları, alt ad sunucuları veya kişisel DNS sunucuları adıyla ayarlanır.

Farklı araçlar neden farklı ad sunucuları gösteriyor?

Çoğu nameserver sorgulama aracı bir çözümleyiciye sorar; bu da değişiklikten sonra günlerce eski olabilen bir önbellek kopyasını gösterir, oysa kayıt kuruluşu ve bölge kendi adlarına yanıt verir. Bazı araçlar yalnızca bölgenin kendi listesini gösterir. Bu sorgulama kayıt kuruluşunun listesini, her sunucunun kendi yanıtını ve Google ile Cloudflare'in önbellek kopyalarını, her kopyanın kalan süresiyle yan yana gösterir.

"Doğrudan sorgulanmadı" ne demek?

Sunucumuz Cloudflare'in ağında çalışır ve bir Cloudflare Worker o ağdaki bir adrese bağlantı açamaz. Oradaki ad sunucuları, yani Cloudflare'in kendileri ve Porkbun, Hostinger ve DigitalOcean gibi onun üzerinde çalışan host'larınkiler, bunun yerine Cloudflare'in çözümleyicisi 1.1.1.1 üzerinden okunur: NS kümesi ve TTL'i gelir, ama her sunucunun AA biti, seri numarası veya yanıt süresi gelmez.

NS sorgulama nslookup ile aynı şey mi?

Hayır. nslookup, Windows, macOS ve Linux'ta NS dahil her kayıt türünü bir çözümleyiciye soran bir komut satırı aracıdır (nslookup -type=ns example.com). NS sorgulama ise sorunun kendisidir: bir alan adına hangi ad sunucularının hizmet verdiği. dig NS gibi nslookup da çözümleyicinizin önbellek kopyasını gösterir; kayıt kuruluşuna ve her sunucuya doğrudan sormak, bu aracın yaptığı gibi, uyuşup uyuşmadıklarını gösterir.

Ad sunucusu değişikliğim neden hâlâ görünmüyor?

Üç yere bakın: kayıt kuruluşunun yeni sunucuları listeleyip listelemediğine (listelemiyorsa değişiklik kayıt şirketinizden henüz çıkmamıştır), yeni bölgenin yetkili yanıt verip vermediğine ve eski kopyaların çözümleyicilerde ne kadar süre kalacağına. "Ad sunucularını değiştirdim" modu yeni sunucularınızı alır, her kopyayı onlarla karşılaştırır ve her çözümleyicinin yeni kümeyi alacağı ana kadar geri sayar.

Ad sunucularını değiştirmeden önce DNSSEC'i kaldırmalı mıyım?

Evet, eski ve yeni DNS host'ları iş birliği yapmıyorsa. Kayıt kuruluşu, yeni host'un anahtarlarıyla eşleşmeyen bir DS kaydı tutmaya devam ederse Google ve Cloudflare gibi doğrulayan çözümleyiciler SERVFAIL yanıtı verir ve alan adı onların kullanıcıları için kararır. DS'i kayıt şirketinde kaldırın, TTL'inin dolmasını bekleyin, ad sunucularını değiştirin, sonra yeni host'un DS'ini yayımlayın.

İlgili DNS araçları