dns-kayitlari-adan-zye-yonetim-rehberi

DNS Kayıtları A’dan Z’ye Yönetim Rehberi

Sharing is caring!

DNS Kayıtları Nedir ve Neden Bu Kadar Kritik?

Bir alan adı satın aldığınız anda, aslında sadece bir isim almış oluyorsunuz. Bu ismi doğru sunucuya, doğru e-posta hizmetine ve doğru güvenlik ayarlarına yönlendiren mekanizma ise DNS kayıtları. Yani DNS panosunda yaptığınız her değişiklik, doğrudan web sitenizin açılıp açılmamasını, e-postalarınızın ulaşıp ulaşmamasını ve hatta SEO performansınızı bile etkiliyor.

Özellikle kurumsal projelerde DNS yönetimi, proje planlama toplantılarında mutlaka konuştuğum konulardan biri. Uygulama mimarisi, veri tabanı tasarımı, ölçeklenebilirlik gibi başlıkların yanında, DNS tarafında A, CNAME, MX, TXT, NS gibi kayıtların nasıl yapılandırılacağı da netleşmeli. Çünkü yanlış bir MX kaydı yüzünden günlerce e-posta alamayan şirketler gördüm; ya da hatalı bir A kaydı nedeniyle yeni açılan sitenin arama motorlarında gereksiz yere yavaş indekslendiğine şahit oldum.

Bu yazıda, sahada aktif olarak sistem yöneten biri olarak, DNS kayıtlarını A’dan Z’ye sade bir dille anlatacağım. A, CNAME, MX, TXT ve diğer önemli kayıt tiplerinin ne işe yaradığını, hangi senaryoda hangisini kullanmanız gerektiğini ve pratikte nasıl yöneteceğinizi adım adım ele alacağız. Eğer alan adı ve <a href="https://www.DCHost.com/tr/web-hosting”>Hosting ilişkisine tam hâkim değilseniz, önce alan adı ve hosting ilişkisini anlattığım rehbere göz atmanız da faydalı olabilir.

DNS’in Temel Mantığı: Alan Adından IP Adresine

DNS’i basitleştirirsek, insanlara okunabilir alan adlarını (örneğin ornekdomain.com) makinelerin anlayacağı IP adreslerine çeviren bir telefon rehberi gibi düşünebilirsiniz. Tarayıcıya bir adres yazdığınızda şunlar olur:

  • Kullanıcının cihazı DNS sunucusuna alan adının IP adresini sorar.
  • DNS sunucusu, ilgili A (veya AAAA) kaydını bulur.
  • Buldğu IP adresine göre tarayıcı, web sunucusuna istek gönderir.

Bu süreçte devreye giren farklı DNS kayıt tipleri, alan adınızın hangi servis için nereye yönleneceğini belirler. Örneğin:

  • Web sitesi için: A / AAAA ve bazen CNAME
  • E-posta için: MX, SPF (TXT), DKIM (TXT), DMARC (TXT)
  • Hizmet keşfi için: SRV kayıtları
  • DNS delegasyonu için: NS kayıtları

DNS yapı taşlarını doğru anlarsanız, web sitenizi yeni bir sunucuya taşırken, HTTPS’e geçerken veya e-posta sağlayıcınızı değiştirirken işiniz inanılmaz kolaylaşır. Örneğin HTTP’den HTTPS’e sorunsuz geçişte sadece SSL sertifikası değil, DNS tarafında yaptığınız yönlendirmeler ve süre (TTL) ayarları da önemli. Bu konuda detaylı bir rehbere ihtiyacınız varsa HTTP’den HTTPS’e geçişte SEO kaybını önleme yazımı da inceleyebilirsiniz.

A Kaydı: Web Sitenizin Ana Adresi

A kaydı (Address Record), bir alan adını IPv4 adresine yönlendiren en temel DNS kaydıdır. Örneğin:

ornekdomain.com A 185.10.10.10

Bu, alan adınıza gelen trafiğin 185.10.10.10 IP’li sunucuya gitmesini sağlar. Yönetirken dikkat ettiğim başlıca noktalar:

  • IP adresi değiştiğinde sadece A kaydını güncellemek yeterlidir.
  • TTL (Time To Live) süresini kritik geçişlerde düşük tutarım (300 saniye gibi), stabil dönemde daha yüksek (3600–14400) kullanırım.
  • Farklı ortamlara (test, staging, prod) farklı alt alan adlarıyla A kayıtları tanımlarım: test.ornekdomain.com, stg.ornekdomain.com gibi.

