DNS Kayıt Türleri Nedir? A, AAAA, MX, CNAME, TXT, SRV ve CAA İçin Uygulamalı Rehber

Alan adınızı satın aldınız, hostinginizi veya sunucunuzu kurdunuz, sıra geldi her şeyi birbirine bağlayan katmana: DNS kayıtları. Panelde karşınıza çıkan A, AAAA, MX, CNAME, TXT, SRV, CAA gibi kısaltmalar ilk bakışta karmaşık görünebilir; ancak mantığını bir kez oturttuğunuzda hem web sitenizi hem de e-posta altyapınızı çok daha kontrollü şekilde yönetebilirsiniz. DCHost ekibinde günlük işimizin önemli bir kısmı, yanlış yapılandırılmış DNS kayıtlarının sebep olduğu erişim ve e-posta sorunlarını çözmekle geçiyor. Bu rehberde amacımız, bu hataları siz daha yapmadan önlemek.

Aşağıda en sık kullanılan DNS kayıt türlerini, gerçekçi senaryolar ve örnek zone çıktılarıyla adım adım anlatacağız. Hangi kaydı ne zaman kullanmanız gerektiğini, hangi durumda kesinlikle kullanmamanız gerektiğini, TTL değerlerini nasıl düşünmeniz gerektiğini ve CAA gibi güvenlik odaklı kayıtları pratikte nasıl ele alabileceğinizi birlikte netleştirelim. Eğer DNS’in temellerini de tazelemek isterseniz, önce alan adı, DNS ve web hosting ilişkisini detaylı anlattığımız rehbere göz atmanız faydalı olabilir.

DNS Kayıtları Nasıl Çalışır?

DNS’i basitçe, alan adınızı (örneğin example.com) teknik ayrıntılara (IP adresleri, mail sunucuları, servis adresleri vb.) çeviren bir telefon rehberi gibi düşünebilirsiniz. DNS bölge dosyanızda (zone) tanımladığınız her kayıt türü, bu rehberin içinde ayrı bir satırdır.

• A / AAAA: Alan adının hangi IP adresine gideceğini söyler.
• MX: E-postaları hangi sunucunun alacağını tanımlar.
• CNAME: Bir alan adını başka bir alan adına takma ad olarak yönlendirir.
• TXT: SPF, DKIM, DMARC gibi doğrulama ve çeşitli metin verilerini tutar.
• SRV: Belirli servislerin (VoIP, chat, autodiscover vb.) hangi host ve porttan hizmet vereceğini belirtir.
• CAA: Alan adınız için hangi sertifika otoritelerinin SSL sertifikası üretebileceğini kısıtlar.

Her kaydın bir ad (name), tip (type), değer (value) ve çoğu zaman bir de TTL (Time To Live) değeri vardır. TTL, bu kaydın DNS önbelleklerinde ne kadar süre saklanacağını belirler. TTL konusu başlı başına bir strateji gerektirir; bu tarafı daha derin anlamak isterseniz DNS TTL değerlerini doğru ayarlamak için hazırladığımız strateji rehberini mutlaka okuyun.

Örnek Bir DNS Zone Dosyası

Anlatımı daha somut hale getirmek için basit bir örnek üzerinden gidelim. Aşağıdaki örnek, example.com için tipik bir DNS zone’udur:

@      3600   IN   A      203.0.113.10
@      3600   IN   AAAA   2001:db8::10
www    3600   IN   CNAME  example.com.
mail   3600   IN   A      203.0.113.20
@      3600   IN   MX     10 mail.example.com.
@      3600   IN   TXT    "v=spf1 a mx -all"
_sip._tcp 3600 IN SRV     10 60 5060 sip.example.com.
@      3600   IN   CAA    0 issue "letsencrypt.org"

Şimdi bu kayıtları tek tek açalım ve gerçek hayat senaryolarında nereye dokunduklarını görelim.

A Kaydı: IPv4 Adresine Giden Yol

A kaydı nedir?

A (Address) kaydı, bir alan adını bir IPv4 adresine (ör. 203.0.113.10) çözer. Kullanıcı tarayıcısına example.com yazdığında, DNS sorgusu A kaydını bulur ve bu IP’ye gider.

DCHost müşterilerinde en sık gördüğümüz kullanım:

