DNSSEC Doğrulayıcı güven zincirini kurabildiğinde, DNS verilerine kaynak kimlik doğrulaması ve bütünlük ekler. DNS yanıtlarını şifrelemez, bir gönderme hizmetini onaylamaz veya mesaj içeriğinin kimliğini doğrulamaz. E-posta açısından değeri, doğrulama zinciri bozulduğunda kullanılabilirlik sonuçlarıyla birlikte DNS bağımlılıklarının korunmasından gelir.
Bir imzanın varlığından ziyade bir zinciri doğrulama
Referanslar: RFC 4033 §3, RFC 4035 §5.
İmzalı bir yanıt kriptografik materyal içerir ancak RRSIG'nin varlığı tek başına başarılı bir doğrulama değildir. Doğrulayıcının güvenilir bir başlangıç noktasına, uygun DNSKEY'e ve yetkilendirme bilgilerine, kullanılabilir imzalara ve geçerli zamanlamaya ihtiyacı vardır. Ana DS verileri ve alt anahtarlar, değişiklikler sırasında koordineli kalmalıdır.
Bilinen bir güven yapılandırmasına sahip, doğrulayıcı bir çözümleyici veya doğrulama özellikli bir tanılama kullanın. Bir uygulama bir çözümleyicinin kimliği doğrulanmış veri göstergesine dayanıyorsa, bu çözümleyiciye olan yol ve güven ilişkisi önemlidir. Yalnızca bir araçla DNSSEC kayıtlarının istenmesi, aracın bunları doğrulamasını sağlamaz ve yetkili yanıt işareti, DNSSEC doğrulama sonucu değildir.
Doğrulama durumlarını ayrı tutun
Referanslar: RFC 4035 §4.3, RFC 7672 §2.1.
Güvenli bir sonuç, döndürülen veriler için doğrulanmış bir güven zincirine sahiptir. Güvenli olmayan bir sonuç, yasal imzasız bir dal olabilir ve tespit edilen bir sahtecilikle eşanlamlı değildir. Sahte sonuç, beklenen doğrulamanın başarısız olduğu anlamına gelir. Belirsiz bir sonucun da ayırt edilmesi gerekir: RFC 4035 gerekli DNSSEC kayıtları alınamadığı için çözümleyici verilerin imzalanıp imzalanmayacağını belirleyemediğinde bunu kullanır. RFC 7672 SMTP için RFC 4035 anlamını kullanır DANE ve böyle bir durumu sessizce imzasız olarak ele almak yerine, bir başarısızlık olarak ele alır. RFC 4033 belirsizliği farklı şekilde tanımladığından tanılama bağlamını koruyun.
Doğrulayan bir çözümleyici, sahte veriler için SERVFAIL döndürebilir, ancak SERVFAIL tek başına DNSSEC teşhis edemez: diğer DNS hataları bunu üretebilir. Doğrulama teşhislerini, üst DS'yi, alt DNSKEY'i, imzaları ve zamanı inceleyin. Varsayılan onarım olarak doğrulamayı devre dışı bırakmayın çünkü bunu yapmak, test edilen güven özelliğini değiştirir.
Üç farklı posta bağımlılığını yeniden oluşturun
Referanslar: RFC 4035 §5.2, RFC 4035 §5.4.
Sentetik A durumu imzalı bir bölgeye, eşleşen bir üst DS'ye ve alt DNSKEY'e ve sorgulanan posta kaydı için şu anda geçerli imzalara sahiptir. Yapılandırılmış doğrulayıcıdan beklenen sonuç güvenlidir. Vaka B'nin, delegasyonunda DS olmadığının doğrulanmış kanıtı olan, kasıtlı olarak imzasız bir çocuğu var. Beklenen sonuç sahte değil, güvensizdir.
Durum C, uyumlu bir rollover olmadan alt anahtarı değiştirdikten sonra eski DS'yi üst öğeye bırakır. Beklenen sonuç, bozuk bir doğrulama zinciri ve tanımlanmış doğrulama çözümleyici donanımı için sıradan bir sorguya SERVFAIL . Doğrulamayan bir doğrudan arama yine de TXT veya MX kaydı. Bu fark, doğrulama çözümleyicisinin hatalı olduğunu kanıtlamaz.
Bu vakaları yalnızca kendi güven bağlantısına sahip tek kullanımlık imzalı bir test hiyerarşisinde yeniden oluşturun. Ana DS'yi, alt DNSKEY'i, sorgulanan kaydı, RRSIG'yi, çözümleyici yapılandırmasını, saati ve ayrıntılı doğrulama izini koruyun. Aynı sahibi sorgulayın ve her durumu yazın ve sınıflandırılmış durumu karşılaştırın. Bu özyinelemeli çözümleyici senaryoları, iddia edilen canlı imzalı bölge kullanıma sunma veya özyinelemeli doğrulayıcı yürütmesi değil, test özellikleridir. Daha sonraki Yakalanan çevrimdışı doğrulama vakaları bölümü, 7 Kasım 2026'da yakalanan ayrı, sınırlı şifreleme düzeneğini belgeliyor; SERVFAIL gözlemlemedi veya entegre SMTP DANE testini yapmadı.
Ek DANE gerekliliklerini anlayın
Referanslar: RFC 7672 §2.2, RFC 7672 §3.
SMTP DANE , DNSSEC kimlik doğrulamalı kullanır TLSA Aktarımın kimliğini doğrulamak için ilişkilendirmeler ve gönderen desteği. Bir alan adını tek başına imzalamak gerekli TLSA kayıtlarını oluşturmaz veya her gönderenin DANE zorunlu kılmasına neden olmaz. MX ve TLSA keşif yolu ve sertifika ilişkisinin RFC 7672 kapsamında kendi doğrulamalarına ihtiyacı vardır.
Bir sertifika veya anahtarın devredilmesi, DNSSEC sağlıklı kalsa bile TLSA eşleşmesini bozabilir. Bunun tersine, bozuk bir DNSSEC zinciri, destekleyen gönderenin aksi takdirde doğru TLSA verilerini güvenli bir şekilde kullanmasını engelleyebilir. Her iki katmanı birlikte planlayın ve kontrollü bir SMTP testi yapın. Ne DANE ne de DNSSEC yerini almaz SPF, DKIM veya DMARC.
İmzalamayı sürdürülen bir bağımlılık olarak çalıştırın
Referanslar: RFC 6781 §4.1.
İmzalama, kayıt şirketi DS güncellemeleri, anahtar aktarımı ve izlemenin sahipliğini kaydedin. DNS sağlayıcılarını değiştirmeden önce anahtarların ve zincirin korunacağını mı yoksa aktarılacağını mı belirleyin. İlgili yollardan imza geçerliliğini ve doğrulamayı izleyin ve bir hatayı kapatmadan önce kurtarma kanıtı isteyin. İmzalı DNS tüm e-postaları güvenli hale getirdiğini iddia etmek yerine, gözlemlenen DNS güvenini ve posta davranışını tam olarak bildirin.
Yakalanan çevrimdışı doğrulama durumları
Referanslar: RFC 4035 §5.
İncelenen ancak bu inceleme için yeniden çalıştırılmayan tutulan yakalama, 7 Kasım 2026'da 20:34:42 UTC'de Python 3.12.14 ve dnspython 2.9.2 ile izole edilmiş bir şifreleme fikstürünün yürütüldüğünü kaydediyor. Oluşturulan bir ana DNSKEY'i örneğin laboratuvar güven bağlantısı olarak sabitledi, signed.example için bir alt anahtar oluşturdu, alt çocuğun DS'sini ana anahtarla imzaladı ve bir test imzaladı. TXT kaydı çocuk anahtarıyla. DS ve TXT için gerçek imza kontrolleri başarılı oldu ve hesaplanan SHA-256 DS, çocuğun DNSKEY'iyle eşleşti. Yakalanan sonuç, doğrulanmış bir çevrimdışı zincirdi.
Kırık zincir durumunda, tesisat eski DS'yi korurken yedek bir alt anahtar oluşturdu. Hesaplanan DS artık eşleşmedi ve fikstür zinciri reddetti. Özyinelemeli bir doğrulayıcı çalıştırmadı ve SERVFAIL gözlemlemedi. İmzasız bir durum için, unsigned.example adresinde, tam adı bit eşlemi NS içeren ve DS'yi içermeyen ebeveyn imzalı bir NSEC'yi doğruladı ve ardından bu yetkilendirmeyi güvensiz olarak sınıflandırdı. Bu dar kanıt, genel bir varoluş reddi çözümleyicisini uygulamaz.
Çoğaltmak için ECDSA P-256 ana ve alt anahtarlarını oluşturun, DNSKEY ve DS kayıtları oluşturun, DS ve TXT sınırlı başlangıç/son kullanma zamanlarıyla imzalayın ve sabitlenmiş ana ve eşleşen alt anahtarlara karşı dnspython'un DNSSEC doğrulama işlemini çağırın. Uyumsuzluk durumunda alt anahtarı değiştirin. İmzasız durum için, tam delegasyon NSEC imzasını doğrulayın ve bit eşlemini inceleyin. Anahtarların genel kayıtlarını, imzalarını, doğrulama süresini, bağımlılık sürümlerini ve sonuçlarını saklayın; Test özel anahtarlarını tek kullanımlık tutun. Kanıtlar, genel DNS doğrulamasını, üretim SMTP DANE veya konuşlandırılmış bir özyinelemeli çözümleyiciyi değil, gerçek yerel şifreleme işlemlerini göstermektedir.