DNS Hataları Yüzünden Site Açılmıyor: DNS_PROBE_FINISHED_NXDOMAIN Teşhis Rehberi

DNS hataları neden sitenizi bir anda görünmez yapıyor?

Tarayıcıya alan adınızı yazıyorsunuz, Enter’a basıyorsunuz ve karşınıza hiç hoş olmayan bir ekran çıkıyor: boş bir sayfa, tarayıcı uyarısı veya “DNS_PROBE_FINISHED_NXDOMAIN” benzeri bir hata. Sunucu tarafında her şeyin yolunda olduğunu, sitenizin dün akşam çalıştığını biliyorsunuz; ama bugün ne siz, ne de müşterileriniz erişebiliyor. Bu tablo, DCHost ekibi olarak sahada en sık karşılaştığımız sorunlardan biri.

DNS hatalarının can sıkıcı tarafı, sorunun kaynağının ilk bakışta belirsiz olmasıdır. Problem; bilgisayarınızda, modeminizde, ISS’in DNS’inde, alan adınızın nameserver kayıtlarında, DNS zonunda, hatta alan adınızın süresinin dolmuş olmasında bile olabilir. Üstelik tarayıcı, çoğu zaman sadece “DNS_PROBE_FINISHED_NXDOMAIN” gibi tek satırlık, yoruma açık bir mesaj gösterir.

Bu yazıda, özellikle DNS_PROBE_FINISHED_NXDOMAIN ve benzeri DNS hatalarını sistematik şekilde teşhis edebilmeniz için adım adım bir yol haritası paylaşacağız. Kullanıcı tarafındaki basit kontrollerden, alan adı yaşam döngüsü ve DNS kayıtlarının detaylı incelemesine kadar tüm katmanları ele alacağız. Amacımız, sorunun hangi katmanda olduğunu hızlıca bulup, doğru noktaya odaklanmanızı sağlamak ve hem anlık kesintileri hem de uzun vadeli DNS problemlerini en aza indirmenize yardımcı olmak.

Tarayıcıda görebileceğiniz yaygın DNS hata mesajları

Tarayıcılar ve işletim sistemleri, DNS sorunlarında farklı hata mesajları gösterebilir. En sık karşınıza çıkabilecek mesajlardan bazıları şunlardır:

• DNS_PROBE_FINISHED_NXDOMAIN – Alan adının DNS tarafında bulunamadığını (NXDOMAIN: Non-Existent Domain) ifade eder.
• ERR_NAME_NOT_RESOLVED – Alan adı bir IP adresine çözümlenemedi, genellikle NXDOMAIN veya hatalı DNS yapılandırması ile ilişkilidir.
• DNS_PROBE_FINISHED_BAD_CONFIG – DNS yapılandırmasında bir sorun olduğunu, çoğu zaman istemci (bilgisayar/modem) veya yanlış DNS sunucusu ayarlarını işaret eder.
• DNS_PROBE_STARTED / DNS_PROBE_FINISHED_NO_INTERNET – Çözümleme başlamış ama internet bağlantısı ya yok ya da kararsız.
• SERVFAIL – DNS sunucusu alan adını çözerken hata aldı; genellikle yetkili DNS sunucusundaki sorunlar, yanlış yapılandırılmış DNSSEC veya geçersiz kayıtlarla ilişkilidir.
• REFUSED – DNS sunucusu isteği bilinçli olarak reddediyor; IP bazlı kısıtlama, yanlış izinler veya firewall kaynaklı olabilir.

Bu hata mesajlarının hepsi aynı şeyi söylemez, ancak ortak noktaları: alan adının geçerli bir IP adresine çözümlenememesidir. Dolayısıyla asıl hedefimiz, DNS’in hangi adımda “koptuğunu” bulmak olacaktır.

İlk adım: Sorun sizde mi, sitede mi? Hızlı kullanıcı tarafı kontrolleri

Önce, problemi gerçekten DNS katmanında mı yoksa yerel cihazınızda mı yaşadığınızı netleştirmek gerekir. Hem kendi işinizi hem de destek ekibinizin işini çok kolaylaştırır.

