NS kaydı ve zone delegation DNS hiyerarşisi

NS Kaydı Nedir? Nameserver ve Zone Delegation Mantığı

Bir domain için DNS sorgusu yapıldığında, yanıtın hangi nameserver'dan geleceğine NS kaydı karar verir. NS — Name Server — kaydı, bir zone için yetkili nameserver'ların listesini tutar ve DNS hiyerarşisinin delegation zincirini oluşturur. Tarayıcı example.com'u çözdürmek istediğinde önce kök nameserver'lara, ardından .com TLD nameserver'larına, oradan da example.com zone'unu barındıran yetkili nameserver'a ulaşır. Bu zincirleme yönlendirmenin her adımı NS kayıtlarıyla yürütülür.

NS kaydı, A, CNAME veya MX gibi kayıt türlerinden farklı bir konumda durur. Diğer kayıtlar belirli bir servisi yönlendirir; NS kaydı zone'un kendisini kimin yönettiğini bildirir. Bu fark pratik bir sonuç doğurur: NS kaydını değiştirmek tek bir kaydın hedefini değiştirmez, zone'un tüm DNS otoritesini başka bir sunucuya devreder. Yanlış bir değişiklik tüm zone'u çözümsüz bırakabilir.

DNS'in günlük işleyişinde NS kaydı çoğunlukla arka planda kalır. Registrar panelinden nameserver girdilerini yazıp bağlamayı tamamlayabilirsiniz; ancak zone delegation'ın nasıl çalıştığını, çoklu NS kaydının neden zorunlu olduğunu ve NS değişikliğinin propagasyon üzerindeki etkisini anlamak; hem arızaları hızla teşhis etmek hem de altyapı geçişlerini sorunsuz yürütmek için gereklidir.

NS kaydının zone içindeki rolü ve söz dizimi

NS kaydı, bir zone için yetkili nameserver'ların hostname'lerini tutar. Her nameserver için ayrı bir satır tanımlanır; birden fazla nameserver bulunuyorsa birden fazla NS kaydı zone'da yer alır.

example.com.  86400  IN  NS  ns1.dnshosting.com.
example.com.  86400  IN  NS  ns2.dnshosting.com.

NS kaydı, zone'un kök noktasında — zone apex'inde — zorunlu olarak bulunur. SOA (Start of Authority) kaydıyla birlikte zone'u geçerli kılan iki kayıttan biridir. NS olmayan bir zone, DNS çözümleme zincirinde yanıt veremez; resolver talebi iletecek yetkili nameserver'ı bulamaz.

TTL değeri NS kayıtları için genellikle uzun tutulur; 86400 saniye yani 24 saat yaygın bir seçimdir. Bu değer, resolver'ların NS bilgisini ne kadar süre önbellekte tutacağını belirler. TTL optimizasyonu açısından kritik bir nokta vardır: nameserver değişikliği planlandığında NS kaydının TTL'sini önceden kısaltmak — örneğin 3600 saniyeye düşürmek — eski nameserver bilgisinin resolver önbelleklerinden temizlenmesini hızlandırır. Değişiklikten en az bir TTL süresi önce bu azaltmayı yapmak, geçiş penceresini daraltır.

NS kaydının değeri daima bir hostname'dir; asla doğrudan IP adresi yazılmaz. NS 203.0.113.1 biçiminde bir giriş geçersizdir ve DNS sunucuları tarafından reddedilir. Nameserver'ın IP'si ilgili A kaydından ya da gerektiğinde glue record aracılığıyla çözümlenir.

Zone delegation: parent zone'dan child zone'a yetki aktarımı

DNS hiyerarşisi delegation zinciri üzerine kuruludur. Kök zone, her TLD için yetkili nameserver'ları bilir. .com TLD zone'u, example.com sorguları için hangi nameserver'ların yetkili olduğunu NS kayıtlarıyla bildirir. Bu bilgi, domain sahibinin registrar aracılığıyla TLD nameserver'larına kayıt ettirdiği veriden gelir.

Delegation zinciri şöyle işler: resolver kök nameserver'a sorar, kök .com TLD nameserver'larını döndürür. Resolver .com nameserver'ına sorar, o da example.com için yetkili nameserver'ları döndürür. Resolver bu nameserver'a ulaşarak asıl sorguyu yanıtlatır ve sonucu önbelleğe alır.

; .com TLD nameserver'ındaki delegation (referral):
example.com.  172800  IN  NS  ns1.dnshosting.com.
example.com.  172800  IN  NS  ns2.dnshosting.com.

; example.com zone'undaki yetkili NS kaydı (authoritative):
example.com.   86400  IN  NS  ns1.dnshosting.com.
example.com.   86400  IN  NS  ns2.dnshosting.com.

