DNS Kayıtları Rehberi: Önemli Olanlar ve İşleri Bozanlar

"Web sitesi çöktü" diye bildirilen kesintilerin çoğu aslında DNS kaynaklıdır. Sunucu çalışıyordur, site sapasağlamdır ama bir metin kaydı yanlış yeri gösteriyordur — veya önbellekte hala eski adrese yönleniyordur.

DNS aynı zamanda bir web sitesinin en az görünen katmanıdır. Bozulana kadar kimse dönüp bakmaz; bozulduğunda ise işi bozan değişiklik haftalar önce işten ayrılmış biri tarafından yapılmıştır bile.

İşte her bir kayıt türünün ne işe yaradığı ve nerede hata yapıldığı:

A ve AAAA — Sitenin yaşadığı yer

A kaydı bir alan adını IPv4 adresine eşler. AAAA kaydı ise IPv6 adresine eşler.

example.com.      A      203.0.113.10
example.com.      AAAA   2001:db8::1
www.example.com.  A      203.0.113.10

Bunlar yanlış veya eksikse bu sayfadaki diğer hiçbir şeyin önemi kalmaz.

Yapılan hata: example.com için bir A kaydı tanımlayıp www.example.com için tanımlamamak (veya tam tersi). Ziyaretçilerinizin yarısı başına www yazarak girer ve hiçbir şey göremez. Siz hep aynı şekilde yazdığınız için bunu asla fark etmezsiniz.

IPv6 hakkında: Birçok ülkede mobil trafiğin büyük bir kısmı yalnızca IPv6 kullanır ve IPv4 sitelerine operatör seviyesinde çeviri katmanlarıyla ulaşır; bu da her bağlantıya gecikme (latency) ekler. Sunucunuz IPv6 destekliyorsa, AAAA kaydı eklemek tamamen ücretsizdir ve bu ek gecikmeyi ortadan kaldırır.

MX — E-postaların nereye geleceği

example.com.  MX  10 mx1.provider.com.
example.com.  MX  20 mx2.provider.com.

Alan adınız için e-posta kabul eden sunucuları listeler. Daha düşük öncelik numarası kazanır; yüksek numaralar yedektir.

Sık karıştırılan iki konu:

MX sadece gelen e-postaları kontrol eder. Gönderdiğiniz e-postalar spama düşüyorsa sorun MX değildir; sorun SPF, DKIM ve DMARC kayıtlarındadır ve bunlar TXT kayıtlarında yaşar.

Bir MX kaydı her zaman bir sunucu adına (hostname) işaret etmelidir, asla IP adresine değil. MX 10 203.0.113.5 geçersizdir ve bazı posta sunucuları böyle yapılandırılmış alan adlarından gelen mailleri doğrudan reddeder.

NS — Yetkili sunucu kim?

example.com.  NS  ns1.provider.com.
example.com.  NS  ns2.provider.com.

Alan adınız için cevap veren ad sunucularıdır (nameservers). Bunlar alan adı kayıt firmanızda (registrar) tanımlı olanlarla birebir eşleşmelidir — DNS bölgesindeki NS kayıtları ile kayıt firmasındaki yetkilendirme iki farklı şeydir ve birbiriyle çelişebilirler.

Taşıma (migration) hatası: Barındırma hizmetini (hosting) taşırsınız, yeni sağlayıcıda DNS kayıtlarını güncellersiniz; site sizde çalışır ama başkalarında açılmaz. Sebebi neredeyse her zaman alan adı kayıt firmasındaki NS yetkisinin hala eski ad sunucularını göstermesidir; yani internetin yarısı eski yanıtları veren eski sağlayıcıya soruyordur.

Her zaman en az iki ad sunucusu bulundurun. Tek bir sunucu, e-postalarınız dahil tüm alan adınız için tek bir arıza noktası (single point of failure) demektir.

TXT — Çok amaçlı metin kayıtları

Artık giderek uzayan bir liste için kullanılan genel metin kayıtları:

• SPF — Hangi sunucuların sizin adınıza e-posta gönderebileceği: v=spf1 include:_spf.google.com ~all
• DMARC — E-posta güvenlik politikası: _dmarc.example.com adresinde
• DKIM — Genel anahtar (public key): selector._domainkey.example.com adresinde
• Alan adı doğrulama — Google Search Console, Microsoft 365, Atlassian, Zoom ve onlarcası

İnsanları yanıltan iki temel kural:

Alan adı başına yalnızca bir SPF kaydı. v=spf1 ile başlayan iki ayrı TXT kaydı kalıcı bir hatadır ve ikisinin de çalışmamasına neden olur. Bu genellikle sisteme ikinci bir e-posta aracı eklendiğinde mevcut kaydı düzenlemek yerine yeni bir kayıt eklendiğinde olur. Bunları tek bir kayıtta birleştirin.

TXT kayıtları birikir. Çoğu eski alan adı, yıllar önce bıraktıkları servislerin doğrulama kayıtlarını taşır. Zararsızdırlar ama kalabalık yaratırlar ve ikinci SPF kaydı genellikle bu kalabalığın arasında gizlenir. Yılda bir kez temizleyin.