Basit bir senaryo üzerinden gidelim: Mevcut sunucunuzdan daha performanslı bir altyapıya geçiyorsunuz. Taşımadan önce yeni sunucuyu hazırlayıp, IP’sini aldıktan sonra:

  1. DNS panelinde TTL’i 300 saniyeye düşürürsünüz.
  2. Yeni sunucunun IP’sini, A kaydında güncellersiniz.
  3. En fazla birkaç dakika içinde trafiğiniz yeni sunucuya akmaya başlar.

Bu tür geçişlerde DNS’in yanı sıra sunucu performansı da kritik. Sunucu tarafını optimize etmek istiyorsanız sunucu performansını artırma rehberine göz atmanız teknik açıdan güzel bir tamamlayıcı olur.

A Kaydı Yönetiminde Dikkat Edilecek Noktalar

  • Tek IP, çok alan adı: Aynı IP’ye birden fazla alan adı veya alt alan adı yönlendirebilirsiniz.
  • Yanlış IP riski: Yanlış IP girerseniz siteniz tamamen erişilemez hale gelir; bu yüzden kaydı kaydetmeden önce mutlaka IP’yi iki kez kontrol edin.
  • Geri dönüş planı: Büyük değişikliklerden önce A kaydının mevcut değerini not edin; bir sorun olursa hızlıca geri dönebilin.

CNAME Kaydı: Takma İsim ve Esnek Yönlendirme

CNAME (Canonical Name) kaydı, bir alan adını başka bir alan adına yönlendiren takma isim kaydıdır. En önemli farkı, IP’ye değil başka bir alan adına işaret etmesidir. Örneğin:

blog.ornekdomain.com CNAME sites.google.com.
cdn.ornekdomain.com CNAME ornekcdn.proje.com.

Bu sayede, arka planda IP adresleri değişse bile CNAME’in işaret ettiği hedef alan adı güncel kaldığı sürece, sizin CNAME kaydınızı değiştirmenize gerek kalmaz.

CNAME Ne Zaman Kullanılmalı?

  • Blog’u harici bir serviste tutuyorsanız (blog.ornekdomain.com gibi).
  • CDN, WAF veya DDoS koruma servisi kullanıyorsanız (www için CNAME yaygın).
  • Aynı kaynağa işaret eden birden fazla alt alan adı tanımlamak istiyorsanız.

Önemli bir nokta: Kök alan adında (ornekdomain.com) genelde CNAME kullanamazsınız; çoğu DNS sağlayıcı desteklemez. Bu yüzden kök alan adında A, alt alan adlarında CNAME tercih etmek yaygın ve sağlıklı bir pratik.

CNAME ile Sık Yapılan Hatalar

  • CNAME + diğer kayıtlar çatışması: Aynı isimde hem CNAME hem de A / MX / TXT kaydı tanımlamayın.
  • Yanlış yönlendirme zinciri: CNAME bir başka CNAME’e, o da bir başkasına gitmesin; zincir uzadıkça gecikme ve hata riski artar.
  • SSL uyumu: CNAME ile işaret ettiğiniz hedefte SSL sertifikisinin alan adınızı da kapsadığından emin olun.

MX, TXT ve E-posta İlgili Kayıtların Yönetimi

E-posta tarafında yaşanan sorunların çok büyük kısmı yanlış yapılandırılmış DNS kayıtlarından kaynaklanıyor. E-posta için en kritik kayıtlar: MX, SPF (TXT), DKIM (TXT) ve DMARC (TXT).

MX Kaydı: E-posta Trafiğinin Yöneticisi

MX (Mail Exchange) kaydı, alan adınıza gelen e-postaların hangi sunucuya gideceğini belirler. Örnek bir yapı:

ornekdomain.com MX 10 mail.ornekdomain.com.
ornekdomain.com MX 20 backupmail.ornekdomain.com.

Buradaki sayı (10, 20) öncelik değeridir; rakam ne kadar küçükse öncelik o kadar yüksektir. Yönetirken şunlara dikkat ederim:

  • MX kaydının doğrudan IP’ye değil bir host adına işaret etmesi gerekir (A kaydı olan bir isim).
  • E-posta sunucusunun IP’si değişirse, MX değil ilgili A kaydı güncellenmelidir.
  • Yedek bir MX kaydı tanımlamak, servis sürekliliği için iyi bir pratiktir.

TXT, SPF, DKIM ve DMARC: Spam Filtresi Dostu Ayarlar

TXT kayıtları, alan adınız hakkında serbest metin bilgisi tutmanızı sağlar ama pratikte en çok SPF, DKIM ve DMARC ayarlarında kullanılır:

  • SPF (Sender Policy Framework): Alan adınız adına hangi IP veya sunucuların mail göndermeye yetkili olduğunu söyler.
  • DKIM (DomainKeys Identified Mail): E-posta içeriğini kriptografik olarak imzalar; alıcı, mailin sizden gelip gelmediğini doğrulayabilir.
  • DMARC: SPF/DKIM geçmezse, alıcının ne yapması gerektiğini (reddet, spam’e at, raporla vb.) belirtir.