1) Farklı cihaz ve ağdan test edin

• Aynı Wi-Fi ağına bağlı başka bir telefondan veya bilgisayardan siteye girin.
• Mümkünse mobil veriye geçerek (4G/5G) aynı alan adını test edin.

Senaryolar:

• Sadece sizin bilgisayarınızda hata oluşuyorsa: Yerel DNS cache, tarayıcı cache’i, güvenlik yazılımları veya hosts dosyası şüpheli.
• Aynı ağdaki herkeste hata oluşuyorsa: Modem/Router DNS ayarları veya ISS kaynaklı bir durum olabilir.
• Farklı ağlarda da aynı hata varsa: Büyük olasılıkla sorun alan adı tarafında (nameserver, DNS zone, alan adı durumu vb.).

2) Tarayıcı ve sistem önbelleğini temizleyin

Tarayıcılar ve işletim sistemleri, DNS sonuçlarını bir süreliğine önbellekte tutar. Önce en basit adımları deneyin:

• Tarayıcı gizli sekmede alan adını açmayı deneyin.
• Tarayıcı cache’ini ve çerezleri silin.
• Farklı bir tarayıcı ile test edin.

3) DNS önbelleğini (DNS cache) sıfırlayın

İşletim sisteminin tuttuğu DNS önbelleği bozulmuş veya eski kalmış olabilir. Aşağıdaki komutları terminal/komut satırında çalıştırarak DNS cache’i temizleyebilirsiniz:

• Windows için:

  ipconfig /flushdns

• macOS (yeni sürümler) için:

  sudo dscacheutil -flushcache
  sudo killall -HUP mDNSResponder

• Linux (systemd-resolved kullanan sistemlerde):

  sudo systemd-resolve --flush-caches

Bu işlemlerden sonra tarayıcıyı tamamen kapatıp açın ve tekrar deneyin.

4) hosts dosyasını kontrol edin

Eğer daha önce test amaçlı olarak hosts dosyanıza manuel kayıt eklediyseniz, artık geçerli olmayan bir IP’ye işaret ediyor olabilir.

• Windows: C:\Windows\System32\drivers\etc\hosts
• Linux/macOS: /etc/hosts

İlgili alan adını eski bir IP’ye zorla yönlendiren satırlar varsa, geçici olarak yorum satırı haline getirin veya silin. Dosyayı kaydedip tarayıcıyı yeniden başlattıktan sonra tekrar test edin.

Adım adım teknik teşhis: DNS_PROBE_FINISHED_NXDOMAIN kök neden analizi

Yerel kontrolleri yaptıktan ve sorunun gerçekten DNS katmanında olduğunu gördükten sonra, daha sistematik gitmemiz gerekiyor. Aşağıdaki adımlar, DCHost tarafında da DNS kaynaklı kesintileri teşhis ederken izlediğimiz tipik yol haritasının sadeleştirilmiş hali.

1) Alan adı gerçekten aktif mi? Süresi dolmuş olabilir

İnanması zor gelse de, “DNS_PROBE_FINISHED_NXDOMAIN” hatalarının önemli bir kısmı alan adı süresi dolduğu için ortaya çıkıyor. Müşteri tarafında fatura e-postası gözden kaçıyor, otomatik yenileme kapalı oluyor ve alan adı grace/redemption dönemine giriyor.

Önce basit bir WHOIS sorgusu ile:

• Alan adının sona erme tarihini,
• Registrar bilgisini,
• Alan adının kilitli (transfere kapalı) olup olmadığını

kontrol edin. Alan adının yaşam döngüsünün nasıl işlediğini daha iyi anlamak için alan adı yaşam döngüsü ve düşen domain yakalama rehberimizi mutlaka gözden geçirmenizi öneririz.

Alan adınız gerçekten grace veya redemption dönemindeyse, önce yenileme sorununu çözmeden DNS tarafında yapacağınız hiçbir düzeltme tek başına işe yaramayacaktır.

2) Nameserver kayıtları doğru ve aktif mi?

