• Home
  • Alan Adı
  • DNS Kayıtları Nedir? A, AAAA, CNAME, MX, TXT ve SPF Kayıtları
dns-kayitlari-nedir-a-aaaa-cname-mx-txt-ve-spf-kayitlari

DNS Kayıtları Nedir? A, AAAA, CNAME, MX, TXT ve SPF Kayıtları

Sharing is caring!

DNS Kayıtları Nedir ve Neden Bu Kadar Önemli?

Bir alan adı satın aldığında aslında yaptığın şey, internette bir adres kiralamak. Ancak bu adresin gerçekten çalışabilmesi için, alan adının hangi sunucuya, hangi IP adresine, hangi e-posta servisine gideceğini birilerinin söylemesi gerekiyor. İşte bu işi yapan yapı DNS kayıtları. Yani DNS kayıtlarını, alan adın için hazırlanmış ayrıntılı bir yol haritası gibi düşünebilirsin.

Projelerde mimari tasarım yaparken ya da yeni bir web uygulamasını yayına alırken en çok zaman harcadığım kısımlardan biri DNS tarafı oluyor. Çünkü küçük bir A kaydı hatası, yanlış bir MX kaydı veya eksik bir SPF kaydı; web sitenin açılmamasına, maillerin spam’e düşmesine veya hiç ulaşmamasına sebep olabiliyor. Üstelik bu hataların çoğu basit, ama etkisi çok büyük.

Bu yazıda A, AAAA, CNAME, MX, TXT ve SPF kayıtlarını tek tek ele alacağım. Hem teknik olarak ne olduklarını hem de gerçek senaryolarda nasıl kullanman gerektiğini, nerede hata yapıldığını sade bir dille anlatacağım. Eğer DNS yönetimi konusunda bir üst seviyeye çıkmak istiyorsan, bu rehberi temel referansın olarak düşünebilirsin. Daha ileri seviye yönetim adımları için ayrıca hazırladığım DNS kayıtları A’dan Z’ye yönetim rehberi yazısına da göz atmanı öneririm.

DNS Nasıl Çalışır? Kısaca Mantığını Oturtalım

DNS (Domain Name System), alan adlarını IP adreslerine çeviren bir sistem. Tarayıcıya berkaybulut.com yazdığında tarayıcı, “Bu alan adının IP adresi ne?” diye DNS sunucularına soruyor. DNS de kayıtlarına bakıp, “IP adresi şudur” diye yanıt veriyor.

Bu süreçte şu temel kavramlar devreye giriyor:

  • Alan Adı (Domain): Örneğin ornekdomain.com.
  • DNS Sunucusu: Alan adına ait kayıtların tutulduğu sunucu.
  • Kayıt Tipi: A, AAAA, CNAME, MX, TXT, SPF gibi, her biri farklı amaç için kullanılıyor.
  • TTL (Time To Live): Kayıdın önbellekte ne kadar süre tutulacağını belirleyen değer.

DNS kayıtları, alan adını hangi servise yönlendireceğini belirler. Web sitesi, e-posta, alt alan adları (subdomain), doğrulama ve güvenlik mekanizmaları; hepsi bu kayıtlar üzerinden çalışır. DNS yapısını anlamak, hem alan adı ile hosting ilişkisini doğru kurmak hem de sorun olduğunda hızlı teşhis koymak için kritik.

A Kaydı Nedir? IPv4 İçin Temel Taş

A kaydı (Address Record), bir alan adını doğrudan bir IPv4 adresine yönlendiren DNS kaydıdır. Örneğin, web siteni barındırdığın sunucunun IP adresi 192.0.2.10 ise, ornekdomain.com için A kaydın şöyle olur:

ornekdomain.com. 3600 IN A 192.0.2.10

Buradaki 3600 TTL değeridir ve saniye cinsindendir (1 saat). Yani DNS çözümleyicileri bu kaydı 1 saat önbellekte tutabilir.

