DNS_PROBE_FINISHED_NXDOMAIN Hatası Nasıl Çözülür?

DNS_PROBE_FINISHED_NXDOMAIN, Chrome'un adresi bir IP'ye çeviremediğini ve DNS'in genel olarak çalıştığını gördüğünü, yani "bu ad yok" sonucuna vardığını söyler. Ziyaretçiyseniz önce adresin yazımını kontrol edin, başka bir ağdan deneyin, işletim sisteminin ve Chrome'un DNS önbelleğini temizleyin, VPN'i, hosts dosyasını ve kullandığınız çözümleyiciyi gözden geçirin. Site sahibiyseniz alan adının süresine ve WHOIS durum kodlarına, kayıt kuruluşundaki isim sunucularına, DNS sağlayıcısında bölgenin gerçekten bulunduğuna ve www kaydına bakın. Sorunun nerede olduğunu en hızlı dig çıktısındaki yanıt kodu gösterir.

Hata gerçekte ne söylüyor?

Bir site açılmadığında Chrome hemen hata sayfasını basmaz. Önce arka planda kısa bir DNS denemesi yapar ve sonucuna göre ekrandaki kodu seçer. Chromium kaynak kodundaki açıklama net: DNS_PROBE_FINISHED_NXDOMAIN, "DNS sunucuları düzgün çalışıyor, öyleyse alan adı var olmamalı" çıkarımının adıdır. Benzer durumda DNS_PROBE_FINISHED_NO_INTERNET internet bağlantısı olmadığını, DNS_PROBE_FINISHED_BAD_CONFIG ise DNS yapılandırmasının yanlış olduğunu ya da sunucuların yanıt vermediğini anlatır.

Buradaki ince nokta şu: ekrandaki NXDOMAIN bir çıkarımdır. Çözümleyicinin gerçekten NXDOMAIN döndürdüğünü kanıtlamaz. Chrome'un adresi hangi yoldan çözdüğüne (işletim sisteminin çözümleyicisi ya da Güvenli DNS) göre başka bir DNS hatası da benzer bir sayfaya düşebilir. Teşhise ekran görüntüsüyle değil, DNS'in kendi yanıt koduyla başlamak bu yüzden daha sağlıklıdır.

DNS standardında NXDOMAIN, RFC 1035'teki "Name Error" kodunun yaygın adıdır: yetkili isim sunucusu, sorulan adın var olmadığını söylemektedir. Bu cevap önbelleğe de alınır. RFC 2308'e göre olumsuz cevabın önbellekte kalma süresi, bölgenin SOA kaydındaki TTL ile SOA'nın MINIMUM alanından küçük olanıdır. Yeni eklediğiniz bir kaydın bir süre "yok" görünmesinin nedeni çoğu zaman budur.

NXDOMAIN, SERVFAIL, REFUSED: farkı neden önemli?

Yanıt kodu, sorunun hangi katmanda olduğunu söyler. Aşağıdaki tablo komut satırında görebileceğiniz sonuçları ve tipik nedenlerini bir araya getiriyor.

Sık karıştırılan bir durumu ayrıca belirtelim. İsim sunucularını yeni bir sağlayıcıya çevirip alan adını o sağlayıcının paneline eklemeyi unuttuysanız, ziyaretçinin çözümleyicisi NXDOMAIN almaz. Yetkili gösterilen sunucuya doğrudan sorduğunuzda çoğunlukla REFUSED, genel bir çözümleyiciden sorduğunuzda SERVFAIL görürsünüz. Çözüm aynıdır ama nerede arayacağınızı bilmek zaman kazandırır. SERVFAIL'in arkasında DNSSEC'teki DS kaydı ya da imza uyuşmazlığı da olabilir, bu durumda sorun bölgenin varlığında değil, güven zincirindedir.

Sorun sizde mi, sitede mi?

Üç dakikalık bir ayrım testi, saatlerce yanlış yerde aramaktan iyidir. Aynı adresi telefonunuzda Wi-Fi'ı kapatıp mobil veriyle açmayı deneyin. Ardından aşağıdaki iki sorguyu çalıştırın. Biri kendi ağınızın çözümleyicisini, diğeri genel bir çözümleyiciyi kullanır:

dig ornek.com.tr
dig @1.1.1.1 ornek.com.tr

Çıktının başındaki status: alanına bakın. İkisi de NOERROR diyor ve ANSWER SECTION altında bir IP görünüyorsa alan adı çözülüyordur, sorun sizin bilgisayarınızda ya da tarayıcınızdadır. İkisi de NXDOMAIN diyorsa sorun alan adı tarafındadır ve ziyaretçinin yapabileceği bir şey yoktur. Biri çözüp diğeri çözmüyorsa önbellek ya da çözümleyici farkı vardır.

Windows'ta dig hazır gelmez. Aynı ayrımı nslookup ornek.com.tr 1.1.1.1 ile yapabilirsiniz. Microsoft'un belgesine göre nslookup, ad bulunamadığında "Nonexistent domain", sunucu hatasında "Server failure", reddedilen sorguda "Refused" yazar.

Ziyaretçiyseniz: kendi tarafınızda yapılacaklar

Yazım ve adres

Kulağa basit geliyor ama ilk bakılacak yer burası. .com.tr yerine .com yazmak, harf atlamak ya da otomatik tamamlamanın eski bir adresi önermesi aynı hatayı üretir. Adresi elle, eksiksiz yazıp deneyin.

İşletim sisteminin DNS önbelleği

Bilgisayarınız daha önce aldığı cevapları, olumsuz cevaplar dahil, bir süre saklar. Site sahibi sorunu düzeltmiş olsa bile sizin makineniz eski "yok" cevabını tekrarlayabilir. Windows'ta Komut İstemi'ni açıp şunu çalıştırın:

ipconfig /flushdns

Microsoft'un belgesi bu komutun DNS istemci önbelleğini sıfırladığını ve olumsuz önbellek kayıtlarını da attığını açıkça yazar. macOS için Apple'ın yayımladığı güncel bir resmî komut sayfası yok. Yaygın kullanılan yöntem şu iki komuttur, ikisi de yönetici parolası ister:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Bu komutlar işe yaramazsa ağ bağlantısını kapatıp açmak ya da bilgisayarı yeniden başlatmak da bellekteki önbelleği boşaltır. Linux'ta durum dağıtıma göre değişir. systemd-resolved kullanan sistemlerde (güncel Ubuntu sürümleri gibi) resolvectl flush-caches komutu, servisin tuttuğu bütün kayıt önbelleklerini temizler. nscd ya da dnsmasq kullanan sistemlerde ilgili servisi yeniden başlatmak gerekir.

Chrome'un kendi önbelleği ve Güvenli DNS

Chrome işletim sisteminden ayrı bir ana makine önbelleği de tutar. Adres çubuğuna chrome://net-internals/#dns yazın ve Clear host cache düğmesine basın. Ardından tarayıcıyı tamamen kapatıp açın.

Bir de Ayarlar > Gizlilik ve güvenlik > Güvenlik altındaki Güvenli DNS kullan (Use secure DNS) seçeneğine bakın. Google'ın yardım sayfasına göre otomatik modda Chrome, şifreli sorgu sorun çıkarırsa şifresiz sorguya geri döner. Özel bir sağlayıcı seçtiyseniz bu geri dönüş olmaz ve o sağlayıcıdaki bir sorun doğrudan hata olarak karşınıza çıkar. Hatayı yalnız Chrome'da görüyor, başka tarayıcıda görmüyorsanız ilk şüpheli bu ayardır.

Çözümleyici, VPN, hosts dosyası ve modem

VPN açıkken bütün DNS sorguları VPN sağlayıcısının çözümleyicisine gider. VPN'i kapatıp deneyin. Ardından hosts dosyasına göz atın: Windows'ta C:\Windows\System32\drivers\etc\hosts, macOS ve Linux'ta /etc/hosts. Taşıma testinden kalmış eski bir satır, alan adını sizin bilgisayarınızda bambaşka bir yere götürebilir.