Alan adının aktif olduğunu doğruladıktan sonra ikinci adım, NS (nameserver) kayıtlarını kontrol etmek olmalı. Çünkü tarayıcı, alan adınızın hangi DNS sunucularına sorulacağını bu kayıtlardan öğrenir.

• Alan adınızın kayıtlı olduğu registar paneline girin.
• NS/nameserver bölümünde yazan sunucu adreslerini not edin (örneğin, ns1.ornekns.com, ns2.ornekns.com gibi).
• Bu nameserver’ların gerçekten var olup olmadığını ve cevap verip vermediğini dig veya nslookup ile test edin.

Örneğin:

dig NS ornekalanadi.com

Bu komutla yetkili NS kayıtlarını görebilirsiniz. Komut çıktısında hiç NS kaydı yoksa veya beklediğinizden farklı NS’ler geliyorsa, alan adı tarafında yanlış veya eksik nameserver tanımlanmış demektir.

Kendi özel ad sunucularınızı kullanıyorsanız (örneğin ns1.sizinmarka.com gibi), glue record yapılandırmasının da doğru olduğundan emin olmanız gerekir. Bu konuyu detaylı anlattığımız özel ad sunucusu ve glue record rehberimizi incelemeniz, ileride oluşabilecek karmaşık DNS sorunlarının önüne geçmenize yardımcı olacaktır.

3) DNS zone içinde A/AAAA ve diğer kritik kayıtlar var mı?

Nameserver’lar doğru ise, sıradaki adım DNS zone içeriğini kontrol etmektir. En kritik kayıtlar genellikle şunlardır:

• A kaydı – Alan adını IPv4 adrese yönlendirir (ör. 203.0.113.10).
• AAAA kaydı – Alan adını IPv6 adrese yönlendirir.
• CNAME kaydı – Bir alan adını başka bir alan adına yönlendirir.
• MX kaydı – E-posta teslimatı için posta sunucularını tanımlar.

Özellikle ana alan adınız (ör. ornekalanadi.com) ve varsa www alt alan adınız için A/AAAA veya CNAME kaydı yoksa, tarayıcı “DNS_PROBE_FINISHED_NXDOMAIN” hatası verebilir.

DNS kayıtlarının doğru türde ve doğru formatta olup olmadığını adım adım öğrenmek için hazırladığımız DNS kayıtları A’dan Z’ye rehberine mutlaka göz atın. Özellikle yanlış kullanılmış CNAME kayıtları veya kök alan adında istenen ama teknik olarak sakıncalı CNAME’ler, uzun süre fark edilmeyen sorunlar yaratabiliyor.

4) TTL ve DNS yayılımı: Gerçekten sorun mu var, yoksa eski kayıt mı görünüyor?

DNS değişikliği yaptıysanız (IP değiştirdiniz, nameserver taşıdınız, A kaydını güncellediniz vb.), TTL (Time To Live) değerleri nedeniyle bazı kullanıcılar bir süre eski kayıtları görmeye devam edebilir. Bu durum, sizde site açılırken başka bir bölgede “DNS_PROBE_FINISHED_NXDOMAIN” alınmasına yol açabilir.

Büyük geçişler ve taşımalarda TTL değerlerini nasıl planlamanız gerektiğini, adım adım örneklerle zero-downtime taşıma için TTL stratejileri rehberimizde anlattık. Kısaca:

• Taşıma öncesinde TTL’leri yavaş yavaş düşürmek,
• Geçişi yaptıktan sonra bir süre düşük TTL’le devam etmek,
• Her şey stabil olduktan sonra TTL’leri tekrar yükseltmek

en sağlıklı yaklaşımdır. Aksi halde, farklı bölgelerde farklı DNS cevapları görmek kaçınılmaz olur.

5) DNSSEC yanlış yapılandırması ve SERVFAIL kaynaklı gizli sorunlar

DNSSEC, DNS kayıtlarınızın bütünlüğünü kriptografik olarak doğrulayan bir güvenlik katmanıdır. Ancak yanlış yapılandırıldığında, alan adınız bazı resolver’lar için tamamen ulaşılamaz hale gelebilir. Örneğin:

• DNSSEC etkin ama DS kayıtları yanlış veya güncel değilse,
• KSK/ZSK anahtar döndürme (key rollover) işlemi hatalı yapıldıysa,
• DNS sağlayıcınızı değiştirdiğiniz halde eski DS kaydı registrar tarafında kaldıysa

bazı kullanıcılar SERVFAIL veya NXDOMAIN benzeri hatalar görebilir, bazıları ise hiç sorun yaşamayabilir.

DNSSEC’in ne işe yaradığını ve nasıl güvenli şekilde etkin tutulacağını anlattığımız DNSSEC rehberimize mutlaka göz atın. Daha ileri seviye ihtiyaçlar için hazırladığımız DNSSEC key rollover yazısı da özellikle büyük projelerde hayat kurtarıcı olabilir.

Komut satırıyla DNS teşhisi: nslookup, dig ve traceroute

Bir noktadan sonra, tarayıcıdaki tek satırlık hata mesajları yetersiz kalır. O an devreye klasik ağ araçları girer: nslookup, dig, traceroute.

1) nslookup ile temel kontrol

Windows, macOS ve Linux’ta kullanabileceğiniz basit bir araçtır. Örneğin:

nslookup ornekalanadi.com

Burada dikkat etmeniz gerekenler:

• Non-existent domain gibi bir çıktı görüyorsanız: Resolver, alan adınız için hiç kayıt bulamamış demektir (NXDOMAIN).
• Cevap veren DNS sunucusunun adresi (genelde ISS DNS’i) ve dönen IP adresleri.

2) dig ile detaylı çıktı almak

dig, özellikle Linux ve macOS tarafında daha detaylı çıktılar sunar. Örneğin:

dig ornekalanadi.com A

Komut çıktısında:

• ANSWER SECTION kısmında IP adresi görmeniz gerekir.
• status: NXDOMAIN görüyorsanız, DNS sunucusu bu alan adının mevcut olmadığını düşünüyor demektir.
• status: SERVFAIL ise, genellikle DNSSEC veya yetkili DNS sunucusu kaynaklı daha derin bir hata vardır.

Yetkili nameserver’ı doğrudan sorgulamak için:

dig @ns1.ornekns.com ornekalanadi.com A

Bu sayede, aradaki resolver’ları atlayarak sorunun yetkili DNS sunucusundaki kayıtlardan mı, yoksa aradaki zincirden mi kaynaklandığını ayırt edebilirsiniz.

3) traceroute / tracert ile ağ yolunu incelemek

DNS sorunlarının bir kısmı, aslında ağ seviyesindeki erişim problemlerinin semptomu olabilir. Örneğin, yetkili DNS sunucunuzun bulunduğu IP bloğu bazı ISS’ler tarafından geçici olarak erişilemez durumdadır.

• Windows: tracert ornekalanadi.com
• Linux/macOS: traceroute ornekalanadi.com

Eğer traceroute çıkışı belirli bir noktada kesiliyor veya time-out veriyorsa, sorun DNS kayıtlarınızdan ziyade network rotasında olabilir. Bu durumda DCHost destek ekibimizle veya ağ yöneticinizle birlikte daha derin bir analiz yapmak gerekir.

DCHost müşterileri için tipik senaryolar ve pratik çözümler

DCHost tarafında, hem paylaşımlı hosting hem de VPS/dedicated sunucu müşterilerimizde DNS kaynaklı benzer senaryoları sıkça görüyoruz. Bunların bir kısmı birkaç dakikalık düzenlemeyle çözülebilirken, bazıları daha planlı bir mimari gerektiriyor.

Senaryo 1: IP değişti, A kaydı güncellenmedi

En sık karşılaştığımız senaryolardan biri: Müşteri, farklı bir sunucuya geçiyor veya yeni bir VPS’e taşınıyor, ancak alan adının A kaydı eski IP’yi göstermeye devam ediyor. Sonuç: “DNS_PROBE_FINISHED_NXDOMAIN” ya da farklı IP’de çalışan, artık geçerli olmayan bir eski site.

