DNS Hataları ve Çözümleri: Yaygın Sorunlar

Site açılmıyor, e-postalar geri dönüyor, kullanıcılar "server not found" görüyor. DNS hataları üretim ortamında sessizce birikirken teslimat durur. NXDOMAIN domain bulunamadığını söyler, SERVFAIL sunucu yanıt veremediğini, timeout ise sorgunun zaman aşımına uğradığını. Her hata farklı katmanda bozulma işaret eder.

Sorun bazen registrar panelinde yanlış nameserver kaydından, bazen zone dosyasındaki syntax hatasından, bazen de ISP önbelleğinin eski kaydı tutmasından kaynaklanır. Hangi katmanda bozulma olduğunu bilmeden rastgele deneme yapmak zaman kaybettirir. Sistematik teşhis 5 dakikada kök nedeni bulur.

NXDOMAIN: Domain Bulunamadı

NXDOMAIN (Non-Existent Domain) tarayıcıda "DNS_PROBE_FINISHED_NXDOMAIN" veya "Server not found" olarak görünür. DNS resolver domain adını sorgular ama yetkili nameserver "böyle bir domain yok" yanıtı döner.

Kök neden genellikle şu dört durumdan biridir:

Domain süresi dolmuş veya hiç kayıtlı değil. WHOIS sorgusu "No match" veya "Domain not found" döner. Registrar panelinde domain durumu "expired" veya "pending delete" görünüyorsa yenileme gerekir.

Nameserver kayıtları yanlış girilmiş. Örneğin ns1.example.com yerine ns1.exampel.com yazılmış. Registrar panelinde nameserver alanını kontrol edin; tek karakter hatası bile NXDOMAIN üretir.

DNS zone dosyasında A kaydı yok. Domain kayıtlı, nameserver doğru ama zone dosyasında hiçbir A veya AAAA kaydı tanımlanmamış. dig @ns1.example.com example.com komutu "NOERROR" ama "ANSWER: 0" dönerse bu durumdur.

Propagation henüz tamamlanmamış. Yeni domain kaydından veya nameserver değişikliğinden sonra 24-48 saat geçmemişse bazı resolver'lar eski durumu görür, bazıları yeni durumu. Bu geçici tutarsızlık normaldir.

İlk adım: WHOIS ile domain durumunu doğrula. Aktifse nameserver kayıtlarını kontrol et. Nameserver doğruysa dig ile A kaydını sorgula. Kayıt varsa önbellek temizle; yoksa DNS panelinde ekle.

SERVFAIL: Sunucu Yanıt Veremiyor

SERVFAIL (Server Failure) DNS sunucusunun sorguyu işleyemediği anlamına gelir. Sunucu çökmüş, zone dosyası bozuk veya DNSSEC doğrulaması başarısız olabilir. NXDOMAIN'den farkı şu: NXDOMAIN "domain yok" der, SERVFAIL "bilmiyorum ama bir şey bozuk" der.

Nameserver erişilebilir değilse SERVFAIL döner. ping ns1.example.com veya dig @ns1.example.com example.com komutu timeout veriyorsa sunucu çalışmıyor demektir. Firewall port 53'ü engelliyor olabilir; UDP ve TCP trafiği açık olmalı.

DNSSEC aktifse imza doğrulaması başarısız olunca SERVFAIL üretir. dig +dnssec example.com komutu "SERVFAIL" dönüyorsa RRSIG kayıtları geçersiz veya DS kaydı registrar'da yanlış girilmiş olabilir. DNSSEC anahtarları süresi dolmuşsa yenilenmeli; yoksa domain erişilemez hale gelir.

Zone dosyası syntax hatası içeriyorsa nameserver zone'u yükleyemez ve SERVFAIL döner. Örneğin MX kaydı CNAME'e işaret ediyorsa veya TTL değeri negatifse zone geçersiz olur. named-checkzone komutuyla zone dosyasını doğrulayın.

