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.

Kayıt doğru görünüyor, yine çalışmıyor: dig çıktısında dört teşhis

dig +short boş döndüğünde çoğu kişi "kayıt yok" der ve paneli tekrar düzenler. Oysa boş cevabın en az dört farklı sebebi vardır ve hepsi kısaltılmamış çıktının üst kısmında, status alanında ve hemen altındaki bölümlerde yazar. +short kullanmadan sorun:

dig ornek.com A

1. NXDOMAIN — ad hiç yok. Ad hiç tanımlanmamış ya da alan adının kendisi kayıtlı değil. Var olmayan bir .com.tr adı sorduğumuzda cevap status: NXDOMAIN geldi ve yetki bölümünde bölgenin SOA kaydı göründü. Bu SOA satırındaki son sayı (bizim denememizde 3600) olumsuz cevabın ne kadar süre önbellekte tutulacağını söyler. Yani bir adı oluşturmadan önce sorgularsanız, oluşturduktan sonra da bir süre "yok" cevabı almaya devam edebilirsiniz.

2. NOERROR ama cevap boş — ad var, o tür yok. status: NOERROR ve ANSWER: 0 görüyorsanız ad mevcuttur ama sorduğunuz kayıt türü tanımlı değildir. Tipik örnek: A kaydı vardır, AAAA yoktur; ya da kayıt kök ada değil yalnız www'ye yazılmıştır. Panelde ad alanına neyin yazıldığını kontrol edin.

3. SERVFAIL — çözümleyici cevabı reddetti. En yaygın sebebi bozuk DNSSEC'tir: alan adının kayıt kuruluşunda eski bir DS kaydı kalmış, ama ad sunucuları artık eşleşen anahtarla imzalamıyordur. Bilerek bozuk tutulan bir deneme alan adında 1.1.1.1 bu durumu açıkça yazdı:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found ...)

Aynı sorguyu +cd (doğrulamayı kapat) ile tekrarladığımızda IP adresi döndü. Kayıt yerinde, imza zinciri kopuk demektir. Ad sunucusu değiştirirken DNSSEC'i önce kapatıp DS kaydını kaldırmak, değişiklikten sonra yeniden açmak bu yüzden önemlidir.

4. Doğru sunucuya sormamak. Genel çözümleyiciler önbellekten cevap verir. Kaynağın ne söylediğini görmek için yetkili ad sunucusuna özyinelemesiz sorun:

dig ornek.com NS +short
dig +norecurse @ad-sunucusu ornek.com A

Cevabın flags satırında aa (authoritative answer) görmelisiniz. Yetkili sunucu doğru cevabı veriyor ama genel çözümleyiciler eskisini veriyorsa sorun kayıtta değil, TTL süresindedir; beklemek yeterlidir. Kayıtları kurulum yapmadan sorgulamak için DNS sorgulama, değişikliğin farklı çözümleyicilere ulaşıp ulaşmadığını görmek için DNS yayılım kontrolü araçlarını kullanabilirsiniz.

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.

Sık sorulan sorular