Sorun yalnız ev ya da ofis ağınızda çıkıyorsa modemin dağıttığı çözümleyiciden şüphelenin. Modemi yeniden başlatmak çoğu zaman yeterli olur. Olmazsa bilgisayarın ağ ayarlarında çözümleyiciyi geçici olarak genel bir hizmete (1.1.1.1, 8.8.8.8 ya da 9.9.9.9 gibi) çevirip deneyin. Kurumsal ağlarda bu ayar yöneticinin denetimindedir, değiştirmeden önce sorun.

Site sahibiyseniz: alan adı tarafında kontrol sırası

Hata herkes için aynıysa sorunu genellikle şu dört yerden birinde bulursunuz. Sırayı değiştirmeyin, çünkü üstteki adım çözülmeden alttakini kontrol etmenin anlamı yoktur.

Alan adının süresi ve durum kodları

Bir gece aniden başlayan NXDOMAIN'in en sık nedeni süresi dolmuş alan adıdır. WHOIS çıktısında bitiş tarihine ve durum (status) alanına bakın. clientHold ya da serverHold görüyorsanız tablo netleşir: EPP standardını tanımlayan RFC 5731'e göre bu iki durumda alan adının yetki devri bilgisi DNS'te yayımlanmaz. Üst bölge alan adını tanımaz, herkes NXDOMAIN alır. clientHold çoğunlukla kayıt kuruluşunun koyduğu askıdır (ödeme, doğrulama gibi nedenlerle), serverHold ise kayıt otoritesinden gelir.

Kontrolü WHOIS sorgulama sayfasından ya da kayıt kuruluşunuzun panelinden yapabilirsiniz. Durum kodlarının geri kalanını WHOIS kayıtlarındaki durum alanları rehberinde, süre dolduktan sonraki takvimi ve kurtarma adımlarını alan adının süresi dolunca yaşanan aşamalar rehberinde anlattık. Ad hiç kayıtlı görünmüyorsa alan adı sorgulama ekranı müsait olup olmadığını söyler.

Kayıt kuruluşundaki isim sunucuları

Süre ve durum temizse yetki zincirine bakın. dig +trace sorguyu kökten başlatıp her adımda kimin yanıt verdiğini gösterir:

dig +trace ornek.com.tr

Çıktı katman katman ilerler: kök sunucular, ardından uzantının sunucuları, en sonda alan adının isim sunucuları. Her bloğun altındaki Received ... from satırı o cevabı veren sunucuyu yazar. NXDOMAIN uzantının sunucularından geliyorsa alan adı üst bölgede hiç yayımlanmıyordur, yukarıdaki süre ve durum kontrolüne dönün. Uzantı sunucuları sizin beklediğinizden farklı isim sunucularını gösteriyorsa kayıt kuruluşundaki NS ayarı yanlış ya da eksik yazılmıştır. En sık yapılan hata, sunucu adını yanlış yazmak ya da birini değiştirip diğerini eski sağlayıcıda bırakmaktır.

Bölge DNS sağlayıcısında gerçekten var mı?

İsim sunucuları doğru görünüyor ama alan adı yine çözülmüyorsa sağlayıcının o sunucularında bölge tanımlı olmayabilir. Yetkili sunucuya doğrudan SOA sorun:

dig @<yetkili-isim-sunucusu> ornek.com.tr SOA

status: NOERROR ve bir SOA kaydı dönüyorsa bölge oradadır. REFUSED ya da SERVFAIL dönüyorsa bölge o sunucuda yüklü değildir. Hosting paneline alan adı eklenmeden isim sunucularının çevrildiği durumlarda tam olarak bunu görürsünüz. Paneli kullanıyorsanız alan adını hesaba ekleyin, harici bir DNS hizmeti kullanıyorsanız bölgeyi orada oluşturun. İsim sunucusu ile A kaydı yöntemlerinin hangisinde bölgenin nerede durduğunu alan adını hostinge bağlama yöntemleri rehberi ayrıntılı anlatıyor.

www ve alt alan adları

