DANE for SMTP (TLSA) neyi çözer?
E-posta iletimi genellikle SMTP üzerinden yapılır ve iki sunucu arasında TLS (STARTTLS) ile şifreleme mümkün olsa da, pratikte en büyük tartışma noktası “karşı tarafın sertifikasına ne kadar güveniyoruz?” sorusudur. Klasik modelde alıcı veya gönderici MTA, sunucunun sunduğu TLS sertifikasını genel sertifika otoriteleri (CA) zinciri üzerinden doğrular. Bu yaklaşım çoğu senaryoda yeterli olsa da, yanlış sertifika verilmesi, araya girme girişimleri, yanlış yapılandırmalar veya saldırganın DNS yanıtlarını manipüle ettiği durumlar gibi risklerin tamamı CA tabanlı güven modelinin dışında farklı kontrol noktaları gerektirir.
DANE for SMTP, TLS sertifikası doğrulamasını DNSSEC ile korunan DNS kayıtlarına taşıyarak, hedef alan adının “hangi sertifikayı veya hangi anahtarı kabul ediyorum” bilgisini doğrulanabilir şekilde ilan etmesine imkân verir. Bu ilan TLSA kaydı ile yapılır. Kısaca DANE, SMTP seviyesinde TLS’in yalnızca “var olmasını” değil, hangi sertifikanın doğru olduğunu da daha sıkı bir şekilde belirlemeyi hedefler.
Ön koşullar: DNSSEC ve doğru isimlendirme
DANE’in temel şartı, TLSA kaydının DNSSEC ile imzalanmış bir bölgede bulunmasıdır. DNSSEC yoksa, TLSA kaydı saldırgan tarafından sahte DNS yanıtlarıyla değiştirilebilir ve güven kazancı tersine dönebilir. Bu nedenle DANE planına başlamadan önce aşağıdaki konular netleşmelidir:
- Alan adınız DNSSEC imzalı mı? DNS sağlayıcınızda zone signing ve DS kaydı yayınlama süreci tamamlanmış olmalıdır.
- MX hedefleri belirgin mi? DANE kayıtları genellikle MX’in işaret ettiği host isimleri için tanımlanır. Dağınık, sık değişen veya üçüncü taraflara yönlenen MX tasarımlarında operasyon zorluğu artar.
- Sunucu FQDN ve sertifika uyumu: SMTP sunucunuzun TLS sertifikasında doğru isim(ler) bulunmalı ve sunucunun sunduğu kimlik beklenen FQDN ile tutarlı olmalıdır.
DANE’e geçiş, “DNS’e bir kayıt ekledim bitti” seviyesinde değildir. DNSSEC’in anahtar yönetimi, sağlayıcı değişikliği süreçleri ve hata durumunda geri dönüş planı mutlaka değerlendirilmelidir.
TLSA kaydı mantığı: usage, selector, matching type
TLSA kaydı dört parçalı bir mantıkla çalışır: port/protokol/host için bir kayıt yayınlanır ve bu kayıtta sertifika veya anahtar parmak izi belirtilir. SMTP tarafında yaygın kullanım, 25 numaralı port üzerindeki STARTTLS (TCP) içindir.
TLSA parametreleri özetle şöyledir:
- Usage: Doğrulamanın CA zinciriyle mi, yoksa doğrudan DNS’te belirtilen anahtar/sertifika ile mi yapılacağını anlatır.
- Selector: Eşleştirme sertifikanın tamamına mı, yoksa SubjectPublicKeyInfo (SPKI) yani açık anahtar bölümüne mi yapılacak?
- Matching type: Tam değer mi kullanılacak, yoksa SHA-256 / SHA-512 özet mi?
Operasyonel bakış açısından en sık tercih edilen yaklaşım, sertifikanın tamamını sabitlemek yerine SPKI üzerinden sabitlemektir. Çünkü sertifika yenilerken (aynı anahtar korunuyorsa) TLSA kaydını değiştirme ihtiyacı azalabilir. Ancak anahtar yenileme/rotasyon politikanız varsa, TLSA kaydı güncelleme süreci de buna göre tasarlanmalıdır.
SMTP’de TLSA kaydı nerede yayınlanır?
TLSA kaydı, belirli bir servis ve host için oluşturulur. Format mantığı şu şekildedir: _port._proto.host. SMTP için tipik örnek _25._tcp ön ekidir ve host kısmı genellikle MX’in işaret ettiği isimdir.
Önemli pratik detay: DANE kurgusunda TLSA kaydını “alan adının kendisine” yazmak yerine, MX hedefi olan host adına yazmak çoğu senaryoda daha doğru olur. Çünkü SMTP bağlantısı fiilen MX hedefindeki sunucuya yapılır. Örneğin example.com alan adının MX’i mail.example.com ise TLSA kaydı mail.example.com için planlanır.
Bazı yapılarda birden fazla MX hedefi olabilir. Her bir MX hostu farklı sunuculara gidiyorsa, her host için ayrı TLSA planı gerekir. Eğer tüm MX’ler aynı TLS yapılandırmasını ve aynı sertifikayı sunuyorsa, operasyon kolaylaşır; yine de kayıtların tutarlı olmasına dikkat edilmelidir.
Adım adım güvenli devreye alma planı
1) Mevcut TLS sağlığını doğrulayın
DANE’e geçmeden önce STARTTLS davranışınızın doğru olduğundan emin olun: doğru sertifika zinciri, doğru host isimleri, güncel protokoller ve tutarlı sunum. Buradaki hatalar DANE sonrası daha görünür hale gelir ve bazı göndericilerde teslimat sorunları yaratabilir.
2) DNSSEC’i stabil hale getirin
DNSSEC etkinleştirmesi tek seferlik bir iş değildir. Anahtar rotasyonu, sağlayıcı taşınması, DS kaydı güncellemeleri gibi süreçler işletme olgunluğu gerektirir. DANE planına geçmeden önce DNSSEC’in düzenli şekilde izlenebildiğinden emin olun.
3) TLSA değerini üretin ve düşük riskle yayınlayın
TLSA üretiminde en kritik kısım, doğru sertifika/anahtarın doğru formatta özetlenmesidir. Yanlış üretilmiş TLSA, DANE uygulayan göndericilerin size TLS kuramamasına yol açabilir. Bu nedenle üretim ve doğrulama adımlarını bir kontrol listesiyle yürütün.
4) Çoklu MX ve sertifika yenileme senaryolarını test edin
Birden fazla MX’iniz varsa, her birinin aynı şekilde TLS sunduğunu ve TLSA kayıtlarının uygun olduğunu doğrulayın. Ayrıca sertifika yenileme gününde ne olacağını önceden simüle edin: yeni sertifika geldiğinde TLSA güncellemesi gerekecek mi, TTL değerleri uygun mu, geri dönüş planı var mı?
5) İzleme ve hata ayıklama
DANE geçişinden sonra bazı uzak sistemler hâlâ opportunistic TLS kullanabilir, bazıları ise DANE’i aktif doğrulayabilir. Sorun yaşandığında SMTP loglarında tipik olarak TLS doğrulama hataları, sertifika uyuşmazlığı veya DNSSEC doğrulama başarısızlığına dair işaretler görülür. Bu nedenle log toplama, mesaj izleme ve DNSSEC doğrulama kontrolleri birlikte ele alınmalıdır.
Yaygın hatalar ve yanlış beklentiler
- “DANE kurdum, herkes TLS zorlayacak”: DANE, karşı tarafın desteklemesine bağlıdır. Destekleyenler için güçlü doğrulama sağlar; desteklemeyenler için davranış değişmeyebilir.
- Yanlış hosta TLSA yazmak: Alan adına TLSA yazıp MX hedefine yazmamak, pratikte etkisiz kalabilir.
- DNSSEC kırılması: Süresi dolmuş imzalar, yanlış DS, hatalı anahtar rotasyonu gibi durumlar yalnız DANE’i değil, DNS çözümlemesini de etkileyebilir.
- Sertifika yenileme gününü unutmak: TLSA sertifikaya sabitlenmişse, sertifika değişince kayıt güncellenmezse DANE doğrulayan göndericiler teslimatı geçici olarak durdurabilir.
DANE, MTA-STS ve TLS: nasıl konumlandırmalı?
DANE, DNSSEC güven köküne dayanır. MTA-STS ise HTTPS üzerinden yayımlanan bir politika ve DNS’te bir işaretleyici ile TLS’i zorlamaya yardımcı olur. İkisi aynı problemi farklı güven modelleriyle ele alır. Bazı kuruluşlar birini, bazıları ikisini birlikte tercih edebilir. Burada amaç “tek doğru” aramak değil; DNSSEC olgunluğu, operasyon kabiliyeti ve risk iştahı doğrultusunda uygun kombinasyonu seçmektir.
İşletmeler için pratik öneriler
- Envanter çıkarın: Hangi alan adları e-posta alıyor? MX hedefleri neler? Sertifika nerede yönetiliyor?
- Standardize edin: MX host adlarını, sertifika isimlerini ve yenileme süreçlerini mümkün olduğunca tutarlı hale getirin.
- TTL planlayın: TLSA değişikliği gerektirecek günlerde TTL’leri önceden düşürmek geri dönüşü kolaylaştırır.
- Kademeli ilerleyin: Önce düşük trafikli bir alt alan adı veya ikincil alan adı üzerinde süreçleri test edip sonra ana alana geçin.
Sonuç: DANE’e geçişi bir DNS ve operasyon projesi olarak ele alın
DANE for SMTP (TLSA), e-posta sunucuları arasında TLS doğrulamasını güçlendirmek için etkili bir araçtır; ancak temel bağımlılığı DNSSEC olduğu için, doğru planlama ve disiplinli işletim gerektirir. Başarılı bir kurulum, sertifika yaşam döngüsü, MX mimarisi, DNSSEC yönetimi ve izleme pratiklerinin uyum içinde çalışmasına bağlıdır.
Kurumsal e-posta altyapınızı tasarlarken DNS, TLS ve teslimat izleme konularını birlikte ele almak, uzun vadede daha az kesinti ve daha öngörülebilir bir işletim sağlar. MX1Mail gibi profesyonel e-posta platformlarına geçiş veya mevcut yapınızı iyileştirme aşamalarında, DANE/DNSSEC dahil olmak üzere DNS tarafındaki değişiklikleri kontrollü ve geri dönüş planlı şekilde yönetmek kritik önem taşır.