DNS Kayıtları A’dan Z’ye: A, AAAA, CNAME, MX, TXT, SRV, CAA ve Sizi Yakan O Küçük Hatalar

Giriş: O Küçücük Harfler Neden Bizi Bu Kadar Yoruyor?

Hiç web sitenizin açılmadığı bir sabaha uyandınız mı? Ben bir gün ofiste kahvemi almış, keyifle güne başlıyorum derken bir müşteriden mesaj geldi: “Site yok.” İlk tepki sunucuya baktım, her şey yolunda. Sonra ağ trafiğine göz attım, o da temiz. Biraz daha kurcalayınca mesele dönüp dolaşıp DNS kayıtlarına geldi. Meğer bir CNAME kaydı yanlış yerde duruyor, bir A kaydının süresi bitmiş, MX de başka bir yere bakıyor. O gün düşündüm ki, bu küçük harflerin ardındaki dünyayı konuşmanın tam zamanı.

Bu yazıda DNS’i bir rehber gibi, ama samimi bir sohbet tadında ele alacağız. A ve AAAA ile başlayan temel adreslendirme işinden, CNAME ile alan adlarını birbirine bağlamaya, e-postaların kalbi olan MX kayıtlarından güveni artıran TXT tabanlı doğrulamalara kadar gideceğiz. SRV ile servislerin yerini işaret etmeyi, CAA ile sertifika otoritelerine sınır çizmeyi konuşacağız. Bir de en çok yapılan hataları, yani bizi sabah sabah terleten o ufak aksaklıkları nasıl önleyeceğimizi anlatacağım. Hadi birlikte katman katman açalım.

DNS’i Hikaye Gibi Düşünmek: Yol Tarifinden Daha Fazlası

DNS’i ilk öğrendiğimde aklımda canlanan görüntü, mahallede adres soran birine yol tarif etmek gibi olmuştu. Biri “example.com nerededir?” diye soruyor; isim sunucuları da “Şu IP’ye sap, sonra dümdüz ilerle” diye cevap veriyor. Basit ama etkili. Mesela şöyle düşünün: Bir restoran arıyorsunuz, ama elinizde sadece adı var. DNS, o ismi bir konuma çeviriyor. Bu konum da çoğu zaman bir IP adresi oluyor. İşte A ve AAAA kayıtları burada devreye giriyor.

Bir noktada DNS sadece adres vermez; “Bu e-postayı nereye teslim edeceğiz?”, “Bu servisin kapısı kaç numara?”, “Bu alan adı için sertifika kime verilebilir?” gibi sorulara da cevap üretir. Her kayıt türü, bu sorulardan birine ses verir. Asıl mesele, her birini doğru yerde, doğru amaçla kullanmak.

DNS’i gözünüzde büyütmeyin. Evet, arka planda önbellekler, TTL’ler, yetkili sunucular ve çözümleyiciler arasında küçük bir dans var. Ama mantık değişmez: İsimden anlamlı bir bilgiye gitmek. Bu yolculuğu ne kadar temiz ve anlaşılır kurgularsanız, siteniz de o kadar sorunsuz çalışır.

İşin temelini sağlam koymak için bazen resmi kaynaklara bakmak da iyi gelir. DNS kayıt tiplerinin kapsamlı listesini merak ederseniz, IANA üzerinde tanımlı kaynak kayıt türlerine dair referansı not düşebilirsiniz. Ama endişelenmeyin, burada işleri sadeleştirerek anlatacağız.

A ve AAAA: Adresin Temeli, İmzanın Klasik ve Modern Hali

A kaydı en tanıdık olanı. Bir alan adını IPv4 adresine işaret eder. “example.com şu 93.184.216.34 adresinde” demek gibi. AAAA kaydı ise aynı mantığı IPv6 için kurar. Hani yeni ve geniş adres havuzu diye bildiğimiz o uzun, iki nokta üst üste ayrılmış adresler var ya, işte onlar. Bir müşterimin sitesinde performans sorununu çözdüğümüz bir projede, sadece IPv6’yı da aktif etmek bile dünya genelinden gelen ziyaretçilerin gecikmesini hissedilir şekilde azalttı. Doğrudan mucize beklemeyin, ama doğru yapılandırma fark yaratır.

Mesela şöyle düşünün: Evinizin iki kapısı var. Biri eski ve dar, diğeri geniş ve yeni. Eski kapıdan hâlâ pek çok kişi geliyor; çünkü mahalle öyle alışmış. Yeni kapının avantajı büyük kalabalıkları daha rahat alması. A ve AAAA bu iki kapı gibi. İkisini de açık tutmak, çoğu senaryoda akıllıca bir tercih.

