Alan Adı Güvenliği İçin DNSSEC Neden Önemlidir
Geniş kapsamlı rehber: Alan Adı Güvenliği İçin DNSSEC Neden Önemlidir. Detaylı ipuçları, kurulumlar ve dikkat edilmesi gereken noktalar.
DNS, 1980’lerde iş birliğine dayalı bir ağ için tasarlandı ve yanıtlara varsayılan olarak güvenir. Sorusuna makul görünen bir yanıt alan çözümleyici genellikle bu yanıtı kabul eder, önbelleğe alır ve aynı soruyu soran herkese iletir. Saldırganların istismar ettiği şey tam olarak bu açıklıktır. DNSSEC (Domain Name System Security Extensions), çözümleyicilerin bir yanıtın gerçekten bölge sahibinden geldiğini ve yolda değiştirilmediğini doğrulamasını sağlayarak bu temel zayıflığı giderir. Bu yazıda DNSSEC’in hangi sorunu çözdüğünü, güven zincirinin nasıl işlediğini ve alan adınızı erişilemez hâle getirmeden onu nasıl etkinleştirebileceğinizi anlatıyoruz.
Çözümleme sürecine yeniyseniz önce DNS nasıl çalışır rehberimize göz atın; A, MX ve TXT gibi kayıt türlerini ise DNS kayıtlarını anlama yazımızda ele aldık.
Alan Adınızı ve Web Sitenizi Anında İnceleyin
TLDix'in WHOIS Domain, Hosting Tespiti ve Domain Oracle (AI) servisleri ile herhangi bir web sitesinin arka plan altyapısını saniyeler içinde analiz edin.
Sorun: DNS yanıtları taklit edilebilir
Klasik bir DNS sorgusu küçük bir UDP paketidir. Çözümleyici, gelen yanıtı sorgu kimliği ve kaynak port gibi birkaç alan üzerinden eşleştirir. Bir saldırgan bu değerleri tahmin edebilir, yarışta öne geçebilir ya da ağ yolunun üzerinde bulunursa sahte bir yanıt enjekte edebilir. Bunun en bilinen örneği, Dan Kaminsky’nin 2008’de kamuoyuna duyurduğu önbellek zehirleme tekniğidir. Bu teknik, uygun koşullarda ağ yolunun dışındaki bir saldırganın bile bir çözümleyicinin önbelleğini bütün bir alan adı için saniyeler içinde zehirleyebileceğini gösterdi.
Kaynak port rastgeleleştirmesi bu tür saldırıları çok daha zor hâle getirdi ama imkânsız kılmadı. Başka tehditler de varlığını sürdürüyor:
- Yol üzerinde manipülasyon: Ele geçirilmiş yönlendiriciler, kötü niyetli Wi-Fi ağları veya sahte altyapılar üzerinden yanıtların değiştirilmesi.
- Çözümleyicinin ele geçirilmesi: Zehirlenmiş bir önbellek, çok sayıda kullanıcıyı aynı anda sahte bir siteye yönlendirebilir.
- E-postanın saptırılması: Sahte MX kayıtlarıyla, şifrelemeyi düzgün uygulamayan e-posta trafiği ele geçirilebilir.
DNS over HTTPS gibi şifreleme yöntemleri sizinle çözümleyiciniz arasındaki bağlantıyı korur, ancak çözümleyicinin verdiği yanıtın gerçek olduğunu kanıtlamaz. Bunu DNSSEC yapar.
DNSSEC neyi yapar, neyi yapmaz?
DNSSEC kaynak doğrulaması ve veri bütünlüğü sağlar. Doğrulama yapan bir çözümleyici, bir kayıt kümesinin bölgeye ait anahtarla imzalandığını ve o zamandan beri değişmediğini teyit edebilir. Ayrıca doğrulanmış yokluk kanıtı sunar; yani saldırgan “bu ad mevcut değil” şeklinde sahte bir yanıt üretemez.
Neyi yapmadığını bilmek de en az bu kadar önemlidir:
- DNS sorgularını veya yanıtlarını şifrelemez; yol üzerindeki herkes onları okumaya devam edebilir.
- Ele geçirilmiş bir kayıt firması hesabına karşı koruma sağlamaz. Biri kayıt firmasında ad sunucularınızı ve DS kaydınızı değiştirirse sahte veriler de başarıyla doğrulanır.
- Web sitesinin kendisini güvence altına almaz; yine HTTPS ve geçerli bir sertifikaya ihtiyacınız vardır.
DNSSEC ile gelen yeni kayıt türleri
| Kayıt | Bulunduğu yer | Amacı |
|---|---|---|
RRSIG | Sizin bölgeniz | Aynı türdeki bir kayıt kümesinin (örneğin www için tüm A kayıtlarının) imzası |
DNSKEY | Sizin bölgeniz | RRSIG imzalarını doğrulamak için kullanılan açık anahtarlar |
DS | Üst bölge (örneğin .com) | Anahtar imzalama anahtarınızın özeti; bölgenizi üst bölgenin güven zincirine bağlar |
NSEC / NSEC3 | Sizin bölgeniz | Bir adın ya da kayıt türünün var olmadığına dair imzalı kanıt; NSEC3, bölgenin taranmasını zorlaştırmak için özetlenmiş adlar kullanır |
Güven zinciri nasıl işler?
Doğrulama yapan bir çözümleyicinin önceden güvendiği tek bir anahtara ihtiyacı vardır: güven çapası (trust anchor) olarak tanımlanan kök bölgenin anahtar imzalama anahtarı. Çözümleyici buradan itibaren şu zinciri takip eder:
- Kök bölgenin DNSKEY kümesi güven çapasıyla doğrulanır.
- Kök bölge,
comiçin imzalı bir DS kaydı içerir. Çözümleyici bu DS kaydının RRSIG imzasını kökün anahtarıyla kontrol eder. - Çözümleyici
combölgesinin DNSKEY kümesini alır ve anahtarlardan birinin DS özetiyle eşleştiğini doğrular. - Aynı desen tekrarlanır:
com,example.comiçin imzalı bir DS yayımlar ve bu DS, sizin bölgenizdeki bir DNSKEY ile eşleşmelidir. - Son olarak sizin DNSKEY anahtarınız, kullanıcının istediği yanıtın, örneğin
www.example.comA kaydının RRSIG imzasını doğrular.
Zincirin her halkası doğrulanırsa çözümleyici yanıtta AD (doğrulanmış veri) bayrağını işaretler. Herhangi bir halka başarısız olursa doğrulama yapan çözümleyici yanıtı reddeder ve SERVFAIL döndürür. Üst bölgede bir alan adı için DS kaydı yoksa o bölge imzasız (güvensiz) kabul edilir ve normal şekilde çözümlenir.
KSK ve ZSK
Bölgelerin çoğu iki farklı rolde anahtar kullanır:
- Anahtar İmzalama Anahtarı (KSK) yalnızca DNSKEY kümesini imzalar. Üst bölgede DS kaydı olarak yayımladığınız şey bu anahtarın özetidir; dolayısıyla KSK’yı değiştirmek kayıt firmasında güncelleme gerektirir.
- Bölge İmzalama Anahtarı (ZSK) diğer tüm kayıtları imzalar. Üst bölgeye dokunmadan, tamamen kendi bölgeniz içinde sık sık yenilenebilir.
DNSKEY kayıtlarında KSK genellikle 257, ZSK ise 256 bayrak değerini taşır. Bazı sağlayıcılar tek bir birleşik imzalama anahtarı (CSK) kullanır; bu da çalışır, ancak her anahtar yenilemesinde DS kaydının da güncellenmesi gerekir.
Algoritma 13 ve neden yaygın olarak tercih edildiği
Her anahtar ve imza bir algoritma numarası taşır. Algoritma 8 (RSA/SHA-256) uzun süre varsayılan seçenek oldu ve hâlâ geniş çapta desteklenir. Algoritma 13 (SHA-256 ile ECDSA P-256 eğrisi) ise güncel en iyi uygulama rehberlerinde önerilmekte ve pek çok büyük DNS sağlayıcısında varsayılan olarak kullanılmaktadır. Bunun birkaç nedeni vardır:
- Karşılaştırılabilir güvenlik düzeyinde RSA’ya göre çok daha küçük anahtar ve imzalar; bu da DNS yanıtlarını küçük tutar.
- Küçük yanıtlar, UDP parçalanması ve TCP’ye geri dönme olasılığını azaltır.
- Modern çözümleyicilerin büyük çoğunluğunda geniş doğrulama desteği bulunur.
Algoritma 15 (Ed25519) da önerilen seçenekler arasındadır, ancak bazı eski doğrulayıcılar ve registry’ler onu daha az tutarlı destekler. DS özet türü ise ayrı bir numaradır: Genellikle 2 (SHA-256) tercih edilir.
dig ile DNSSEC kontrolü
+dnssec parametresiyle DNSSEC verilerini isteyin; RRSIG kayıtlarını ve ad bayrağını arayın (çıktı kısaltılmıştır):
$ dig +dnssec example.com A
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2
example.com. 300 IN A 93.184.215.14
example.com. 300 IN RRSIG A 13 2 300 20261021000000 20261007000000 12345 example.com. (imza)
RRSIG satırında 13 algoritmayı, 12345 anahtar etiketini (key tag) gösterir; iki zaman damgası ise imzanın bitiş ve başlangıç zamanlarıdır. Anahtarlarınızı üst bölgeyle karşılaştırmak için:
$ dig example.com DNSKEY +short
257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0d...
256 3 13 oJMRESz5E4gYzS/q6XDrvU1qMPYIjCWz...
$ dig example.com DS +short
12345 13 2 3490A6806D47F17A34C29E2CE80E8A999FFBE4BE...
DS satırı sırasıyla anahtar etiketi, algoritma, özet türü ve özet değerinden oluşur. Anahtar etiketi ve algoritma, DNSKEY kümenizdeki KSK’ya (bayrak 257) karşılık gelmelidir. DNSViz gibi çevrim içi analiz araçları zincirin tamamını görselleştirir ve kopuk halkaları vurgular.
Sık görülen hatalar ve SERVFAIL
| Hata | Tipik neden | Çözüm |
|---|---|---|
| DS hiçbir DNSKEY ile eşleşmiyor | DNS sağlayıcısı değiştirildi ya da KSK yenilendi ama kayıt firmasında güncellenmedi | Doğru DS kaydını yayımlayın veya geçişten önce eski DS’yi kaldırın |
| İmzaların süresi dolmuş | İmzalama süreci durmuş; RRSIG kayıtlarının bitiş tarihi geçmiş | Otomatik imzalamayı yeniden başlatın, imza geçerliliğini izleyin |
| Algoritma uyumsuzluğu | DS, bölgede artık kullanılmayan bir algoritmaya işaret ediyor | Düzgün bir algoritma geçiş prosedürü uygulayın |
| Kısmi imzalama | İkincil ad sunucuları imzasız ya da eski bir bölge yayınlıyor | Tüm yetkili sunucuların imzalı bölgeyi aldığından emin olun |
İşin zor yanı, yalnızca doğrulama yapan çözümleyicilerin başarısız olmasıdır. Doğrulama yapmayan bir çözümleyici kullananlar sitenizi normal şekilde görür; bu yüzden bir DNSSEC arızası gizemli, kısmi bir kesinti gibi görünebilir. Doğrulama yapan bir çözümleyiciye dig +cd (doğrulama devre dışı) ile sorgu göndermek işe yarar: Sorgu +cd ile çalışıp onsuz başarısız oluyorsa sorunun kaynağı DNSSEC’tir.
DNSSEC’i güvenle etkinleştirme adımları
- Desteği doğrulayın. TLD’nizin, kayıt firmanızın ve DNS sağlayıcınızın DNSSEC’i desteklemesi gerekir. Büyük TLD’lerin çoğu zaten imzalıdır.
- DNS sağlayıcısında imzalamayı açın. Sunuluyorsa algoritma 13’ü seçin ve ZSK yenilemelerini sağlayıcının otomatik yönetmesine izin verin.
- DS kaydını kayıt firmasında yayımlayın. Anahtar etiketi, algoritma, özet türü ve özet değerini birebir kopyalayın. Bazı kayıt firmaları ve sağlayıcılar bu işlemi CDS/CDNSKEY kayıtlarıyla otomatik yapar.
- Doğrulayın. Doğrulama yapan bir çözümleyici üzerinden
adbayrağını kontrol edin ve zinciri bir analiz aracında inceleyin. - Geçişleri planlayın. DNS sağlayıcısını değiştirirken ya anahtarları düzgün biçimde devredin ya da DS’yi kaldırın, üst bölgedeki DS TTL süresinin dolmasını bekleyin, geçişi yapın ve ardından DNSSEC’i yeniden etkinleştirin.
DS kaydı kayıt firmasında durduğu için DNSSEC, kayıt firması hesabınızın sağlıklı kalmasına da bağlıdır. Kayıt firması, ad sunucusu ve bitiş tarihi bilgilerini TLDix WHOIS ve RDAP sorgulama aracıyla kontrol edin; tüm portföyünüzün yenilemelerini TLDix panelinde takip ederek süresi dolan bir kaydın güven zincirini kırmasının önüne geçin.
DNSSEC zahmete değer mi?
E-posta, oturum açma, ödeme ya da marka güveni taşıyan alan adları için yanıt genellikle evettir. Modern sağlayıcılarda imzalama büyük ölçüde otomatiktir ve algoritma 13 ek yükü küçük tutar. Asıl operasyonel risk, başta DS değişiklikleri ve sağlayıcı geçişleri olmak üzere birkaç öngörülebilir anda yoğunlaşır. Bu anları dikkatle yönetirseniz DNSSEC, DNS’in ilk gününden beri var olan bir açığı sessizce kapatır ve imzalı DNS verisi üzerine kurulan DANE gibi teknolojilerin de önünü açar.
Karar verirken şunu da göz önünde bulundurun: DNSSEC bir kez açılıp unutulacak bir ayar değildir. Kimin anahtarlardan sorumlu olduğunu, DS kaydının hangi kayıt firmasında durduğunu ve sağlayıcı değişikliğinde hangi adımların izleneceğini kısa bir iç notla belgelemek, ileride yaşanabilecek kesintilerin büyük bölümünü önler.