DNSSEC (DNS Security Extensions, yani DNS Güvenlik Uzantıları), DNS kayıtlarına dijital imzalar ekler; böylece çözümleyiciler bir yanıtın gerçekten alan adının sahibinden geldiğini ve yolda değiştirilmediğini doğrulayabilir. Hiçbir şeyi şifrelemez; özgünlüğü, DNS kökünden başlayan bir güven zinciriyle kanıtlar.
Sıradan DNS, gerçek bir yanıtı sahte bir yanıttan ayırt edemez. RFC 4033, 4034 ve 4035 ile standartlaştırılan DNSSEC bu boşluğu kapatır. Bu rehber, işin içindeki kayıt türlerini, doğrulamanın nasıl çalıştığını ve imzalı alan adlarını en sık çevrimdışı bırakan hataları açıklıyor.
DNSSEC'in çözdüğü sorun
Özyinelemeli bir çözümleyici, sorusuyla eşleşen ilk yanıtı kabul eder. Ağ yolunda bulunarak ya da bir önbellek zehirleme saldırısında gerçek sunucuyla yarışı kazanarak sahte bir yanıt enjekte edebilen bir saldırgan, o çözümleyicinin kullanıcılarını seçtiği bir IP adresine yönlendirebilir. Aynı çözümleyiciyi paylaşan herkes, önbellekteki kayıt süresi dolana kadar sahte yanıtı alır.
DNSSEC sahteciliği fark edilebilir kılar. Her kayıt kümesi bölgenin özel anahtarıyla imzalanır ve eşleşen açık anahtar DNS'te yayımlanır. Doğrulayan bir çözümleyici imzayı denetler ve doğrulanmayan her şeyi reddeder. Önce çözümleyiciler ve yetkili sunucular hakkında bilgi tazelemek isterseniz DNS nedir ve nasıl çalışır yazısını okuyun.
DNSSEC kayıt türleri
| Kayıt | Bulunduğu yer | Amaç |
|---|---|---|
DNSKEY | İmzalı bölge | Bölgenin imzalarını doğrulamak için kullanılan açık anahtarlar |
RRSIG | İmzalı bölge | Bir kayıt kümesinin (örneğin bir ad için tüm A kayıtlarının) imzası; geçerlilik başlangıç ve bitiş zamanlarıyla birlikte |
DS | Üst bölge | Delegation Signer (yetki devri imzalayıcısı): alt bölgenin anahtar imzalama anahtarının özeti; üst bölgeyi alt bölgeye bağlar |
NSEC | İmzalı bölge | Sıralı düzende var olan bir sonraki adı belirterek bir adın veya kayıt türünün var olmadığını kanıtlar |
NSEC3 | İmzalı bölge | NSEC ile aynıdır ama adlar özetlenmiştir (RFC 5155); bu da bölgedeki tüm adları listelemeyi zorlaştırır |
CDS / CDNSKEY | İmzalı bölge | Üst bölgeye hangi DS kaydını yayımlaması gerektiğini bildirir ve otomatik güncellemelere olanak tanır (RFC 7344) |
DNS kayıt türleri rehberimiz, bu imzaların koruduğu A, MX ve TXT gibi sıradan kayıtları anlatır.
Var olmadığını kanıtlamak neden gerekli
NSEC veya NSEC3 olmasaydı, bir saldırgan sahte bir NXDOMAIN ("bu ad yok") yanıtı üretebilirdi; imzalanacak bir kayıt olmadığından bu yanıt kendi imzasını taşıyamaz. NSEC kayıtları çözümleyiciye iki ad arasında hiçbir şeyin bulunmadığına dair imzalı bir ifade verir; böylece "yok" yanıtı da doğrulanabilir.
Anahtar imzalama anahtarları ve bölge imzalama anahtarları
Çoğu bölge, ikisi de DNSKEY kaydı olarak yayımlanan iki tür anahtar kullanır:
- Bölge imzalama anahtarı (ZSK), DNSKEY bayrakları
256: bölgenin sıradan kayıt kümelerini imzalar. Başka kimseyi işe karıştırmadan sık sık değiştirilebilir. - Anahtar imzalama anahtarı (KSK), DNSKEY bayrakları
257: yalnızca DNSKEY kayıt kümesini imzalar. Özeti, üst bölgedeki DS kaydına giren şeydir; bu yüzden değiştirilmesi için kayıt şirketinin (registrar) güncellenmesi gerekir.
Rolleri ayırmak, rutin anahtar değişikliklerinin DNS sağlayıcınızın içinde kalmasını, üst bölgeye dokunan tek değişikliğin ise daha seyrek yapılan KSK değişikliği olmasını sağlar. Bazı kurulumlar bunun yerine tek bir birleşik imzalama anahtarı kullanır; bu daha basittir ve algoritma 13 (SHA-256 ile ECDSA P-256) gibi modern eliptik eğri algoritmalarıyla yaygındır.
Güven zinciri
Bir imza, ancak çözümleyici onu üreten anahtara güveniyorsa işe yarar. DNSSEC bu güveni 2010'da imzalanan kökten başlayarak adım adım kurar. Doğrulayan çözümleyiciler, kök bölgenin KSK'sını yerleşik bir güven çapası (trust anchor) olarak içerir. Bir çözümleyici www.example.com adını şöyle doğrular:
- Kök DNSKEY kümesini doğrulamak için kök güven çapasını kullanır.
- Kök bölgedeki
comiçin imzalı DS kaydını doğrular, ardından bununcomDNSKEY kümesindeki KSK ile eşleştiğini denetler. combölgesindekiexample.comiçin imzalı DS kaydını doğrular, ardından bununexample.comtarafından yayımlanan KSK ile eşleştiğini denetler.www.example.comiçin A kayıtları üzerindeki RRSIG'i doğrulamak içinexample.comDNSKEY kümesini kullanır.
Her halka doğrulanırsa yanıt güvenlidir (secure). Üst bölgede bir bölge için DS kaydı yoksa bölge güvensizdir (insecure, yani imzasızdır) ve yanıt normal şekilde döndürülür. Bir DS varsa ama imzalar doğrulanmıyorsa yanıt sahtedir (bogus).
Doğrulama nasıl görünür: AD ve SERVFAIL
Doğrulayan bir çözümleyici bir yanıtı başarıyla doğruladığında, yanıtta AD (Authenticated Data, yani doğrulanmış veri) bayrağını ayarlar. Bunu dig ile görebilirsiniz:
$ dig +dnssec www.example.com A @1.1.1.1
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
www.example.com. 300 IN A 192.0.2.10
www.example.com. 300 IN RRSIG A 13 3 300 20261101000000 20261011000000 12345 example.com. (signature data)
Doğrulama başarısız olduğunda çözümleyici, sahte olabilecek veriyi geri vermez. SERVFAIL döndürür; kullanıcılara bu, var olmayan bir siteyle veya bir DNS kesintisiyle aynı görünür. Nedenin DNSSEC olduğunu doğrulamak için sorguyu denetim kapalıyken yineleyin:
dig www.example.com A # status: SERVFAIL
dig +cd www.example.com A # status: NOERROR, answer returned
+cd (checking disabled, yani denetim devre dışı) sorgusu başarılı olup normal sorgu başarısız oluyorsa bölgenin DNSSEC'i bozuktur. DNSSEC Kontrolü bu denetimleri sizin için yapar ve DS, DNSKEY ve imza durumunu gösterir.
DNSSEC'in bozulduğu yaygın durumlar
DS kaydını kaldırmadan DNS sağlayıcısı değiştirmek
Klasik hata budur. Kayıt kurumundaki (registry) DS kaydı hâlâ eski sağlayıcının KSK'sını gösterir. Ad sunucuları değiştikten sonra yeni sağlayıcı bölgeyi ya imzasız sunar ya da farklı anahtarlarla imzalar. Doğrulayan çözümleyiciler eşleşen anahtarı olmayan bir DS bulur, bölgeyi sahte olarak işaretler ve her sorgu SERVFAIL döndürür.
Güvenli bir taşıma şöyle görünür:
- Kayıt şirketinde DS kaydını silin.
- Eski DS'nin önbelleklerden süresinin dolmasını bekleyin: en az üst bölgedeki DS kaydının TTL süresi kadar; bunu
dig example.com DSile görebilirsiniz. Bir iki gün beklemek yaygın bir güvenlik payıdır. - Ad sunucularını yeni sağlayıcıya çevirin ve eski NS kayıtlarının süresinin dolmasını bekleyin.
- Yeni sağlayıcıda DNSSEC'i etkinleştirin ve onun yeni DS kaydını kayıt şirketinde yayımlayın.
Bazı sağlayıcılar imzasız boşluğu önleyen bir çoklu imzalayıcı (multi-signer) kurulumunu destekler, ancak bu, iki sağlayıcı arasında iş birliği gerektirir.
Süresi dolmuş imzalar
Her RRSIG'in bir bitiş zamanı vardır. İmzalama süreci durursa (örneğin yeniden imzalama işi başarısız olan, kendi barındırdığınız bir sunucuda) imzaların süresi er ya da geç dolar ve bölge sahte duruma düşer.
Çok hızlı yapılan anahtar değişimleri
Eski bir anahtarı, önbellekler yenisini almadan kaldırmak, hâlâ eski DNSKEY kümesini veya DS kaydını tutan çözümleyiciler için hatalara yol açar. Anahtar değişimleri ilgili TTL sürelerine uymalıdır.
Alan adınız için DNSSEC nasıl etkinleştirilir
- TLD'nizin DNSSEC'i desteklediğinden emin olun; genel TLD'lerin çoğu ve ülke kodlu TLD'lerin birçoğu destekler.
- DNS barındırma sağlayıcınızda DNSSEC imzalamayı açın. Sağlayıcı anahtarları üretir ve bölgeyi imzalar.
- DS kaydı ayrıntılarını (anahtar etiketi, algoritma, özet türü ve özet) kayıt şirketinizin DNSSEC ayarlarına kopyalayın. Sağlayıcınız ve kayıt şirketiniz aynı şirketse bu çoğu zaman otomatiktir; bazı kayıt kurumları CDS kayıtlarını da otomatik olarak alır.
- Sonucu DNSSEC Kontrolü ile doğrulayın ve sıradan sorguların hâlâ çalıştığını DNS Sorgulama aracıyla kontrol edin.
Sıkça sorulan sorular
DNSSEC DNS sorgularımı şifreler mi?
Hayır. DNSSEC özgünlük ve bütünlük sağlar, gizlilik sağlamaz. Sorgular ve yanıtlar ağda hâlâ görülebilir. Şifreleme, DNSSEC'i tamamlayan DNS over TLS veya DNS over HTTPS'ten gelir.
Sitem HTTPS kullanıyorsa DNSSEC'e ihtiyacım var mı?
HTTPS sertifikaları, sahte bir DNS yanıtının fark edilmeden sitenizin kimliğine bürünmesini zaten engeller, ancak DNSSEC e-posta yönlendirmesini, doğrulama için kullanılan TXT kayıtlarını ve diğer kayıtları da korur. TLS sertifika bilgilerini DNS'te yayımlayan DANE için de gereklidir.
Alan adım bazı ağlarda çalışıp bazılarında neden çalışmıyor?
DNSSEC bozuksa yalnızca doğrulayan çözümleyiciler SERVFAIL döndürür; doğrulamayanlar yine yanıt verir. Bu da kesintinin ağa bağlıymış gibi görünmesine yol açar.
DNSSEC'i güvenle nasıl kapatırım?
Önce kayıt şirketinde DS kaydını kaldırın, önbelleklerden süresinin dolmasını bekleyin ve ancak ondan sonra bölgeyi imzalamayı bırakın. Bunu ters sırayla yapmak kesintiye yol açar.