Örnek bir SPF kaydı:

ornekdomain.com TXT "v=spf1 a mx ip4:185.10.10.10 -all"

Birkaç pratik not:

  • Tek bir alan adı için birden fazla SPF kaydı tanımlamayın; hepsini tek bir TXT kaydında birleştirin.
  • E-posta sağlayıcınızı değiştirdiğinizde, mutlaka SPF, DKIM ve DMARC kayıtlarını da güncelleyin.
  • Uzun TXT kayıtlarında boşluk, tırnak gibi karakterleri kurallara uygun yazmaya özen gösterin; ufak bir karakter hatası bile SPF’i geçersiz kılar.

E-posta güvenliği ve sunucu tarafındaki önlemler, DNS ayarlarıyla birlikte düşünülmeli. Sunucu katmanında neler yapmanız gerektiğini merak ediyorsanız, web hosting güvenliği için öneriler başlıklı yazım iyi bir başlangıç noktası olabilir.

Diğer Önemli DNS Kayıtları: NS, AAAA, SRV, PTR

A, CNAME, MX ve TXT günlük hayatta en çok dokunduğumuz kayıtlar ama tamamı bu kadar değil. Özellikle kurumsal projelerde aşağıdaki kayıtlarla da sık sık uğraşıyorum.

NS Kayıtları: Yetkili DNS Sunucuları

NS (Name Server) kayıtları, bir alan adı için yetkili DNS sunucularını belirtir. Genelde Domain Kayıt firması veya barındırma sağlayıcısı tarafından otomatik atanır. Örneğin:

ornekdomain.com NS ns1.dnsornek.com.
ornekdomain.com NS ns2.dnsornek.com.

NS kayıtlarını, DNS yönetimini başka bir panele taşımak istediğinizde güncellersiniz. Örneğin alan adınız bir yerde, DNS’inizi başka bir profesyonel sağlayıcıda tutmak istediğinizde. Ciddi projelerde ben genelde kendi yönettiğim DNS sunucularını veya kullandığım sağlayıcının (örneğin DCHost gibi kurumsal altyapıya sahip firmaların) sunduğu gelişmiş DNS panellerini tercih ediyorum.

AAAA Kaydı: IPv6 Adresleri

AAAA kaydı, A kaydının IPv6 versiyonudur. IPv6 kullanıyorsanız:

ornekdomain.com AAAA 2a03:XXXX:...:1234

Hem A hem AAAA kaydı tanımlarsanız, istemciler ağ yapılandırmalarına göre uygun olanı kullanır. Özellikle modern veri merkezlerinde ve yeni projelerde IPv6 desteğini aktif etmeye çalışıyorum; hem geleceğe dönük hem de bazı ağlarda ek performans ve güvenilirlik avantajı sağlayabiliyor.

SRV Kaydı: Hizmet Keşfi

SRV (Service) kayıtları, belirli bir servisin hangi sunucu ve portta çalıştığını belirtir. En çok VoIP, chat, bazı kurumsal uygulamalar ve Microsoft servislerinde karşımıza çıkar. Örneğin:

_sip._tcp.ornekdomain.com SRV 10 60 5060 sipserver.ornekdomain.com.

Buradaki sıralama:

  • 10: Öncelik
  • 60: Ağırlık
  • 5060: Port
  • sipserver.ornekdomain.com: Hedef sunucu

PTR Kaydı: Ters DNS

PTR (Pointer) kaydı, IP adresini alan adına çeviren ters DNS kaydıdır. Genelde IP bloklarını yöneten taraf (veri merkezi, ISP) tarafından yönetilir. Özellikle mail sunucuları için kritiktir; PTR kaydınız yoksa birçok alıcı sunucu mailinizi spam olarak işaretleyebilir.

Örneğin 185.10.10.10 IP’si için:

10.10.10.185.in-addr.arpa PTR mail.ornekdomain.com.

Burada önemli olan, PTR kaydının işaret ettiği alan adının da A kaydıyla aynı IP’ye dönmesi. Bu uyumu her proje geçişinde mutlaka kontrol ediyorum.

DNS Yönetiminde En İyi Uygulamalar

DNS yönetimi, doğru yapıldığında fark edilmeyen; yanlış yapıldığında ise herkesi ayağa kaldıran bir iş. Yıllardır edindiğim tecrübeye göre şu pratikler hayat kurtarıyor:

