DNSSEC: DNS Güvenlik Uzantıları ile Alan Adı Güvenliği

DNSSEC Nedir? DNS Güvenlik Uzantıları ve Pratik Etkinleştirme

DNSSEC (DNS Security Extensions), bir alan adının DNS yanıtlarına dijital imza ekleyerek "bu yanıt gerçekten yetkili sunucudan mı geldi?" sorusunu kriptografik olarak çözen bir güvenlik katmanıdır. Yıllarca opsiyonel görünen bu katman, son birkaç yılda phishing ve DNS cache poisoning vakalarının artmasıyla beraber küçük orta ölçekli kurumlar için bile gündelik bir konu hâline geldi. Büyükweb müşterilerinden gelen "DNSSEC açmalı mıyım?" sorusuna verdiğim genel cevabı bu yazıda detaylandırıyorum.

Önce Şunu Netleştirelim: DNSSEC Ne Yapar, Ne Yapmaz?

DNSSEC yapar:

• DNS yanıtının yetkili sunucudan geldiğini doğrular
• Saldırganın MITM ile sahte DNS cevabı enjekte etmesini engeller
• Kullanıcıyı sahte siteye yönlendirme tipi dolandırıcılığı zorlaştırır

DNSSEC yapmaz:

• DNS sorgusunu şifrelemez (içerik açık kalır; bunun için DoH/DoT gerekir)
• Web sitesini saldırılardan korumaz (bu WAF/CDN işi)
• Sunucu tarafı güvenliği sağlamaz (bu firewall/HIDS işi)

DNSSEC sadece "kim cevap verdi" sorusuna kriptografik garanti verir. Bu garanti, başka güvenlik katmanlarına değil, DNS güveninin kendisine dair bir katmandır.

DNS Cache Poisoning: DNSSEC Neden Var?

DNS sorgusu UDP/53 üzerinde imzasız bir protokol olarak çalışıyor. Saldırgan, ağda yeterli pozisyondaysa veya zafiyetli bir resolver bulursa, sahte yanıt enjekte edip hedef domaini farklı bir IP'ye yönlendirebilir. Saldırı senaryosu:

1. Kullanıcı: example.com → ?
2. Saldırgan (yarış kazanır): example.com → 1.2.3.4 (kendi sunucusu)
3. Resolver bunu cache'ler, sonraki sorgular da aynı sahte IP'ye gider
4. Kullanıcı kendini yetkili sitede sanır; phishing/keylog/oturum çalma başlar

DNSSEC, her DNS yanıtına dijital imza (RRSIG) iliştirir. Resolver imzayı bölgenin DNSKEY'i ile doğrular; uyumsuzluk varsa yanıtı reddeder. Chain of trust, kök bölgeden (.) TLD'ye (.com), oradan domaine kadar zincirleme imzalama ile kurulur.

Saldırı Tipleri: Off-Path, On-Path ve Doğum Günü Problemi

DNS cache poisoning saldırıları üç ana kategoride sınıflandırılır:

• On-path (MITM) saldırgan: Ağ trafiğinin ortasında bulunur (paylaşımlı Wi-Fi, ele geçirilmiş router, sahte access point). Gerçek yanıtı görüp değiştirebildiği için saldırı basittir; DNSSEC olmadan tespit imkânsızdır.
• Off-path saldırgan: Trafiği göremez ama resolver'ın sorgu göndereceğini tahmin edip sahte yanıtı önceden "yarışa sokar". Kazanmak için hedef port numarasını ve transaction ID'yi (16 bit, 65536 olasılık) tahmin etmesi gerekir.
• Doğum günü saldırısı (birthday attack): Aynı anda çok sayıda sahte yanıt gönderip transaction ID eşleşmesi olasılığını artıran istatistiksel teknik. Resolver aynı anda birden fazla sorgu gönderiyorsa saldırganın başarı şansı matematiksel olarak yükselir.

Kaynak port randomizasyonu (RFC 5452) bu saldırıları zorlaştırsa da tamamen engellemez; sadece "tahmin uzayını" büyütür. DNSSEC ise tahmine dayalı savunma yerine kriptografik doğrulama sunduğu için bu üç saldırı tipine karşı da eşit derecede etkilidir — saldırgan doğru transaction ID'yi bulsa bile geçerli bir RRSIG imzası üretemez, çünkü imzayı üretebilmek için bölgenin özel anahtarına (private key) ihtiyaç duyar.