Burada küçük bir parantez açayım. IPv4 adreslerinin kıymeti artık altın gibi. Adres bulmak zor, fiyatlar arttı. Bu konuyu merak ediyorsanız, IPv4 adres fiyatlarının neden yükseldiğini ve pratik çözüm yollarını anlattığım rehberi de okumanızı öneririm. IPv6’yı devreye almak, uzun vadede rahat etmenizi sağlar.

A ve AAAA kayıtlarıyla ilgili sık yapılan bir hata, aynı isim için birden çok IP verip “yük dengeleme işini DNS yapsın” demek. DNS bunu bir yere kadar yapar; ama bir sunucu çökerse hâlâ o IP’yi döndürebilir. Kısacası, DNS’i canlı bir trafik polisi gibi görmek riskli. Gerçek yük dengeleme gerekiyorsa, bunun için ayrı bir katman kurgulamak gerekir.

Bir de TTL meselesi var. Çok düşük TTL koyarsanız, sürekli sorgu trafiği yaratır, çok yüksek koyarsanız değişiklikler geç yayılır. Yeni IP’ye geçiş yaparken TTL’i önce düşürüp, değişikliği yaptıktan sonra yeniden yükseltmek pratik bir yaklaşımdır. Bunu bir taşınma planı gibi görün; önce kolileri indirip çıkarma mesafesini kısaltır, taşınma bitince normal düzene dönersiniz.

CNAME ile Alanları Birbirine Bağlamak ve MX ile E-Postayı Yolda Kaybetmemek

CNAME kayıtları, “Bu ismin cevabı aslında başka bir isimde” demenin yolu. Mesela www adresinizi kök alan adınıza ya da bir CDN adresine yönlendirmek istersiniz. Bir müşteride www için CNAME’i CDN’e verdik, kök alan da A/AAAA ile kendi IP’sine bakıyordu. Böylece CDN değiştiğinde sadece CNAME’in hedefini güncelledik, başka hiçbir şeye dokunmadık. Temiz, düzenli ve güvenli bir yaklaşım.

Ancak bir kural var: Kök alan adı (örneğin example.com) üzerinde CNAME olmamalı. Çünkü kökte NS ve SOA gibi kayıtlar da bulunmalı ve CNAME bu yapıyı bozar. O yüzden CNAME’i alt alan adlarında kullanmak en sağlıklı yöntem. Ayrıca aynı isimde hem CNAME hem de başka kayıtlar olmasın, birbirlerini ezerler.

MX kayıtları e-postanın pusulası. “Bu alanın e-postaları şu sunucuya teslim edilir” diye yazar. MX’i yanlış bir yere gösterdiğinizde e-postalarınız ya gecikir ya da hiç gelmez. Bir keresinde basit bir yazım hatası yüzünden e-postalar günlerce başka diyarlarda dolaştı. Çözüm, heceleme değil; disiplin. Hedefi kontrol etmek, öncelik değerlerini doğru kurgulamak ve test etmek.

MX kurarken genelde birkaç sunucu tanımlanır. Aynı isimle farklı öncelikler vererek birincil ve yedekler belirlenir. Burada kritik nokta, yedek MX’in gerçekten e-posta kabul edebilmesi. Sadece DNS’e yazmak yetmez; yedek sunucunun kapıları da doğru açılmış olmalı.

E-postanın dünyası MX ile bitmiyor. Kimlik doğrulama ve spam filtrelerinden sağ salim geçmek için TXT kayıtlarıyla SPF, DKIM, DMARC gibi politikalar eklemek gerekir. Bunun detayını birazdan açacağım ama şimdiden ipucu olsun: SPF, DKIM, DMARC ve rDNS ile e-posta teslim edilebilirliğini adım adım yükseltmek için hazırladığımız rehber bu işte çok yardımcı olur.

TXT, SPF, DKIM, DMARC: Kayıtlara Küçük Notlar Bırakıp Güveni Arttırmak

TXT kayıtları alan adınıza küçük notlar düşmenin en esnek yolu. Eskiden sadece bilgi yazılırdı, şimdi e-postadan doğrulamaya, site sahipliğini kanıtlamaktan güvenlik politikalarına kadar her şey burada. En sık gördüklerimiz SPF, DKIM, DMARC ve bazı servis doğrulamaları. Hepsinin ortak amacı, “Bu alan adı arkasındaki kişi hakkını doğru kullanıyor mu?” sorusuna net bir yanıt vermek.