• Alan adının kökü (root / @) için bir A kaydı: @ → 203.0.113.10
• Alt alan adları için ek A kayıtları: api → 203.0.113.11, panel → 203.0.113.12 gibi.

Pratik A kaydı senaryoları

• Tek VPS üzerinde site: Tüm trafik aynı IP’ye gider: @ ve www aynı sunucuya işaret eder.
• Ön tarafta CDN, arkada origin: @ kaydınızı CDN’in verdiği IP’ye, origin.example.com kaydınızı ise gerçek sunucu IP’sine yönlendirebilirsiniz.
• Ayrı uygulama sunucuları: api.example.com, admin.example.com gibi farklı alt alan adlarını farklı VPS’lere yönlendirebilirsiniz.

A kaydında sık yapılan hatalar

• Yanlış IP: En kritik ve en basit hata. Yeni sunucuya geçtiğinizde IP’yi güncellemeyi unutursanız site eski sunucuya gitmeye devam eder.
• Çok yüksek TTL ile kilitlenmek: 86400 (24 saat) gibi yüksek TTL değerleriyle, taşınma anında değişikliklerinizin geç yayılmasına sebep olabilirsiniz. Taşıma öncesi TTL’i geçici olarak düşürmek daha iyi bir stratejidir.
• Boşta kalan A kayıtları: Kullanılmayan alt alan adlarını bırakmak, subdomain takeover gibi güvenlik risklerine açık kapı bırakabilir.

En tipik DNS yanlışlarını daha geniş bir perspektifle görmek için, en sık yapılan DNS hatalarını listelediğimiz yazıya da mutlaka göz atmanızı öneririz.

AAAA Kaydı: IPv6’ya Hazırlık

AAAA kaydı nedir?

AAAA (Quad-A) kaydı, bir alan adını IPv6 adresine (ör. 2001:db8::10) çözer. Yapı, A kaydına çok benzer; tek fark kullanılan IP sürümüdür. Modern tarayıcılar ve işletim sistemleri, hem A hem AAAA kaydı varsa tercihen IPv6 bağlantı kurmaya çalışır.

Ne zaman AAAA kaydı eklemelisiniz?

• Sunucunuzda IPv6 adresi tanımlıysa,
• Firewall ve web sunucusu konfigürasyonunuz IPv6’yı destekliyorsa,
• Monitoring, log ve güvenlik kurallarınız IPv6’yı hesaba katıyorsa.

Sık yapılan hata, sadece AAAA kaydı ekleyip sunucuda IPv6’yı doğru yapılandırmamaktır. Bu durumda IPv6 üzerinden gelen istekler cevap alamaz, ziyaretçileriniz zaman zaman siteye ulaşamaz.

Örnek A + AAAA beraber kullanımı

@   3600  IN  A     203.0.113.10
@   3600  IN  AAAA  2001:db8::10

Bu durumda hem IPv4 hem IPv6’lı kullanıcılar alan adınıza ulaşabilir. DCHost üzerinde yeni nesil projeler planlıyorsanız, IPv6 tarafını da baştan tasarlamak uzun vadede büyük avantaj sağlar.

MX Kaydı: E-Postanın Gittiği Yer

MX kaydı nedir?

MX (Mail Exchanger) kaydı, alan adınıza gelen e-postaları hangi sunucunun teslim alacağını belirler. Örneğin [email protected] adresine gönderilen mailin hangi sunucuya gideceğine MX kaydı karar verir.

@   3600  IN  MX  10  mail.example.com.
mail 3600  IN  A      203.0.113.20

Burada:

• mail.example.com e-posta sunucusudur,
• MX kaydı bu host’a işaret eder,
• 10 ise öncelik değeridir (birden çok MX kaydı varsa düşük olan daha önceliklidir).

Yedekli MX (backup MX) kullanımı

Daha kurumsal yapılarda, birincil sunucu geçici olarak erişilemez olsa bile maillerin kaybolmaması için yedek MX kullanılır:

@   3600  IN  MX  10 mail1.example.com.
@   3600  IN  MX  20 mail2.example.com.

Böylece birincil sunucu down olduğunda, gönderen sunucular ikinci MX’e mail bırakmayı dener. Bu yapıların tasarımına dair daha kapsamlı bir bakış için, e-posta altyapısında yedeklilik rehberimizi inceleyebilirsiniz.

