Bir alan adı satın aldığınızda o alan adının kayıtlarını (A, MX, TXT, CNAME) fiziksel olarak bir yerde tutan sunuculara ihtiyaç duyarsınız. İşte "bu alan adının kayıtları hangi sunucularda tutulur?" sorusunun cevabını internete duyuran kayıt tipine NS kaydı (Name Server record) denir. NS kaydı, bir DNS bölgesinin (zone) yetkili ad sunucularını isimleriyle listeler ve dünyanın herhangi bir yerindeki çözümleyicinin, sizin siteniz için doğru adrese ulaşmasını sağlayan yol tabelasıdır.
NS kaydı çoğu kullanıcının hiç fark etmeden hayatını etkileyen ama yanlış yapılandırıldığında siteyi tamamen erişilemez hâle getirebilen kritik bir yapı taşıdır. Bu rehberde NS kaydının ne işe yaradığını, kayıt kuruluşundaki (registrar) NS bilgisi ile bölge dosyasındaki NS kayıtlarının farkını, bir alt alan adını başka bir DNS sağlayıcısına nasıl devredebileceğinizi (delegation) ve NS hatalarının siteyi neden aniden çökerttiğini gerçek komut çıktıları ve örnek zone dosyalarıyla ele alacağız. Sonunda dig çıktısındaki NS satırlarını rahatça yorumlayabilecek ve kendi devir yapınızı güvenle kurabilecek seviyeye geleceksiniz.
NS Kaydı Tam Olarak Ne İşe Yarar?#
NS kaydı, bir DNS bölgesinin yetkisini (authority) hangi ad sunucularının taşıdığını belirtir. Basit bir benzetmeyle, alan adınız bir bina ise NS kaydı o binanın hangi kapıcıların (ad sunucuları) sorumluluğunda olduğunu söyleyen levhadır. Bir çözümleyici ornek.com için "web sitesi hangi IP'de?" diye sorduğunda, önce bu alan adının NS kayıtlarına bakıp yetkili sunucuları öğrenir, sonra o sunuculara gidip asıl A kaydını ister.
NS kaydının değeri her zaman bir IP adresi değil, bir ad sunucusunun host adıdır. Yani ornek.com için NS kaydı 1.2.3.4 değil, ns1.clou.tr gibi bir isim içerir. Bu isimlerin de kendi A/AAAA kayıtları vardır ve çözümleme sırasında ayrıca bulunur. Tipik bir zone dosyasında NS satırları şöyle görünür:
; ornek.com bölgesinin başlangıcı
$ORIGIN ornek.com.
$TTL 3600
@ IN SOA ns1.clou.tr. hostmaster.ornek.com. (
2026071001 ; serial
7200 ; refresh
3600 ; retry
1209600 ; expire
3600 ) ; minimum TTL
; Bu bölgenin yetkili ad sunucuları
@ IN NS ns1.clou.tr.
@ IN NS ns2.clou.tr.
; Asıl web kaydı
@ IN A 203.0.113.10
www IN CNAME ornek.com.
Bir alan adının neredeyse her zaman en az iki NS kaydı vardır. Bu bir tercih değil, çoğu kayıt kuruluşunun ve .tr gibi uzantıların dayattığı bir kuraldır: tek bir ad sunucusu çökerse alan adının tamamen erişilemez hâle gelmemesi için yedeklilik zorunludur. NS kaydını dig ile hemen sorgulayabilirsiniz:
# ornek.com'un yetkili ad sunucularını listele
dig ornek.com NS +short
# ns1.clou.tr.
# ns2.clou.tr.
# Belirli bir çözümleyiciden sor
dig @1.1.1.1 ornek.com NS
Registrar'daki NS ile Bölge İçi NS Kaydının Farkı#
NS konusunda en çok kafa karıştıran nokta, NS bilgisinin iki ayrı yerde bulunmasıdır ve bunların farkını bilmek sorun çözerken hayat kurtarır. Aynı bilgi hem alt (üst uzantı) tarafında hem de sizin bölgenizin içinde tutulur ve ideal durumda bu ikisi birbiriyle uyumludur.
Birinci yer kayıt kuruluşunun (registrar) panelidir. Alan adınızı .com için Verisign'a, .tr için TRABİS'e kaydeden kuruluşta girdiğiniz "nameserver" bilgisi, aslında üst bölgeye (parent zone) yazılan delegation NS kaydıdır. Yani .com uzantısının sunucuları, "ornek.com'un yetkilisi ns1.clou.tr ve ns2.clou.tr" bilgisini buradan öğrenir. Bu kayıt teknik olarak sizin değil, üst uzantının sorumluluğundadır ve çözümlemenin başladığı yerdir.
İkinci yer kendi bölge dosyanızın (zone) içidir. Yetkili sunucularınızın kendi zone dosyalarında da NS kayıtları bulunur; buna "in-zone NS" veya "apex NS" denir. Bu kayıtlar bölgenin kendi içinde kimin yetkili olduğunu tekrar beyan eder. İdeal olarak registrar tarafındaki delegation NS ile bölge içi NS birebir aynı olmalıdır. İkisi çeliştiğinde "lame delegation" adı verilen sinsi bir arıza ortaya çıkar: bazı çözümleyiciler siteyi bulurken bazıları bulamaz, sorun kesikli ve teşhisi zor hâle gelir.
| Özellik | Registrar / Üst Bölge NS | Bölge İçi (Apex) NS |
|---|---|---|
| Nerede tutulur | Üst uzantının sunucularında (.com, .tr) | Kendi zone dosyanızda |
| Kim yönetir | Kayıt kuruluşu paneli | DNS sağlayıcınız / siz |
| Görevi | Çözümlemeyi başlatır (delegation) | Yetkiyi bölge içinde beyan eder |
| Yanlış olursa | Alan adı hiç çözülmez | Lame delegation, kesikli erişim |
| Nasıl kontrol edilir | dig +trace üst yanıtı | dig @yetkili-sunucu NS |
Bu iki katmanı ayrı ayrı sorgulayarak farkı somut olarak görebilirsiniz:
# Üst bölgenin (delegation) verdiği NS'i gör - +trace ile
dig +trace ornek.com NS
# Doğrudan yetkili sunucuya sorup bölge içi NS'i gör
dig @ns1.clou.tr ornek.com NS
İki çıktı aynı sunucu listesini veriyorsa yapılandırmanız sağlıklıdır. Nameserver değişikliğinin adım adım nasıl yapıldığını ve panelde nereden düzenleneceğini nameserver değiştirme rehberimizde ayrıntısıyla bulabilirsiniz.
Delegation: Yetki Devri Nasıl Çalışır?#
DNS'in tüm ölçeklenebilirliği delegation yani yetki devri mekanizmasına dayanır. Kimse tüm dünyanın kayıtlarını tek bir yerde tutmaz; her seviye bir alt seviyeye "bu kısmın sorumlusu şu sunucular" diyerek yetkiyi devreder ve bu devir tam olarak NS kaydıyla yapılır. Kök sunucular .com'u ilgili TLD sunucularına, TLD sunucuları da ornek.com'u sizin yetkili sunucularınıza devreder.
Devir zincirini gözünüzde canlandırmak için hiyerarşiyi yukarıdan aşağıya izlemek yeterlidir. Her ok, bir NS kaydı aracılığıyla yapılan bir yetki devrini temsil eder:
. (kök)
└── NS → a.gtld-servers.net (.com uzantısı devredildi)
└── NS → ns1.clou.tr (ornek.com devredildi)
└── A → 203.0.113.10 (yetkili cevap burada)
Bu zincirin kritik yanı, üst tarafın asıl kayıtları tutmamasıdır. .com sunucusu ornek.com'un IP'sini bilmez; sadece "kim biliyor?" sorusunun cevabını (NS kaydını) bilir. Buna "referral" denir. Çözümleyici referral'ı takip ederek en alttaki yetkili sunucuya iner ve kesin cevabı oradan alır. Süreci +trace ile satır satır izleyebilirsiniz:
dig +trace www.ornek.com
# Çıktı özetle şöyle akar:
# . NS a.root-servers.net. <- kök, .com'a yönlendirir
# com. NS a.gtld-servers.net. <- TLD, ornek.com'a yönlendirir
# ornek.com. NS ns1.clou.tr. <- delegation, yetkiliye iner
# www.ornek.com. A 203.0.113.10 <- yetkili sunucunun kesin cevabı
Delegation, yalnızca alan adının tamamı için değil, bir alt alan adı (subdomain) için de yapılabilir. Bir sonraki bölümde asıl gücü buradadır: blog.ornek.com gibi bir alt alanı, ana alan adının kalanına dokunmadan bambaşka bir DNS sağlayıcısına devredebilirsiniz. Alan adının en temel kavramlarını gözden geçirmek isterseniz DNS nedir yazımız iyi bir başlangıç noktasıdır.
Alt Alan Adını Başka Bir DNS'e Devretmek#
Bazen bir alt alan adının yönetimini bütünüyle başka bir ekibe ya da servise bırakmak istersiniz. Örneğin status.ornek.com bir durum-sayfası servisinde barınacak, docs.ornek.com bir dokümantasyon platformunda tutulacak veya bir departman kendi ar-ge.ornek.com bölgesini bağımsız yönetecektir. Bunun temiz yolu, alt alanı NS kaydıyla o servisin sunucularına devretmektir; böylece ana bölgeniz alt alanın onlarca kaydıyla dolmaz ve karşı taraf istediği kaydı bağımsızca değiştirir.
Devir işlemi, ana zone dosyanıza alt alan için NS kayıtları eklemekle yapılır. Aşağıdaki örnekte ana bölge, blog alt alanını dış bir sağlayıcının sunucularına devreder:
$ORIGIN ornek.com.
$TTL 3600
@ IN NS ns1.clou.tr.
@ IN NS ns2.clou.tr.
@ IN A 203.0.113.10
; blog alt alanını dış sağlayıcıya devret
blog IN NS dns1.harici-saglayici.com.
blog IN NS dns2.harici-saglayici.com.
Bu satırları ekledikten sonra, blog.ornek.com ve altındaki her şey (www.blog.ornek.com, api.blog.ornek.com) için yetki artık sizde değil, dns1.harici-saglayici.com'dadır. Karşı tarafın kendi panelinde blog.ornek.com için bir bölge oluşturması ve içine A/CNAME kayıtlarını girmesi gerekir. Devrin çalıştığını +trace ile doğrulayın:
# blog alt alanı için delegation'ı takip et
dig +trace blog.ornek.com A
# ornek.com.'un blog için verdiği NS referral'ını doğrudan gör
dig @ns1.clou.tr blog.ornek.com NS
Alt alan devrinde sık yapılan bir hatanın önüne geçmek gerekir. Aynı alt alan için hem devir (NS) hem de doğrudan bir A/CNAME kaydı tanımlarsanız çakışma yaşarsınız; bir isim ya devredilir ya da yerel olarak çözülür, ikisi bir arada olmaz. Ayrıca devredilen alt alanın sunucusu bir host adı olduğundan, o sunucunun kendi A kaydının çözülebiliyor olması şarttır. Aşağıdaki tablo iki yaklaşımı karşılaştırır:
| Senaryo | Kayıt tipi | Kayıtları kim yönetir | Ne zaman tercih edilir |
|---|---|---|---|
| Alt alanı kendin yönet | A / CNAME | Sen (kendi zone'unda) | Az sayıda kayıt, tek ekip |
| Alt alanı devret | NS (delegation) | Karşı taraf (kendi zone'unda) | Bağımsız ekip / dış servis |
| İkisini karıştır | NS + A birlikte | Belirsiz | Asla — çakışma yaratır |
Yanlış NS Kaydı Siteyi Neden Tamamen Çökertir?#
NS kaydının en tehlikeli tarafı, hata yaptığınızda sitenin "yavaşlaması" değil, tamamen görünmez olmasıdır. Çünkü NS, çözümleme zincirinin en başındadır: A kaydınız kusursuz olsa bile, çözümleyici doğru yetkili sunucuya ulaşamazsa o A kaydını hiçbir zaman okuyamaz. Bu yüzden NS hataları genellikle "site tamamen açılmıyor, ama sunucu ayakta" gibi ilk bakışta çelişkili görünen tablolara yol açar.
En yaygın NS hatası, kayıt kuruluşuna yanlış veya var olmayan bir ad sunucusu girmektir. ns1.clou.tr yerine yazım hatasıyla ns1.cluo.tr girerseniz, üst bölge çözümleyiciyi hiçbir yere ulaşmayan bir sunucuya yönlendirir ve alan adı SERVFAIL ya da zaman aşımıyla döner. İkinci sık hata, delegation NS ile bölge içi NS'in çelişmesidir (lame delegation): registrar ns1 ve ns2 derken, sunucular yalnızca ns1'i tanır. Bu durumda çözümleyicinin ns2'ye düştüğü sorgular başarısız olur ve site "bazen açılıyor, bazen açılmıyor" davranışı sergiler. Bu tür kesintileri teşhis ederken kullanacağınız komutlar şunlardır:
# Yetkili sunucuların yanıt verip vermediğini tek tek dene
dig @ns1.clou.tr ornek.com SOA +short
dig @ns2.clou.tr ornek.com SOA +short
# Üst bölgenin ne devrettiğini gör (delegation)
dig ornek.com NS @a.gtld-servers.net
# SERVFAIL / lame delegation belirtisi ara
dig ornek.com A
# status: SERVFAIL -> NS zinciri kırık demektir
Üçüncü ve en sinsi hata, ad sunucusu değişikliğinden sonra eski NS'in TTL süresince önbellekte kalmasıdır. NS kayıtlarının TTL'i genellikle uzundur (bir gün veya daha fazla), bu yüzden bir DNS sağlayıcısından diğerine geçtiğinizde eski sunucular hâlâ trafik alırken yeni sunucular da devreye girer. Bu geçiş penceresinde her iki bölgenin de aynı kayıtları içermesi (yani geçiş öncesi kayıtları yeni sağlayıcıya önceden kopyalamak) kesintiyi önler. Aşağıdaki tablo en yaygın NS arızalarını ve belirtilerini özetler:
| Hata | Belirti | Teşhis komutu | Çözüm |
|---|---|---|---|
| Yazım hatalı NS | Site hiç açılmaz, SERVFAIL | dig ornek.com NS | Registrar'da NS'i düzelt |
| Lame delegation | Kesikli erişim | dig @nsX ornek.com SOA | Tüm NS'leri eşitle |
| Var olmayan sunucu | Zaman aşımı | dig @ns1... +tries=1 | Sunucuyu kaldır/düzelt |
| Eski NS önbellekte | Geçişte kesinti | dig ornek.com NS @1.1.1.1 | Kayıtları önden kopyala, TTL düşür |
| Tek NS tanımlı | Sunucu çökünce site gider | dig ornek.com NS +short | En az iki NS kullan |
Değişiklik yapmadan önce NS kaydının TTL'ini birkaç gün öncesinden düşürmek (örneğin 3600 saniyeden 300 saniyeye), geçişin çok daha hızlı ve öngörülebilir olmasını sağlar. Değişikliğin dünyaya yayılması ise ayrı bir konudur ve TTL değerleriyle doğrudan ilgilidir.
NS Kayıtları ve TTL: Değişiklik Ne Zaman Etkili Olur?#
NS kaydını değiştirdiğinizde etkinin anında olmamasının nedeni TTL (Time To Live) ve önbelleklemedir. Çözümleyiciler, aldıkları NS kaydını TTL süresince saklar ve o süre boyunca tekrar üst bölgeye sormaz. Bu, DNS'i hızlı ve ölçeklenebilir yapan tasarımın bir sonucudur; ancak değişiklik anında geçiş beklediğinizde kafa karıştırıcı olur.
NS kayıtlarının iki farklı TTL'i olduğunu bilmek gerekir. Üst bölgedeki (delegation) NS kaydının TTL'ini genellikle uzantının kendisi belirler ve .com gibi uzantılarda bu değer gün mertebesinde olabilir; siz doğrudan kontrol edemezsiniz. Bölge içi (apex) NS kaydının TTL'ini ise kendi zone dosyanızda siz belirlersiniz. Bu ikisinin çıktısını karşılaştırarak hangi katmanın ne kadar önbelleklendiğini görebilirsiniz:
# TTL değerini gör (sağdaki üçüncü sütun saniye cinsinden TTL'dir)
dig ornek.com NS
# ornek.com. 86400 IN NS ns1.clou.tr.
# ^^^^^ bu kayıt 86400 sn (24 saat) önbellekte kalır
# Önbelleği atlayıp doğrudan yetkiliden taze değer al
dig @ns1.clou.tr ornek.com NS
Pratik kural nettir: büyük bir NS değişikliğinden en az bir gün önce TTL'i düşürün, değişikliği yapın, yayılım tamamlanınca TTL'i normale çekin. Bu yöntem, ad sunucusu göçlerini birkaç güne yayılan belirsiz bir sürecten, birkaç saatte tamamlanan öngörülebilir bir işleme dönüştürür. Yayılım sürecini ve TTL yönetimini derinlemesine ele almak isterseniz, çözümleme mantığının tamamını DNS nedir rehberimizde bulabilirsiniz.
Sıkça Sorulan Sorular#
NS kaydı ile A kaydı arasındaki fark nedir?#
NS kaydı bir alan adının hangi ad sunucularının yetkisinde olduğunu söyler, A kaydı ise o alan adının hangi IP adresine karşılık geldiğini söyler. Yani NS "kayıtları kim tutuyor?" sorusunu, A "asıl adres nerede?" sorusunu yanıtlar. Çözümleme sırasında önce NS kaydı okunup yetkili sunucu bulunur, sonra o sunucudan A kaydı istenir; bu yüzden NS zinciri kırıksa A kaydınız kusursuz olsa bile siteye ulaşılamaz.
Bir alan adı için kaç tane NS kaydı olmalı?#
En az iki NS kaydı olması hem iyi bir uygulama hem de çoğu kayıt kuruluşunun zorunlu kıldığı bir kuraldır. Tek bir ad sunucusuna güvenmek, o sunucu çöktüğünde alan adının tamamen erişilemez hâle gelmesi anlamına gelir. İki veya daha fazla NS ile yedeklilik sağlarsınız; çözümleyici bir sunucuya ulaşamazsa diğerini dener. Kurumsal yapılar genellikle coğrafi olarak dağıtılmış üç ya da dört ad sunucusu kullanır.
NS kaydını değiştirdim ama site hâlâ eski sunucuya gidiyor, neden?#
Bunun nedeni büyük ihtimalle NS kaydının TTL süresince çözümleyicilerin önbelleğinde saklanmasıdır. NS kayıtlarının TTL'i genellikle uzundur (bir güne kadar), bu yüzden değişiklik dünyaya yayılana kadar bazı ziyaretçiler eski sunucuyu görmeye devam eder. Değişiklikten önce TTL'i düşürmek bu süreyi kısaltır. Kendi tarafınızda dig @1.1.1.1 ornek.com NS gibi bir sorgu ile farklı çözümleyicilerin ne gördüğünü kontrol edebilirsiniz.
Alt alan adını başka bir sağlayıcıya devredebilir miyim?#
Evet, bir alt alanı ana bölgenize onun için NS kayıtları ekleyerek başka bir DNS sağlayıcısına devredebilirsiniz. Örneğin blog.ornek.com için blog IN NS dns1.harici.com. satırlarını eklerseniz, o alt alanın tüm kayıtları artık karşı tarafın sunucularında yönetilir. Devrettiğiniz alt alan için aynı anda hem NS hem de A/CNAME kaydı tanımlamamaya dikkat edin; bu iki yaklaşım çakışır ve öngörülemez sonuçlar doğurur.
Lame delegation nedir ve nasıl anlarım?#
Lame delegation, kayıt kuruluşundaki delegation NS kayıtları ile yetkili sunucuların gerçekte tanıdığı NS kayıtlarının çeliştiği durumdur. Belirtisi genellikle sitenin bazı ziyaretçilerde açılıp bazılarında açılmamasıdır. Teşhis etmek için her ad sunucusuna tek tek dig @ns1.clou.tr ornek.com SOA ve dig @ns2.clou.tr ornek.com SOA sorgusu atın; sunuculardan biri SOA yanıtı vermiyor ya da farklı yanıt veriyorsa lame delegation vardır. Çözüm, registrar ve tüm yetkili sunuculardaki NS listelerini birebir eşitlemektir.
NS kaydı bir IP adresi mi yoksa isim mi içerir?#
NS kaydı her zaman bir ad sunucusunun host adını içerir, doğrudan IP adresi değil. Yani ns1.clou.tr gibi bir isim yazarsınız, 1.2.3.4 değil. Bu ismin çözülebilmesi için ayrıca kendi A/AAAA kaydının bulunması gerekir. Eğer ad sunucusu, hizmet ettiği alan adının kendi altındaysa (örneğin ns1.ornek.com, ornek.com'a hizmet ediyorsa) araya "glue record" adı verilen özel bir kayıt girer ve bu kayıt üst bölgede tutulur.
Kapanış#
NS kaydı, DNS'in görünmeyen ama en belirleyici katmanıdır: doğru yapılandırıldığında hiç fark edilmez, yanlış yapıldığında ise en sağlam sunucuyu bile internetten silebilir. Registrar tarafındaki delegation NS ile bölge içi NS'i birbirine eşit tutmak, en az iki ad sunucusu kullanmak, değişiklik öncesi TTL'i düşürmek ve alt alan devirlerinde NS ile A kayıtlarını karıştırmamak; bu dört alışkanlık, karşılaşacağınız NS sorunlarının neredeyse tamamını baştan önler.
Kendi ad sunucularınızla uğraşmadan hızlı, yedekli ve yönetimi kolay bir DNS altyapısı istiyorsanız, Clou.TR ile alan adınızı domain tarafında yönetip barındırmanızı hosting hizmetine dakikalar içinde bağlayabilirsiniz. Kendi ad sunucusu (özel nameserver) çalıştırmak isteyen bayiler için reseller hosting, tam kontrol arayanlar için VDS sunucu ve kurulum yükünü bize bırakmak isteyenler için sunucu yönetimi hizmetlerimiz hazır. DNS geçişi sırasında kesintisiz taşıma için site taşıma ekibimizle iletişime geçebilir, WordPress altyapınızı ise WordPress hosting paketlerimizle güvenle çalıştırabilirsiniz.