DNS kayıtları: A, CNAME, MX, TXT ve TTL yönetimi

DNS, alan adını IP adresine çeviren dağıtık defterdir. Web tarafında karşılaşacağınız kayıt türü sayısı azdır; ama her birinin kendi kuralları vardır ve karıştırıldıklarında site ya da e-posta sessizce çalışmayı bırakır.

Zincirin çalışma biçimi

Alan adınızın kayıtları yetkili ad sunucularında tutulur. Ad sunucularını alan adı kayıt kuruluşundaki (registrar) panelden belirlersiniz. Bu yüzden ilk soru her zaman şudur: alan adının kayıtları nerede yönetiliyor? Kaydı yanlış yerde düzenlemek, "değiştirdim ama olmadı" şikâyetlerinin en yaygın sebebidir.

Temel kayıt türleri

• A — alan adını IPv4 adresine bağlar. Sitenizi bir sunucuya yönlendiren kayıttır.
• AAAA — aynı işi IPv6 için yapar.
• CNAME — bir adı başka bir ada yönlendirir. Örneğin www adını kök alan adına bağlamak için kullanılır.
• MX — gelen postanın hangi sunucuya teslim edileceğini söyler. Öncelik değeri düşük olan önce denenir.
• TXT — serbest metin. SPF, DKIM, DMARC ve alan adı sahiplik doğrulamaları burada durur.
• NS — alan adının yetkili ad sunucuları.
• SRV — belirli servisler için sunucu ve port bilgisi; otomatik yapılandırma kullanan e-posta ve sohbet servislerinde geçer.
• CAA — alan adınıza hangi sertifika otoritesinin sertifika verebileceğini sınırlar. 0 issue "letsencrypt.org" satırı, başka bir otoritenin adınıza sertifika üretmesini engeller.
• SOA — bölgenin yönetim bilgileri. Doğrudan elle düzenlemezsiniz, ama içindeki minimum değeri olumsuz cevapların (kayıt yok) ne kadar önbelleklendiğini belirler. Yeni eklediğiniz bir kaydın gecikmeli görünmesinin sebebi çoğu zaman budur.

CNAME'in üç kuralı

1. Kök alan adında (alanadiniz.com) CNAME kullanılamaz. Standart buna izin vermez; kökte A kaydı olmalıdır. Bazı sağlayıcılar bunu "ALIAS" veya "ANAME" adıyla taklit eden özel bir kayıt sunar.
2. Bir ad için CNAME varsa aynı ad için başka kayıt olamaz. www için hem CNAME hem TXT tanımlarsanız çözümleme tutarsızlaşır.
3. CNAME zinciri gecikme ekler. Her halka ek bir sorgu demektir; ikiden fazla halka istemezsiniz.

MX kayıtları ve öncelik

Öncelik değeri düşük olan sunucu önce denenir; ulaşılamazsa sıradaki denenir. Tipik yapı: birincil sunucu 10, yedek sunucu 20. Sık yapılan hata, e-postayı başka bir servise taşırken eski MX kayıtlarını silmeyi unutmaktır. İki farklı servisin kaydı aynı anda duruyorsa iletilerin bir kısmı eski sunucuya gider ve kaybolmuş gibi görünür.

MX kaydı bir IP adresini değil, bir ana makine adını göstermelidir; o adın da A kaydı bulunmalıdır.

TXT kayıtlarının kendine has kuralları

E-posta doğrulaması TXT üzerinden yürür ve buradaki hatalar sessizdir: kimse size hata mesajı göndermez, iletileriniz yalnızca daha sık istenmeyen klasörüne düşer.

• Bir alan adında yalnız bir SPF kaydı olur. Birden fazla sağlayıcı kullanıyorsanız ikinci kayıt eklemez, mevcut kayda include: satırı eklersiniz: v=spf1 include:_spf.saglayici.com include:mail.digeri.com ~all
• DKIM kayıtları uzundur. Tek bir metin dizesi 255 karakteri geçemez; 2048 bitlik anahtarlar bu yüzden tırnak içinde parçalara bölünerek yazılır. Panel bunu kendisi yapmıyorsa kaydı bölerek girmeniz gerekir.
• DMARC kaydı _dmarc alt adında durur, kök alan adında değil. Aynı şekilde DKIM kaydı seçici._domainkey biçimindedir.