SERVFAIL çözümü genellikle DNS sağlayıcı desteği gerektirir. Sunucu tarafı sorunsa müdahale edemezsiniz. DNSSEC kullanıyorsanız geçici olarak devre dışı bırakabilirsiniz ama bu saldırıya açık hale getirir; kalıcı çözüm imza ve anahtar kayıtlarını düzeltmektir.

Timeout: Sorgu Zaman Aşımına Uğruyor

Timeout DNS sorgusunun belirli sürede yanıt alamaması durumudur. Tarayıcı "DNS lookup timed out" veya "Connection timed out" gösterir. Sorgu gönderilir ama yanıt dönmez; resolver bekler, süre dolar, hata verir.

DNS sunucusu yavaş yanıt veriyorsa timeout üretir. Sunucu aşırı yüklenmiş veya ağ gecikmesi yüksek olabilir. dig example.com komutu 2-3 saniyeden uzun sürüyorsa sunucu yavaştır. Normal DNS sorgusu 50-200ms içinde dönmeli.

Firewall veya güvenlik duvarı port 53 trafiğini engelliyor olabilir. Özellikle kurumsal ağlarda DNS trafiği kısıtlanır. dig @8.8.8.8 example.com çalışıyor ama dig @yerel-dns example.com timeout veriyorsa yerel DNS erişimi engellenmiştir.

ISP DNS sunucusu çökebilir veya bakım modunda olabilir. Bu durumda alternatif DNS kullanın: Google DNS (8.8.8.8, 8.8.4.4) veya Cloudflare DNS (1.1.1.1, 1.0.0.1). İşletim sisteminde DNS ayarlarını değiştirin ve tekrar deneyin.

CNAME zinciri çok uzunsa timeout riski artar. Örneğin example.com → cdn.example.com → edge.cdn.com → origin.edge.cdn.com gibi 4-5 adımlı CNAME zinciri her adımda yeni sorgu gerektirir. RFC 1034 CNAME zincirini sınırlamaz ama çoğu resolver 10 adımdan sonra timeout verir.

Yanlış IP Dönüyor: Önbellek ve Propagation

DNS sorgusu başarılı ama yanlış IP adresi dönüyor. Site açılmıyor veya başka bir sunucunun içeriği görünüyor. Bu genellikle önbellek veya propagation tutarsızlığıdır.

Yerel DNS önbelleği eski kaydı tutuyor olabilir. İşletim sistemi, tarayıcı ve yerel resolver ayrı önbellek tutar. Windows'ta ipconfig /flushdns, macOS'ta sudo dscacheutil -flushcache, Linux'ta sudo systemd-resolve --flush-caches komutuyla önbellek temizlenir. Tarayıcı önbelleği için chrome://net-internals/#dns sayfasından "Clear host cache" yapın.

Propagation tamamlanmamışsa bazı DNS sunucuları eski IP'yi görür. dig @8.8.8.8 example.com ile dig @1.1.1.1 example.com sonuçları farklıysa propagation devam ediyordur. TTL değeri yüksekse (örneğin 86400 saniye = 24 saat) eski kayıt uzun süre önbellekte kalır.

DNS kaydı yanlış girilmişse doğru IP dönmez. DNS panelinde A kaydını kontrol edin; 192.168.1.10 gibi özel IP adresi girmişseniz dışarıdan erişilemez. Genel IP adresi olmalı.

DNS hijacking veya cache poisoning saldırısı olabilir. Kötü niyetli DNS yönlendirmesi domain'i saldırganın sunucusuna yönlendirir. dig example.com sonucu beklenmedik IP dönüyorsa ve DNS panelinde kayıt doğruysa hijacking şüphesi vardır. Registrar ve DNS sağlayıcısıyla iletişime geçin, şifreleri değiştirin, iki faktörlü kimlik doğrulama aktif edin.

E-posta Teslim Hataları: MX ve SPF Sorunları