MX kayıtlarında kritik hatalar

• MX’in A yerine CNAME’e işaret etmesi: Birçok e-posta servisi, MX hedefinin CNAME olmasını istemez. Mümkünse doğrudan A (veya AAAA) kaydına işaret eden bir hostname kullanın.
• MX kaydı var, ama karşılığında A/AAAA yok: mail.example.com için A ya da AAAA kaydı tanımlı değilse, e-postalarınız geri döner.
• MX kaydı hiç yok: Çoğu gönderici sunucu e-posta atamaz veya alan adınızı geçersiz sayar.

CNAME Kaydı: Takma Ad Mantığı

CNAME nedir?

CNAME (Canonical Name) kaydı, bir alan adını başka bir alan adına takma ad (alias) yapar. Özetle, “Bu alt alan adı, aslında şurayı gösteriyor” demektir.

www   3600  IN  CNAME  example.com.
cdn   3600  IN  CNAME  cdn-sağlayıcı-örneği.com.

Burada www.example.com, example.com’un takma adı olur. Tarayıcı www için sorgu yaptığında, önce CNAME’i görür, sonra hedefteki (ör. A/AAAA) kaydı çözer.

CNAME ne zaman mantıklı?

• www → kök alan adı: En yaygın senaryo. IP’yi tek yerde yönetmiş olursunuz.
• CDN veya dış servisler: CDN, e-posta doğrulama, üçüncü parti servislere yönlenen alt alan adları için idealdir.
• Aynı servisi kullanan çoklu alt alan adları: static, assets, images gibi alt alan adlarını tek bir “kanonik” host’a CNAME ile bağlayabilirsiniz.

CNAME’de yapılmaması gerekenler

• Kök alan adında (@) CNAME kullanmak: DNS standartlarına göre zone kökü için CNAME kullanmak doğru değildir ve birçok DNS sağlayıcı buna izin vermez.
• MX hedefini CNAME yapmak: Bir önceki bölümde değindiğimiz gibi, MX hedefleri doğrudan A/AAAA’ya işaret etmelidir.
• Gereksiz CNAME zincirleri: a → b → c → d gibi uzun zincirler gecikme ve hata riskini artırır.

CNAME’lerin TTL değerleri ve zincirlenmesiyle ilgili ince ayar yaparken, tekrar TTL stratejisi rehberine bakmak iyi bir fikirdir.

TXT Kaydı: SPF, DKIM, DMARC ve Daha Fazlası

TXT kaydı nedir?

TXT (Text) kaydı, serbest metin saklamak için kullanılır. Ancak pratikte en önemli kullanım alanları:

• SPF: Hangi sunucuların alan adınız adına e-posta göndermeye yetkili olduğunu belirtir.
• DKIM: Gönderilen e-postaların imzasını doğrulamak için kullanılır.
• DMARC: SPF/DKIM sonuçlarına göre e-posta politikanızı (reject/quarantine/none) bildirir.
• Sahiplik doğrulama: Arama motorları, e-posta servisleri, üçüncü parti uygulamalar alan adınızın size ait olduğunu doğrulamak için TXT kaydı ister.

Örnek TXT kayıtları

@      3600  IN  TXT  "v=spf1 a mx -all"
_dmarc 3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
@      3600  IN  TXT  "google-site-verification=xyz123"

Burada:

• SPF kaydı, sadece alan adınızın A ve MX kayıtlarındaki IP’lerin mail göndermesine izin verir.
• DMARC, SPF/DKIM başarısız olursa mailleri karantinaya almayı önerir ve raporların nereye gönderileceğini belirtir.
• Son TXT kaydı, bir servis sağlayıcının alan adı doğrulaması içindir.

TXT kayıtlarında dikkat edilmesi gerekenler

• Birden çok SPF kaydı: Aynı alanda birden fazla SPF kaydı olmamalıdır; tüm yetkili IP’leri tek bir SPF dizesinde birleştirin.
• 255 karakter sınırı: DNS satır başına 255 karakter sınırı vardır; uzun DMARC veya SPF kayıtlarını bölmeniz gerekebilir.
• Yanlış alanda TXT: Özellikle DMARC için _dmarc.example.com gibi özel alt alan kullanmanız gerekir; kök alana yazmak yeterli değildir.

