Alan Adı Güvenliği İçin DNSSEC Neden Önemlidir

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.

Güvenlik TLDix Editör Ekibi Yayınlandı: Güncellendi: 6 dk okuma

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.

⚡ TLDix Araçlar Radarı

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.

🔍 Domain WHOIS 🖥️ Hosting Tespiti 🔮 Domain Oracle ✨ Ücretsiz Üye Ol →

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ıtBulunduğu yerAmacı
RRSIGSizin bölgenizAynı türdeki bir kayıt kümesinin (örneğin www için tüm A kayıtlarının) imzası
DNSKEYSizin bölgenizRRSIG 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 / NSEC3Sizin bölgenizBir 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:

  1. Kök bölgenin DNSKEY kümesi güven çapasıyla doğrulanır.
  2. Kök bölge, com için imzalı bir DS kaydı içerir. Çözümleyici bu DS kaydının RRSIG imzasını kökün anahtarıyla kontrol eder.
  3. Çözümleyici com bölgesinin DNSKEY kümesini alır ve anahtarlardan birinin DS özetiyle eşleştiğini doğrular.
  4. Aynı desen tekrarlanır: com, example.com için imzalı bir DS yayımlar ve bu DS, sizin bölgenizdeki bir DNSKEY ile eşleşmelidir.
  5. Son olarak sizin DNSKEY anahtarınız, kullanıcının istediği yanıtın, örneğin www.example.com A 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

HataTipik nedenÇözüm
DS hiçbir DNSKEY ile eşleşmiyorDNS sağlayıcısı değiştirildi ya da KSK yenilendi ama kayıt firmasında güncellenmediDoğ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ğuDS, bölgede artık kullanılmayan bir algoritmaya işaret ediyorDü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ıyorTü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ı

  1. 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.
  2. 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.
  3. 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.
  4. Doğrulayın. Doğrulama yapan bir çözümleyici üzerinden ad bayrağını kontrol edin ve zinciri bir analiz aracında inceleyin.
  5. 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.

Sık sorulan sorular

DNSSEC web sitemi yavaşlatır mı?
Etkisi genellikle ihmal edilebilir düzeydedir. İmzalı yanıtlar daha büyüktür ve doğrulama yapan çözümleyiciler ek kriptografik işlem yapar; ancak yanıtlar diğer DNS verileri gibi önbelleğe alındığından ziyaretçilerin çoğu farkı hissetmez. Algoritma 13 imzaları küçük tuttuğu için yanıtlar tek bir UDP paketine sığar ve TCP’ye geri dönme ihtiyacı azalır. Sayfa yükleme hızını asıl belirleyen başka etkenlerdir.
Alan adımı başka bir kayıt firmasına transfer edersem ne olur?
DNS barındırmanız ve anahtarlarınız aynı kaldığı sürece yalnızca kayıt firması değiştirmek DNSSEC’i bozmak zorunda değildir; ancak bazı firmalar transfer sırasında DS kaydını düşürebilir. Transferden sonra yeni firmada DS kaydının hâlâ mevcut olduğunu kontrol edin. DNS sağlayıcısını da değiştiriyorsanız anahtar devrini planlayın veya taşımadan önce DS kaydını geçici olarak kaldırın.
Bir sorun çıkarsa DNSSEC’i kapatabilir miyim?
Evet. Önce kayıt firmanızdaki DS kaydını kaldırın ve eski DS önbelleklerden silinene kadar bölgenizi imzalı tutmaya devam edin. Bu süre üst bölgenin TTL değerine bağlıdır ve çoğu zaman bir ila iki gündür. İmzalamayı ancak bundan sonra durdurun. DS hâlâ önbellekteyken imzaları kaldırmak, o kullanıcılarda doğrulama hatalarına yol açar.
Hangi çözümleyiciler gerçekten DNSSEC doğrulaması yapar?
Google, Cloudflare ve Quad9 gibi büyük açık çözümleyicilerin pek çoğu DNSSEC doğrulaması yapar; birçok servis sağlayıcı çözümleyicisi ile Unbound ve BIND gibi yazılımların varsayılan kurulumları da öyle. Kapsam ülkeye ve ağa göre değişir. Kendi çözümleyicinizi, imzalı olduğu bilinen bir alan adını sorgulayıp yanıtta ad bayrağının bulunup bulunmadığına bakarak test edebilirsiniz.
Bölgem için NSEC3, NSEC’ten daha mı iyi?
NSEC3, yokluk kanıtlarında adların özetini kullanır; bu da bölgenizdeki tüm adların listelenmesini düz NSEC’e göre zorlaştırır. Her alt alan adınızı açığa çıkarmak istemiyorsanız bu faydalıdır. Güncel öneriler, NSEC3’ün ek yineleme olmadan ve tuz (salt) kullanılmadan yapılandırılmasıdır; çünkü ek yinelemeler anlamlı bir koruma sağlamadan yükü artırır. Birçok sağlayıcı bunu otomatik olarak ayarlar.
Sıkça Sorulan Sorular

Merak Edilenler ve Yanıtları

TLDix.com, domain sorgulama ve AI servisleri hakkında en çok sorulan sorular.