DNS Kayıtları Rehberi: A, AAAA, CNAME, MX, TXT, NS, PTR

Alan adını sunucuya yönlendirmek için DNS bölgenizde (zone) alan adını sunucunun IP adresine bağlayan bir A kaydı (IPv4) ve gerekiyorsa bir AAAA kaydı (IPv6) oluşturmanız yeterlidir. Mail, doğrulama ve ters çözümleme için MX, TXT ve PTR kayıtları, değişikliklerin ne kadar hızlı yayılacağı için ise TTL değeri devreye girer. Bu rehberde her kayıt türünü örnekleriyle, dig komutlarıyla ve sık yapılan hatalarla birlikte ele alıyoruz.

Örneklerde alan adı olarak example.com, IP adresi olarak dokümantasyon aralıkları (192.0.2.0/24, 2001:db8::/32) kullanılmıştır. Kendi değerlerinizle değiştirin.

DNS Nasıl Çalışır? Kısa Özet

Bir kullanıcı www.example.com yazdığında tarayıcı, işletim sisteminin çözümleyicisine (resolver) sorar. Çözümleyici sırayla kök sunucuları, .com TLD sunucularını ve son olarak alan adınızın yetkili (authoritative) name server'larını sorgular. Yetkili sunucu, bölgenizdeki kayıtlarla cevap verir. Cevap, kayıtta yazan TTL süresi boyunca çözümleyicide önbelleğe alınır.

Bu yüzden iki farklı yer vardır:

• Kayıt defteri (registrar): Alan adını satın aldığınız yerdir. Burada hangi NS'lerin yetkili olduğunu belirlersiniz.
• DNS barındırıcı: A, MX, TXT gibi kayıtların tutulduğu yerdir. Registrar'ın kendi DNS'i, bir DNS sağlayıcısı veya kendi kurduğunuz BIND/PowerDNS olabilir.

Kayıtları nerede düzenlemeniz gerektiğini bulmanın en kolay yolu NS kayıtlarına bakmaktır:

dig +short NS example.com

Çıkan sunucular hangisiyse, kayıtlar orada yönetilir.

Temel Kayıt Türleri

A ve AAAA Kaydı

A kaydı bir adı IPv4 adresine, AAAA kaydı IPv6 adresine bağlar. Sunucunuzda IPv6 yapılandırılmışsa ve servisiniz o adreste gerçekten dinliyorsa AAAA ekleyin. Dinlemeyen bir adrese AAAA vermek, IPv6 öncelikli istemcilerde zaman aşımına ve yavaş açılışa yol açar.

CNAME Kaydı

CNAME, bir adı başka bir adın takma adı yapar. Kurallar önemlidir:

• Aynı addaki başka bir kayıtla (A, MX, TXT, NS) birlikte bulunamaz.
• Bölgenin kökünde (example.com, yani apex) standart olarak kullanılamaz, çünkü kökte zaten SOA ve NS kayıtları vardır. Bazı sağlayıcılar bunun için ALIAS/ANAME gibi özel çözümler sunar; bunlar standart DNS kaydı değildir.
• MX ve NS kayıtlarının hedefi CNAME olmamalıdır; doğrudan A/AAAA'sı olan bir ad olmalıdır.

MX Kaydı

MX kaydı, alan adına gelen postayı alacak sunucuyu ve önceliğini belirtir. Düşük sayı daha yüksek önceliktir.

example.com.   3600 IN MX 10 mail.example.com.
example.com.   3600 IN MX 20 mail2.example.com.

mail.example.com için ayrıca bir A kaydı olmalıdır. IP adresi doğrudan MX'e yazılamaz.

TXT Kaydı

TXT kayıtları SPF, DKIM, DMARC, alan adı sahipliği doğrulama (Google, Microsoft vb.) ve Let's Encrypt DNS-01 doğrulaması için kullanılır. Dikkat edilecek nokta: bir adda yalnızca bir SPF kaydı (v=spf1 ile başlayan) olmalıdır. İki tane eklerseniz SPF değerlendirmesi hata verir.

example.com.          3600 IN TXT "v=spf1 mx ip4:192.0.2.10 -all"
_dmarc.example.com.   3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

