Nameserver Güncellenmiyor Sorunu Nasıl Çözülür?

Registrar panelinizde nameserver'ları güncellediniz, kaydet'e bastınız. Ama 24 saat geçti; site hâlâ eski nameserver'dan yanıt veriyor. Sorgu attığınızda eski NS değerleri geliyor, yeni DNS sağlayıcısının paneli domain'i tanımıyor. Sorun nerede? Çoğu zaman yanıt tek bir yerde değil, birbirini bekleyen iki ayrı sistemin arasında saklanıyor: registrar ve TLD registry.

Registrar panelinde "kaydet" tuşuna basmak, değişikliği registrar'ın kendi veritabanına yazar — ama bu, değişikliğin TLD registry'ye iletildiği anlamına gelmez. İletim ayrı bir adımdır ve kendi gecikmesiyle gelir. Registry güncellemeyi aldıktan sonra bile resolver önbelleklerinde eski NS bilgisi yaşamaya devam edebilir. DNS propagasyonunun genel işleyişini bilmek bu durumu anlamaya yardımcı olur; ancak nameserver değişikliğinin özelinde registry iletim adımı ayrıca ele alınmayı hak eder.

Aşağıda registrar ile TLD arasındaki iletim mekanizması, propagasyon için gerçekçi bekleme süreleri, değişikliğin gerçekten TLD'ye ulaşıp ulaşmadığını test etme yöntemleri ve güncellemeyi engelleyen yaygın durumlar ele alınıyor.

Registrar ile TLD registry arasındaki iletim: iki ayrı sistem

Nameserver değişikliği iki ayrı veritabanını etkiler. Birincisi registrar'ın kendi veritabanı; ikincisi TLD registry'nin zone'u. Registrar panelinde yaptığınız değişiklik yalnızca ilkini anında günceller. TLD zone'una ulaşması için registrar'ın EPP (Extensible Provisioning Protocol) üzerinden registry'ye güncelleme komutu göndermesi gerekir.

Bu iletim gerçek zamanlı olmayabilir. Büyük ve modern registrar'ların büyük çoğunluğu güncellemeyi dakikalar içinde registry'ye iletir. Ancak bazı registrar'lar güncellemeleri belirli aralıklarla toplu olarak gönderir — saatte bir, dört saatte bir ya da günlük batch işlemleriyle. Bu toplu işlem modelinde panel değişikliğinizi kabul ettikten saatler sonra TLD zone'u hâlâ eski NS bilgisini içeriyor olabilir.

; .com TLD nameserver'ını doğrudan sorgula (resolver önbelleğini atla):
dig @a.gtld-servers.net. example.com NS +short

; .net için:
dig @a.gtld-servers.net. example.net NS +short

; .org için:
dig @b0.org.afilias-nst.org. example.org NS +short

; Yanıt yeni NS değerlerini gösteriyorsa registry güncellendi.
; Hâlâ eski NS değerleri geliyorsa registrar henüz iletmedi.

Bu sorgu, standart bir DNS sorgusundan kritik bir farkla çalışır: resolver önbelleğini atlar ve doğrudan TLD nameserver'ına gider. Buradan dönen yanıt, registry'nin şu an için sahip olduğu gerçek bilgiyi yansıtır. Eğer TLD hâlâ eski NS değerlerini döndürüyorsa sorun registrar ile registry arasındadır ve beklemek bir çözüm üretmez — müdahale gerekir. Yanıt yeni NS değerlerini gösteriyorsa registry güncellenmiş demektir; kalan süreç standart DNS propagasyonunun tamamlanmasını beklemektir.

Nameserver değişikliği için gerçekçi bekleme süreleri

Registry güncellemesi tamamlandıktan sonra bile değişikliğin tüm resolver'larda görülmesi zaman alır. TLD NS kayıtlarının TTL'si — registrar'ın kontrolünde değil, TLD registry tarafından belirlenir — genellikle 24 ile 48 saat arasındadır. Bu TTL süresi dolmadan, mevcut NS bilgisini önbelleğe almış resolver'lar yeni sorgu yapmaz.