DNSSEC Kayıt Türleri

RRSIG (Resource Record Signature):
  - Bir DNS kaydının dijital imzası
  - Her A, MX, TXT vb. kaydın kendi RRSIG'i olur

DNSKEY (DNS Public Key):
  - Bölgenin açık anahtarı (imzaları doğrulamak için)
  - ZSK (Zone Signing Key): Kayıtları imzalar (kısa ömürlü, sık döndürülür)
  - KSK (Key Signing Key): Sadece DNSKEY setini imzalar (uzun ömürlü, güçlü)

DS (Delegation Signer):
  - Üst bölgede (registrar) bulunan KSK'nın hash özeti
  - Chain of Trust'ı buradan kurar

NSEC / NSEC3:
  - Var olmayan kayıt için "yok" yanıtının kanıtı
  - NSEC3 zone walking saldırısını zorlaştırmak için karma kullanır

Pratik olarak, kendi DNS sunucusunu yöneten müşteriler bu beş kayıtla sürekli temas eder; managed DNS (Cloudflare, registrar paneli) kullananlar ise sadece DS kaydını registrar'a ekleyip işi bitirir.

Algoritma Seçimi: Hangi İmzalama Algoritmasını Kullanmalı?

DNSSEC birden fazla imzalama algoritmasını destekler; seçim performans ve uyumluluk dengesini doğrudan etkiler.

Algorithm ID	İsim	İmza Boyutu	Doğrulama Hızı	Tavsiye
8	RSA/SHA-256	Büyük (~256 byte)	Görece yavaş	Eski sistemlerle uyumluluk gerekiyorsa
13	ECDSA P-256 (SHA-256)	Küçük (~64 byte)	Hızlı	Yeni kurulumlarda genel tercih
14	ECDSA P-384 (SHA-384)	Orta	Hızlı	Daha yüksek güvenlik istenen senaryolar
15	Ed25519	En küçük	En hızlı	Destekleyen resolver'lar için ideal, yaygınlığı henüz sınırlı

Pratikte BIND ve PowerDNS gibi modern DNS sunucu yazılımları algorithm 13'ü (ECDSAP256SHA256) varsayılan olarak öneriyor: RSA'ya kıyasla hem imza boyutu küçük (bu da UDP paket şişmesini azaltır) hem doğrulama hızı yüksektir. Ed25519 teorik olarak daha üstün performans sunsa da bazı eski resolver ve registrar altyapılarında hâlâ tam desteklenmiyor; bu yüzden geniş uyumluluk isteyen kurulumlarda algorithm 13 güvenli bir orta yol olarak öne çıkıyor.

DNSSEC Sizin İçin Mi? (Dürüst Karar Matrisi)

Büyükweb müşterilerinin büyük çoğunluğu için pratik tavsiye: registrar paneli destekliyorsa açın, BIND/PowerDNS gibi kendi DNS'inizi yönetiyorsanız Tam yapılandırma öncesi otomasyonu olgunlaştırın.

Senaryo	DNSSEC Tavsiye	Sebep
Cloudflare + Registrar	✓ Aç	Tek tık, otomatik anahtar yönetimi
Hosting paneline (cPanel) DNS	⚠ Sağlayıcı destekliyorsa	Manuel rollover karmaşık olabilir
Kendi BIND/PowerDNS sunucusu	⚠ Otomasyon hazır değilse erteleyin	İmza süresi dolduğunda site offline olur
Sadece geliştirici/test domaini	✗ Açmayın	Pratik fayda yok, ek karmaşıklık
Bankacılık/devlet/kritik servis	✓ Mutlaka	KVKK/yasal uyumluluk perspektifi

Büyükweb perspektifi: Hosting paketlerimizdeki DNS, cPanel WHM üzerinden yönetiliyor. Kendi DNS'inizi VDS üzerinde BIND/PowerDNS ile çalıştırmak istiyorsanız VDS sunucu paketleri bunun için uygun; ama DNSSEC otomasyonunu (anahtar rollover, imza yenileme) özellikle ilk kurulumda ihmal eden müşterilerde aralıklı çözümleme hatası gördük. Tercih etmeyin durumu: küçük blog veya tek kullanıcılı portal için DNSSEC zahmeti getiriyor, riskini taşıyor; managed DNS (Cloudflare ücretsiz planı yeterli) ile aynı korumayı tek tık ile alabiliyorsunuz.

