DNS Kayıtlarını Anlamak (A, CNAME, MX, TXT)

DNS ne işe yarar, kayıtlar nerede durur?

Alan Adı Sistemi (DNS), ornek.com gibi insanların aklında tutabileceği adları bilgisayarların ihtiyaç duyduğu verilere çevirir: IP adresleri, e-posta sunucusu adları, güvenlik politikaları ve daha fazlası. Temel tanımlar 1987 tarihli RFC 1034 ve RFC 1035'tir ve temel model o günden beri neredeyse hiç değişmedi.

DNS, dağıtık ve hiyerarşik bir veritabanıdır. En tepede kök sunucular, onların altında .com, .tr veya .de gibi her üst düzey alan adının sunucuları, en altta da tek tek alan adlarının yetkili ad sunucuları bulunur. Bir alan adı kaydettiğinizde kayıt şirketiniz, uzantı bölgesinde sizin bölgenizi barındıran ad sunucularını gösteren NS kayıtları yayımlar. Bu bölge (zone), aslında kaynak kayıtlarının bir listesidir; bu rehberin konusu da tam olarak bu kayıtlar.

Bir sorgu hangi yolu izler?

1. Tarayıcı işletim sistemine, işletim sistemi de özyinelemeli bir çözümleyiciye (genellikle internet servis sağlayıcınızın ya da herkese açık bir servisin) sorar.
2. Yanıt önbellekte yoksa çözümleyici bir kök sunucuya sorar; kök sunucu onu uzantı sunucularına yönlendirir.
3. Uzantı sunucuları, alan adınızın yetkili ad sunucularını gösterir.
4. Yetkili sunucu kaydı döndürür, çözümleyici de onu TTL süresi boyunca önbelleğe alır.

Bir DNS kaydının yapısı

Her kayıt aynı beş parçadan oluşur. Standart zone dosyası sözdiziminde bu parçalar açıkça görülür:

www.ornek.com.   3600   IN   A   192.0.2.10
ad               TTL    sınıf tür veri

• Ad – kaydın ait olduğu sunucu adı. Sondaki nokta tam nitelikli adı belirtir; zone dosyalarında ve birçok kontrol panelinde @ işareti kök alan adını (çıplak alan adı) temsil eder.
• TTL – saniye cinsinden yaşam süresi; çözümleyicilere yanıtı ne kadar süre önbellekte tutabileceklerini söyler.
• Sınıf – neredeyse her zaman internet anlamına gelen IN.
• Tür – A, AAAA, CNAME, MX, TXT gibi.
• Veri – biçimi türe göre değişen değer.

En yaygın DNS kayıt türleri

A ve AAAA kayıtları: adları sunuculara yönlendirmek

A kaydı tek bir IPv4 adresi, AAAA kaydı ise tek bir IPv6 adresi içerir. Bir adın her türden birden fazla kaydı olabilir; çözümleyiciler hepsini döndürür ve bu da basit bir yük dağıtımı sağlar. Barındırma sağlayıcınız IPv6 destekliyorsa ikisini birden yayımlayın; böylece yalnızca IPv6 kullanan veya çift yığınlı ağlardaki istemciler doğrudan bağlanabilir.

@     3600  IN  A     192.0.2.10
@     3600  IN  AAAA  2001:db8::10
www   3600  IN  A     192.0.2.10

Yeni bir sunucuya taşındığınızda değiştireceğiniz kayıtlar A ve AAAA kayıtlarıdır. Hata ayıklarken bir adresin hangi ağa ait olduğunu bilmek işe yarar; TLDix hosting sorgulama aracı bir IP adresini hangi sağlayıcının işlettiğini gösterir.

CNAME kayıtları: takma adlar ve sınırları

CNAME, bir adın başka bir asıl (kanonik) adın takma adı olduğunu söyler. Çözümleyiciler zinciri takip ederek hedefin kayıtlarını döndürür. CNAME, kontrolünüzde olmayan servislere alt alan adı yönlendirmek için çok pratiktir: barındırılan bir e-ticaret mağazası, CDN veya durum sayfası gibi. Sağlayıcı IP adreslerini değiştirdiğinde sizin hiçbir şeyi düzenlemeniz gerekmez.