Bu iki kayıt kümesinin — TLD'deki delegation ile zone dosyasındaki NS kaydının — birbiriyle tutarlı olması zorunludur. TLD nameserver'ındaki delegation kaydı registrar üzerinden güncellenir; zone dosyasındaki NS kaydı ise DNS yönetim panelinden düzenlenir. İkisi arasındaki tutarsızlık, DNS terminolojisinde lame delegation (topal delegasyon) olarak adlandırılan durumu yaratır: TLD resolver'ı ns1.dnshosting.com'a yönlendirirken zone dosyası ns1.newhosting.com'u yetkili olarak tanımlıyor olabilir. Bu durumda resolver, TLD'nin işaret ettiği nameserver'a ulaştığında zone için REFUSED veya SERVFAIL yanıtı alır.

Delegation'ın propagasyonu TLD nameserver'ındaki kaydın TTL'sine bağlıdır. Bu TTL genellikle 24-48 saattir ve TLD nameserver'ı tarafından belirlenir; zone sahibinin doğrudan kontrolünde değildir. DNS propagasyon süresi hesaplanırken bu dış bağımlılık göz önünde bulundurulmalıdır.

Çoklu NS kaydı: artıklık ve dağılım gerekliliği

Zone için yalnızca tek bir nameserver tanımlamak teknik olarak mümkündür; ancak bu yapı tek nokta hatası oluşturur. Yetkili nameserver yanıt veremez hale geldiğinde zone'daki tüm kayıtlar çözümlenemez — web sitesi, e-posta ve diğer tüm servisler erişilemez olur. Çoğu registrar en az iki NS kaydını zorunlu kılar; bu sınır artıklığın minimum eşiğidir.

İki nameserver, tek nameserver'a kıyasla belirgin bir güvenilirlik avantajı sağlar. Resolver'lar NS listesindeki nameserver'lara paralel sorgu gönderebilir ya da birinden yanıt alınamazsa listedeki diğerine geçer. Büyük managed DNS sağlayıcıları dört veya daha fazla nameserver sağlar; bazı anycast tabanlı sağlayıcılarda her nameserver hostname'i arkasında onlarca fiziksel sunucu bulunur.

Coğrafi ve ağ çeşitliliği de kritik bir faktördür. İki nameserver aynı fiziksel veri merkezinde veya aynı ağ omurgasına bağlıysa, veri merkezi ya da ağ arızası her ikisini birden etkiler. Kurumsal yapılarda birbirinden bağımsız ağlara ve farklı coğrafi konumlara dağılmış nameserver'lar tercih edilir. Anycast adresleme kullanan büyük DNS sağlayıcıları — Cloudflare, AWS Route 53, Google Cloud DNS gibi — bu artıklığı altyapı düzeyinde otomatik olarak sunar; Cloudflare DNS geçişi bu avantajı elde etmenin yaygın yollarından biridir.

NS kayıt sayısını artırmak her zaman avantajlı değildir. Çok sayıda nameserver tanımlandığında resolver'ların hepsine ulaşıp doğrulaması gerekebilir; bu gecikme ekleyebilir. Pratikte iki ile dört arasında nameserver, artıklık ile performans arasındaki dengeyi çoğu yapı için yeterince karşılar.

NS değişikliği ve propagasyon penceresi

NS kaydını değiştirmek — yani nameserver'ı başka bir sağlayıcıya taşımak — diğer DNS kayıt güncellemelerinden daha kapsamlı ve dikkat gerektiren bir işlemdir. İki ayrı sistemde eş zamanlı yapılandırma gerektirir: registrar panelinde yeni nameserver'ların kaydedilmesi ve yeni nameserver üzerinde zone dosyasının eksiksiz hazırlanması.

Bu iki adım arasındaki sıralama kritiktir. Yeni nameserver zone dosyasını barındırmaya hazır olmadan önce registrar'da geçiş yapılırsa, TLD delegation kaydı yeni nameserver'ı göstermeye başlar; ancak o nameserver zone için yetkili değildir ve REFUSED yanıtı döner. Geçiş süreci şu sırayla yürütülmelidir: önce yeni nameserver üzerinde zone dosyası yapılandırılır ve test edilir, ardından registrar'da nameserver kaydı güncellenir.

; Yeni nameserver'ı doğrudan sorgula — zone hazır mı?
dig @ns1.newhosting.com example.com SOA +short
dig @ns1.newhosting.com example.com A +short
dig @ns1.newhosting.com example.com MX +short

SOA sorgusuna NOERROR ve geçerli bir SOA kaydı dönüyorsa nameserver zone için yetkili biçimde yanıt veriyor demektir. Bu doğrulamadan sonra registrar değişikliği güvenle yapılabilir.

Geçiş tamamlandıktan sonraki propagasyon penceresi boyunca — 24 ile 48 saat arasında — bazı resolver'lar eski nameserver'dan, bazıları yeni nameserver'dan yanıt alabilir. Her iki zone dosyasının içeriği tutarlıysa bu durum kullanıcıya görünmez. Eski ve yeni nameserver arasındaki zone farkı büyükse — örneğin kayıtlar eksik veya hatalı taşınmışsa — bazı kullanıcılar erişim sorunu yaşayabilir. Nameserver değişikliği sürecinde propagasyon penceresini minimize etmek için geçiş öncesinde NS TTL'sini kısaltmak ve her iki zone'u paralel aktif tutmak standart yaklaşımdır.

