DNS: Altyapı Sorunlarının Çoğunlukla Başladığı Yer

Teknik ekiplerraş içinde ünlü bir şaka vardır: "Bir denedin mi kapattıktan sonra açmayı?" Ama altyapı alanında yeterince uzun çalışırsan, bundan çok daha güvenilir bir kuralı keşfedersin: "DNS'i kontrol ettin mi?"

Bu, mizah değil. Uykusuz gecelerin birikmiş bilgeliğidir.

DNS'in Garip Paradoksu

DNS, modern altyapının belki de en kritik ama en az değerlendirilen katmanıdır. Domain sağlayıcın bunu yönetir. Hosting firman nameserver'ları kontrol eder. CDN'inin kendi kayıtları vardır. E-postalar MX kayıtları üzerinden akar. SSL sertifika doğrulaması DNS'e bağımlıdır. Oysa çoğumuz DNS'i tesisata benzer şekilde görüyoruz—çalıştığı sürece fark etmez, koptuğu zaman felaket olur.

İşte paradoks bu: DNS aynı anda en basit ve en zor sistemdir.

Basit tarafı düşüncesinde açıktır—domain adlarını IP adreslerine eşlemek. Bir kaç kayıt. Biraz ayarlama. Ne kadar zor olabilir ki?

Zor tarafı ise DNS'in temel bir katmanda çalışması ve diğer her şeyin ona bağlı olmasıdır. DNS sessizce başarısız olduğunda, ya da daha kötüsü kısmen başarısız olduğunda, sorun belirtileri yığının başka yerlerinde görünür. Uygulama sunucun sorunsuz. Veritabanı bağlantın iyi. SSL sertifikan geçerli. Ama kullanıcılar seni bulamıyor çünkü bir CNAME kaydı hatalı ayarlanmış.

Muhtemelen Şu Anda Yaşadığın Sessiz Arızalar

DNS dünyasının başlıca belalı problemlerine bakalım:

Yayılma Gecikmesi: DNS kayıtlarını güncelledin ama internet henüz kararlaştıramadı. Bazı kullanıcılar eski sunucunu görüyor. Diğerleri yeniyi görüyor. TTL'nin yüksek olması nedeniyle eski kayıt hala cached'dir. Sadece kullanıcıların yüzde 40'ını etkileyen bir sorunu çoğaltmaya çalışırken çıldırıyorsun.

Nameserver Karmaşası: Domain'ini yeni bir registrara taşıdın ama nameserver'lar eski sağlayıcıyı göstermeye devam ediyor. Yeni DNS değişikliklerin etkinleşmiyor. Ya da daha korkuncu—değişikliklerin etkinleşmediğinden haberin bile yok.

MX Kayıt Hataları: E-postalar gizemli şekilde kayboluyor ama SMTP logların kusursuz görünüyor. E-posta sunucun mesajları alıyor ama hiç kimse göndermiyor çünkü MX kayıtları çevrimdışı bir sunucuya ya da yanlış önceliğe işaret ediyor.

Joker Kayıt Çatışmaları: *.example.com için joker kaydın var ama özel subdomain'ler de oluşturdun. DNS kendisiyle çatışıyor. Bazı istekler çözümleniyor, diğerleri hayır. Davranış rastgele görünüyor ama aslında değil.

DNSSEC Doğrulama Başarısızlıkları: Güvenlik için DNSSEC'i etkinleştirdin ama DS kayıtların hatalı. Bazı resolver'lar başarılı doğrulama yapıyor. Diğerleri tamamen başarısız oluyor. Yine—rastgele görünen kısmi arızalar.

TTL Cehennem: Emniyet için TTL'yi 3600 saniyeye ayarladın, acil bir geçiş sırasında eski kayıtlara bir saat boyunca kilitlenebileceğini fark etmedin. Ya da "esneklik" için 60 saniyeye ayarladın ve şimdi DNS sorgularıyla bombardıman altındasın.

DNS Neden Saklambaçta Hep Kazanır

DNS sorunlarının bu kadar sinsi olmasının sebebi, kendilerini başka şey gibi göstermeleridir:

• Ağ sorunu mu? Hayır, DNS'tir.
• Uygulama timeout'u mu? Hayır, DNS'tir.
• CDN cache problemi mi? Muhtemelen DNS'tir.
• SSL sertifika doğrulaması başarısız mı? Önce DNS'i kontrol et.
• E-posta iletilmiyor mu? Kesinlikle DNS'tir.

İzleme sisteminiz çok yardımcı olamıyor çünkü DNS arızaları genellikle izleme sisteminin hizmete ulaşabilmesinden önce meydana geliyor. Alan adı çözümlenemeyen bir sunucuya ping nasıl atarsın?

Kariyeri Kurtaran Kontrol Listesi

Birşey bozulduğunda, panik yapmadan önce bunu kontrol et:

1. Kaydın var mı doğrula:

dig yourdomain.com
nslookup yourdomain.com

2. Tüm nameserver'larının aynı şeyi söylediğini kontrol et:

dig yourdomain.com @ns1.yourprovider.com
dig yourdomain.com @ns2.yourprovider.com

Farklı cevaplar alırsan, sorunu bulmuşsundur.

3. Yayılmayı doğrula:

dig yourdomain.com +trace

Bu tüm çözümleme zincirini gösterir. Doğru nameserver'ları mı vuruyorsun? TTL beklediğin yerde mi?

4. Belirli kayıt türlerini kontrol et:

dig yourdomain.com MX
dig yourdomain.com CNAME
dig yourdomain.com A
dig yourdomain.com AAAA

5. İlgili tüm kayıtlara bak: Sertifikan doğrulanmıyorsa TXT kayıtlarını kontrol et (ACME challenge'ları). E-posta başarısızsa SPF, DKIM ve DMARC kayıtlarını doğrula. Bunlar sadece DNS değil—güvenlik DNS'idir.

6. Yerel DNS cache'ini temizle:

# macOS
sudo dscacheutil -flushcache

# Linux (systemd)
sudo systemctl restart systemd-resolved

# Windows
ipconfig /flushdns

Neden Şimdi Akıllanmalısın

DNS heyecan verici değildir. GitHub README'sinde yer almaz. DNS optimizasyonunu kutlayan bir Medium yazısı yazmayacaksın (tabii ki yazabilirsin). Ama her şeyin üzerine inşa edildiği temeldir.

DNS'i derinlemesine anlayan mühendisler—30 dakikada değil 30 saniyede DNS sorununu teşhis edebilen tipler—bunlar deha gibi görünürler. Değillerdir. Sadece DNS'i önce kontrol etmeyi öğrenmişlerdir.

Bir sonraki sefer birşey bozulduğunda kendine bir iyilik yap: DNS'i ikinci sırada kontrol et. Sunucunun gerçekten çalışıp çalışmadığını kontrol ettikten sonra tabii ki, ama kesinlikle kodları yeniden yazmaya başlamadan önce.

Çünkü neredeyse her zaman DNS'tir.

DNS sorunuyla yanmış mısın? Sorunun DNS olduğunu fark etmeden kaç dakika harcadın? Savaş hikayelerini paylaş—acı sevdiğini biliyorum, ve senin hikayend başkasını saatlerce üzülmekten kurtarabilir.