SPF, “Bu alan adına ait e-postalar şuradaki sunuculardan çıkabilir” der. Basit görünür ama yanlış yazıldığında e-postalarınız dışarıda kalır. Mesela iki ayrı SPF satırı koyarsanız çalışmaz; tek satırda birleştirmeniz gerekir. İçine IP aralıkları, başka alanların SPF’lerine referanslar ve en sonda bir sonuç politikası yazarsınız. -all çok serttir, sahte gönderenleri keser ama yanlış yapılandırılmış meşru e-postaları da dışarı atabilir. ~all daha yumuşaktır, izler ve raporlar, toparlanana kadar nefes aldırır.

DKIM, e-postalara bir imza ekler. Özel anahtarla imzalanır, alıcı taraf DNS’teki TXT kaydından public key’i alıp doğrular. İlk kurduğum DKIM’lerden birinde anahtarı yanlış yerde aradığım için saatler harcadım. Çözüm yine sistematik yaklaşım: Seçici adı (selector), alan adı ve TXT kaydındaki uzun anahtarın eksiksiz olduğundan emin olmak.

DMARC ise olayı politika seviyesine taşır. “SPF ve DKIM uyumlu mu, kimlik eşleşiyor mu, sorun olursa ne yapalım?” sorularına yanıt verir. Raporlama adresleriyle neler olup bittiğini izlemek şahane bir kontrol sağlar. Başlangıçta izleme modunda tutup veriyi görmek, sonra adım adım sıkılaştırmak genelde en sağlıklı yöntem.

TXT kayıtlarını sadece e-posta için kullanmıyoruz. Bazı servisler site sahipliğini doğrulamak için alan adınıza bir TXT kaydı eklemenizi ister. Bu kaydı belirli bir süre tutup sonra kaldırabilirsiniz, ama kaldırmadan önce servisin gerçekten doğrulamayı tamamladığından emin olun. Aksi halde tekrar en başa dönersiniz.

Bir de pratik bir ayrıntı: TXT kayıtları bazen uzun oluyor ve DNS arayüzleri satır sonlarını farklı yorumlayabiliyor. Bölmeli yazmanız gerekiyorsa doğru yerlerden bölün, gereksiz tırnak işaretleri ya da eksik boşluklar hatalara yol açar. Küçük gibi görünen bu ayrıntı, saatlerinizi geri kazandırır.

Tüm bu e-posta ayarlarını yaptıktan sonra bile iş bitmiyor. İstemeden spam kapılarına düşmemek için sunucu tarafında güvenlik başlıkları, TLS ayarları, geri çözümleme gibi parçalar da işin içinde. Güvenlik tarafına meraklıysanız, HTTP güvenlik başlıklarını doğru uygulama rehberine göz atmak, genel güvenlik kültürünüze de katkı sağlar.

SRV: Servisin Yeri ve Kapısı; CAA: Sertifika Otoritelerine Sınır Çizmek

SRV kayıtları biraz daha niş, ama yerini buldu mu hayati. “Bu servis şu adreste, şu porttan hizmet veriyor” demek için kullanılır. Örneğin anlık mesajlaşma, VoIP, bazı kurumsal uygulamalar SRV’den beslenir. Bir projede, istemciler farklı konumlardaki sunuculara bağlanmakta zorlanıyordu. SRV ile servis yerlerini tanımlayıp öncelik ve ağırlıkları düzenledik, bağlantılar kendine geldi. İyi kurgulanmış SRV, karmaşık ağlarda pusula gibidir.

SRV’nin formatında servis adı, protokol, hedef ve port gibi bileşenler var. İlk bakışta göz korkutabilir, ama mantık basit. Servisin adını doğru yazmak, protokolü net belirtmek ve hedefte gerçekten o servisin dinliyor olduğundan emin olmak yeterli. Hedef kayıtları çoğunlukla A/AAAA veya CNAME ile çözümlenir; zincirin halkaları sağlam olmalı.

CAA kayıtları ise alan adınız için hangi Sertifika Otoritelerinin sertifika verebileceğini sınırlar. Özellikle otomatik sertifika süreçlerinin yaygınlaştığı dönemde, CAA beklenmedik sertifika taleplerini engellemekte güçlü bir araç. Bir keresinde üretim alanında istemeden test otoritesinden sertifika istenmişti; CAA politikası sayesinde red alıp fark ettik. Bu küçücük kayıt büyük bir hatayı önledi.

CAA yazarken “issue”, “issuewild” ve “iodef” gibi parametrelerle politika ve bildirim ayarlarsınız. Yanlış değil, eksik CAA bile bazen beklenmedik engellere neden olabilir. O yüzden sertifika yenileme süreçlerinden önce CAA’nın güncel olduğuna bakmak iyi bir alışkanlık.

