DNSSEC Nedir?

DNSSEC (DNS Security Extensions), DNS cevaplarına kriptografik imzalar ekleyerek bir kaydın gerçekten bölge sahibi tarafından yayınlandığını ve yolda değiştirilmediğini doğrulamayı sağlar. RFC 4033, 4034 ve 4035'te tanımlanmıştır.

DNSSEC hangi sorunu çözer?

Klasik DNS'te bir resolver aldığı cevabın doğru kaynaktan geldiğini doğrulayamaz. Bu durum, saldırganın sahte cevapları resolver önbelleğine yerleştirdiği önbellek zehirleme (cache poisoning) saldırılarına kapı açar. DNSSEC her kayıt kümesini imzalar; doğrulama yapan bir resolver imzayı kontrol eder ve geçersiz cevapları reddeder.

DNSSEC'in yapmadıkları da önemlidir: sorguları şifrelemez ve gizlilik sağlamaz. Bu iş DoH ve DoT'nin alanıdır (bkz. DNS Nedir?). DNSSEC yalnızca bütünlük ve kaynak doğrulaması sunar.

DNSSEC kayıt türleri

• DNSKEY: Bölgenin açık anahtarlarını içerir. Yaygın uygulamada iki tür anahtar bulunur: DNSKEY kümesini imzalayan KSK (Key Signing Key, bayrak değeri 257) ve diğer kayıtları imzalayan ZSK (Zone Signing Key, bayrak değeri 256). Tek bir anahtarın her iki görevi üstlendiği yapılandırmalar da mümkündür.
• RRSIG: Bir kayıt kümesinin (ör. example.com için tüm A kayıtları) imzasıdır. Geçerlilik başlangıç ve bitiş zamanı taşır; imzalar süresi dolmadan yenilenmelidir.
• DS (Delegation Signer): Çocuk bölgenin KSK'sının özetidir (hash) ve üst bölgede yayınlanır. Güven zincirini bir seviyeden diğerine bağlayan halkadır.
• NSEC / NSEC3: Bir ismin veya kayıt türünün var olmadığını kanıtlamak (authenticated denial of existence) için kullanılır.

example.com.  3600  IN  DNSKEY  257 3 13 ( mdsswUyr3DPW132mOi8V9xESWE8jTo0d... )
example.com.  3600  IN  DNSKEY  256 3 13 ( oJMRESz5E4gYzS/q6XDrvU1qMPYIjCWz... )
www.example.com. 3600 IN RRSIG  A 13 3 3600 20261107000000 20261008000000 12345 example.com. ( ... )

; .com bölgesinde
example.com.  86400  IN  DS  12345 13 2 ( 3490A6806D47F17A34C29E2CE80E8A999FFBE4BE... )

DS kaydındaki alanlar sırasıyla anahtar etiketi (key tag), algoritma (13: ECDSA P-256 SHA-256) ve özet türüdür (2: SHA-256).

Güven zinciri

Doğrulama kökten başlar. Resolver'lar kök bölgenin anahtarına önceden yapılandırılmış bir güven çapası (trust anchor) olarak güvenir. Ardından zincir şöyle ilerler:

1. Kök bölge, .com için bir DS kaydı yayınlar ve bu kaydı kendi anahtarıyla imzalar.
2. .com bölgesinin DNSKEY'i, kökteki DS ile eşleşir; böylece .com anahtarına güvenilir.
3. .com, example.com için DS kaydı yayınlar ve imzalar.
4. example.com'un KSK'sı bu DS ile eşleşir; KSK, DNSKEY kümesini; ZSK ise www.example.com A kaydını imzalar.

Zincirin herhangi bir halkası koparsa (DS ile DNSKEY eşleşmezse, imza süresi dolmuşsa vb.) doğrulama yapan resolver cevabı reddeder ve istemciye SERVFAIL döner. Kullanıcı açısından alan adı tamamen erişilemez görünür.

; doğrulamalı sorgu: başarılıysa cevapta "ad" bayrağı görünür
$ dig +dnssec www.example.com A

; DS kaydını üst bölgeden kontrol etme
$ dig example.com DS +short

; zinciri ayrıntılı doğrulama (BIND araçları)
$ delv www.example.com A +vtrace