Çözüm adımları:

• Yeni sunucunun IP adresini kesin olarak doğrulamak.
• Alan adınızın DNS zonunda A/AAAA kayıtlarını doğru IP’ye güncellemek.
• TTL değerlerini geçici olarak düşürerek geçiş sürecini hızlandırmak.

DNS yayılımını beklerken, farklı bölgelerden sorgu yaparak hangi resolver’ların yeni IP’yi görmeye başladığını takip edebilirsiniz.

Senaryo 2: Farklı DNS sağlayıcısı kullanırken nameserver unutuldu

Bazen müşterilerimiz, performans veya özellik nedeniyle üçüncü parti bir DNS hizmetine geçiyor; ancak alan adının registrar panelindeki nameserver kayıtlarını güncellemeyi atlayabiliyor. Tarayıcı, eski nameserver’lara bakmaya devam ettiği için, DNS kayıtları ile gerçekte kullanılan DNS paneli birbirini tutmuyor.

Bu durumda kontrol listesi:

• Hangi DNS panelini gerçekten kullandığınızı netleştirin.
• Registrar panelindeki NS kayıtlarını bu panele ait nameserver’larla hizalayın.
• Eski DNS panelinde kalan “artık” kayıtları temizleyin; ileride kafa karışıklığı yaşamayın.

Farklı DNS çözümleri arasında seçim yaparken dikkat edilmesi gereken noktaları, nameserver stratejisi üzerine hazırladığımız yazıda detaylı olarak anlattık. DCHost üzerinde barınan projeleriniz için de benzer prensipler geçerli.

Senaryo 3: VPS üzerinde kendi DNS sunucunuzu yönetirken yapılandırma hatası

VPS veya dedicated sunucu üzerinde kendi DNS sunucunuzu (örneğin BIND, PowerDNS vb.) yönetiyorsanız, ufak bir konfigürasyon hatası bile NXDOMAIN veya SERVFAIL hatalarına sebep olabilir:

• Zone dosyasında syntax hatası,
• SOA/NS kayıtlarında eksiklik,
• Yanlış seri numarası (serial) veya hatalı increment,
• Master/Slave replikasyon problemleri

DCHost üzerinde kendi DNS altyapısını yöneten müşterilerimiz için, test ortamında değişiklik yapmak, staging zone’lar kullanmak ve konfigürasyonları sürüm kontrollü bir depo ile yönetmek en güvenli yaklaşım oluyor. Böylece sorun çıktığında “önceki çalışan” sürüme hızlıca dönebilmek mümkün.

Benzer hatalar: BAD_CONFIG, SERVFAIL, REFUSED… Ne anlama geliyor?

Her DNS hatası NXDOMAIN değildir. Tarayıcıların gösterdiği bazı hata kodları, sorunun kökeni hakkında ipucu verir.

DNS_PROBE_FINISHED_BAD_CONFIG

Genellikle istemci tarafındaki (bilgisayarınız, modeminiz veya kullandığınız DNS sunucusu) hatalı yapılandırmayı işaret eder:

• Modemde yanlış DNS sunucusu IP’leri tanımlanmış olabilir.
• Bilgisayarınızda manuel olarak girilmiş, artık çalışmayan DNS adresleri olabilir.
• Yerel firewall veya güvenlik yazılımları, DNS trafiğini engelliyor olabilir.

Bu durumda ağ ayarlarındaki DNS alanını “otomatik”e çekip, modemi yeniden başlatmak ve alternatif bir ağda test etmek iyi bir başlangıçtır.

SERVFAIL

SERVFAIL, yetkili DNS sunucusunun soru karşısında hata verdiğini gösterir. Nedenleri arasında:

• Yanlış yapılandırılmış DNSSEC,
• Yetkili DNS sunucusuna ağ seviyesinde ulaşılamaması,
• DNS sunucusunun iç hata (konfigürasyon, yazılım) üretmesi