CAA ve sertifika dünyasına giriş için üretici dokümanları kısa yoldur. Pratik bir başlangıç isterseniz, Let’s Encrypt’in CAA rehberi konuyu sadeleştirir. DNS’in büyük resmini hatırlamak için de DNS nedir sorusuna anlaşılır bir bakış faydalı olabilir.

Yaygın Hatalar: Ufak Dokunuşlarla Büyük Problemleri Önlemek

İtiraf edeyim, DNS’te en çok can yakan hatalar genelde “küçük ayrıntılar.” Bir harf fazlası, yanlış alt alan, TTL’in uygunsuz değeri ya da aynı isimde çakışan kayıtlar. Mesela aynı isim için hem CNAME hem A yazmak, trafikte iki tabela asmak gibi; biri düz diyor, diğeri sağ. Çözüm basit: İsim başına tek anlam, tek kayıt türü. Geri kalanı alt alanlara dağıtın.

Bir diğer klasik yanlış, TTL yüzünden değişikliklerin görülmemesi. “Ben düzelttim ama bende açılıyor, müşteride açılmıyor” cümlesini çok duydum. Çoğu zaman önbellekler henüz yeni kaydı almamıştır. Kritik anlarda önce TTL’i düşürmeyi, geçişler tamamlanınca eski, makul bir seviyeye çekmeyi unutmayın. Hem çözümleyicilerin yükünü hem de bekleme süresini dengelersiniz.

MX ve TXT tarafında yazım hataları çok görülür. Alan adının sonuna nokta koyulması gereken yerler, gereksiz tırnak işaretleri, birden fazla SPF kaydı gibi. Pratik yol, tek tek kontrol etmek ve mümkünse bir doğrulama aracıyla test etmek. Değişiklikten sonra gerçek bir e-posta gönderip almayı denemek de paha biçilemez.

“Subdomain’lerde aynı politikayı mı uygulayayım?” sorusu da sık gelir. Cevabı her zaman aynı değil. Örneğin mail.example.com için farklı bir SPF kuralı mantıklı olabilir. Ama kök alan adında DMARC varken alt alanları kapsayıp kapsamadığını gözden geçirin. Küçük bir uyumsuzluk yüzünden meşru e-postaları kaybetmek istemezsiniz.

Güvenlik tarafında ise DNS’i tek başına yeterli sanmak hatalı. Dışarıdan gelen saldırılara karşı DNS seviyesinde bazı korumalar işe yarar, ama işin sadece bir parçasıdır. Konu ilginizi çekiyorsa, DDoS saldırılarına karşı pratik korunma yöntemlerini anlattığım yazı, DNS’in yerine oturmasını kolaylaştırır. DNS sağlam, ağ sağlam, uygulama sağlam; zincirin her halkası birbirini güçlendirir.

Bir de bellek tazelemek için küçük alışkanlıklar edinin: Değişiklikleri kayıt altına alın, hangi gün ne yaptığınızı kısa notlarla yazın, yetkili isim sunucuları ile panelinizin senkron olduğundan emin olun. Ve en önemlisi, bakım pencereleri belirleyin. Acil olmayan değişiklikleri trafiğin düşük olduğu saatlere saklamak, sürprizleri azaltır.

Bazı projelerde DNS değişiklikleri ile uygulama ayarları birbirine karışıyor. Servis adreslerini SRV’ye taşıyıp uygulamayı buna göre okur yapmak, ileride taşınmaları çok kolaylaştırıyor. Ayrıca sertifika yenilemeleri arifesinde CAA kontrolü yapmak, gece yarısı şaşkınlıklarını önlüyor. Küçük bir kontrol listesi oluşturun, her değişimde üzerinden geçin; farkı hissedersiniz.

DNS Değişikliklerini Test Etmek: Kuru Teori Değil, Canlı Prova

Bir müşteride, yeni bir CDN’e geçişte sadece CNAME hedefini değiştirdik ve teoride her şey doğruydu. Ama bazı ülkelerden erişim yavaşladı. Sorun, CDN tarafında coğrafi dağıtım politikalarının farklı olmasıydı, DNS’te değil. Yine de test sürecinde kullandığımız yöntemler hatayı hızlı bulmamızı sağladı. Birkaç basit adım iş görür: Değişiklikten önce ve sonra dig ya da nslookup ile çözümlemeyi kontrol edin, TTL’i aklınızda tutun, farklı ağlardan sorgu yapın ve mümkünse birkaç gerçek kullanıcıdan geri bildirim alın.