; .com TLD NS kaydının TTL'sini öğren:
dig @a.gtld-servers.net. example.com NS

; AUTHORITY SECTION'da TTL görünür:
; example.com.  172800  IN  NS  ns1.yenisaglayici.com.
; 172800 saniye = 48 saat

172800 saniye (48 saat) TTL değeri .com zone'u için tipiktir. Bu değer, dünya genelindeki resolver'ların NS bilgisini en fazla 48 saat önbellekte tutabileceği anlamına gelir. Resolver bu TTL dolmadan yeni sorgu yapmaz; eski NS bilgisini kullanmaya devam eder. Dolayısıyla "48 saat bekle" önerisi, propagasyonun teorik üst sınırını temsil eder — ancak pratikte çoğu resolver 12-24 saat içinde güncel bilgiye geçer.

48 saat geçmesine rağmen bazı konumlardan hâlâ eski NS bilgisi görülüyorsa birkaç farklı neden olabilir. Internet servis sağlayıcılarının recursive resolver'ları bazen TTL'den daha uzun süre önbellekte tutabilir — bu teknik bir protokol ihlalidir ama pratikte görülür. Belirli bir coğrafi bölge veya ISP'deki sorun, o resolver'ın cache davranışıyla ilgilidir ve etkilenen kullanıcıların DNS ayarını geçici olarak 8.8.8.8 veya 1.1.1.1 gibi herkese açık resolver'lara çevirmesi sorunu çözebilir.

Güncellemeyi engelleyen yaygın durumlar

TLD sorgusunda eski NS değerleri görünüyorsa — yani registry henüz güncellenmemişse — bu durumu tetikleyen birkaç yaygın senaryo vardır.

Registrar lock ve clientUpdateProhibited: Domain üzerindeki clientUpdateProhibited statüsü, NS dahil tüm kayıt güncellemelerini engeller. Registrar lock çoğunlukla yalnızca transferi engellediği sanılır; oysa bazı registrar'lar güncelleme kilidi de uygular. Güncelleme yapmadan önce domain'in WHOIS statüsünü kontrol etmek, bu engeli önceden tespit eder:

whois example.com | grep -i status

; Olası engelleyici statüsler:
; clientUpdateProhibited  → NS güncelleme engelli
; serverUpdateProhibited  → Registry düzeyinde güncelleme engeli
; clientHold              → Domain askıya alınmış

Kayıtlı olmayan nameserver: Bazı TLD'ler ve bazı registrar'lar, nameserver olarak eklenmek istenen hostname'in registry'de kayıtlı olmasını zorunlu kılar. NS kaydı mekanizması açısından bu özellikle child nameserver yapılarında geçerlidir: ns1.example.com gibi kendi zone'u içinde yer alan bir nameserver, registry'de host kaydı olarak ayrıca tescil edilmiş olmak zorunda olabilir. Yeni bir DNS sağlayıcısının harici nameserver'larını eklerken bu sorunla karşılaşılmaz; kendi nameserver altyapınızı kurarken dikkat edilmesi gereken bir durumdur.

Format ve karakter hatası: Nameserver hostname'inde boşluk, geçersiz karakter ya da eksik nokta bulunması registrar'ın iletimi sessizce başarısız saymasına yol açabilir. Bazı paneller hatalı formatı reddetmez; kaydı kabul eder ama registry'ye iletmez. Hostname'in FQDN formatında — sonunda nokta olmadan, sadece küçük harf ve tire kullanarak — girildiğini doğrulamak bu riski ortadan kaldırır.

Hesap veya ödeme sorunu: Registrar hesabında bekleyen ödeme, askıya alınmış abonelik ya da doğrulanmamış iletişim bilgisi, bazı registrar'larda domain güncellemelerini durdurur. Panel değişikliği kabul edip görüntüler; ancak arka planda işlem tamamlanmaz. Bu durumu kontrol etmek için registrar hesabının uyarılar bölümünü ve e-posta kutusunu incelemek gerekir.