A Kaydının En Yaygın Kullanım Senaryoları

  • Web sitesi yayına alma: Alan adını web sunucunun IPv4 adresine yönlendirmek.
  • Alt alan adları: api.ornekdomain.com gibi subdomain’leri farklı IP’lere yönlendirmek.
  • Yük dengeleme: Bazı durumlarda birden fazla A kaydı kullanarak basit round-robin yük dengeleme yapmak.

Pratik Örnek

Diyelim ki DCHost üzerindeki bir vps sunucunda uygulaman çalışıyor ve IP adresin 85.111.222.33. Alan adı panelinden şu A kaydını tanımlarsın:

@ 3600 A 85.111.222.33

Buradaki @ işareti kök alan adını (root domain) temsil eder. Artık tarayıcıya alan adın yazıldığında trafik ilgili sunucuya gider.

Sık Yapılan A Kaydı Hataları

  • Yanlış IP adresi: En klasik hata. Özellikle sunucu taşıma sonrası eski IP’nin kalması yaygındır.
  • Çok uzun TTL: Sunucu değişikliği sırasında TTL yüksekse (örneğin 86400), yeni IP’nin oturması çok uzun sürebilir.
  • Çakışan kayıtlar: Aynı isim için hem A hem CNAME oluşturmaya çalışmak (standartlara aykırı).

Sunucu taşıma, IP değişimi gibi durumlarda, önce TTL değerini düşürüp sonra IP güncellemek iyi bir pratiktir. HTTP’den HTTPS’ye geçiş rehberinde de benzer mantıkla kademeli geçiş anlatıyorum.

AAAA Kaydı Nedir? IPv6 Dünyasına Geçiş

AAAA kaydı, A kaydının IPv6 versiyonudur. Yani alan adını bir IPv6 adresine yönlendirir. IPv4 adresleri yavaş yavaş tükenirken, yeni nesil altyapılarda IPv6 ciddi anlamda önem kazanıyor.

Bir AAAA kaydı örneği şöyle olabilir:

ornekdomain.com. 3600 IN AAAA 2001:db8::1234

AAAA Kaydını Ne Zaman Kullanmalısın?

  • Sunucun IPv6 adresine sahipse ve bunu aktif kullanmak istiyorsan,
  • Modern altyapılarda (örneğin veri merkezlerinde IPv6 zorunlu veya tavsiye ediliyorsa),
  • Geleceğe dönük hazırlık yapmak ve IP adresi kıtlığı riskini azaltmak istiyorsan.

Ben yeni kurduğum sistemlerde, imkan varsa hem A hem AAAA kaydını tanımlıyorum. Böylece hem IPv4 hem IPv6 üzerinden erişim mümkün oluyor. Tabii bunun için kullandığın sunucunun gerçekten IPv6 desteği olması şart; DCHost üzerindeki bazı altyapılarda bu desteği standart veya opsiyonel olarak görebilirsin.

CNAME Kaydı Nedir? Alan Adı Yönlendiren Kayıt

CNAME kaydı (Canonical Name), bir alan adını başka bir alan adına yönlendirir. Yani IP’ye değil, bir diğer domain’e işaret eder. Özellikle alt alan adlarını yönetirken, bakım maliyetini ciddi şekilde azaltır.

CNAME Mantığı

Senin asıl web siten ornekdomain.com üzerinde olsun ve bu alan adı A kaydıyla IP’ye yönlensin. www.ornekdomain.com için ayrıca A kaydı tanımlamak yerine, şu şekilde bir CNAME oluşturabilirsin:

www 3600 CNAME ornekdomain.com.

Artık www.ornekdomain.com için bir istek geldiğinde DNS, önce bu alan adının ornekdomain.com olduğunu, sonra da A kaydı üzerinden IP’yi dönecektir.

CNAME Ne İşe Yarar?

  • Yönetimi kolaylaştırır: IP adresi değiştiğinde sadece A kaydını güncellersin, tüm CNAME’ler otomatik etkilenir.
  • Harici servisler: CDN, e-posta hizmeti, analitik aracı gibi birçok servis CNAME ile yönlendirme ister.
  • Alt alan adlarını sadeleştirir: blog.ornekdomain.com gibi subdomain’leri farklı servis sağlayıcılarına işaret edebilirsin.