E-posta teslim edilebilirliği tarafını bütünsel ele almak isterseniz, DNS ve IP itibarı boyutunu da kapsayan e-posta teslim edilebilirliği denetim listemiz size iyi bir kontrol çerçevesi sunacaktır.

SRV Kaydı: Servis Keşfi (Service Discovery)

SRV kaydı nedir?

SRV (Service) kaydı, belirli bir servisin hangi host, port ve öncelik ile hizmet verdiğini tanımlar. Özellikle VoIP (SIP), XMPP, bazı Microsoft servisleri ve autodiscover mekanizmalarında kullanılır.

_sip._tcp   3600  IN  SRV  10 60 5060 sip1.example.com.
_sip._tcp   3600  IN  SRV  20 40 5060 sip2.example.com.

Bu kayıtta:

• _sip servis adıdır,
• _tcp protokoldür (TCP/UDP),
• 10 öncelik, 60 ağırlık, 5060 port numarasıdır.

Öncelik ve ağırlık nasıl kullanılır?

• priority (öncelik): En düşük değerli kayıt önce denenir. Diğerleri yedek gibi davranır.
• weight (ağırlık): Aynı önceliğe sahip kayıtlar arasında yük dağılımını belirler. Örneğin biri 60, diğeri 40 ise isteklerin yaklaşık %60’ı birinciye, %40’ı ikinciye gider.

SRV kayıtları çoğu web projesinde doğrudan kullanılmasa da, VoIP sistemleri, chat altyapıları veya bazı kurumsal e-posta istemcileri için kritiktir. SRV kayıtlarınızın hedefi olan host’lar için mutlaka geçerli A/AAAA kayıtları da tanımlamayı unutmayın.

CAA Kaydı: SSL Sertifikası Güvenlik Katmanı

CAA kaydı nedir?

CAA (Certification Authority Authorization) kaydı, alan adınız için hangi sertifika otoritelerinin (CA) SSL/TLS sertifikası üretebileceğini belirler. Varsayılan durumda herhangi bir CAA kaydınız yoksa, tüm CA’lar sertifika verebilir. CAA eklediğiniz anda liste dışı CA’ların sertifika üretmesi engellenir.

@ 3600 IN CAA 0 issue "letsencrypt.org"

Bu örnekte sadece letsencrypt.org alan adınız için sertifika üretebilir. Başka bir CA üzerinden sertifika almak isterseniz, o CA’yı da CAA kayıtlarınıza eklemeniz gerekir.

CAA kayıt türleri

• issue: Bu CA, alan adı için sertifika üretebilir.
• issuewild: Bu CA, wildcard sertifikası (ör. *.example.com) üretebilir.
• iodef: Yetkisiz sertifika girişimleri konusunda raporların gönderileceği e-posta veya URL’yi belirtir.

@ 3600 IN CAA 0 issue "letsencrypt.org"
@ 3600 IN CAA 0 issue "digicert.com"
@ 3600 IN CAA 0 iodef "mailto:[email protected]"

CAA kayıtları konusunda daha derin bir güvenlik ve çoklu-CA stratejisi kurmak istiyorsanız, CAA kayıtlarını derinlemesine incelediğimiz makaleyi ayrıca tavsiye ederiz.

CAA kullanırken dikkat edilmesi gerekenler

• Yanlış veya eksik CA adı: Sertifika almak istediğiniz CA’nın dokümantasyonunda geçen tam domain adını kullanın.
• Wildcard için issuewild: Sadece issue yetkisi wildcard sertifika için her zaman yeterli olmayabilir; CA’nızın gereksinimlerini kontrol edin.
• Otomasyonla uyum: ACME tabanlı sertifika otomasyon araçları (Let’s Encrypt vb.) ile CAA kayıtlarınızın uyumlu olduğundan emin olun.

DNS Değişiklikleri, TTL ve Yayılım Süresi

DNS kayıtlarınızı değiştirdiğinizde, hemen her yerde aynı anda etkisini görmezsiniz. Bunun sebebi, resolver’ların TTL süresi boyunca eski kaydı önbellekten kullanmaya devam etmesidir. Özellikle:

• Yeni sunucuya taşınırken A/AAAA kayıtları,
• E-posta altyapısını değiştirirken MX, SPF, DKIM, DMARC kayıtları,
• SSL sertifika sağlayıcısını değiştirirken CAA kayıtları