CAA — Sizin adınıza kim sertifika üretebilir?

Bu listedeki en az kullanılan ama en kritik kayıt türü.

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issuewild ";"
example.com.  CAA  0 iodef "mailto:security@example.com"

CAA, alan adınız için hangi sertifika otoritelerinin (CA) SSL sertifikası üretebileceğini belirtir. Bu olmadan, dünyadaki herhangi bir açık CA adınıza sertifika üretebilir. Bu kayıtla ise sadece adını yazdıklarınız üretebilir.

Sertifika otoriteleri sertifika üretmeden önce bu kaydı kontrol etmek zorundadır. Hatalı/sahte sertifika üretimine karşı gerçek bir güvenlik önlemidir, kurulumu iki dakika sürer ama neredeyse kimse ayarlamaz.

Doğru yapmak için: Kullandığınız her CA'yı dahil edin (CDN veya barındırma sağlayıcınızın sizin adınıza ürettikleri dahil) ve wildcard sertifika kullanmıyorsanız issuewild ";" ile wildcard üretimini yasaklayın.

SOA — Alan bölgesi meta verisi

Her DNS bölgesinde bir tane bulunur, çoğunlukla otomatiktir. Bilinmesi gereken en önemli alan seri numarasıdır (serial number): Bölge her düzenlendiğinde artar. Bir taşıma sırasında bu seri numarası artmadıysa, yaptığınız düzenleme yayına girmemiş demektir. Sadece bu kontrol bile "ama ben zaten değiştirmiştim" karmaşasını anında çözer.

TTL: Taşıma işlemlerini kabusa çeviren detay

Her kayıt bir TTL (Time To Live - Yaşam Süresi) taşır; yani DNS çözümleyicilerin o kaydı kaç saniye boyunca önbellekte tutabileceğini belirtir.

24 saatlik TTL'e sahip bir kaydın dünya genelinde güncellenmesi tam bir gün sürer. Değişikliği yaptıktan sonra bunu hızlandırmanın hiçbir yolu yoktur. Bir çözümleyici eski yanıtı önbelleğe aldıysa, TTL süresi bitene kadar o yanıtı vermeye devam eder.

Bu sorunu tamamen ortadan kaldıran teknik:

1. Taşımadan 48 saat önce, değiştireceğiniz kayıtların TTL değerini 300 saniyeye (5 dakika) düşürün.
2. Eski TTL süresinin tamamen dolmasını bekleyin; böylece tüm çözümleyiciler kısa süreli TTL'i öğrenmiş olur.
3. Değişikliği yapın. Artık tüm dünyada 5 dakika içinde yayılacaktır.
4. Bir gün sonra, TTL değerini tekrar 3600 veya daha yüksek bir değere çekin.

Dördüncü adım önemlidir — kalıcı olarak düşük TTL, her ziyaretçi için daha fazla DNS sorgusu ve marjinal olarak daha yavaş ilk bağlantı demektir.

Bu, DNS yönetimindeki en faydalı uygulamadır ve mutlaka önceden yapılmalıdır. Geriye dönük uygulanamaz.

Farklı araçlar neden farklı yanıtlar gösterir?

Çünkü farklı DNS çözümleyicilere sorarlar ve bu çözümleyiciler en son ne zaman sorgulama yaptıklarına bağlı olarak farklı önbellek kopyalarına sahiptir.

Bir değişiklikten hemen sonra bu gayet normaldir ve TTL süresi doldukça düzelir. TTL süresi geçtikten sonra da devam ediyorsa, sistem gerçekten tutarsız yanıtlar veriyordur — genellikle eksik bir taşıma sonrası iki farklı ad sunucusu seti hala aktiftir.

Alan adınızın tüm kayıtlarını ve TTL değerlerini Ücretsiz DNS Sorgulama Aracımız ile inceleyebilirsiniz. Sorguyu doğrudan tarayıcınızdan yaptığı için size en yakın çözümleyicinin o anda ne gördüğünü de gösterir.

DNS taşıma kontrol listesi

1. Bir şeye dokunmadan önce mevcut DNS bölgesini (zone file) eksiksiz dışa aktarın.
2. 48 saat önceden TTL değerlerini 300 saniyeye düşürün.
3. Yetkiyi değiştirmeden önce yeni sağlayıcıda tüm bölgeyi eksiksiz oluşturun.
4. Alan adı kayıt firmasından ad sunucularını (NS) değiştirin.
5. A, AAAA, MX, TXT ve CAA kayıtlarının yeni sağlayıcıda çalıştığını doğrulayın.
6. Her iki yöne de test e-postası gönderin.
7. Eski DNS bölgesini en az bir hafta açık tutun — uzun önbelleğe sahip çözümleyiciler hala eski sunucuya soruyor olabilir.
8. Trafik oturduktan sonra TTL değerlerini tekrar yükseltin.

Yedinci madde insanların hep atladığı maddedir; taşımanın birinci gün harika görünüp üçüncü gün e-postaların geri dönmesinin (bounce) asıl sebebi budur.