Glue record ile delegation döngüsünü kırmak

NS kaydı bir alt alan adını hedef gösterdiğinde özel bir durum ortaya çıkar. example.com için nameserver olarak ns1.example.com tanımlandığında bir çözümleme döngüsü riski doğar: ns1.example.com'un IP adresini bulmak için example.com zone'una sorgu atılması gerekir, ancak o zone'a ulaşmak için ns1.example.com'un IP'si bilinmelidir.

Bu döngüyü kırmak için glue record kullanılır. Parent zone'a — bu örnekte .com TLD — ns1.example.com için doğrudan bir A kaydı eklenir. Resolver, delegation yanıtıyla birlikte bu IP'yi de alır ve nameserver'a bağlanabilir.

; .com TLD nameserver'ında delegation + glue:
example.com.      172800  IN  NS  ns1.example.com.
example.com.      172800  IN  NS  ns2.example.com.
ns1.example.com.    3600  IN  A   203.0.113.1
ns2.example.com.    3600  IN  A   203.0.113.2

Glue record zorunluluğu yalnızca NS hedefi, yönetilen zone'un kendi alt alanı olduğunda ortaya çıkar. ns1.dnshosting.com gibi harici bir hostname kullanıldığında glue record gerekmez; dnshosting.com zone'u ns1'in IP'sini bağımsız biçimde çözümler. Kendi nameserver altyapısını barındıran veya beyaz etiket nameserver yapısı kullanan organizasyonlar için glue record registrar panelinde ayrıca yapılandırılmalıdır. Registrar'ın bunu desteklediği "child nameserver" veya "host kaydı" girişinden yapılır; bu adım atlandığında NS kaydı zone'da doğru görünse de çözümleme döngüsü nedeniyle yanıt alınamaz.

NS uyumsuzluğu ve zone çözümleme sorunlarının tanısı

NS yapılandırma hataları, belirli bir kaydın değil zone'un tamamının yanıtsız kalmasına yol açar. Bu nedenle diğer DNS sorunlarından daha belirgin etkiler üretir; ancak nedenini teşhis etmek kimi zaman daha uzun sürer.

Lame delegation durumunda registrar'daki nameserver zone için yanıt vermiyor demektir. Nameserver adresi yanlış girilmişse, DNS sağlayıcısı hesabı kapatılmışsa ya da nameserver üzerindeki zone dosyası silinmişse REFUSED veya SERVFAIL döner. NS eşleşmezliği daha ince bir sorundur: registrar'daki ve zone dosyasındaki NS kayıtları birbirinden farklıdır. Bu durumda çözümleme tutarsız görünür — bazı resolver'lar doğru nameserver'a, bazıları hatalı olana ulaşır; sorun aralıklı biçimde kendini gösterir.

; Recursive resolver'ın gördüğü NS kaydını kontrol et:
dig example.com NS +short

; TLD'nin gönderdiği delegation kaydına bak:
dig example.com NS @a.gtld-servers.net. +short

; Yetkili nameserver'ı doğrudan sorgula — SOA dönüyor mu?
dig @ns1.dnshosting.com example.com SOA

NS kayıtlarını zone dosyasından silmek ya da tüm NS satırlarını tek seferde başka bir sağlayıcıyla değiştirmek zone'u geçici olarak çözümsüz bırakabilir. Domain transfer sürecinde nameserver değişikliği yapılacaksa transfer onaylanmadan önce yeni nameserver'ın zone'u barındırdığını doğrulamak ve eski nameserver'ı transferin tamamlanmasına kadar aktif tutmak, kesinti penceresini ortadan kaldırır.

DNSSEC etkin bir zone'da NS kayıtları da imzalanır. NS kümesindeki bir değişiklik yeni RRSIG imzası gerektirir; NS güncellemesi ile zone imzalama arasında koordinasyon sağlanmadığında DNSSEC doğrulama hatası yaşanabilir. DNSSEC etkin zone'larda NS değişikliğini managed DNS sağlayıcısı otomatik olarak imzalar; kendi nameserver'ını yönetenler için bu adım elle tetiklenmesi gereken bir zone imzalama operasyonudur.

NS kaydı, DNS altyapısının görünmeyen taşıyıcı sütunudur. Registrar'da yazılan birkaç satırlık nameserver girişi, resolver'ların tüm dünyada zone'a nasıl ulaşacağını belirler. Delegation zinciri, çoklu nameserver artıklığı ve zone ile TLD kaydının tutarlılığı — bu üç prensip NS yönetiminin temelini oluşturur.

Nameserver değişikliği veya zone taşıma işlemlerinde en sık gözden kaçan iki nokta, geçiş öncesinde zone hazırlığını yeni nameserver üzerinde doğrulamamak ve NS TTL'sini önceden düşürmeyi unutmaktır. Bu iki adımın her ikisi de gecikme maliyeti olmadan uygulanabilir; ancak atlandığında propagasyon penceresi gereksiz yere uzar.