Bir uygulamaya IP adresiyle erişilirken adıyla erişilemiyorsa DNS ilk inceleme alanlarından biridir. Ancak her bağlantı sorunu DNS kaynaklı değildir. Yanlış kayıt, istemci önbelleği, VPN profili veya uygulamanın kendi çözümleme davranışı benzer belirtiler üretebilir. Etkili sorun giderme, önce hangi katmanın yanlış cevap verdiğini belirler.
Bu rehber Windows istemci ve sunucu ortamında sistematik bir teşhis yaklaşımı sunar. Amaç, her arızada DNS servisini yeniden başlatmak veya bütün önbellekleri temizlemek yerine kanıt toplamaktır. Örnek ad app01.ad.example.com, örnek kurumsal DNS 10.30.10.10'dur. Kendi alan adınız ve yetkili sistemlerinizle çalışın; test sonucunu ağ bağlamıyla birlikte değerlendirin.
1. Belirtiyi doğru tanımlayın
Hangi isim, hangi kullanıcı ve hangi ağda çalışmıyor? Sorun bütün cihazlarda mı, yalnızca bir VPN bağlantısında mı görülüyor? Kısa adla tam alan adı aynı sonucu mu veriyor? Bu sorular, daha komut çalıştırmadan inceleme alanını daraltır. Kullanıcının “internet yok” ifadesini doğrudan tek bir teknik arızaya çevirmeyin.
Saat ve örnek hedef kaydedin. Aynı uygulamanın tarayıcıda başarısız olmasıyla komut satırında doğru çözülmesi farklı bağlamlara işaret edebilir. Güvenli DNS, proxy veya uygulama önbelleği gibi ayrı yollar bulunabilir. Çalışan ve çalışmayan cihazın ağ ayarlarını karşılaştırmak rastgele değişiklikten daha anlamlıdır.
2. İstemcinin gerçekten hangi DNS'i kullandığını görün
Microsoft DNS istemci sorun giderme dokümanı, ilk incelemede IP ve DNS yapılandırmasının kontrol edilmesini önerir. Aşağıdaki çıktıda doğru adres, maske, ağ geçidi, DNS listesi ve bağlantı soneki aranır.
ipconfig /allBir cihazda hem kablolu hem kablosuz bağlantı, sanal adaptör ve VPN bulunabilir. Tek bir arayüzün ayarına bakıp bütün cihazın çözümleme yolunu açıklamaya çalışmayın. Sorunun bağlantı açıldığında veya kapandığında değişip değişmediğini kontrollü test edin. Bu test sırasında çalışan oturumu veya erişimi etkileyebilecek değişiklikleri planlayın.
3. Belirli sunucuyu sorgulayarak yolu ayırın
Aşağıdaki ilk komut normal istemci yolunu, ikinci komut ise açıkça seçilmiş sunucunun cevabını gözlemlemeyi sağlar. Aynı isim için farklı sonuçlar görmek, incelemeyi çözümleyici veya istemci tarafına yönlendirebilir.
Resolve-DnsName app01.ad.example.com
Resolve-DnsName app01.ad.example.com -Server 10.30.10.10
Resolve-DnsName app01.ad.example.com -Type AAAA -Server 10.30.10.10IPv4 ve IPv6 kayıtlarını ayrı değerlendirin. A kaydı doğruyken eski AAAA kaydının başka adrese gitmesi bazı istemcilerde farklı davranış yaratabilir. Aynı şekilde bir CNAME zincirindeki son hedefin yanlış olması, ilk kaydın görünürde doğru olduğu durumlarda gözden kaçabilir. Cevabın tamamını inceleyin.
4. Hata türünü aynı sepete koymayın
NXDOMAIN, sorgulanan adın bulunmadığına dair bir cevaptır. SERVFAIL, çözümleme sürecinin başarısız olduğunu gösterir. Zaman aşımı ise beklenen cevabın alınamamasıdır; ağ erişimi veya servis davranışı dahil farklı nedenleri olabilir. Bu belirtiler aynı düzeltmeyi gerektirmez.
Yanlış zone, eksik delegasyon, koşullu yönlendirme ve erişim kuralları ayrı adaylardır. AD ortamında servis kayıtlarının bulunmaması da uygulama erişimini etkileyebilir. Tanıyı yalnızca son hata metnine dayandırmayın; hangi sunucunun hangi aşamada cevap verdiğini bulun. Değişiklik öncesi ve sonrası sorguları aynı hedef ve yöntemle karşılaştırın.
5. Önbelleği kanıtı kaybetmeden inceleyin
Kayıt değişikliği yapıldıktan sonra eski cevabın bir süre görülmesi TTL ve önbellek davranışıyla ilişkili olabilir. Önce yetkili cevabı doğrulayın. Sonra kurumsal çözümleyici ve istemci arasındaki farkı değerlendirin. Hemen önbellek temizlemek, eski cevabın nereden geldiğini anlamanızı güçleştirebilir.
İstemci önbelleğini görüntülemek için aşağıdaki komut kullanılabilir. Çıktı iç alan adlarını içerebilir; paylaşım kapsamını buna göre belirleyin. Temizlik gerekliyse seçilmiş istemcide, neden ve beklenen sonuç belli olacak şekilde uygulayın.
ipconfig /displaydns6. DNS dışındaki olasılıkları doğrulayın
İsim doğru IP'ye dönse bile uygulama portu kapalı, servis durmuş veya TLS sertifikası yanlış olabilir. DNS cevabıyla hizmet sağlığını aynı test saymayın. Ağdan IP'ye erişim, ilgili uygulama portuna bağlantı ve uygulama seviyesinde cevap ayrı ayrı değerlendirilir. ICMP kapalı bir ortamda yalnızca ping başarısızlığına dayanarak DNS arızası demeyin.
Varsayımsal bir şube kullanıcısı VPN açıkken uygulamaya ulaşamıyorsa ilk hedef yalnızca DNS kaydını değiştirmek olmamalıdır. VPN'in dağıttığı DNS, rota ve erişim politikası birlikte incelenir. Merkezde çalışan bir cihazın cevabı karşılaştırma için kullanılır. Bu yöntem sorunun bütün şirketi etkilemesini önleyen daha küçük bir düzeltme alanı sağlar.
Sorun giderme kaydında neler bulunsun?
- Etkilenen ad, kullanıcı ağı ve zaman aralığı.
- İstemci DNS listesi ve bağlantı soneki.
- Belirli çözümleyicilerden alınan cevaplar.
- Hata türü, TTL ve CNAME gibi ilgili kayıt bilgileri.
- Yapılan değişiklik, geri dönüş yolu ve son doğrulama.
CieloSync ile altyapı işletimini bu tür ölçülebilir incelemeler üzerinden geliştirebilirsiniz. Tekrarlayan DNS sorununuzu paylaşın; belirtiden kök nedene uzanan bir çalışma planlayalım.