E-posta tarafında da durum benzer. SPF/DMARC güncellemesinden sonra hemen bir deneme e-postası gönderin, başlıklara bakın. DKIM imzası düşmüş mü, DMARC uyumu var mı? Sorunu teoride değil, pratikte yakalamak daha sağlıklıdır. Bir de geri dönüş adreslerine raporları gönderip gerçekten rapor alabildiğinizi doğrulayın.

Güvenlik ekibiyle koordinasyon önemli. DNS’i değiştirip uygulama ekibine haber etmezseniz, firewall ya da TLS ayarları yüzünden beklenmedik taşlar yola çıkabilir. Bu yüzden DNS’e dair değişiklikleri bir değişim planı içine alın. Öncesi, sırası ve sonrası net olursa, haftalar sonra “Bunu kim yapmıştı?” sorusunu sormazsınız.

Bu aşamada, genel web güvenliğiyle DNS’in nasıl el sıkıştığını görmek de faydalı. Mesela HSTS başlığı ile TLS kullanımını zorunlu hale getirirken, CAA ile sertifika kaynağını sınırlamak uyumlu bir ikili olur. İlgilenenler için HTTP güvenlik başlıklarını doğru uygulama rehberi burada da güzel bir arka plan sunuyor.

Küçük Bir Yol Haritası: Hangi Kayıt Ne Zaman?

Özetle düşünelim. Siteyi bir IP’ye bağlayacaksanız A ve AAAA, alan adlarını birbirine zincirlemeniz gerekiyorsa CNAME, e-posta rotasını tanımlamak için MX, e-posta güvenini artırmak ve doğrulama amaçları için TXT; servislerin kapısını ve yerini göstermek için SRV, sertifika otoritelerine sınır koymak için CAA. Bu kadar sade olunca kafada yer ediyor. Ama her projenin farklı olduğunu da unutmayın; kimi yerde AAAA şart, kimi yerde CAA hayati, kimi yerde SRV olmazsa olmaz değil.

Bir geçiş planı yaparken önce riskleri toplayın. Trafiğin en yoğun olduğu saatleri, kritik müşterileri, geri dönüş kanallarını listeleyin. Sonra DNS değişikliklerini adım adım yazın: TTL’i düşür, yeni kaydı ekle, testi yap, eskiyi kaldır, TTL’i yükselt. Bu kadar. Önceden yazılmış bir senaryo, anlık panikleri söndürür.

E-posta özelinde SPF/DKIM/DMARC üçlüsünü birlikte düşünmek, güvenilirlik ve teslim edilebilirlik için büyük fark yaratır. İlgili detayları bir arada görmek isterseniz, adım adım e-posta teslim edilebilirliği rehberi iyi bir ek kaynak olur. DNS’in tek başına mucize yaratmadığını, ama doğru kurulduğunda birçok mucizeye kapı açtığını görmek hoşunuza gidecek.

Son bir not da donanım ve ağ açısından gelsin. Eski bir veri merkezinden yeni bir bulut sağlayıcısına taşınırken DNS çoğu zaman son dokunuş olur. Oysa planın en başında düşünülmesi gerekir. Adresler, sertifikalar, servis noktaları, hepsi DNS’in küçük dünyasında birer imza bekler. Bu imzayı ne kadar temiz atarsanız, taşınma o kadar sessiz olur.

Kapanış: DNS, Sessiz Kahraman

DNS’i bazen elektrik tesisatına benzetiyorum. Her şey çalışırken kimse adını anmıyor, bir kesinti olunca ilk ona bakılıyor. Doğru yapılandırılmış A/AAAA kayıtlarıyla başlayan yolculuk, CNAME ile çevik yönlendirmelere, MX ve TXT ile güvenilir e-postalaşmaya, SRV ile servis keşfine ve CAA ile sınırları belirlemeye uzanıyor. Küçük hatalar büyük sorunlar yaratabiliyor; ama küçük alışkanlıklar da büyük konfor sağlıyor.

Pratik önerileri cebinizde tutun: Değişikliklerden önce TTL’i planlayın, aynı isimde çakışan kayıtlar yazmayın, e-posta doğrulamalarını tek tek test edin, CAA’yı sertifika yenilemelerinden önce kontrol edin, SRV’nin hedeflerinde servislerin gerçekten dinlediğini doğrulayın. Ve hepsinden önemlisi, yaptığınız işlerin bir izini bırakın. Umarım bu yazı kafanızdaki düğümleri biraz çözdü. Sorularınız olursa not alın, bir sonraki projede birlikte üzerinden geçeriz. Bir dahaki yazıda görüşmek üzere; DNS sakin olunca, biz de sakiniz.