DNS Kayıt Hataları Web ve E-Postayı Nasıl Etkiler?
Bir web sitesi açılmıyorsa sunucu sağlıklı olsa bile DNS kayıtlarını incelemek gerekir. Yanlış hedefe giden bir CNAME, eski IP adresini içeren bir A kaydı veya hatalı MX hedefi farklı hizmetleri etkileyebilir. TTL’nin dolması kaydı yetkili sunucudan silmez; normalde önbellekteki yanıtın yeniden sorgulanmasını gerektirir. Sorunu bulmak için kaydın içeriğini, yetkili sunucuları ve istemcilerin aldığı yanıtları ayrı kontrol edin.
Bu rehberde A, AAAA, CNAME, MX, TXT, SRV ve CAA kayıtlarının görevlerini ve yanlış kullanıldıklarında oluşan sorunları ele alıyoruz. Amaç yalnız kayıt adlarını öğrenmek değil; çakışmaları, hatalı hedefleri, e-posta doğrulama eksiklerini ve geçiş sırasında beklenmedik önbellek sonuçlarını ayırt etmek. Her bölümün sonunda kontrol edilecek noktaları kendi DNS değişiklik planınıza uyarlayabilirsiniz.
DNS’i Hikaye Gibi Düşünmek: Yol Tarifinden Daha Fazlası
DNS’i, bir adın hangi kaynaklarla ilişkili olduğunu söyleyen bir rehber gibi düşünebilirsiniz. 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: IPv4 ve IPv6 Adreslerini Doğru Yayımlamak
A kaydı bir adı IPv4 adresine, AAAA kaydı IPv6 adresine eşler. Örneğin example.com için belgeleme amacıyla ayrılmış 203.0.113.10 ve 2001:db8::10 adreslerini düşünebilirsiniz; gerçek DNS ayarlarında hizmetinizin adreslerini kullanırsınız. Bu kayıtlar web uygulamasını, güvenlik duvarını veya TLS sertifikasını kendiliğinden yapılandırmaz. IP’nin doğru olması kadar hedef hizmetin o adrese gelen isteği karşılaması da gerekir.
IPv4 ve IPv6 iki ayrı erişim yoludur; IPv6’nın daha büyük adres alanı her bağlantıyı daha hızlı yapmaz. AAAA yayımlamadan önce IPv6 yönlendirmesini, dinleyen servisi, güvenlik duvarını ve HTTPS yanıtını test edin. Çalışmayan bir IPv6 adresi eklemek bazı istemcilerde gecikme veya erişim sorunu yaratabilir. İki protokol de hazırsa A ve AAAA aynı isimde birlikte bulunabilir.
IPv6 planlaması adres ihtiyacı ve ağ tasarımıyla da ilgilidir. Konunun maliyet tarafı için IPv4 adres maliyetlerini ve altyapı seçeneklerini ele alan rehbere bakabilirsiniz. AAAA eklemek, IPv4 üzerinden erişmesi gereken kullanıcıların ihtiyaçlarını tek başına ortadan kaldırmaz.
Aynı isim için birden çok A veya AAAA kaydı yayımlamak geçerlidir. Ancak standart bir adres kayıt kümesi sağlık kontrolü yapmaz ve istemcilerin trafiği eşit dağıtacağını garanti etmez. Bir IP yanıt vermediğinde o adres önbelleklerden hemen silinmez. DNS tabanlı failover kullanılacaksa sağlık kontrolü, sağlayıcının kayıt güncellemesi ve önbellek davranışı birlikte değerlendirilmelidir; gerekirse uygulama önüne ayrı yük dengeleme katmanı konur.
TTL, yanıtın tekrar sorgulanmadan önbellekte tutulabileceği süreyi saniye cinsinden belirtir. Düşük TTL daha sık sorguya, yüksek TTL ise eski yanıtların daha uzun kullanılmasına yol açabilir. Planlı IP değişiminde TTL’yi önceden düşürün ve önceki TTL kadar süre geçmesini hesaba katın; sonradan yapılan düşüş mevcut önbellekleri temizlemez. TTL, tüm kullanıcıların aynı saniyede yeni hedefe geçeceği garantisi değildir.
CNAME Takma Adları ve MX E-Posta Hedefleri
CNAME, bir adı başka bir DNS adına takma ad olarak bağlar; IP adresi, URL veya dosya yolu içermez. Örneğin www.example.com, CDN’nin verdiği hedef adına bağlanabilir. Bu bir HTTP yönlendirmesi değildir: tarayıcıdaki URL kendiliğinden değişmez ve CDN’nin asıl alan adınızı ve TLS sertifikasını desteklemesi gerekir. Hedef değiştiğinde takma adların neyi çözdüğünü yeniden kontrol edin.
Kök alan adı (zone apex), zorunlu SOA ve NS kayıtları nedeniyle standart CNAME olamaz. Aynı isimde CNAME ile A, AAAA, MX veya TXT gibi normal verileri birlikte yayımlamayın; DNSSEC’e ait ilgili metaveri istisnaları bu kuralın dışındadır. Sağlayıcıların ALIAS/ANAME veya CNAME flattening özellikleri farklı çalışabilir; kökte gerçek CNAME yerine sentezlenen adres yanıtları sunabilirler. Taşınmadan önce yeni sağlayıcının bu özelliği nasıl uyguladığını kontrol edin.
MX, alan adınıza gelen e-postayı kabul eden sunucuları belirtir. Hedef bir IP adresi veya URL değil, doğrudan A ve/veya AAAA kaydı olan sunucu adı olmalıdır; CNAME hedefi kullanmayın. Yanlış MX, posta kuyruğu, gecikme veya teslim hatası oluşturabilir. Posta sağlayıcısının verdiği hedefleri ve her hedefin gerçekten bu alan adı için posta kabul ettiğini doğrulayın.
Birden çok MX kaydında küçük öncelik değeri önce denenir; eşit öncelikli sunucular arasında seçim dağıtılabilir. Yedek MX eklemek tek başına yedeklilik sağlamaz: sunucu alan adınızı tanımalı, gerekli alıcılara posta kabul etmeli ve teslim/aktarım kuralları doğru olmalıdır. Gelen posta için MX ayarlamak, giden posta yetkisini veya teslim edilebilirliğini belirlemez.
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ı, DNS’te metin verisi yayımlar. SPF politikası, DKIM açık anahtarı, DMARC politikası ve servis doğrulama değeri farklı amaçlar taşır. Kök alan adında birden çok TXT kaydı bulunması normaldir; her uygulama kendi adındaki ve biçimindeki değeri okur. Bir doğrulama TXT’si, alan adını kullanan her kişinin veya her e-postanın güvenilir olduğunu kanıtlamaz.
SPF, gönderen sunucunun zarf göndereni (MAIL FROM) veya HELO alan adını kullanmaya yetkili olup olmadığını değerlendirir; görünen From adresini tek başına doğrulamaz. Aynı isim için yalnız bir v=spf1 politikası yayımlayın; diğer TXT kayıtları kalabilir. Include ve redirect zincirleri dahil DNS sorgusu gerektiren terimlerin toplamı değerlendirmede 10 ile sınırlıdır; aşılması permerror üretir. -all fail, ~all softfail sonucudur. ~all bir izleme veya raporlama modu değildir; alıcının kabul, karantina veya ret kararı kendi politikasına da bağlıdır.
DKIM için gönderici posta sistemi mesajı özel anahtarla imzalar; alıcı, selector._domainkey.example.com gibi bir isimdeki açık anahtarla imzayı doğrular. DNS’e anahtar eklemek, sunucuda imzalamayı kendiliğinden açmaz. Seçici adı, imzanın d= alan adı ve yayımlanan anahtar birlikte eşleşmelidir. Anahtar değiştirirken yeni imzalamayı test edin ve eski anahtarı, onunla imzalanmış iletilerin doğrulama ihtiyacı bitmeden kaldırmayın.
DMARC, mesajın görünen From alan adıyla SPF veya DKIM’de doğrulanan alan adının hizalanmasını arar. En az bir mekanizmanın hem başarılı hem hizalı olması yeterlidir; ikisinin birden geçmesi zorunlu değildir. p=none ile izleme yapıp raporları incelemek, meşru göndericileri belirledikten sonra quarantine/reject politikasına geçmek mümkündür. Rapor adreslerini ayrıca yapılandırın; her alıcı rapor göndermez ve bir test mesajından hemen rapor gelmesi beklenmez.
Bazı servisler alan adı denetimini doğrulamak için TXT kaydı ister. Kaydın yerini, değerini ve ne kadar süre tutulacağını o servisin güncel talimatından öğrenin. İlk doğrulama tamamlandı diye otomatik silmeyin: bazı servisler sürekli veya yeniden doğrulama yapar. Gereksiz kalan kayıtları ise hangi hizmete ait olduklarını belirleyip o hizmetin talimatına göre kaldırın.
TXT kaydı bir veya daha fazla karakter dizisinden oluşabilir; her parça en fazla 255 bayttır. SPF ve DKIM gibi uygulamalar aynı kayıt içindeki parçaları araya yeni boşluk koymadan birleştirir. Uzun bir politikayı ayrı SPF kayıtlarına bölmeyin. Zone dosyalarında tırnaklar sözdiziminin parçasıyken bir DNS paneli çıplak değeri isteyebilir; panelin biçimini izleyin ve yayımlanan değeri sorgulayarak kontrol edin.
E-posta teslim edilebilirliği için kimlik doğrulamanın yanında IP/alan adı itibarı, ters DNS, SMTP yapılandırması ve TLS de değerlendirilir. HTTP güvenlik başlıkları ise web yanıtları içindir; SPF veya DMARC sorununu çözmez. Web tarafındaki ayrı korumaları incelemek için HTTP güvenlik başlıklarını doğru uygulama rehberine bakabilirsiniz.
SRV: Servisin Yeri ve Kapısı; CAA: Sertifika Otoritelerine Sınır
SRV, destekleyen istemcilere bir servisin hedef adını, portunu, önceliğini ve ağırlığını bildirir. Örneğin SIP veya XMPP gibi protokollerde servis keşfi için kullanılabilir. SRV kaydı oluşturmak, herhangi bir web tarayıcısını veya uygulamayı bu kaydı okumaya zorlamaz; kullanılan protokol ve istemci açıkça SRV desteklemelidir.
SRV sahibi _servis._protokol.example.com biçimindedir; veri alanında öncelik, ağırlık, port ve hedef bulunur. Düşük öncelik önce denenir; aynı öncelikte ağırlık göreli seçim olasılığını etkiler. Hedef doğrudan A/AAAA kaydı olan bir sunucu adı olmalı, IP veya CNAME olmamalıdır. Hedefte nokta (.) kullanımı, o ad için servisin sunulmadığını belirtir. Zone dosyasında tam hedef adının sonundaki nokta, adın mevcut zone’a göre uzatılmasını önler; paneller bunu otomatik yapabilir.
CAA, alan adınız için hangi sertifika otoritelerinin sertifika düzenleyebileceğini sınırlar. Uygun CAA politikası, bu kurala uyan otoritelerde istenmeyen sertifika düzenleme riskini azaltır; alan adı doğrulamasının yerine geçmez. Var olan sertifikaları iptal etmez ve tarayıcının mevcut sertifikayı güvenilir sayıp saymayacağını belirlemez.
CAA’da issue normal sertifika düzenlemeyi ve issuewild yoksa wildcard düzenlemeyi de kapsar. issuewild varsa wildcard için bu kayıtlar kullanılır. iodef bir bildirim adresi belirtir; tek başına düzenleme yetkisi vermez veya kısıtlamaz ve bildirim garantisi değildir. Kontrol, istenen ada en yakın uygulanabilir CAA kümesini kullanır; üst alan kayıtları ve CNAME çözümlemesi de sonucu etkileyebilir. Yenilemeden önce yalnız kökü değil sertifikadaki adların uygulanabilir politikasını kontrol edin.
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
“İsim başına tek kayıt türü” genel bir DNS kuralı değildir. Aynı isimde A, AAAA, MX ve TXT gibi farklı kayıtlar birlikte bulunabilir. Esas çakışma, CNAME takma adını aynı isimdeki normal kayıtlarla birleştirmektir. Ayrıca CNAME zincirini kısa tutun ve döngü oluşturmayın; a.example.com → b.example.com → a.example.com zinciri geçerli bir hedefe ulaşmaz.
TTL değişikliğini geçişten hemen önce yapmak eski yanıtları unutturmaz. Önceki TTL’nin dolmasını bekleyecek bir plan kurun; yeni kaydın yetkili sunucularda gerçekten yayımlandığını kontrol edin. Daha önce bulunmayan isim veya tür için negatif önbellek de olabilir: NXDOMAIN/NODATA yanıtının süresi SOA TTL ile SOA.MINIMUM değerlerinin küçüğünden türetilir. Yeni pozitif kaydı eklemek bu önbelleği anında temizlemez.
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.
Alt alan politikalarını birbirinden bağımsız inceleyin. SPF, kontrol edilen alan adına aittir ve kökteki SPF alt alanlara kendiliğinden miras kalmaz. DKIM anahtarı, imzanın alan adı ve seçicisiyle bulunur. DMARC’ta ise görünen From alan adı için uygulanabilir politika ve alt alan kapsamı ayrıca belirlenir. Kök alanı ayarlamak her alt alanın doğru posta yetkisine sahip olduğunu göstermez.
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.
DNS değişikliği ile uygulama ayarını birlikte planlayın. SRV destekleyen uygulamalarda servis konumunu DNS’ten okumak taşınmayı kolaylaştırabilir; desteklemeyen uygulamada yalnız kayıt eklemek işe yaramaz. CNAME hedefi değişirken yeni platformun alan adı ve TLS desteğini, CAA değişirken sertifika yenileme yetkisini kontrol edin. Bu bağımlılıkları değişiklik listesinde açıkça yazın.
DNS Değişikliklerini Test Etmek: Kuru Teori Değil, Canlı Prova
Bir CDN değişikliğinde DNS hedefi doğru olsa bile gecikme, önbellek, sertifika veya origin bağlantısı farklı davranabilir. Değişiklikten önce ve sonra dig veya nslookup ile tüm yetkili sunucuları, ardından birkaç çözümleyiciyi sorgulayın. Yanıt kodunu, kayıt türünü, hedefi ve kalan TTL’yi karşılaştırın. Farklı ağlardan gerçek HTTP/HTTPS erişimini de test edin; DNS yanıtının doğru olması web işleminin başarılı olduğunu kanıtlamaz.
Posta değişikliğinde dışarıdaki deneme alıcılarına her meşru gönderim kaynağından mesaj yollayın; gelen posta yolunu da ayrı test edin. Alıcı sistemin güvenilir Authentication-Results başlığında SPF, DKIM ve DMARC sonucunu ve hizalanan alan adını inceleyin. İmzanın yalnız mevcut olması doğrulandığı anlamına gelmez. DMARC rapor adresinin çalıştığını ve gerekiyorsa harici rapor yetkilendirmesini kontrol edin; raporlar gecikmeli ve alıcı desteğine bağlıdır.
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.
HSTS ve CAA farklı katmanları korur: HSTS, politikayı öğrenmiş veya preload kapsamındaki tarayıcının HTTPS kullanmasını sağlar; CAA ise otoritenin sertifika düzenleme yetkisini sınırlar. Hiçbiri DNS yanıtlarını imzalamaz; bunun için doğru güven zinciriyle DNSSEC kullanılır. Web tarafındaki kapsam ve istisnalar için HTTP güvenlik başlıklarını doğru uygulama rehberine başvurabilirsiniz.
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.
Geçiş planında mevcut kayıtları kaydedin, yeni hedefi ve sertifikayı hazırlayıp test edin, TTL’yi önceki değerini dikkate alarak önceden düşürün. Geçişte yalnız ilgili kayıtları değiştirin; CNAME ile çakışacak ikinci bir kayıt eklemeyin. Eski hedefi ve gerekiyorsa posta alımını bir süre açık tutun, yazılabilir verinin senkronizasyonunu planlayın. Sorunda DNS’i geri çevirmek de önbelleğe tabidir; geri dönüş bir düğmeyle anında tamamlanmaz.
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. Kimlik doğrulama hatalarını gidermek önemlidir; fakat gelen kutusuna teslimi tek başına garanti etmez.
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.