Bu üç kaydın nasıl kurulacağı ve raporların nasıl okunacağı e-posta teslimatı yazısında ayrıntılı anlatılıyor.

TTL: değişikliği planlamanın anahtarı

TTL, çözümleyicilerin cevabı ne kadar süre önbellekte tutacağını saniye cinsinden söyler. Yönetimi basit bir kurala bağlayın:

• Normal işleyişte 3600 saniye (1 saat) makul bir değerdir.
• Planlı bir değişiklikten en az 48 saat önce ilgili kayıtların TTL değerini 300 saniyeye indirin.
• Değişiklik tamamlanıp bir gün sorunsuz geçtikten sonra tekrar yükseltin.

Meşhur "DNS yayılması 48 saat sürer" cümlesi bir doğa yasası değildir; TTL'in sonucudur. Düşük TTL ile yapılan bir geçiş dakikalar içinde tamamlanır.

Ad sunucusu değiştirirken sıra

1. Yeni sağlayıcıda bölgeyi oluşturun ve mevcut tüm kayıtları birebir girin. En sık unutulanlar: MX, SPF/DKIM TXT kayıtları ve doğrulama kayıtları.
2. Kayıtları yeni ad sunucularına doğrudan sorarak karşılaştırın.
3. Ancak bundan sonra kayıt kuruluşunun panelinden NS kayıtlarını değiştirin.
4. Eski bölgeyi en az bir hafta silmeyin; geri dönmeniz gerekirse hazır dursun.

Sıra tersine çevrildiğinde, yani önce NS değiştirilip sonra kayıtlar girildiğinde site ve e-posta arada kalan sürede tamamen durur. Aynı mantık sunucu taşımalarında da geçerlidir; kesintisiz taşıma yazısındaki sıra bu ilkeye dayanır.

Değişiklik sonrası doğrulama

Tarayıcıda siteyi açmak yeterli bir test değildir; tarayıcı ve işletim sistemi de önbellek tutar. Doğrudan sorgulayın:

dig +short alanadiniz.com A
dig +short alanadiniz.com MX
dig +short @1.1.1.1 alanadiniz.com A

Üçüncü satır, farklı bir genel çözümleyicinin ne gördüğünü söyler. Yetkili sunucuya doğrudan sormak için dig @ns1.saglayici.com alanadiniz.com kullanın; oradaki cevap doğruysa geri kalan yalnız zaman meselesidir.

Zincirin nerede koptuğunu görmek isterseniz dig +trace alanadiniz.com komutu kök sunuculardan başlayıp yetkili sunucuya kadar her adımı gösterir. Kayıt kuruluşundaki NS bilgisi ile bölgedeki NS kayıtları birbirini tutmuyorsa, uyumsuzluk bu çıktıda görülür.

Bu yaklaşım ne zaman yanlış olur?

DNS bir yönlendirme defteridir; yük dengeleyici ya da yedeklilik aracı değildir. Aynı ada iki A kaydı yazmak (round-robin) trafiği kabaca ikiye böler, ama sunuculardan biri çöktüğünde çözümleyici o IP'yi döndürmeye devam eder. Ziyaretçilerin bir kısmı ölü sunucuya gider. Gerçek yedeklilik istiyorsanız sağlık denetimi yapan bir katmana ihtiyacınız vardır.

Benzer biçimde, TTL'i sürekli 60 saniyede tutmak da çözüm değildir: çözümleyici trafiğini artırır, bazı ağlar bu kadar düşük değerleri zaten dikkate almaz ve kazandığınız esneklik ölçülemez kalır. Düşük TTL bir geçiş aracıdır, kalıcı bir ayar değil.

Sık yapılan beş hata

1. Kayıtları eski ad sunucularında düzenlemek — değişiklik hiçbir yere ulaşmaz.
2. Kök alan adına CNAME tanımlamaya çalışmak.
3. İkinci bir SPF TXT kaydı eklemek; doğrulamayı tamamen bozar.
4. Sunucu IP'si değiştiğinde yalnız www kaydını güncelleyip kökü unutmak.
5. Yüksek TTL ile geçiş yapıp saatlerce süren karışık davranışa şaşırmak.

Alan adı ve DNS yönetimini tek panelden yapmak isterseniz alan adı hizmetimiz tüm kayıt türlerini arayüzden düzenlemenize izin verir; yeni bir isim arıyorsanız alan adı avcısı boştaki adayları toplu tarar.