E-postalar geri dönüyor, spam klasörüne düşüyor veya hiç ulaşmıyor. Sorun genellikle MX kaydı, SPF veya DKIM yapılandırmasındadır.

MX kaydı eksikse e-posta sunucusu bulunamaz. dig MX example.com komutu "ANSWER: 0" dönüyorsa MX kaydı yok demektir. E-posta sağlayıcınızın verdiği MX kayıtlarını DNS paneline ekleyin. Örneğin Google Workspace için aspmx.l.google.com gibi kayıtlar gerekir.

MX kaydı CNAME'e işaret ediyorsa RFC 2181 ihlali olur ve e-posta teslim edilmez. MX kaydı yalnızca A kaydı olan hostname gösterebilir. Yanlış: MX 10 mail.example.com (mail.example.com CNAME ise). Doğru: MX 10 mail.example.com (mail.example.com A kaydı ise).

SPF kaydı eksik veya yanlışsa gönderen doğrulaması başarısız olur. dig TXT example.com komutuyla SPF kaydını kontrol edin. "v=spf1 include:_spf.google.com ~all" gibi kayıt olmalı. SPF kaydı yoksa veya yanlış IP adresi içeriyorsa e-postalar spam olarak işaretlenir.

DKIM imzası geçersizse e-posta güvenilmez sayılır. DKIM kaydı DNS paneline TXT kaydı olarak eklenir; genellikle default._domainkey.example.com gibi bir subdomain altında. DKIM kaydı kopyalanırken boşluk veya satır sonu eklenirse imza bozulur. Kaydı tek satırda, boşluksuz girin.

MXToolbox.com gibi araçlarla e-posta yapılandırmasını test edin. MX, SPF, DKIM ve DMARC kayıtlarını aynı anda kontrol eder; eksik veya hatalı kayıtları gösterir.

Alt Domain Erişim Sorunları

Ana domain açılıyor ama alt domain açılmıyor. example.com çalışıyor, blog.example.com "server not found" veriyor. Alt domain için ayrı DNS kaydı gerekir.

Alt domain A veya CNAME kaydı yoksa erişilemez. DNS panelinde blog.example.com için A kaydı veya CNAME kaydı tanımlanmalı. Ana domain kaydı alt domainleri kapsamaz; her alt domain ayrı kayıt gerektirir.

Wildcard kayıt (*) tüm tanımlanmamış alt domainleri kapsar ama özel kayıtlar önceliklidir. Örneğin *.example.com A 192.0.2.1 kaydı varsa test.example.com, demo.example.com gibi tüm alt domainler bu IP'ye gider. Ama blog.example.com için ayrı A kaydı varsa wildcard geçersiz olur.

Alt domain SSL sertifikası eksikse HTTPS erişiminde "certificate error" verir. Wildcard sertifika (*.example.com) tüm alt domainleri kapsar; tek alt domain için ayrı sertifika da alınabilir. Let's Encrypt ile ücretsiz wildcard sertifika alabilirsiniz ama DNS doğrulaması gerekir.

DNSSEC Doğrulama Hataları

DNSSEC aktifse imza doğrulaması başarısız olunca domain erişilemez hale gelir. SERVFAIL döner ve site tamamen kapanır. DNSSEC hataları kritiktir; yanlış yapılandırma üretim ortamını durdurur.

DNSSEC anahtarları (KSK ve ZSK) süresi dolmuşsa imza geçersiz olur. Anahtarlar genellikle 3-12 ay geçerlidir; süresi dolmadan yenilenmelidir. dig +dnssec example.com komutu "ad" (authenticated data) bayrağı göstermiyorsa imza doğrulanamıyor demektir.

DS kaydı registrar'da yanlış veya eksikse DNSSEC zinciri kopar. DS kaydı nameserver'daki DNSKEY kaydıyla eşleşmelidir. Nameserver değişikliğinden sonra DS kaydı güncellenmezse DNSSEC bozulur.