Pratik Etkinleştirme Yöntemleri

Yöntem 1: Registrar Paneli Üzerinden (En Kolay)

Türkiye'deki çoğu registrar (NIC.TR yetkili kayıt operatörleri dahil) DNSSEC için DS kaydı eklemenize izin verir. Adımlar:

1. DNS yöneticinizden (Cloudflare/managed DNS) DS kayıt değerini alın
2. Registrar panelinde domaininize gidin → "DNSSEC" sekmesi
3. Key Tag, Algorithm, Digest Type, Digest alanlarını girin
4. Kaydedin → 24-48 saat propagasyon

Cloudflare örneği:

Cloudflare Panel → DNS → Settings → DNSSEC → Enable
→ Key Tag: 12345
→ Algorithm: 13 (ECDSAP256SHA256)
→ Digest Type: 2 (SHA-256)
→ Digest: ABC123...

Bu değerleri registrar panelinde DS kaydı olarak girin.

Yöntem 2: Kendi BIND Sunucunuzda Inline Signing

BIND 9.16+ ile inline signing kullanın; manuel anahtar üretimi/imzalama yerine BIND otomatik yönetir.

# /etc/bind/named.conf.local
zone "ornek.com" {
    type master;
    file "/etc/bind/zones/ornek.com.zone";
    key-directory "/etc/bind/keys";
    auto-dnssec maintain;
    inline-signing yes;
};

# Anahtar üretimi (KSK ve ZSK)
cd /etc/bind/keys
dnssec-keygen -a ECDSAP256SHA256 -b 256 -n ZONE -f KSK ornek.com
dnssec-keygen -a ECDSAP256SHA256 -b 256 -n ZONE ornek.com

systemctl restart bind9

ECDSAP256SHA256 (algorithm 13) günümüzde RSA-SHA256'ya tercih ediliyor; daha küçük imzalar, daha hızlı doğrulama. BIND yeni kurulumlarda bu varsayılan oluyor.

Yöntem 3: PowerDNS

PowerDNS pdnsutil ile basitleştirilmiş yönetim sunar:

# Zone'a DNSSEC ekle
pdnsutil secure-zone ornek.com

# DS kaydını al
pdnsutil show-zone ornek.com | grep DS

# DS değerini registrar paneline gir

PowerDNS DNSSEC için BIND'a göre daha "set-and-forget" yaklaşım sunar; rollover otomasyonu varsayılan olarak çalışır.

Örnek Senaryo: Sıfırdan Cloudflare Üzerinden DNSSEC Kurulumu

Aşağıdaki senaryo, bir işletmenin ornekfirma.com.tr alan adına DNSSEC eklerken izlediği tipik zaman çizelgesini gösterir:

1. Gün 0 — Hazırlık: DNS yönetimi zaten Cloudflare üzerinde. Panelde "DNS → Settings → DNSSEC" bölümüne girilir ve "Enable DNSSEC" tıklanır. Cloudflare, o an için DS kaydı değerlerini (Key Tag, Algorithm, Digest Type, Digest) üretip ekranda gösterir.
2. Gün 0 — Registrar'a Bildirim: Bu DS değerleri, domainin kayıtlı olduğu registrar panelindeki "DNSSEC" veya "DS Kaydı" sekmesine kopyalanır. .com.tr uzantılı domainlerde bu işlem NIC.TR yetkili operatör panelinden yapılır.
3. Gün 0-2 — Propagasyon: DS kaydı üst bölgeye (.com.tr veya .com) yayılana kadar 24-48 saat beklenir. Bu süre boyunca dig +dnssec ornekfirma.com.tr DS komutu ile kaydın görünüp görünmediği kontrol edilebilir.
4. Gün 2 — Doğrulama: Propagasyon tamamlandığında dig +dnssec ornekfirma.com.tr A çalıştırılır; yanıtta ad bayrağı görülmesi zincirin kurulduğunu doğrular. Ek olarak DNSViz üzerinden görsel kontrol yapılır.
5. Sürekli İzleme: Cloudflare kullanıldığı için anahtar rollover otomatik yürütülür; müşterinin ek bir aksiyon alması gerekmez. Aynı senaryo kendi BIND/PowerDNS sunucunuzda yürütülseydi, 4. adımdan sonra imza son kullanma tarihlerinin cron ile izlenmesi gerekirdi.