magaza  3600  IN  CNAME  stores.saglayici.example.
durum   3600  IN  CNAME  ornek.statuspage.example.

Çiğnenmemesi gereken kurallar

• CNAME bulunan bir adda başka hiçbir kayıt türü olamaz (RFC 1034, RFC 2181 ile netleştirildi). Aynı ada hem CNAME hem MX koyamazsınız.
• Kök alan adında her zaman SOA ve NS kayıtları bulunduğu için standart CNAME çıplak alan adında kullanılamaz. Birçok DNS sağlayıcısı bunu aşmak için ALIAS, ANAME veya CNAME düzleştirme gibi kendine özgü çözümler sunar; daha yeni HTTPS kayıt türü (RFC 9460) de bir seçenektir.
• MX ve NS kayıtları CNAME'e değil, A veya AAAA kaydı olan bir sunucu adına işaret etmelidir.
• Uzun CNAME zincirlerinden kaçının; her adım sorgu süresini uzatır ve yeni bir arıza noktası ekler.

MX kayıtları: e-postanın yönlendirilmesi

MX kayıtları, e-posta gönderen sunuculara alan adınıza gelen iletileri nereye teslim edeceklerini söyler. Her kaydın bir öncelik numarası vardır; düşük numara önce denenir, eşit öncelikteki kayıtlar yükü paylaşır.

@  3600  IN  MX  10 mx1.epostasaglayici.example.
@  3600  IN  MX  20 mx2.epostasaglayici.example.

Bir alan adının MX kaydı yoksa gönderen sunucular A veya AAAA kaydına yönelir; bu da nadiren istenen bir durumdur. Hiç e-posta almaması gereken alan adları için RFC 7505 boş MX (null MX) tanımlar: önceliği 0 ve hedefi tek bir nokta olan tek bir kayıt.

TXT kayıtları: doğrulama ve e-posta kimlik doğrulaması

TXT kayıtları serbest metin saklar ve zamanla politikaların ve sahiplik kanıtlarının yeri hâline geldi. Arama motorları, sertifika otoriteleri ve SaaS platformları, alan adını kontrol ettiğinizi kanıtlamanız için genellikle bir doğrulama kodu içeren TXT kaydı eklemenizi ister. En önemli üç kullanım e-postayla ilgilidir:

• SPF (RFC 7208), alan adınız adına e-posta gönderebilecek sunucuları listeler; örneğin v=spf1 include:_spf.epostasaglayici.example -all. Her ad için yalnızca bir SPF kaydı yayımlayın.
• DKIM (RFC 6376), s1._domainkey gibi bir seçici altında açık anahtar yayımlar; alıcılar bu anahtarla ileti imzalarını doğrular.
• DMARC (RFC 7489), _dmarc altında durur ve SPF ile DKIM kontrolleri başarısız olduğunda alıcının ne yapacağını belirtir; örneğin v=DMARC1; p=quarantine; rua=mailto:dmarc@ornek.com.

Tek bir TXT dizesi en fazla 255 karakter olabilir, ancak bir kayıt art arda eklenen birden çok dize içerebilir. Uzun DKIM anahtarları bu şekilde saklanır.

NS, SOA ve CAA: bölgeyi yöneten kayıtlar

NS kayıtları

NS kayıtları bir bölgenin yetkili sunucularını listeler ve iki seviyede birbiriyle uyumlu olmalıdır: kayıt şirketiniz aracılığıyla ayarlanan üst uzantı bölgesinde ve kendi bölgenizin içinde. Uyumsuzluk, teşhis etmesi zor tutarsız yanıtlara yol açar. Farklı ağlarda en az iki ad sunucusu kullanmak standart bir uygulamadır.

SOA kaydı

@  IN  SOA  ns1.ornek.net. hostmaster.ornek.com. (
        2026100701 ; seri
        7200       ; yenileme
        3600       ; yeniden deneme
        1209600    ; sona erme
        3600 )     ; olumsuz önbellek TTL