RRSIG kayıtları geçersizse DNS kaydı imzalanamaz. DNS kaydı değiştiğinde (örneğin A kaydı güncellendiğinde) RRSIG de yeniden üretilmelidir. Otomatik imzalama yoksa manuel güncelleme gerekir.

DNSSEC sorunları karmaşıktır; DNS sağlayıcınızın desteğine başvurun. Acil durumda DNSSEC'i geçici olarak devre dışı bırakabilirsiniz: registrar panelinde DS kaydını silin. Ama bu domain'i DNS spoofing ve cache poisoning saldırılarına açık hale getirir. Kalıcı çözüm anahtarları ve imzaları düzeltmektir.

Propagation Tutarsızlığı

Bazı kullanıcılar siteyi görüyor, bazıları göremiyor. Aynı anda farklı sonuçlar dönüyor. Bu propagation sürecinin doğal sonucudur ama 48 saatten uzun sürerse sorun vardır.

TTL değeri yüksekse eski kayıt uzun süre önbellekte kalır. TTL 86400 saniye (24 saat) ise DNS değişikliği 24 saat boyunca bazı resolver'larda görünmez. Değişiklik öncesi TTL'yi düşürün (örneğin 300 saniye = 5 dakika); değişiklik yaptıktan sonra tekrar yükseltin.

ISP önbellek politikası agresifse TTL'yi yok sayar. Bazı ISP'ler TTL 300 saniye olsa bile kaydı 1 saat önbellekte tutar. Bu durumda kullanıcıya alternatif DNS (8.8.8.8 veya 1.1.1.1) kullanmasını önerin.

Nameserver değişikliği propagation 24-48 saat sürer. Nameserver kaydı registrar seviyesinde değiştirilir; bu değişiklik TLD nameserver'larına yayılmalıdır. dig NS example.com komutuyla hangi nameserver'ların döndüğünü kontrol edin. Eski nameserver dönüyorsa propagation devam ediyordur.

Propagation sırasında tutarsızlık normaldir. Sabırla bekleyin; genellikle 24-48 saat içinde tamamlanır. Acil durumda kullanıcılara hosts dosyası düzenlemesini önerebilirsiniz ama bu geçici çözümdür.

DNS Hijacking: Yetkisiz Değişiklik Tespiti

DNS kayıtları beklenmedik şekilde değişmişse hijacking olabilir. Domain başka bir IP'ye yönlendirilir, e-postalar başka sunucuya gider, saldırganlar kontrolü ele geçirir.

Hijacking belirtileri: DNS paneline giriş yapamıyorsunuz, kayıtlar tanımadığınız IP adreslerine işaret ediyor, WHOIS bilgileri değişmiş, registrar e-postası başkasına yönlendirilmiş. dig example.com sonucu beklenmedik IP dönüyorsa ve siz değişiklik yapmadıysanız hijacking şüphesi vardır.

Hemen registrar ve DNS sağlayıcısıyla iletişime geçin. Hesap şifrelerini değiştirin, iki faktörlü kimlik doğrulama aktif edin, domain kilidini (registrar lock) aktif edin. Domain kilidi aktifse transfer ve nameserver değişikliği engellenmiş olur.

Hijacking sonrası DNS kayıtlarını doğru değerlere geri yükleyin. Eski yedekleriniz varsa kullanın; yoksa doğru IP adreslerini ve MX kayıtlarını yeniden girin. Propagation 24-48 saat sürer; bu sürede bazı kullanıcılar hala saldırganın sunucusunu görebilir.

Gelecekte korunmak için güçlü şifre kullanın, iki faktörlü kimlik doğrulama aktif edin, registrar lock aktif edin, WHOIS gizliliği kullanın, düzenli olarak DNS kayıtlarını kontrol edin. Registrar paneline giriş bildirimlerini aktif edin; yetkisiz giriş olursa hemen haberdar olursunuz.