DNSSEC nedir?
DNSSEC (Domain Name System Security Extensions), DNS kayıt kümelerine dijital imzalar ekler. DNSSEC doğrulaması yapan bir çözümleyici, imzalı DNS verilerinin kaynağını doğrulamak ve yetkisiz değişiklikleri saptamak için geçerli imzalardan ve güven zincirinden yararlanabilir. DNSSEC, DNS sorgularını veya yanıtlarını şifrelemez.DNSSEC nasıl çalışır?
Güven Zinciri (KSK ve ZSK'nin ayrı kullanıldığı örnek):
Kök Bölge (.)
├── Kök KSK (güven çapası), kök DNSKEY RRset'ini imzalar
└── Kök ZSK, .com için üst bölge tarafındaki DS RRset'ini de içeren kök bölgenin yetkili RRset'lerini imzalar
└── DS özeti, .com KSK'siyle eşleşir
├── .com KSK'si, .com DNSKEY RRset'ini imzalar
└── .com ZSK'si, example.com için üst bölge tarafındaki DS RRset'ini de içeren .com bölgesinin yetkili RRset'lerini imzalar
└── DS özeti, example.com KSK'siyle eşleşir
├── example.com KSK'si, example.com DNSKEY RRset'ini imzalar
└── example.com ZSK'si, example.com bölgesinin yetkili RRset'lerini imzalar
Çözümleyici, kök güven çapasından başlayarak imzaları ve DS özetlerini doğrular
DNSSEC kayıt türleri
| Kayıt | Amaç | Açıklama |
|---|---|---|
| RRSIG | İmza | Her kayıt kümesi için kriptografik imza |
| DNSKEY | Açık anahtar | Bölgenin açık imzalama anahtarları (KSK ve ZSK) |
| DS | Delegasyon imzalayıcısı | Üst bölgede çocuk bölgenin KSK özeti |
| NSEC/NSEC3 | Kimliği doğrulanmış yokluk | Bir kaydın bulunmadığını kanıtlar |
Anahtar türleri
| Anahtar | Amaç | Döndürme sıklığı |
|---|---|---|
| KSK (Key Signing Key) | DNSKEY kayıtlarını imzalar | Operatör politikasına bağlı; aşağıdaki nota bakın |
| ZSK (Zone Signing Key) | Diğer yetkili RRset'leri imzalar; üst bölge tarafındaki delegasyon NS RRset'leri ve glue RRset'leri imzalanmaz ([RFC 4035 §2.2](https://www.rfc-editor.org/rfc/rfc4035.html#section-2.2)) | Operatör politikasına bağlı; aşağıdaki nota bakın |
Döndürme zamanlaması KSK'nin rolüne ve operatör politikasına bağlıdır. Üst bölgesinde DS kaydı bulunan bir KSK için düzenli döndürme tercih edildiğinde [RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) bir yılı makul bir anahtar kullanım süresi olarak tanımlar. Güven çapası olarak kullanılan bir KSK'nin döndürülmesi, doğrulayıcı çözümleyicilerle koordinasyon gerektirir ve bu anahtarın kullanım süresi çok daha uzun olabilir ([RFC 6781 §3.2.2](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.2.2)).
ZSK'nin döndürme zamanlaması DNSKEY ve imza TTL'lerine, bölgenin yayılım gecikmesine ve eski anahtarla oluşturulan imzaların çözümleyici önbelleklerinde ne kadar süre kalabileceğine bağlıdır ([RFC 7583 §3.2.1](https://www.rfc-editor.org/rfc/rfc7583.html#section-3.2.1)). Ele geçirilme riskinin görece yüksek olduğu bir ortamda çevrimiçi tutulan bir ZSK için [RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) bir aylık hedeflenen kullanım süresini makul kabul eder; bu koşullu bir rehberdir, evrensel bir döndürme aralığı değildir.
11 Ekim 2026 Kök KSK Döndürmesi
ICANN, kök bölge KSK döndürme tarihini 11 Ekim 2026 olarak listeliyor. DNSSEC doğrulaması yapan çözümleyicinizin güven çapası yapılandırmasında KSK-2024'ün (anahtar etiketi 38696) bulunduğunu doğrulayın. Otomatik güven çapası güncellemelerinin başarılı olduğunu varsaymayın. Anahtar yoksa otomatik güncellemelerin etkin olduğunu doğrulayın ve güven çapalarını güncellemek için çözümleyici sağlayıcınızın yönergelerini izleyin. Güncel ayrıntılar için [ICANN'in kök KSK döndürme kılavuzuna](https://www.icann.org/resources/pages/ksk-rollover-en) bakın.
DNSSEC doğrulama süreci
1. İstemci, DNS çözümleyicisinden example.com A kaydını ister
2. Çözümleyici A kaydını ve RRSIG imzasını alır
3. Çözümleyici, RRSIG'yi doğrulamak için DNSKEY'yi getirir
4. Çözümleyici, DS kaydını DNSKEY ile karşılaştırarak doğrular
5. Zincir köke kadar ilerler ve her düzeyi doğrular
6. Tüm imzalar geçerliyse yanıtın gerçekliği doğrulanmış olur
DNSSEC doğrulamasının saptayabileceği tehditler
Bu kontroller için imzalı RRset'ler, doğrulama yapan bir çözümleyici ve bozulmamış bir güven zinciri gerekir. İmzasız veya DNSSEC açısından güvensiz verilerin kimliği doğrulanamaz.
| Tehdit | Örnek | DNSSEC koruması |
|---|---|---|
| Önbellek zehirleme | Çözümleyici önbelleğine sahte DNS verisi eklenmesi | Doğrulama yapan çözümleyici, imza veya güven zinciri doğrulamasından geçemeyen veriyi reddedebilir. |
| Yanıtın değiştirilmesi | İmzalı bir DNS RRset'inin aktarım sırasında değiştirilmesi | Değiştirilen veri imza doğrulamasından geçemez. |
| DNS sahteciliği | İmzalı bir bölge için sahte yanıt verilmesi | Doğrulama yapan çözümleyici, doğrulamadan geçmeyen yanıtı reddedebilir. |
Uygulama hususları
- Performans: İmzalar nedeniyle yanıtlar büyür (yaklaşık 1000-4000 bayt, yaklaşık 100 bayt yerine)
- Anahtar yönetimi: Güvenli anahtar üretimi, depolama ve döndürme gerekir
- Bölge imzalama: Kayıtlar değiştiğinde bölge yeniden imzalanmalıdır
- Çözümleyici desteği: İstemciler DNSSEC doğrulayan çözümleyiciler kullanmalıdır
En iyi uygulamalar
1. Bir DNSSEC imzalama algoritması seçin: [IANA DNSSEC algoritma kayıt defteri](https://www.iana.org/assignments/dns-sec-alg-numbers) imzalama ve doğrulama için ECDSAP256SHA256 (algoritma 13) kullanımını önerir. 192 bit güvenlik düzeyi gerektiren uygulamalara ECDSAP384SHA384 (14) uygun olabilir; algoritmayı değiştirmeden önce çözümleyici desteğini kontrol edin ([RFC 9904](https://www.rfc-editor.org/rfc/rfc9904.html), [RFC 8624 §3.1](https://www.rfc-editor.org/rfc/rfc8624.html#section-3.1))
2. Anahtar döndürmeyi otomatikleştirin: Anahtar yaşam döngüsü için OpenDNSSEC gibi araçlar kullanın
3. Süre sonunu izleyin: RRSIG imzalarının geçerlilik süreleri vardır
4. Dağıtımdan önce test edin: Bölgeyi dnsviz.net gibi araçlarla doğrulayın
5. Acil durumları planlayın: Anahtar değiştirme prosedürlerini belgeleyin
Doğrulama yapan bir çözümleyici güven zincirini doğruladığında DNSSEC, imzalı DNS verilerinin kaynağını ve bütünlüğünü doğrular. Döndürülen bir adresteki web sitesinin veya sunucunun güvenilir olduğunu göstermez.