Değişiklik Öncesi ve Sonrası Kontrol Listesi

  • Her değişiklikten önce mevcut kayıtların ekran görüntüsünü alın veya dışa aktarın.
  • Değişiklikleri yoğun trafik saatleri dışında yapmaya çalışın.
  • Önce alt alan adlarında test edin, sonra kök alan adında uygulayın.
  • Değişiklikten sonra dig, nslookup veya benzeri araçlarla doğrulama yapın.

TTL Stratejisi: Her Zaman 300 Saniye Olmaz

TTL’i her kayıtta 300 saniye yapmak, kağıt üzerinde esnek görünse de pratikte DNS sorgu yükünü artırır ve gereksiz yere çözüm sürelerini uzatabilir. Benim izlediğim yol genelde şöyle:

  • Statik kayıtlar (NS, MX, SPF): 3600–14400 arası.
  • Sık değişecek kayıtlar (geçiş dönemi A/CNAME): 300–900.
  • Test ortamları: 60–300 (kısa süreli, kontrollü kullanım).

Versiyonlama ve Dokümantasyon

Özellikle çok alan adınız veya karmaşık bir mimariniz varsa, DNS yapılandırmasını mutlaka dokümante edin. Hangi kayıt neden var, hangi servise hizmet ediyor, sorumlu birim kim? Bunları yazılı hale getirmek, gelecekte ekip büyüdüğünde ya da outsource çalıştığınızda çok fazla zaman kazandırıyor.

Ben, DNS değişikliklerini genelde diğer sunucu değişiklikleriyle birlikte planlıyorum. Örneğin yeni bir VPS ortamı kurup servisi oraya taşıyacaksam, önce güvenlik tarafını (örneğin VPS sunucu güvenliği rehberinde anlattığım adımları) tamamlıyor, ardından DNS yönlendirmesini yapıyorum. Böylece dış dünyaya açtığım her kayıt, arka planda güvenli ve hazır bir sunucuya işaret ediyor.

Sık Yapılan DNS Hataları ve Çözüm Önerileri

DNS tarafında en sık karşılaştığım ve müşterilerin de en çok canını yakan hatalar genelde benzer:

  • Yanlış MX kaydı: E-postalar hiç gelmiyor veya “mail delivery failed” dönüyor.
  • Eksik SPF / DKIM: Gönderilen mailler alıcı tarafında spam klasörüne düşüyor.
  • DNS kayıtlarının farklı panolarda yönetilmesi: Alan adı bir yerde, DNS başka yerde, e-posta ayarları tamamen kaybolmuş.
  • Alan adı yenilemesinin unutulması: Alan adının süresi doluyor, DNS kayıtları otomatik siliniyor.

Bu sorunların çoğu, temel DNS prensiplerine hâkim olup düzenli kontrol yaparak önlenebilir. Alan adlarınızı toplu yönetiyorsanız, alan adı yönetimi için paylaştığım ipuçları da süreci ciddi şekilde kolaylaştıracaktır.

Sonuç: DNS Kayıtlarını Doğru Yönetmek Neden Oyunun Kurallarını Değiştirir?

DNS, web projelerinin çoğunda arka planda kalan ama her şeyin ayakta kalmasını sağlayan omurga. A kaydıyla sitenizin nereye işaret ettiğini, CNAME ile hangi servislere takma isim verdiğinizi, MX ve TXT kayıtlarıyla e-posta güvenliğini ve teslim edilebilirliğini, NS ve PTR kayıtlarıyla da altyapınızın güvenilirliğini tanımlıyorsunuz.

Benim yaklaşımım hep şu oldu: Projenin mimarisini çizerken DNS’i en başta masaya koymak. Hangi alan adları hangi ortamlara (test, staging, prod) gidecek, hangi e-posta servisleri kullanılacak, SSL ve HTTPS geçişlerinde hangi alt alanlar devreye girecek… Bunların hepsini projelendirdiğinizde, canlıya geçişler neredeyse sorunsuz oluyor. HTTPS tarafında da benzer bir bakış açısıyla çalışmak istiyorsanız, HTTPS geçiş kontrol listesi size iyi bir yol haritası çıkaracaktır.

Eğer DNS kayıtlarınızı şu ana kadar sadece “alan adı aldığım firmadaki varsayılan ayarlar” düzeyinde bıraktıysanız, küçük adımlarla kontrolü ele almanın tam zamanı. Önce mevcut kayıtlarınızı yedekleyin, sonra her bir kayıt tipini bu yazıyı referans alarak gözden geçirin. İhtiyaç halinde, DNS yönetimini daha gelişmiş paneller sunan güvenilir bir altyapıya (örneğin DCHost gibi veri merkezi ve sunucu tarafında güçlü olan sağlayıcılara) taşıyabilirsiniz. Doğru kurgulanmış DNS, hem performans hem güvenlik hem de SEO tarafında size uzun vadeli kazanç sağlayacaktır.

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