İkincil sunucuların güncellemeyi alabilmesi için bölge her değiştiğinde seri numarası artırılmalıdır; yukarıdaki gibi tarihe dayalı bir biçim yaygındır. Son alan, çözümleyicilerin "bulunamadı" yanıtını ne kadar süre önbellekte tutacağını belirler (RFC 2308).

CAA kayıtları

CAA kayıtları, alan adınız için hangi sertifika otoritelerinin TLS sertifikası verebileceğini belirtir. 2017'den bu yana güvenilir sertifika otoriteleri sertifika vermeden önce bu kaydı kontrol etmek zorundadır. 0 issue "letsencrypt.org" eklemek, yalnızca bu otoritenin sertifika verebileceği anlamına gelir ve hatalı sertifika verilmesi riskini azaltır.

PTR ve SRV kayıtları

PTR kayıtları ters yöndeki sorguyu yanıtlar: bir IP adresinden sunucu adına ulaşılır. Bu kayıtlar alan adınızın bölgesinde değil, IP bloğunun sahibi olan barındırma sağlayıcısının ters bölgesinde (in-addr.arpa veya ip6.arpa) tutulur; bu yüzden genellikle sağlayıcınızın panelinden ya da destek ekibinden istenir. Kendi e-posta sunucusunu çalıştıranlar için doğru bir PTR kaydı teslim edilebilirlik açısından önemlidir. SRV kayıtları ise SIP veya XMPP gibi servislerin hangi sunucu ve portta çalıştığını öncelik ve ağırlık değerleriyle bildirir.

TTL, yayılma ve kayıtları kontrol etmek

DNS'te küresel bir "gönder" düğmesi yoktur: değişiklikler, önbellekteki kopyaların süresi doldukça görünür hâle gelir. TTL değeri 86400 olan bir kayıtta bazı çözümleyiciler eski değeri bir güne kadar sunmaya devam edebilir. Planlı bir taşımadan önce mantıklı yöntem şudur: bir iki gün önceden TTL'i 300 saniyeye düşürün, değişikliği yapın, doğrulayın ve ardından TTL'i yeniden yükseltin.

Gerçekte neyin yayımlandığını görmenin en güvenilir yolu dig aracıdır:

dig ornek.com A
dig ornek.com MX +short
dig _dmarc.ornek.com TXT
dig @ns1.ornek.net ornek.com SOA
dig ornek.com NS +trace

Yetkili sunucuyu @ ile doğrudan sorgulamak güncel değeri gösterir ve önbellekleri atlar. +trace seçeneği yetki devrini kökten itibaren izler; kayıt şirketiniz ile DNS sağlayıcınız arasında uyumsuzluktan şüphelendiğinizde çok işe yarar.

Sık yapılan hatalar ve çözümleri

• Alan adının süresinin dolması. Alan adı askıya alındığı anda tüm kayıtlar çalışmayı bırakır. Bitiş tarihlerini takip edin; TLDix alan adı sorgulama aracı kayıt durumunu ve ad sunucularını gösterir, yenileme uyarıları ise dokümantasyonda anlatılır.
• Zone dosyalarında sondaki noktayı unutmak. Bu hata mail.ornek.com adını mail.ornek.com.ornek.com hâline getirir.
• Aynı ad üzerinde iki SPF kaydı. SPF değerlendirmesi kalıcı hatayla sonuçlanır.
• CNAME çakışmaları. Kök alan adında ya da MX ve TXT kayıtlarıyla aynı adda CNAME kullanmak.
• Eskimiş kayıtlar. Kapatılmış bulut kaynaklarına işaret eden kayıtlar alt alan adı ele geçirme (subdomain takeover) saldırılarına kapı açabilir. Servisleri kaldırırken kayıtlarını da silin.

Yukarıdaki birkaç kayıt türünü kavradığınızda neredeyse her DNS işi doğru türü seçmek, değeri dikkatle yazmak ve sonucu dig ile doğrulamaktan ibaret hâle gelir.