NS Kaydı

NS kayıtları, bölgeden kimin yetkili olduğunu söyler. Registrar'daki NS ayarı ile bölgenizin içindeki NS kayıtları aynı olmalıdır. Alan adınızın altındaki adları NS olarak kullanıyorsanız (ns1.example.com), registrar'da glue kaydı (ns1'in IP adresi) tanımlamanız gerekir; aksi halde döngüsel bağımlılık oluşur.

PTR Kaydı

PTR, IP adresinden ada çözümleme yapar (ters DNS). Özellikle mail sunucularında alıcı sunucular bu kaydı kontrol eder. PTR kaydı sizin alan adı panelinizde değil, IP bloğunun sahibinin ters DNS bölgesinde (in-addr.arpa / ip6.arpa) tutulur. Yani VDS veya sunucu IP'niz için PTR'yi genellikle IP'yi size veren sağlayıcı tanımlar ya da size yetki verir. Kendi IP bloğunuz varsa RIR/sağlayıcı üzerinden ters bölge delegasyonunu siz yönetirsiniz.

dig +short -x 192.0.2.10
dig +short -x 2001:db8::10

İyi bir uygulama, PTR'nin gösterdiği adın tekrar aynı IP'ye çözülmesidir (forward-confirmed reverse DNS).

Örnek Bölge Dosyası

Kendi DNS sunucunuzu (BIND gibi) çalıştırıyorsanız bölge dosyası şuna benzer:

$TTL 3600
@   IN SOA ns1.example.com. hostmaster.example.com. (
        2025010101 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        3600 )     ; negative cache TTL

    IN NS   ns1.example.com.
    IN NS   ns2.example.com.

    IN A    192.0.2.10
    IN AAAA 2001:db8::10
    IN MX   10 mail.example.com.
    IN TXT  "v=spf1 mx -all"

www  IN CNAME example.com.
mail IN A     192.0.2.11
ns1  IN A     192.0.2.53
ns2  IN A     198.51.100.53

Her değişiklikte serial değerini artırmayı unutmayın; ikincil sunucular bu sayıya bakarak güncelleme yapar. Dosyayı yüklemeden önce kontrol edin:

named-checkzone example.com /etc/bind/db.example.com

Alan Adını Sunucuya Yönlendirme: Adım Adım

1. Sunucu IP'sini öğrenin. Örneğin 192.0.2.10. IPv6 kullanıyorsanız onu da not edin.
2. Yetkili DNS'i belirleyin. dig +short NS example.com ile kayıtların hangi panelde yönetildiğini doğrulayın.
3. A kaydını ekleyin. Ad alanına @ (kök) ve değer olarak 192.0.2.10 yazın.
4. www için CNAME ekleyin. www → example.com. (sondaki nokta, tam nitelikli ad olduğunu gösterir).
5. IPv6 varsa AAAA ekleyin. Servis IPv6'da dinliyorsa.
6. Mail kullanacaksanız MX, SPF ve PTR'yi ayarlayın.
7. Sunucuda web sunucusunu hazırlayın. Nginx/Apache'de server_name example.com www.example.com; gibi sanal host tanımı yoksa istek yanlış siteye düşer.
8. Doğrulayın:

dig +short A example.com
dig +short AAAA example.com
dig +short CNAME www.example.com
curl -I http://example.com --resolve example.com:80:192.0.2.10

Son komut, DNS yayılmasını beklemeden sunucunun doğru cevap verip vermediğini test etmenizi sağlar.

TTL ve Yayılma Süresi

TTL (Time To Live), çözümleyicilerin bir kaydı saniye cinsinden ne kadar süre önbellekte tutacağını belirtir. 3600 değeri bir saat demektir. "DNS yayılması" aslında dünya genelinde bir şeyin kopyalanması değil, eski cevapların farklı çözümleyicilerde TTL dolana kadar önbellekte kalmasıdır.

Yayılma süresini belirleyen unsurlar:

• Değiştirdiğiniz kaydın eski TTL değeri.
• NS (delegasyon) değişikliklerinde TLD tarafındaki NS kayıtlarının TTL'i; bu genellikle saatler hatta bir gün mertebesinde olabilir.
• Negatif önbellek: Var olmayan bir ad sorgulandıysa, "yok" cevabı SOA'daki negatif TTL kadar tutulabilir.
• Bazı istemci ve ISP çözümleyicilerinin TTL'e tam uymaması.

Sunucu Taşırken Önerilen TTL Stratejisi

1. Taşımadan en az bir eski TTL süresi kadar önce kayıtların TTL'ini 300 saniyeye düşürün.
2. Eski TTL süresi dolunca yeni sunucuyu hazırlayıp A kaydını değiştirin.
3. Trafiğin yeni sunucuya geçtiğini doğruladıktan sonra TTL'i tekrar 3600 veya daha yüksek bir değere çıkarın.
4. Eski sunucuyu birkaç gün açık tutun; önbelleği uzun tutan istemciler olabilir.

Kısa TTL sorgu sayısını artırır; kararlı kayıtlarda yüksek TTL gereksiz yük ve gecikmeyi azaltır.

Yayılmayı Kontrol Etme

Belirli bir çözümleyiciden sorgulayarak farklı önbellekleri karşılaştırabilirsiniz:

dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer
dig @ns1.example.com example.com A +noall +answer

Yetkili sunucu yeni değeri veriyor ama public çözümleyiciler eskiyi veriyorsa sorun yok; sadece TTL dolmasını beklemeniz gerekir. Cevaptaki TTL sayısı her sorguda azalır, böylece kalan süreyi görebilirsiniz. Yerel makinede önbelleği temizlemek için:

# Linux (systemd-resolved)
resolvectl flush-caches
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Sık Yapılan Hatalar ve Çözümleri

• Kayıtlar yanlış yerde düzenleniyor. Registrar'da NS başka bir sağlayıcıya işaret ediyorsa, registrar panelindeki A kaydı hiçbir işe yaramaz. Önce dig NS ile kontrol edin.
• Kökte CNAME kullanmak. Mail ve NS kayıtlarını bozar. Kökte A/AAAA kullanın.
• MX'in CNAME'e işaret etmesi. Bazı sunucular teslim etmeyi reddeder. Doğrudan A/AAAA'lı bir ad kullanın.
• Birden fazla SPF kaydı. Tek bir v=spf1 kaydında birleştirin.
• Sondaki nokta eksikliği. Bölge dosyasında mail.example.com yazarsanız mail.example.com.example.com. olarak yorumlanır. Tam adın sonuna nokta koyun.
• Serial'ı artırmamak. İkincil DNS sunucuları güncellenmez.
• Eski AAAA kaydı. Sunucu değişti ama eski IPv6 kaydı kaldı; kullanıcıların bir kısmı eski sunucuya gider.
• PTR ile HELO adının uyuşmaması. Mail sunucusunun kendini tanıttığı ad, PTR ve A kaydıyla tutarlı olmalıdır.

Kendi Sunucunuzda DNS Çalıştırmak

Alan adlarınızı kendi altyapınızda yönetmek istiyorsanız, en az iki yetkili DNS sunucusunu farklı IP bloklarında ve tercihen farklı lokasyonlarda tutmak dayanıklılığı artırır. Açık DNS çözümleyicileri ve yetkili sunucular UDP amplifikasyon saldırılarında sık hedef olduğu için, 53 numaralı portta rate limiting ve filtreleme de planlanmalıdır. Bunun için BGP destekli VDS sunucular üzerinde yetkili DNS sunucusu çalıştırabilir, kendi IP adreslerinizle NS ve glue kayıtlarınızı oluşturabilirsiniz. Saldırı riski yüksek servisler için DDoS koruma ve firewall seçeneklerini de değerlendirebilirsiniz.

Hızlı Kontrol Listesi

• dig NS ile yetkili DNS'i doğruladım.
• Kök için A (ve gerekiyorsa AAAA), www için CNAME ekledim.
• Mail varsa MX, tek SPF, DMARC ve PTR hazır.
• Taşıma öncesi TTL'i düşürdüm, sonrasında yükselttim.
• dig @yetkili-ns ile yeni değeri doğruladım.
• Web sunucusunda ilgili sanal host tanımlı.