TLD sorgusundan sonra izlenecek yol

Yukarıdaki TLD sorgusunun sonucuna göre iki farklı senaryodan biri geçerlidir.

TLD yeni NS değerlerini döndürüyorsa registry güncellenmiş demektir. Yapılacak tek şey propagasyonun tamamlanmasını beklemektir. Yeni nameserver'ın zone'u hazır olduğunu doğrulamak için doğrudan sorgu atılabilir:

; Yeni NS üzerinden A kaydını sorgula:
dig @ns1.yenisaglayici.com. example.com A +short

; SOA kaydı — zone hazır mı?
dig @ns1.yenisaglayici.com. example.com SOA +short

SOA sorgusuna NOERROR ve geçerli bir serial numarası dönüyorsa yeni nameserver zone'u barındırıyor ve yanıt vermeye hazırdır. Propagasyon tamamlandığında ziyaretçiler otomatik olarak yeni nameserver'a geçecektir.

TLD hâlâ eski NS değerlerini döndürüyorsa registrar iletimi gerçekleştirmemiş demektir. Bu noktada beklemenin bir faydası yoktur. Registrar'ın destek kanalına başvurmak gerekir. Başvuruda şu bilgilerin hazır olması süreci hızlandırır: domain adı, eski nameserver değerleri, yeni nameserver değerleri, değişikliğin yapıldığı tarih ve saat, TLD sorgusunun çıktısı. TLD sorgusunun kopyasını eklemek, sorunun registrar ile registry arasında olduğunu net biçimde gösterir ve destek ekibinin gereksiz teşhis adımlarını atlamasını sağlar.

Propagasyon tamamlandıktan sonra kontrol edilmesi gerekenler

Nameserver güncellemesi tamamlandıktan sonra yalnızca A kaydının çözümlendiğini görmek yetmez. Tam işlevsel bir geçiş için birkaç ek kontrol yapılması gerekir.

E-posta kesintisi nameserver değişikliklerinin en sık gözden kaçan yan etkisidir. MX kaydı yeni nameserver'a tam olarak aktarılmamışsa posta teslimi başarısız olur. Eski sağlayıcıdaki MX, SPF, DKIM ve DMARC kayıtlarının yeni zone'a birebir taşındığını doğrulamak geçiş öncesinde yapılması gereken bir adımdır. TTL optimizasyonu çerçevesinde geçiş öncesinde eski nameserver'daki TTL değerlerini kısaltmak, olası bir geri dönüş senaryosunu da kolaylaştırır.

; A kaydı — web sitesi erişilebilir mi?
dig example.com A +short

; MX kaydı — e-posta yönlendirmesi doğru mu?
dig example.com MX +short

; TXT kaydı — SPF yerinde mi?
dig example.com TXT +short

; Tüm sorguları yetkili NS'den al (önbellek atla):
dig @ns1.yenisaglayici.com. example.com ANY +short

Nameserver değişikliği registrar'ın veritabanından başlayıp TLD registry'ye, oradan resolver önbelleklerine uzanan bir zincir sürecidir. Bu zincirin her halkasında farklı gecikmeler ve farklı engelleyiciler olabilir. TLD sorgusunu referans nokta olarak kullanmak, sorunun hangi halkada olduğunu net biçimde ortaya koyar ve gereksiz bekleme yerine doğru müdahaleye yönlendirir.

Panelinizde kayıtlı görünen ama TLD'ye ulaşmamış bir nameserver değişikliğini, hiçbir ek araç gerektirmeden doğrulamak mümkündür. TLD'yi doğrudan sorgulamak sorunun nerede takıldığını netleştirir; oradan sonra ya propagasyonu beklersiniz ya da registrar desteğine somut veriyle başvurursunuz. Zone hazırlığının geçiş öncesinde tamamlanmış olması ise nameserver değişikliğini salt bir DNS işlemi olmaktan çıkarıp sorunsuz bir altyapı geçişine dönüştüren tek ön koşuldur.