NS kaydı, hosting panelinde bir kez girilip unutulan bir ayar gibi görünür. Ama alan adının DNS altyapısında ne kadar merkezi bir rol oynadığını gerçekten kavrayan çoğu geliştirici, bunu ilk kez büyük bir geçiş sırasında ve genellikle bir kesinti ortasında anlar.
Name Server (NS) kaydı, bir alan adının DNS bölgesini (zone) kimin yönettiğini belirler. Dünya genelindeki resolver'lar bu alana ilk erişmek istediğinde, TLD sunucusundan (.com, .net gibi) alınan yanıt doğrudan NS kaydındaki sunuculara yönlendirir. Bu sunuculara authoritative nameserver denir; A, MX, CNAME, TXT gibi tüm alt kayıtlar için son yetkili yanıt buradan gelir. NS kaydı yanlış yapılandırıldığında yalnızca web sitesi değil, e-posta, CDN ve tüm alt alan adları da yanıt veremez hale gelir.
NS kaydının temel işlevi ve zone kontrolü
Her alan adı için en az iki NS kaydı olması zorunludur. Bu zorunluluk teknik bir tercih değil, RFC 1034 standardının gerektirdiği yedekliliktir. Yalnızca tek bir name server tanımlıysa ve o sunucu yanıt veremez hale gelirse, zone'daki hiçbir kayıt sorgulanamaz; web sitesi, e-posta ve alt alan adlarının tamamı erişilemez olur. Çoğu DNS sağlayıcısı varsayılan olarak iki veya daha fazla NS sunar; ancak bunun farkında olunmadan tek NS ile çalışan alan adları hâlâ sık görülen bir yapılandırma hatasıdır.
@ 86400 IN NS ns1.example-dns.com.
@ 86400 IN NS ns2.example-dns.com.Zone dosyasında NS kaydı bu biçimde tanımlanır; @ kök alan adını temsil eder, 86400 TTL değeridir (saniye cinsinden 24 saat), IN NS ise kayıt tipini belirtir. İki satır birbirinin yedeğidir; biri yanıt veremez hale gelirse diğeri devralır.
Tek NS, tek hata noktasıdır.
Registrar panelinde görünen NS adresleri (örneğin ns1.example-dns.com ve ns2.example-dns.com) ile DNS zone'unda tanımlı NS kayıtları tutarlı olmalıdır. Bu iki katman arasındaki uyumsuzluk, bazı resolver'ların eski sunucuya, bazılarının yenisine gitmesiyle sonuçlanır; kullanıcı bazındaki tutarsız erişim deneyimi bu durumun tipik belirtisidir. Uyumsuzluk, özellikle registrar transferlerinden sonra görülür; eski registrar'daki NS bilgisi güncellenmeden yeni registrar'a geçilirse zone kontrolü belirsizleşir.
NS kaydının bir diğer özelliği, zone'un "başlangıç noktasını" (Start of Authority) tanımlamasıdır. SOA kaydıyla birlikte NS, zone'un otorite yapısını kurar. Bu yüzden apex domain'de (seodenetim.com gibi, alt alan adı olmayan kök) CNAME kaydı tanımlanamaz; apex, NS ve SOA kayıtlarını barındırmak zorundadır. Bu kural bazı sağlayıcılarda CNAME flattening tekniğiyle aşılır, ancak standart zone davranışında geçerlidir.
Authoritative ve recursive resolver arasındaki pratik ayrım
Bir tarayıcı alan adını çözümlemek istediğinde önce recursive resolver'a gider. Bu resolver, ISS tarafından sağlanan bir sunucu veya Google'ın 8.8.8.8'i ya da Cloudflare'in 1.1.1.1'i gibi genel erişimli bir sunucu olabilir. Yanıtı önbelleğinde bulamamışsa hiyerarşiyi adım adım takip eder: root sunucular, TLD sunucuları ve ardından NS kaydındaki authoritative sunucu. Authoritative sunucu bu zincirin son halkasıdır; zone'daki tüm kayıtlar yalnızca bu sunucudan doğruluk payıyla okunur.
Recursive resolver, aldığı yanıtı NS kaydının TTL değeri boyunca önbellekte tutar. Burada kritik bir ayrım var: resolver, zone'daki diğer kayıtların TTL'sini değil, NS kaydının kendi TTL değerini esas alır. NS kaydı 86400 saniye (24 saat) TTL ile tanımlanmışsa, bu süre dolmadan resolver eski name server adresini kullanmaya devam eder; propagation penceresi tam olarak bu nedenle tahmin edilmesi güç bir aralık haline gelir.
Propagation süresi tahmin edilemez.
Hosting taşıması veya CDN geçişi sırasında "güncellendi ama bazı kullanıcılarda hâlâ eski site görünüyor" şikayeti bu mekanizmadan kaynaklanır. Farklı ISS'lerin recursive resolver'ları farklı önbellekleme davranışına sahiptir; birinde değişiklik anında görünürken diğerinde saatlerce eski NS adresi geçerli kalabilir. Bu tutarsızlık, DNS değişikliğinin hatalı yapıldığını değil, önbellekleme zincirinin kendi TTL sürelerini tükettiğini gösterir.
Alan adının o anki NS kayıtlarının farklı DNS noktalarında nasıl göründüğünü anlık olarak sorgulamak, geçiş sırasında hangi resolver'ların henüz güncellemediğini net biçimde ortaya koyar ve yersiz panik yerine somut durum tespiti sağlar.
Geçiş öncesinde TTL düşürme ve zamanlama
NS kaydı değişikliği planlanıyorsa, geçişten en az 24 ila 48 saat önce TTL değerini düşürmek propagation penceresini önemli ölçüde kısaltır. Çoğu DNS sağlayıcısı minimum 300 saniye (5 dakika) TTL'ye izin verir; bu değer ayarlandıktan sonra resolver'lar kısa sürede güncel NS adresini alır.
Bu adımın zamanlaması doğru yapılmadığında işe yaramaz.
NS kaydı güncellenirken TTL zaten 86400 saniyeyse, resolver'lar bu değeri cache'den atmadan önce 24 saate kadar bekleyebilir; düşürülen TTL, eski değerin süresi dolmadan hiçbir resolver tarafından uygulanmaz. Geçiş tarihine 6 saat kala TTL düşürmek, potansiyel propagation avantajını kaybettirir; değişikliğin etkin olması için eski TTL süresi zaten geçmiş olmalıdır.
Geçiş tamamlandıktan sonra TTL değerini tekrar standart seviyeye (3600 veya 86400 saniye) çıkarmak da ihmal edilen bir adımdır. Düşük TTL, authoritative sunucuya gelen sorgu yükünü artırır ve yoğun trafikli sitelerde fark edilebilir bir ek yük yaratır. 300 saniyelik TTL'de name server başına dakikada gelen sorgu sayısı, 86400 saniyeye kıyasla teorik olarak yaklaşık 288 kat daha fazladır; çoğu site için bu fark ihmal edilebilir ama büyük ölçekli zone'larda dikkat gerektiren bir hesaptır.
NS kaydı ne zaman güncellenmeli?
Üç temel senaryo, NS kaydı değişikliğini zorunlu kılar.
İlki hosting veya sunucu taşımasıdır. Yeni sağlayıcının name server adresleri registrar panelinde güncellenir. Sıranın önemi burada belirginleşir: önce tüm DNS kayıtları yeni sağlayıcıya taşınmalı, ardından NS değiştirilmelidir. Ters sırayla yapılırsa yeni authoritative sunucu, henüz kendisine aktarılmamış kayıtlar için sorgu almaya başlar ve boş yanıt döner.
Sıra önemlidir. Her seferinde.
Bir MX kaydının kopyalanmadan NS güncellenmesi, e-posta teslimini sessizce keser; bu sorun genellikle saatlerce fark edilmez.
İkincisi CDN entegrasyonudur. Cloudflare gibi servisler, proxy modunda etkinleştirildiğinde tüm DNS zone'unu kendi altyapısına devreder ve NS kaydı bu devrin mekanizmasıdır. CDN sağlayıcısının verdiği name server adresleri registrar paneline girilir; DDoS koruması, önbellekleme ve SSL sonlandırma gibi özellikler ancak bu devir tamamlandıktan sonra aktif olur. Bazı geliştiriciler CDN'nin "aktif edildi" adımını tamamladıklarını düşünürken NS kaydını güncellemeyi atlar; bu durumda trafik CDN üzerinden geçmez, yalnızca kayıt yönetimi CDN paneline taşınmış olur.
Üçüncüsü birincil DNS sağlayıcısı değişikliğidir; örneğin ücretsiz bir hizmetten kurumsal bir sağlayıcıya geçiş. Bu senaryo en fazla hata riski taşır çünkü her MX, TXT, CNAME ve A kaydının yeni sağlayıcıya eksiksiz kopyalanması gerekir. SPF, DKIM ve DMARC TXT kayıtlarının atlanması e-posta teslimini kesebilir; bu kayıtların yapısını ve birbirleriyle ilişkisini anlamak geçişi güvenli kılmak açısından kritiktir.
NS kaydı hataları ve kesinti senaryoları
NS kaydına bağlı kesintiler genellikle birkaç kalıptan birinden çıkar.
Kesinti başladıktan sonra iş işten geçer.
- Boş veya silinmiş NS kaydı: Zone'a hiçbir authoritative yanıt dönemez. Alan adı tamamen erişilemez hale gelir; e-posta dahil tüm servisler durur.
- Tek NS kullanımı: Yedeksiz çalışma. Name server bakımda, yeniden başlatılıyor veya ağ bağlantısı yoksa zone sorgularına yanıt dönmez; bu süre boyunca alan adı erişilemez olur.
- Registrar ve zone arasında uyumsuz NS: Registrar panelinde tanımlı NS ile zone'daki NS kayıtları farklı. Sorgulama kaynağına göre tutarsız yanıtlar üretir ve kullanıcı deneyimi öngörülemez hale gelir.
- Süresi dolmuş alan adı: Registrar, alan adı yenilenmediğinde NS kaydını geçersiz kılabilir. Yenileme yapılsa bile NS propagation yeniden yaşanır; bu sürede alan adı kısmen veya tamamen erişilemez olabilir.
Apex domain'de CNAME tanımlanamayacağına değinilmişti; bu durum NS ile doğrudan bağlantılıdır ve pratikte sık karıştırılan bir kısıtlamadır. CNAME kaydının yapısını ve kısıtlamalarını anlamak, zone tasarımı sırasında hangi kayıt tipinin nerede kullanılabileceğini netleştirir.
NS geçişi sırasında SSL sertifika yenileme penceresi açıksa, sertifika doğrulaması için gereken DNS-01 veya HTTP-01 challenge yanıtlarının farklı resolver'lardan tutarsız sonuçlar döndürebileceğini hesaba katmak gerekir. Geçiş öncesi ve sonrasında sertifika durumunu kontrol etmek, name server değişikliğinin TLS katmanını etkileyip etkilemediğini görmeyi sağlar.
Alan adı üzerindeki yetkinin tam olarak kimin elinde olduğunu ve NS güncellemesinin registrar katmanına yansıyıp yansımadığını WHOIS kaydı üzerinden doğrulamak da geçiş sonrası kontrol listesinin bir parçası olmalıdır; registrar transferi tamamlanmış ama NS güncellemesi henüz yayılmamışsa bu sorgu farkı gösterir.
NS kaydı, yalnızca hosting kurulumunun değil; DNS altyapısının tamamının otorite kapısıdır. Taşıma sırasında sırayı doğru kurmak, TTL'yi önceden planlamak ve iki name server kullanmak, çoğu kesinti senaryosunu başlamadan önce kapatır. Bu üç kural çoğu zaman yeterlidir.