CNAME ile Yapılmaması Gerekenler

  • Kök alan adında CNAME: Teknik olarak bazı DNS sağlayıcıları izin verse de, standartlara göre @ için CNAME kullanmak önerilmez.
  • Aynı isim için hem A hem CNAME: Bir hostname ya A olur ya CNAME. İkisi aynı anda olmamalı.
  • MX kaydı hedefinde CNAME: MX’in işaret ettiği alan adının A veya AAAA kaydı olmalı, CNAME olmamalı.

MX Kayıtları: E-posta Trafiğinin Kalbi

MX (Mail Exchanger) kaydı, alan adına gelen e-postaların hangi posta sunucusuna gideceğini belirler. Eğer MX kaydın yanlışsa, mail altyapın neredeyse tamamen işlevsiz hale gelir.

Temel MX Kaydı Yapısı

Basit bir MX kaydı şöyle görünür:

ornekdomain.com. 3600 IN MX 10 mail.ornekdomain.com.

Buradaki 10 değeri öncelik (priority) değeridir. Küçük sayı daha yüksek öncelik demektir. Yani 10 öncelikli sunucu, 20 öncelikli olandan önce denenir.

Birden Fazla MX Kaydı Kullanımı

Yüksek erişilebilirlik için genelde birden fazla MX kaydı kullanılır:

ornekdomain.com. 3600 IN MX 10 mail1.ornekdomain.com.
ornekdomain.com. 3600 IN MX 20 mail2.ornekdomain.com.

Böylece birincil posta sunucusu çökse bile, gönderici e-posta sunucuları ikinci sunucuya mail göndermeyi dener. Özellikle kurumsal ortamlarda, veri merkezi tarafında yedeklilik tasarlarken MX yapılandırmasını mutlaka iki veya daha fazla sunucu ile planlıyorum. Bu bakış açısını veri merkezlerinde yedeklilik neden bu kadar önemli yazımda da detaylıca ele almıştım.

MX Kaydı Sık Yapılan Hatalar

  • IP yerine hostname yazmak: MX kaydı, mail.ornekdomain.com gibi bir alan adına işaret etmeli, doğrudan IP adresine değil.
  • Hedef host için A/AAAA eksikliği: MX’in işaret ettiği hostname’in mutlaka A veya AAAA kaydı olmalı.
  • TTL değerlerinin aşırı yüksek olması: Özellikle e-posta altyapısını taşıyorsan, yüksek TTL geçiş sürecini zorlaştırır.

TXT Kayıtları: Doğrulama ve Politikaların Ortak Adresi

TXT (Text) kaydı, DNS üzerinde serbest metin tutmak için kullanılan bir kayıt türü gibi görünse de, modern dünyada kimlik doğrulama, güvenlik ve politika tanımları için yoğun şekilde kullanılıyor.

TXT Kaydının Yaygın Kullanım Alanları

  • Alan adı doğrulama: Google Search Console, e-posta servisleri veya SaaS araçları, alan adının sana ait olduğunu doğrulamak için TXT kaydı ister.
  • SPF, DKIM, DMARC: E-posta güvenliğini sağlayan bu mekanizmalar TXT kayıtları içinde tanımlanır.
  • Özel konfigürasyonlar: Bazı servisler kendilerine özel TXT formatları kullanır.

Örneğin bir doğrulama TXT kaydı şöyle olabilir:

@ 3600 TXT "google-site-verification=UzunDogurlamaKoduBurada"

SPF Kaydı Nedir? TXT İçinde Tanımlanan E-posta Güvenlik Politikası

SPF (Sender Policy Framework), alan adın adına hangi sunucuların e-posta göndermeye yetkili olduğunu tanımlayan bir mekanizmadır. Teknik olarak bir TXT kaydıdır, ama içeriği belirli bir formata sahiptir.

SPF Kaydı Örneği

@ 3600 TXT "v=spf1 ip4:85.111.222.33 include:mailservis.example ~all"

