Bir domain satın aldığınızda elinizde yalnızca bir isim olur. Bu ismin bir IP adresine bağlanması, e-posta alabilmesi, üçüncü taraf servislerle entegre olabilmesi — bunların hepsi DNS kayıtları aracılığıyla kurulur. Her kayıt türü belirli bir problemi çözer; doğru kaydı yanlış bağlamda kullanmak ise ya hiç sonuç vermez ya da beklenmedik bir arızaya yol açar.
DNS sisteminin genel işleyişini DNS Nedir? başlıklı yazımızda ele almıştık. Bu yazı kayıt türlerine odaklanıyor: A, AAAA, MX, CNAME, NS ve TXT. Her birinin ne işe yaradığını, ne zaman oluşturulduğunu ve hangi hataların bu kayıtlardan kaynaklandığını aktarıyoruz.
Başlamadan önce önemli bir not: Farklı kayıt türleri birbirini etkiler. MX kaydını doğru ayarlamış olmanız, TXT'deki bir SPF hatası nedeniyle e-postalarınızın spam klasörüne düşmesini engellemez. Bu yüzden kaydı tek başına değil, alan adının tamamı bağlamında değerlendirmek daha sağlıklı bir yaklaşımdır.
A ve AAAA Kaydı: Sunucu Adresinin Tanımlanması
A kaydı (Address Record), alan adını bir IPv4 adresiyle eşleştirir. Tarayıcıya example.com yazdığınızda, DNS resolver bu alan adına karşılık gelen A kaydını sorgular ve 93.184.216.34 gibi dört oktetli bir IPv4 adresi döndürür. Tarayıcı bu adrese bağlanarak web sunucusuna ulaşır.
AAAA kaydı aynı işlevi IPv6 adresleri için yapar. 2606:2800:220:1:248:1893:25c8:1946 formatındaki sekiz gruplu onaltılık adresleri döndürür. IPv4 havuzunun tükenmeye başladığı dönemden bu yana modern sunucuların büyük çoğunluğu her iki formatı paralel olarak yönetir; pratikte bir alan adı hem A hem de AAAA kaydı taşıyabilir.
Bir domain için birden fazla A kaydı tanımlamak mümkündür. Bu yapı yük dengeleme amacıyla kullanılır: sorgu geldiğinde DNS sunucusu kayıtları sırayla veya rastgele döndürerek trafiği birden fazla sunucuya dağıtır. Buna round-robin DNS denir. Basit bir trafik dağılımı sağlar; ancak bir sunucu çöktüğünde bunu otomatik algılayıp trafiği yeniden yönlendirmez. Böyle bir otomasyon için health-check destekleyen bir DNS yönetim sistemi gerekmektedir.
A kaydı değişikliklerinin yayılma süresi, kaydın TTL (Time to Live) değerine bağlıdır. TTL'nin 3.600 saniye olduğu bir senaryoda, kaydı güncelledikten sonra dünya genelindeki DNS sunucularının eski değeri önbellekten temizlemesi en fazla bir saat alabilir. Planlı bir sunucu taşıması öncesinde TTL'yi birkaç saat önceden düşürmek bu geçiş süresini önemli ölçüde kısaltır.
MX Kaydı: E-posta Akışını Yöneten Kayıt
MX (Mail Exchanger) kaydı, bir alan adına gönderilen e-postaların hangi sunucuya iletileceğini belirler. bilgi@example.com adresine e-posta gönderildiğinde, gönderici sunucu MX kaydını sorgular ve teslimatı burada belirtilen sunucuya yönlendirir.
Her MX kaydında bir öncelik değeri (priority) bulunur; genellikle 10, 20, 30 gibi tam sayılar kullanılır. Sayı küçüldükçe öncelik artar. Birincil sunucu yanıt vermediğinde e-posta, öncelik sırasındaki bir sonraki sunucuya yönlendirilir. Bu yapı mail sunucu yedekliliğinin temelidir.
MX kaydı eksik olan bir domain e-posta alamaz. Gönderici sunucu sorgu yaptığında kayıt bulamazsa, iletimi başarısız olarak işaretler ve gönderenin inbox'ına bir "delivery failed" bildirimi geri döner. Benzer biçimde, Google Workspace veya Microsoft 365 gibi bir servise geçişte MX kayıtlarını güncellemeyi unutmak ya da yanlış öncelik değerleri girmek, e-posta akışını tamamen keser.
Geçiş döneminde hem eski hem yeni MX kayıtlarının aynı anda aktif tutulması önerilir. Yeni kayıtların dünya genelinde yayıldığını doğruladıktan sonra eski kayıtlar kaldırılabilir. Bu adım atlandığında bazı e-postaların eski sunucuya gittiği, yeni sunucuya geçişin ise tamamlanmamış göründüğü durumlarla karşılaşılabilir.
CNAME Kaydı: Takma Ad Yönlendirmesi
CNAME (Canonical Name) kaydı bir alan adını başka bir alan adına yönlendirir. A kaydından farkı şudur: CNAME bir IP adresi değil, başka bir domain adı döndürür. DNS sistemi bu hedef domain adını ayrıca çözerek nihai IP adresine ulaşır.
Yaygın kullanım senaryoları arasında www.example.com adresini example.com adresine yönlendirmek, bir alt domaini CDN sağlayıcısının verdiği adrese bağlamak veya bir SaaS platformunun kurulum adımlarında istediği alt domain tanımlamasını yapmak yer alır. Birçok üçüncü taraf servis, entegrasyon için belirli bir alt domaine CNAME kaydı eklemenizi talep eder.
CNAME'in kritik kısıtlaması kök domain (apex domain) için geçerlidir: example.com → başka bir domain adı biçiminde doğrudan CNAME tanımlanamaz. Bu sınır DNS standardından (RFC 1034) kaynaklanır. Bazı DNS sağlayıcıları bu durumu aşmak için ALIAS veya ANAME gibi tescilli kayıt türleri sunar; bu kayıtlar dışarıya CNAME gibi görünür, içeride ise A kaydı gibi çözümlenir. Kök domain için CNAME denemesi başarısız olduğunda, kaydın gerçekte ne döndürdüğünü DNS Lookup aracıyla sorgulayarak kaynağı hızla tespit edebilirsiniz.
NS Kaydı: Yetkili Sunucu Tanımlaması
NS (Name Server) kaydı, bir domain için hangi DNS sunucularının yetkili (authoritative) olduğunu tanımlar. DNS sorgusu geldiğinde sistem önce bu kaydı bulur; ardından soruyu yanıtlayacak yetkili sunucuya yönlenir ve asıl sorguyu oradan alır.
Domain satın aldığınızda registrar size varsayılan NS sunucuları atar. DNS yönetimini başka bir sağlayıcıya taşımak istediğinizde — örneğin farklı bir DNS hizmetine geçiş yaparken — NS kayıtlarını registrar panelinden güncellemeniz gerekir. Bu işlem yalnızca DNS sunucusunda değil, domain kayıt sistemi (registry) seviyesinde de işleneceğinden, değişikliğin yayılması diğer kayıt türlerine kıyasla daha uzun sürebilir.
NS değişikliği sırasında bir geçiş penceresi oluşur: bazı kullanıcılar eski sunucuya, bazıları yeni sunucuya yönlendirilir. Bu örtüşme birkaç saatten kırk sekiz saate kadar uzayabilir. Geçiş öncesinde yeni sağlayıcıdaki tüm kayıt yapısını eksiksiz hazırlamak, bu süreçte yaşanabilecek kesintileri en aza indirir. NS değişikliğini başlatmadan önce yeni ortamda A, MX ve TXT kayıtlarının doğru tanımlı olduğunu test etmek kritik önem taşır.
TXT Kaydı: Doğrulama ve E-posta Güvenliği
TXT kaydı, alan adına metin tabanlı bilgi eklenmesini sağlar. İlk tasarlandığında yalnızca insan tarafından okunabilir notlar içindi; zaman içinde domain doğrulama ve e-posta güvenlik protokollerinin temel bileşeni haline geldi.
En sık kullanıldığı alan olan domain doğrulama: Google Search Console, Google Workspace, Microsoft 365 ve benzeri servisler, domain sahipliğini kanıtlamak için belirli bir değer içeren TXT kaydı eklemenizi ister. Bu kayıt herhangi bir yönlendirme veya trafiği etkileyen işlev taşımaz; yalnızca kimlik doğrulama amacıyla mevcuttur.
SPF (Sender Policy Framework), hangi IP adreslerinin bu domain adına e-posta göndermeye yetkili olduğunu tanımlar. v=spf1 include:_spf.google.com ~all formatında bir değer alır ve TXT kaydı olarak yayımlanır. Bir domain için yalnızca tek bir SPF TXT kaydı tanımlanmalıdır; birden fazla SPF kaydı bazı alıcı sunucularda iletim sorunlarına yol açar. SPF'nin e-posta sahteciliğini nasıl önlediğini ve nasıl yapılandırıldığını SPF Kaydı Nedir? başlıklı yazımızda ayrıntılı ele aldık.
DMARC, SPF ve DKIM kontrollerinin başarısız olduğu durumda e-postanın ne yapılacağını belirler; aynı zamanda domain adına gönderilen sahtekâr e-postalar için raporlama altyapısı kurar. Değeri v=DMARC1; p=none; ile başlar ve pek çok ek parametre içerebilir.
Bir domain birden fazla TXT kaydı taşıyabilir; Google doğrulaması, SPF ve DMARC bunların tamamı aynı anda aktif olabilir. Yalnızca SPF için bu kural geçerli değildir: SPF standardı tek bir TXT kaydı gerektirir.
Kaydı Hangi Durumda Değiştirmelisiniz?
Her senaryo farklı bir kayıt türünü gerektirir. Hangi işlemin hangi kaydı etkilediğini bilmek, sorun yaşandığında nereye bakacağınızı da belirler:
| Senaryo | Düzenlenecek Kayıt |
|---|---|
| Sitenizi yeni bir sunucuya taşıyorsunuz | A kaydı (yeni sunucu IP adresi) |
| E-posta servisini değiştiriyorsunuz | MX kaydı |
| Alt domain oluşturuluyor, başka domain'e yönlendirilecek | CNAME kaydı |
| Alt domain oluşturuluyor, doğrudan IP'ye bağlanacak | A kaydı |
| DNS sağlayıcısı değiştiriliyor | NS kaydı (registrar panelinden) |
| Üçüncü taraf servis entegrasyonu (Search Console vb.) | TXT kaydı |
| E-posta gönderme yetkisi tanımlanıyor | TXT (SPF değeri) |
Değişiklik yapmadan önce TTL değerini kontrol edin. TTL, DNS önbelleğinin eski değeri ne kadar süre saklayacağını belirler. Varsayılan değer çoğu zaman 3.600 saniye (bir saat) ya da daha uzundur. Planlı bir geçişten birkaç saat önce TTL'yi 300 saniyeye indirirseniz, değişiklik çok daha hızlı yayılır. Geçiş kararlı hale geldikten sonra TTL'yi eski değerine döndürebilirsiniz.
Mevcut kayıtları sorgulamak ve yayılma durumunu kontrol etmek için DNS Lookup aracını kullanabilirsiniz. A, AAAA, MX, TXT, CNAME ve NS kayıtlarını ayrı ayrı sorgulayabilir; hangi sunucudan ne döndürüldüğünü görebilirsiniz. Özellikle NS veya MX değişikliklerinin ardından yayılma durumunu doğrulamak, olası sorunları erken tespit etmenizi sağlar.
Her kayıt türünün farklı bir yayılma süresi vardır. A ve CNAME kayıtları genellikle birkaç dakika ile birkaç saat içinde güncellenir. NS değişikliklerinin registry seviyesinde de işlenmesi gerektiğinden bu süreç daha uzun sürebilir. Bir değişiklik sonrasında ne kadar beklemeniz gerektiğini tahmin ederken kayıt türünü ve TTL değerini birlikte göz önünde bulundurun.