için TTL stratejisinin baştan planlanması kritik önem taşır. Değişikliğe gideceğiniz dönem öncesinde TTL’i 300–600 saniye gibi değerlere çekip, geçiş tamamlandıktan sonra tekrar daha yüksek bir değere almayı düşünebilirsiniz.

DNS yayılımının neden bazen 24 saate kadar uzayabildiğini ve bunu hangi noktalarda hızlandırabileceğinizi daha iyi anlamak için, DNS yayılım süresini anlattığımız rehbere mutlaka göz atın.

Yeni Bir Proje İçin Örnek DNS Taslağı

Diyelim ki DCHost üzerinde yeni bir VPS veya paylaşımlı hosting paketi açtınız ve example.com alan adınızı bu altyapıya bağlayacaksınız. Basit ama sağlıklı bir başlangıç şeması şöyle olabilir:

; Web sitesi
@      300  IN  A      203.0.113.10
www    300  IN  CNAME  example.com.

; IPv6
@      300  IN  AAAA   2001:db8::10

; E-posta
mail   300  IN  A      203.0.113.20
@      300  IN  MX     10 mail.example.com.
@      300  IN  TXT    "v=spf1 a mx -all"
_dmarc 300  IN  TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

; Güvenlik
@      300  IN  CAA    0 issue "letsencrypt.org"

Buna ek olarak, CDN, API sunucuları, admin paneli gibi bileşenleri projeye göre alt alan adlarıyla ve gerekirse ek A/AAAA/CNAME kayıtlarıyla genişletebilirsiniz. Birden fazla müşteri veya marka yönetiyorsanız, DNS kayıtlarınızı düzenli ve dökümante tutmak kritik önem taşıyor; bu noktada ajanslar için hazırladığımız hosting ve DNS altyapısı kontrol listesi işinizi ciddi anlamda kolaylaştırabilir.

DCHost Tarafında DNS Yönetimini Nasıl Düşünmelisiniz?

DCHost olarak hem domain hem de hosting/vps/dedicated/colocation hizmetlerinde DNS’i mimarinin merkezi bir parçası olarak ele alıyoruz. Pratik öneriler:

• Önce DNS tasarımını planlayın: Hangi alt alan adlarının hangi sunuculara gideceğini, ileride CDN veya e-posta servisi değişikliklerini nasıl yapacağınızı kağıt üzerinde netleştirin.
• Değişiklikleri küçük adımlarla yapın: A/AAAA, MX, TXT, CAA gibi kritik kayıtları tek seferde toplu güncellemek yerine, her adımda test ederek ilerleyin.
• Test için ek alanlar kullanın: Örneğin test.example.com veya staging.example.com gibi alanlarda önce deneme yapmak, canlı ortamda riskinizi azaltır.
• Log ve izleme ile doğrulayın: Web ve e-posta loglarını, DNS sorgu sonuçlarıyla birlikte değerlendirerek sorun anında nerede hata olduğunu hızla tespit edebilirsiniz.

Özet ve Sonraki Adımlar

Bu rehberde A, AAAA, MX, CNAME, TXT, SRV ve CAA kayıtlarının ne işe yaradığını; hangi durumda hangisini seçmeniz gerektiğini, pratik örneklerle birlikte ele aldık. DNS’in gücü, basit görünen birkaç satırın, tüm web ve e-posta trafiğinizin kaderini belirlemesinden geliyor. Yanlış yapılandırılmış bir A veya MX kaydı, saatlerce süren erişim ve iletişim sorunlarına yol açabilir; doğru tasarlanmış bir kayıt dizisi ise yıllarca düzgün ve sessizce çalışır.

Eğer mevcut DNS yapılandırmanızı gözden geçirmek, yeni bir projeyi DCHost altyapısına taşımak veya çoklu alan adlı daha karmaşık bir mimari kurmak istiyorsanız, bu yazıyı bir kontrol listesi gibi kullanabilirsiniz. Daha detaylı senaryolar için genel DNS kayıt rehberimize ve bağlantı verdiğimiz diğer yazılara da mutlaka göz atın. Takıldığınız noktada DCHost destek ekibi, DNS kayıtlarınızı birlikte üzerinden geçmek ve projenize en uygun yapıyı kurmak için her zaman yanınızda.