Bu örnekte kritik nokta şu: DS kaydı registrar'a girilmeden önce DNS tarafında imzalama aktif olmalı. Sıra tersine çevrilirse (önce DS eklenip DNS tarafında imzalama gecikirse) domain geçici olarak çözümlenemez hâle gelir — bu yüzden adım sırası önemlidir.

DNSSEC'i Doğrulama

Yapılandırma sonrası mutlaka test edin. Birkaç komut:

# AD (Authentic Data) bayrağını kontrol et
dig +dnssec ornek.com A
# flags: qr rd ra ad   ← "ad" görmelisiniz

# DNSKEY ve DS kaydını çek
dig +dnssec ornek.com DNSKEY
dig +dnssec ornek.com DS

# Doğrulama yapan resolver ile test (8.8.8.8 doğrular)
dig @8.8.8.8 +dnssec +multi ornek.com A

# Görsel doğrulama
# https://dnsviz.net/d/ornek.com  ← Chain of trust görsel
# https://dnssec-analyzer.verisignlabs.com  ← Detaylı analiz

DNSSEC doğru kuruluysa AD (Authentic Data) bayrağı yanıtta görünür. Yoksa DS kaydı eksik veya imzalar geçersizdir.

DNSSEC'in Sık Karşılaşılan Hataları

1. SERVFAIL — En Sık Sorun

Dig çıktısında status: SERVFAIL görüyorsanız büyük ihtimalle DS ile DNSKEY uyumsuz. Çözüm:

# DS kaydını yeniden üret
dnssec-dsfromkey -2 /etc/bind/keys/Kornek.com.+013+xxxxx.key

# Çıktıyı registrar paneline gir

Algorithm uyumsuzluğu da SERVFAIL üretir; KSK'nız RSA ise registrar'a gönderdiğiniz DS de RSA olmalı.

2. İmza Süresi Dolması

DNSSEC imzaları ömürlüdür; varsayılan 30 gün. Otomatik yenilenmiyorsa imza dolduğunda alan adınız çözümlenmez. Inline signing veya auto-dnssec maintain bunu otomatik halleder; ama monitoring şart:

# İmza süresini kontrol
dig +dnssec ornek.com A | awk '/RRSIG/ {print $9, $10}'
# 20260601000000 20260501000000  → 1 Haziran'da dolacak

# Cron ile günlük kontrol + alert

3. Anahtar Rollover Hatası

ZSK veya KSK değiştirirken yanlış sırada yapılırsa zone "imzasız" görünebilir. Kural:

• ZSK rollover (sık): Yeni ZSK ekle → her iki ZSK ile imzala → eski ZSK'yı kaldır
• KSK rollover (yıllık): Yeni KSK üret → DS kaydını registrar'a ekle → 48 saat bekle → eski KSK'yı kaldır

DNSViz veya unbound-host ile ara aşamalarda mutlaka doğrulama yapın.

4. Acil Devre Dışı Bırakma

Bir şey ters giderse ve domain çözülmüyorsa:

1. Registrar panelinden DS kaydını kaldır
2. Üst bölge TTL'i kadar bekle (genelde 24-48 saat)
3. Zone dosyasından DNSSEC yapılandırmasını kaldır
4. Sorunu çöz, yeniden etkinleştir

DS kaldırıldığı an chain of trust kırılır; resolver'lar bölgeyi "imzalı kabul etmek zorunda" hissetmez. Bu acil durum kapısıdır.

5. Yanlış TTL Ayarları

DNSKEY ve RRSIG kayıtlarının TTL değeri çok düşük ayarlanırsa resolver'lar sürekli yeniden sorgu yapar, DNS sunucusuna gereksiz yük biner. Çok yüksek ayarlanırsa ise rollover sırasında eski anahtar bilgisi uzun süre cache'te kalır ve geçiş sorunlu hâle gelir. Pratik tavsiye: DNSKEY TTL'ini zone'un diğer kayıtlarıyla tutarlı tutun (genelde 3600-86400 saniye arası) ve planlı bir rollover öncesinde TTL'i geçici olarak düşürerek geçiş süresini kısaltın.