Kök adres açılıyor ama www.ornek.com.tr NXDOMAIN veriyorsa (ya da tersi) bölgede ilgili ad tanımlı değildir. Sağlayıcı değişikliğinden sonra en sık unutulan kayıt budur. Kök için bir A kaydı, www için kök adrese giden bir CNAME ya da ikinci bir A kaydı ekleyin. cPanel kullanıyorsanız Zone Editor'de A ve CNAME kaydı ekleme adımları bu işi görür. Kayıt türlerinin farkını ve TTL'in değişikliklere etkisini DNS kayıtları ve yayılma süresi rehberinde bulabilirsiniz.

Yeni kayıt ya da yeni eklenen ad

Diyelim ki www kaydını az önce eklediniz ama bir saat önce birisi bu adı sorgulamış ve NXDOMAIN almıştı. O cevap, RFC 2308'deki kurala göre bölgenin SOA değerlerine bağlı bir süre boyunca çözümleyicilerde kalır. Süreyi görmek için:

dig www.ornek.com.tr
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, ...
;; AUTHORITY SECTION:
ornek.com.tr.  3600  IN  SOA  ns1.ornek.com.tr. hostmaster.ornek.com.tr. 2026102901 7200 3600 1209600 3600

Örnekte AUTHORITY bölümündeki SOA satırının en sonundaki sayı MINIMUM alanıdır (3600 saniye, bir saat). Kaydın kendi TTL'i de 3600 olduğundan olumsuz cevap bir saate kadar önbellekte kalabilir. Yeni kayıt ettirilen alan adlarında da benzer bir bekleme yaşanabilir: kayıt tamamlanıp isim sunucuları üst bölgede yayımlanana kadar ad çözülmez, öncesinde yapılmış sorguların olumsuz cevabı bir süre daha önbellekte durur.

Düzeldiğini nasıl doğrularsınız?

Düzeltmeyi yaptıktan sonra tek bir tarayıcı denemesine güvenmeyin. Önbellekler farklı zamanlarda boşalır. Şu kontroller birlikte olumlu sonuç vermelidir:

• dig +trace ornek.com.tr zincirin sonunda bir A kaydıyla bitiyor.
• dig @1.1.1.1 ornek.com.tr ve dig @8.8.8.8 www.ornek.com.tr sorgularında status: NOERROR ve doğru IP görünüyor.
• Yetkili sunucuya doğrudan yapılan SOA sorgusu NOERROR dönüyor.
• İşletim sistemi ve Chrome önbelleği temizlendikten sonra site hem bilgisayarda hem mobil veride açılıyor.

Genel çözümleyicilerden biri hâlâ NXDOMAIN veriyorsa ve yetkili sunucu doğru cevap veriyorsa yapacak bir şey yoktur, olumsuz önbellek süresinin dolmasını bekleyin. Ad çözüldüğü hâlde site açılmıyorsa sorun artık DNS'te değil, sunucu ya da uygulama katmanındadır. Cloudflare kullanan sitelerde bu aşamada ekrana Cloudflare'in kendi hata sayfaları çıkar, örneğin Cloudflare ile sunucu arasındaki bağlantının zaman aşımına uğradığını anlatan 522 hatası.

Destek talebi açmadan önce hazırlayın

Alan adı ya da DNS hizmeti Netx'teyse Netx müşteri panelinden destek talebi açabilirsiniz. "Site açılmıyor" yerine aşağıdaki bilgileri gönderirseniz teşhis doğrudan doğru katmandan başlar:

• Alan adı ve tam hata kodu (DNS_PROBE_FINISHED_NXDOMAIN, ERR_NAME_NOT_RESOLVED gibi)
• Hatanın kök adreste mi, www'de mi, yoksa bir alt alan adında mı görüldüğü
• dig +trace ve yetkili sunucuya yapılan SOA sorgusunun çıktısı
• Farklı ağ ya da cihazda da görülüp görülmediği
• Son günlerde yapılan değişiklik: isim sunucusu, transfer, yenileme, DNS sağlayıcısı değişimi