Bu SPF politikası şu anlama gelir:

  • v=spf1: SPF sürümünü belirtir.
  • ip4:85.111.222.33: Bu IP adresi bu alan adına ait mail gönderebilir.
  • include:mailservis.example: Bu alan adının SPF kaydını da kurala dahil et.
  • ~all: Diğer tüm kaynaklar için “soft fail” uygula (tamamen reddetme, ama işaretle).

SPF Neden Önemli?

  • Spam riskini azaltır: Senin alan adını kullanarak sahte mail göndermeye çalışanları tespit etmeye yardımcı olur.
  • İtibarını korur: Mail gönderim altyapının güvenli görünmesi, alıcı tarafında puanını artırır.
  • İnbox oranını yükseltir: SPF, DKIM ve DMARC üçlüsünü doğru kurduğunda, maillerinin gelen kutusuna düşme ihtimali artar.

SPF ile Yapılan Tipik Hatalar

  • Birden fazla SPF kaydı eklemek: Aynı alan adı için birden fazla SPF TXT kaydı olmamalı. Tüm kuralları tek bir satırda birleştirmelisin.
  • DNS sorgu limitini aşmak: Çok fazla include, redirect gibi mekanizma kullanmak SPF’in 10 sorgu limitini aşmasına sebep olabilir.
  • Yanlış all kullanımı: -all (hard fail) çok agresiftir; yanlış yapılandırılmışsa meşru mailleri de reddedebilir. Genelde önce ~all ile başlamak daha güvenli.

DNS Kayıtlarını Yönetirken Dikkat Edilmesi Gereken Genel İpuçları

1. TTL Stratejisini Doğru Kur

TTL, değişikliklerin ne kadar sürede yayılacağını doğrudan etkiler. Sunucu taşıma, HTTPS geçişi, e-posta altyapısı değişikliği gibi kritik operasyonlar öncesinde TTL’leri geçici olarak düşürmek iyi bir pratiktir. Özellikle HTTPS geçiş kontrol listesi tarzı planlı işlerde bu detaylar çok iş kurtarıyor.

2. Değişiklikleri Kademeli Yap

Özellikle e-posta altyapısında SPF, MX, DKIM, DMARC gibi kayıtları aynı anda kökten değiştirmek yerine kademeli olarak revize etmeyi tercih ediyorum. Böylece olası bir hata olduğunda sorunun kaynağını daha hızlı tespit etmek mümkün oluyor.

3. Güvenlik Boyutunu Unutma

DNS kayıtları, saldırganlar için de cazip bir hedef. Yanlış yönlendirilmiş bir A kaydı veya ele geçirilmiş bir DNS paneli, trafiğinin tamamen başka bir yere akmasına yol açabilir. Bu yüzden:

  • DNS yönetim panelinde mutlaka iki faktörlü doğrulama kullan,
  • Yetkisiz kişilere panel erişimi verme,
  • DNS sunucularını seçerken güvenliğe önem veren hizmetleri tercih et.

Sunucu tarafında da güvenliği ihmal etmemelisin. Bu konuda detaylı bir rehber arıyorsan, VPS sunucu güvenliği için hazırladığım uygulamalı rehber sana iyi bir başlangıç noktası olacaktır.

4. DNS ve SSL/HTTPS İlişkisini Doğru Kur

HTTPS’e geçerken DNS kayıtların, SSL sertifikan ve sunucu konfigürasyonun uyumlu çalışmalı. Yanlış IP’ye işaret eden bir A kaydı, doğru yüklenmeyen bir SSL sertifikası sonucu tarayıcıda güvenlik uyarıları görebilirsin. Bu konuyu hem SSL sertifikası türleri rehberinde hem de HTTP’den HTTPS’ye geçiş yazılarında ayrıntılı anlattım.

Gerçek Hayattan Kısa Senaryolar

Senaryo 1: Sunucu Taşıma ve A Kaydı