DNSSEC Performans Etkisi

DNSSEC yanıtları imzasız yanıtlardan büyüktür; UDP 512 byte sınırını sıkça aşar ve TCP fallback gerekebilir. Modern resolver'lar EDNS0 ile bunu yönetir, ama gözlenen pratik:

• Sorgu boyutu 2-4x artar (RRSIG, DNSKEY ek kayıtları sebebiyle)
• İlk sorgu 5-15 ms ek gecikme getirir; cache'lendikten sonra fark yok
• Resolver doğrulama yükü minimal (modern CPU'larda)

E-ticaret sitesi gibi yoğun DNS sorgu yapan platformlarda fark hissedilmez; ama IoT cihazları gibi dar bant senaryolarında ölçüm yapılmalı.

Sık Sorulan Sorular

DNSSEC + Cloudflare yeterli mi, ek bir şey gerekir mi?

Çoğu senaryo için yeterli. Cloudflare DNSKEY/RRSIG yönetimini siz değil onlar yapar; siz sadece DS kaydını registrar'a girmekle sorumlusunuz. Tek tık DNSSEC için en pratik çözüm.

DNSSEC açtım, web sitem hâlâ HTTP. Sorun olur mu?

Olmaz. DNSSEC ile HTTPS iki farklı katman. DNSSEC DNS yanıtını imzalar; HTTPS web içeriğini şifreler. İdeal olan ikisi birden, ama DNSSEC'i HTTPS olmadan da kullanabilirsiniz.

DNSSEC, DNS sorgularımı şifreler mi?

Hayır. İçerik açık kalır. Sorgu içeriğini şifrelemek için DNS-over-HTTPS (DoH) veya DNS-over-TLS (DoT) gerekir. Bunlar farklı katmandır.

Büyükweb hosting paketlerinde DNSSEC var mı?

Hosting paneliniz cPanel WHM ise DNS doğrudan WHM tarafında yönetiliyor; managed DNS değişikliği için Cloudflare gibi bir CDN/DNS önyüzü kullanmanız önerilir. Kendi VDS'inizde BIND/PowerDNS yönetiyorsanız DNSSEC tüm yapılandırma sizin elinizde, VDS paketlerimiz bu kullanım için uygun.

.com.tr domainlerinde DNSSEC çalışıyor mu?

Evet. NIC.TR DS kaydı kabul ediyor; çoğu .tr registrarı kontrol panelinden DNSSEC etkinleştirilebilir. Bazı küçük registrarlarda destek hâlâ ekleniyor; doğrulamak için registrar'ınıza sorun.

KSK'mı kaybettim, ne olur?

Felaket senaryosu. Yeni KSK üretip yeni DS kaydını registrar'a göndermeniz, eski TTL boyunca bekleyip sonra eskilerini temizlemeniz gerekir. Bu süreçte alanınız 24-48 saat aralıklı çözümlenir. Anahtar yedekleme (offline, şifreli) şart.

NSEC vs NSEC3 hangisi tercih edilmeli?

NSEC3 (genellikle yeni kurulumlarda varsayılan). NSEC zone walking saldırısına açık; NSEC3 hash kullanarak bunu zorlaştırır. Eski sistemlerle uyum gerekiyorsa NSEC, aksi durumda NSEC3.

DNSSEC ile e-posta güvenliği (SPF, DKIM, DMARC) ilişkisi ne?

DNSSEC, e-posta TXT kayıtlarının (SPF, DKIM, DMARC) bütünlüğünü garanti eder. Bir saldırgan SPF kaydını sahte cevapla değiştiremez. E-posta güvenliği için DNSSEC bir altyapı katmanıdır.

DNSSEC kullanmak ekstra ücret getirir mi?

Registrar ve DNS sağlayıcısına göre değişir; birçok modern DNS sağlayıcısı DNSSEC'i standart hizmetin parçası olarak sunar, ayrı ücret talep etmez. Kendi BIND/PowerDNS sunucunuzu VDS üzerinde çalıştırıyorsanız yazılım ücretsizdir, maliyet sadece sizin ayırdığınız yönetim ve izleme zamanıdır.

Wildcard domainlerde (*.ornek.com) DNSSEC çalışır mı?

Evet, DNSSEC wildcard kayıtları destekler. NSEC/NSEC3 mekanizması wildcard eşleşmelerini de kapsayacak şekilde tasarlanmıştır; ek bir yapılandırma gerekmez, zone imzalandığında wildcard kayıtlar otomatik olarak zincire dahil olur.

CDN kullanırken DNSSEC ile bir çakışma yaşanır mı?

Hayır, CDN ve DNSSEC farklı katmanlarda çalışır. CDN sağlayıcınız aynı zamanda DNS yönetimini de üstleniyorsa (ör. Cloudflare) DNSSEC kurulumu tek panelden yapılır. CDN'iniz sadece içerik dağıtım katmanıysa ve DNS ayrı bir sağlayıcıdaysa, DNSSEC o ayrı DNS sağlayıcısı üzerinden etkinleştirilir; iki katman birbirini etkilemez.

DNSSEC Devreye Alma Kontrol Listesi

Yapılandırmadan önce ve sonra izlenecek adımları tek yerde toplamak, özellikle kendi DNS sunucunuzu yönetiyorsanız hata riskini azaltır.

Kurulum öncesi:

• Mevcut DNS zone dosyanızın yedeği alındı mı?
• TTL değerleri rollover'a uygun şekilde ayarlandı mı (gerekirse geçici düşürüldü mü)?
• Kullanılacak algoritma belirlendi mi (öneri: ECDSAP256SHA256)?
• Registrar panelinde DNSSEC/DS kaydı desteği doğrulandı mı?

Kurulum sırasında:

• KSK ve ZSK anahtarları üretildi mi?
• Zone imzalama (signing) aktif edildi mi?
• DS kaydı registrar paneline doğru girildi mi (Key Tag, Algorithm, Digest Type, Digest)?

Kurulum sonrası:

• dig +dnssec ile AD bayrağı doğrulandı mı?
• DNSViz veya benzeri araçla chain of trust görsel olarak kontrol edildi mi?
• İmza son kullanma tarihi için otomatik uyarı/monitoring kuruldu mu?
• Anahtar rollover takvimi (ZSK sık, KSK yıllık) belgelenip takip planına eklendi mi?
• Acil devre dışı bırakma prosedürü (DS kaydı kaldırma adımları) ekip tarafından biliniyor mu?

Bu liste özellikle kendi BIND/PowerDNS altyapısını yöneten VDS kullanıcıları için kritik; managed DNS (Cloudflare gibi) kullananlarda listedeki çoğu madde sağlayıcı tarafından otomatik olarak karşılanır.

Sonuç ve Büyükweb Yaklaşımımız

DNSSEC, DNS güveninin temel taşı. Yıllarca "akademik" görünen bu protokol artık registrar paneli ile tek tık etkinleştirilebilir hâlde. Büyükweb tavsiyemiz:

• Cloudflare/managed DNS kullanıyorsanız: Açın, kayıp yok
• Kendi DNS'inizi VDS'de yönetiyorsanız: Önce monitoring/rollover otomasyonunu kurun, sonra açın
• Küçük blog/test: DNSSEC zahmeti getirir; managed DNS daha pratik

Büyükweb tarafında VDS sunucu paketleri BIND/PowerDNS DNSSEC kurulumu için uygun altyapı sağlar; teknik destek ekibimiz kurulum sürecinde rehberlik eder. Hosting tarafındaki DNS ihtiyacı için cPanel paneli yeterli; ek DNS güvenliği için Cloudflare önerilir.

---

İlgili Büyükweb Hizmetleri

Domain ve DNS altyapısı için Türkiye lokasyonlu paketler:

• VDS Sunucu (kendi DNS sunucunuz için)
• cPanel Web Hosting
• WordPress Hosting
• WHMCS Hosting
• Tüm hosting ve sunucu paketleri

Sorularınız için 0850 302 60 70 numaralı satış öncesi destek numaramıza ulaşabilir veya iletişim sayfamıza yazabilirsiniz.