sayılabilir. Eğer dig çıktısında status: SERVFAIL görüyorsanız, sorunun köküne inmek için yetkili DNS sunucusunun loglarını da incelemek gerekir.

REFUSED

REFUSED, DNS sunucusunun isteğinizi bilerek reddettiği anlamına gelir. Sık görülen sebepler:

• DNS sunucusu sadece belirli IP bloklarından gelen isteklere izin veriyor olabilir.
• Recursion (özyinelemeli sorgu) yetkisi kısıtlanmış olabilir.
• Firewall, belirli portlardan (genellikle 53/UDP, 53/TCP) gelen istekleri kesiyor olabilir.

Bu tür durumlar, özellikle kendi DNS sunucunuzu çalıştırıyorsanız yanlış firewall kuralı veya yanlış “allow-query” yapılandırmasından kaynaklanabilir.

Kalıcı olarak DNS sorunlarından kaçınmak için iyi pratikler

DNS sorunlarını sadece “yangın çıktığında” çözmeye çalışmak yerine, baştan doğru tasarlamak çok daha az maliyetli ve streslidir. DCHost olarak çoğu projede önerdiğimiz bazı pratikler:

• Alan adı yenileme takvimi oluşturun, otomatik yenileme ve hatırlatıcıları aktif tutun. Özellikle kritik projeler için birden fazla kişiye uyarı gitmesini sağlayın.
• DNS değişikliklerini belgeleyin. Hangi tarihte hangi kaydı değiştirdiğinizi, eski ve yeni değerleri not edin; gerekirse bir değişiklik günlüğü (changelog) tutun.
• TTl stratejisi geliştirin. Taşıma veya IP değişimi yapacaksanız, TTL’leri önceden düşürün; her şeyi test ettikten sonra yükseltin.
• Staging/test ortamı kullanın. Özellikle kendi DNS sunucusunu yöneten ekipler için, canlıya almadan önce test zone’larında değişiklikleri denemek çok önemli.
• DNSSEC ve güvenlik yapılandırmalarını bilinçli yönetin. Ne yaptığınızdan emin değilseniz, önce test domain’lerinde deneme yapın.

Daha büyük mimarilerde, kesintisiz erişilebilirlik hedefliyorsanız, Anycast DNS ve otomatik failover üzerine hazırladığımız rehber de size yol gösterebilir.

Sonuç: DNS_PROBE_FINISHED_NXDOMAIN hatalarını sistematik şekilde çözmek

“DNS_PROBE_FINISHED_NXDOMAIN” ve benzeri DNS hataları, ilk bakışta gizemli ve sinir bozucu görünebilir. Ancak sorunu katmanlara ayırdığınızda; önce kullanıcı tarafını (cache, hosts, modem), ardından alan adı durumunu (WHOIS, sona erme tarihi), sonra nameserver ve DNS zone’unu (NS, A/AAAA, CNAME, MX kayıtları), gerekirse de DNSSEC ve ağ rotasını incelediğinizde, çoğu problemi birkaç net adımda teşhis etmek mümkündür.

DCHost olarak hem paylaşımlı hosting hem de VPS/dedicated altyapılarımızda, DNS yapılandırmanızı mümkün olduğunca sade, anlaşılır ve dokümante şekilde tutmaya çalışıyoruz. Yine de bazen alan adı tarafındaki paneller, harici DNS servisleri veya manuel müdahaleler işleri karıştırabiliyor. Böyle durumlarda, yukarıdaki kontrol listesini izleyerek sorunun hangi halkada koptuğunu tespit edebilir, ardından doğru noktaya odaklanabilirsiniz.

Eğer hala nereden başlayacağınıza emin değilseniz veya büyük bir taşıma, IP değişikliği ya da DNS mimarisi planlıyorsanız, DCHost destek ekibiyle iletişime geçmekten çekinmeyin. Alan adı, DNS ve hosting tarafındaki birikimimizi projenize uyarlayarak, hem bugünkü DNS_PROBE_FINISHED_NXDOMAIN benzeri hataları gidermenize hem de gelecekteki kesintileri en aza indirmenize yardımcı olabiliriz.