Bir müşterimin sitesini daha performanslı bir altyapıya almak için yeni bir Fiziksel Sunucuya geçiş yaptım. Taşıma öncesinde eski IP’ye ait A kaydının TTL değerini 3600’den 300’e düşürdüm. Tüm dosyalar ve veritabanı senkronize olduktan sonra tek bir A kaydı değişikliğiyle trafiği yeni sunucuya aktardım. DNS önbellekleri maksimum 5 dakika içinde yenilendiği için kesinti neredeyse fark edilmedi.

Senaryo 2: Mail’lerin Spam’e Düşmesi ve SPF

Başka bir projede, müşteri sürekli olarak “Gönderdiğimiz mailler spam’e düşüyor” şikayetiyle geldi. İnceleyince gördüm ki alan adında SPF kaydı yok, MX kayıtları karışık ve DKIM yapılandırılmamış. Önce düzgün bir SPF politikası tanımladım, ardından posta sunucusu için DKIM anahtarlarını oluşturdum. Birkaç gün içinde spam oranı ciddi şekilde düştü ve iletiler gelen kutusuna düşmeye başladı.

DNS Yönetimi İçin Hangi Altyapıyı Kullanmalısın?

DNS yönetimi genellikle alan adını aldığın yerde veya hosting sağlayıcında yapılır. Alan adını farklı bir firmadan, sunucunu DCHost gibi başka bir sağlayıcıdan almış olabilirsin; bu durumda yetkili DNS sunucularını hangi tarafta tutacağına bilinçli karar vermelisin.

Benim yaklaşımım şöyle:

  • Eğer proje küçük ve basitse, alan adının bulunduğu yerdeki DNS paneli çoğu zaman yeterli.
  • Daha kurumsal, yüksek trafiğe sahip veya kritik projelerde, DNS tarafında daha gelişmiş özellikler sunan servisleri ya da DCHost gibi veri merkezi odaklı yapıları tercih etmek mantıklı.
  • DNS değişikliklerine sık ihtiyaç duyuyorsan, panelin kullanılabilirliği ve otomasyona (API, Terraform vb.) uygunluğu büyük avantaj sağlıyor.

Sonuç: DNS Kayıtlarını Öğrenmek, Projelerini Kontrol Altına Almak Demek

DNS çoğu kişiye ilk bakışta karmaşık geliyor ama aslında mantığını oturttuktan sonra son derece tutarlı ve öngörülebilir bir sistem. Bu yazıda A, AAAA, CNAME, MX, TXT ve SPF kayıtlarının ne olduğunu, nerede ve nasıl kullanman gerektiğini, gerçek senaryolarla birlikte anlatmaya çalıştım. Amacım, alan adınla ilgili bir şey yapmak istediğinde “DNS tarafında ne yapmam gerekiyor?” sorusuna kendi başına yanıt verebilecek seviyeye gelmeni sağlamak.

Özellikle yeni projelere başlarken, alan adı seçiminden DNS planlamasına, sunucu ve güvenlik stratejine kadar tüm resmi birlikte düşünmek gerekiyor. Bu resmi tamamlamak için, alan adı neden bu kadar önemli sorusuna değindiğim yazıyı ve Web Hosting seçiminde dikkat edilmesi gerekenler için hazırladığım makaleleri de okumanı öneririm.

Eğer DNS kayıtlarınla ilgili spesifik bir senaryon varsa, ya da hangi kaydı nasıl kurgulayacağını tam kestiremiyorsan, önce burada anlattığım temel yapıyı uygula; sonra TTL, güvenlik ve yedeklilik tarafında ince ayara geç. Zamanla, DNS yönetiminin ne kadar güçlü bir “kontrol paneli” olduğunu sen de fark edeceksin.

Yeni Paylaşılanlar
Clear Filters

When you plan new infrastructure today—a few VPS instances, a small Kubernetes cluster, or a new SaaS platform—one of the…

Son birkaç yıldır yaptığım neredeyse her kapasite ve maliyet analizinde aynı tabloyla karşılaşıyorum: Sunucu, depolama, lisans kalemlerinin yanında artık ayrı…

Yorum Yapın

Bağlantılı Makaleler