DS kaydı registry'de nasıl yayınlanır?

Bölgenizi imzalayan DNS sağlayıcısıdır; ancak DS kaydı üst bölgede durduğu için onu sağlayıcınız değil, registry yayınlar. Süreç genellikle şöyledir: DNS sağlayıcınız DS bilgisini (key tag, algoritma, özet türü, özet) gösterir, siz bu bilgiyi registrar panelinize girersiniz, registrar da EPP üzerinden registry'ye iletir. Bazı registry'ler CDS/CDNSKEY kayıtları (RFC 7344, RFC 8078) aracılığıyla bu aktarımın otomatik yapılmasını destekler. Rol dağılımı için Registrar ve Registry sayfasına bakın.

RDAP'ta DNSSEC bilgisi

RDAP cevaplarındaki alan adı nesnesi, secureDNS adlı bir alan içerebilir (RFC 9083). Buradaki delegationSigned değeri, registry'de bu alan adı için DS kaydı bulunup bulunmadığını gösterir; dsData dizisi ise yayınlanan DS kayıtlarının ayrıntılarını içerir:

"secureDNS": {
  "delegationSigned": true,
  "dsData": [
    { "keyTag": 12345, "algorithm": 13, "digestType": 2,
      "digest": "3490A6806D47F17A34C29E2CE80E8A999FFBE4BE..." }
  ]
}

delegationSigned: true yalnızca üst bölgede DS bulunduğunu söyler; bölgenin gerçekten doğru imzalandığını garanti etmez. DS'teki key tag ve özetin, DNS sağlayıcınızın yayınladığı DNSKEY ile eşleştiğini ayrıca kontrol etmelisiniz. Sorgulama aracı RDAP sonucunda bu bilgiyi gösterir.

DNS sağlayıcısı değiştirirken sık görülen hata

DNSSEC kaynaklı kesintilerin en yaygın sebebi, DNSSEC açık bir alan adının nameserver'larını değiştirmektir. Registry'de eski sağlayıcının anahtarına ait DS kaydı kalırken yeni sağlayıcı bölgeyi farklı bir anahtarla imzalar veya hiç imzalamaz. Doğrulama yapan resolver'lar DS ile DNSKEY'i eşleştiremez ve alan adı için SERVFAIL döner; doğrulama yapmayan resolver'larda ise her şey çalışır göründüğü için sorun kısmi ve kafa karıştırıcı olur.

Güvenli geçiş için iki yaygın yol vardır:

• Önce DNSSEC'i kapatmak: Registrar panelinden DS kaydını kaldırın, DS kaydının TTL'i (ve bir miktar pay) dolana kadar bekleyin, nameserver'ları değiştirin, yeni sağlayıcıda imzalamayı açın ve yeni DS kaydını ekleyin. Geçiş süresince alan adı imzasız kalır ama erişilebilir olur.
• Kesintisiz geçiş: Her iki sağlayıcı da destekliyorsa yeni sağlayıcının anahtarını önce eski bölgedeki DNSKEY kümesine ekleyip, yeni DS'i registry'ye önceden yayınlayarak çok imzacılı (multi-signer) bir geçiş yapılabilir. Bu yöntem daha karmaşıktır ve iki sağlayıcı arasında anahtar paylaşımı gerektirir.

Benzer bir hata, alan adı başka bir registrar'a taşınırken DS kaydının kaybolması veya bölge imzalarının yenilenmemesi sonucu imzaların süresinin dolmasıdır. Nameserver değişikliğinin genel adımları Nameserver (NS) Nedir? sayfasında açıklanıyor.

Özet

• DNSSEC cevapları imzalar; şifreleme veya gizlilik sağlamaz.
• DNSKEY bölgenin anahtarlarını, RRSIG imzaları, DS ise üst bölgedeki bağlantıyı taşır.
• DS kaydı registrar aracılığıyla registry'de yayınlanır; RDAP'taki delegationSigned alanı bunu gösterir.
• DNS sağlayıcısı değiştirmeden önce DS kaydını planlayın; eşleşmeyen DS, alan adını doğrulama yapan resolver'larda erişilemez kılar.