DNSSEC Nedir? Alan Adınızı Nasıl Güvenceye Alırsınız?

DNSSEC alan adınızın hangi cevaba güveneceğini belirler

Evdeki Proxmox lab’ımda bir test alanının KSK anahtarını döndürüyordum. DS kaydını yeni anahtar hazır olmadan değiştirdim ve birkaç dakika sonra bütün sorgular SERVFAIL vermeye başladı. Üretim alan adı değildi; yine de DNSSEC’in küçük bir zamanlama hatasını nasıl görünür bir kesintiye çevirdiğini o gün tekrar gördüm.

DNSSEC’in temel görevi, DNS cevabının gerçekten yetkili kaynaktan gelip gelmediğini ve aktarım sırasında değiştirilip değiştirilmediğini doğrulamaktır. DNSSEC DNS trafiğini şifrelemez. Parolalarınızı ya da web sayfanızın içeriğini gizlemez. DNS kayıtlarına dijital imza ekler ve doğrulama yapan resolver’ın cevaba güvenip güvenmeyeceğini belirlemesine yardım eder.

“DNSSEC nedir?” sorusuna kısa cevabım şu: DNSSEC, alan adınızın DNS kayıtlarının sahte cevaplarla değiştirilmesini zorlaştıran ve DNS hiyerarşisi boyunca çalışan bir doğrulama mekanizmasıdır. A, AAAA, MX veya TXT kaydını isteyen doğrulayıcı bir DNS çözümleyici, aldığı cevabın imzasını ve güven zincirini kontrol eder.

DNS’in zayıf noktası nerede?

DNS, alan adını IP adresine çevirir. Tarayıcı example.com için A veya AAAA kaydı sorduğunda, çoğu zaman recursive resolver sizin adınıza yetkili DNS sunucularına gider ve cevabı önbelleğe alır. Normal DNS yapısında resolver, aldığı cevabın gerçekten alan adı sahibinden geldiğini kriptografik olarak kanıtlayamaz.

Bu boşluk, DNS önbellek zehirlenmesi veya araya giren sahte cevap saldırıları için kullanılabilir. Saldırgan, kullanıcı doğru alan adını yazdığı halde onu kendi sunucusuna yönlendirmeye çalışabilir. HTTPS sertifika uyarısı bazı saldırıları görünür kılar; fakat kullanıcı uyarıyı görmezden gelebilir veya saldırgan başka bir hizmeti taklit etmeye çalışabilir.

DNSSEC burada imza zincirini devreye sokar. Resolver, “Bu IP adresi gerçekten bu alan adının yetkili kaydından mı geliyor?” sorusunu yalnızca sunucunun beyanıyla değil, doğrulanabilir kriptografik kayıtlarla yanıtlar. İmza geçersizse doğrulama yapan resolver cevabı kabul etmez ve çoğu durumda SERVFAIL döndürür.

İmza zinciri hangi kayıtlardan oluşur?

DNSSEC terimleri ilk bakışta kalabalık gelebilir. Destek biletlerinde anlatırken şu dört kaydı ayrı ayrı ele alıyorum:

• DNSKEY: Alan adının DNSSEC anahtarlarını içerir. Yönetilen hizmetlerde ayrıntılar gizlenebilir; kendi BIND kurulumlarında genellikle KSK ve ZSK rollerini görürsünüz.
• RRSIG: A, MX ve TXT gibi DNS kayıt kümelerinin dijital imzasıdır. Resolver bu imzayı uygun DNSKEY ile doğrular.
• DS: Delegation Signer kaydıdır. Alan adının DNSKEY kaydının özetini üst bölgeye taşır. TLD ile alan adınız arasındaki güven zincirinin bağlantısıdır.
• NSEC veya NSEC3: Bir kaydın mevcut olmadığını kanıtlamak için kullanılır. DNSSEC yalnızca “bu kayıt var” cevabını değil, “bu isimde kayıt yok” cevabını da doğrulamaya çalışır.

Akış basitçe şöyledir: kök DNS bölgesi TLD bölgesine güvenir; TLD bölgesi alan adınızın DS kaydını yayımlar; DS kaydı alan adınızın DNSKEY kaydını doğrulamaya yardım eder; DNSKEY de A, MX ve diğer kayıtların RRSIG imzalarını doğrular.

Zincirin tek bir halkası bile uyuşmazsa doğrulama başarısız olur. DNS sağlayıcınızda DNSSEC açık görünürken registrar tarafındaki DS kaydı eskiyse zincir kopar. Paneldeki yeşil işaret tek başına kanıt değildir; dışarıdan sorgu gerekir.

KSK ve ZSK farkı

DNSSEC kurulumlarında iki anahtar rolüyle karşılaşmanız yaygındır. Zone Signing Key, yani ZSK, bölgedeki normal DNS kayıtlarını imzalar. Key Signing Key, yani KSK, DNSKEY kümesini imzalar ve bu anahtarın özeti DS kaydı olarak üst bölgeye yazılır.

Bu ayrım anahtar yenileme işlemlerini daha kontrollü kılar. ZSK daha sık değiştirilebilir; KSK değiştiğinde DS kaydının da güncellenmesi gerekir. Bazı yönetilen DNS servisleri bu işlemleri otomatik yürütür. Kendi BIND sunucunuzu işletiyorsanız otomasyonun gerçekten çalıştığını izleyin. “Cron çalışıyordur” varsayımı, sertifika yenilemede olduğu gibi DNSSEC’te de pahalı olabilir.

DNSSEC ile HTTPS aynı şey değildir

Bu iki teknoloji sık karıştırılıyor. HTTPS, tarayıcı ile web sunucusu arasındaki bağlantıyı TLS ile korur. DNSSEC ise DNS cevabının doğruluğunu kontrol eder. SSL/TLS sertifikanızın olması, DNS kaydınızın sahte bir resolver cevabıyla değiştirilmesini tek başına engellemez.

DNSSEC etkin bir alan adında HTTPS sertifikanızı kullanmaya devam edersiniz. E-posta güvenliği için SPF, DKIM ve DMARC kayıtlarını da ayrıca yapılandırmanız gerekir. Birinin kurulması diğerinin yerini tutmaz.

Etkinleştirmeden önce DNS mimarisini netleştirin

DNSSEC’i tek düğmeyle açmak mümkün olabilir; ben yine de önce DNS’in nerede yönetildiğini yazarım. Registrar, yetkili DNS sağlayıcısı ve hosting sunucusu aynı şirket olmak zorunda değildir.

1. Yetkili DNS sunucularını belirleyin. Registrar panelindeki nameserver değerlerine bakın. DNS kayıtlarını gerçekten hangi servis yayımlıyor, bunu bilin.
2. Sağlayıcının DNSSEC yöntemini öğrenin. Bazı paneller otomatik imza üretir, bazıları sizden DS bilgisi ister. İki yöntemi rastgele birlikte uygulamayın.
3. Mevcut kayıtları dışarı alın. A, AAAA, MX, TXT, CNAME, CAA ve varsa özel SRV kayıtlarını kaydedin. DNS kayıt türlerini karıştırıyorsanız DNS Kayıt Türleri Nedir? A, AAAA, MX, CNAME, TXT, SRV ve CAA İçin Uygulamalı Rehber başlıklı içeriğimizdeki örnekler işinize yarayabilir.
4. İkincil DNS veya DNS proxy kullanıp kullanmadığınızı kontrol edin. CDN, WAF ve registrar DNS’i aynı anda devredeyse imzayı hangi tarafın ürettiği kesin olmalı.
5. Alternatif iletişim yöntemi hazırlayın. DNSSEC hatasında alan adına bağlı e-posta adresiniz de çalışmayabilir. Registrar hesabındaki telefon ve alternatif e-posta bilgilerini kontrol edin.

Nameserver değişikliği yapacaksanız DNSSEC durumunu işlem planına ekleyin. Alan adı transferinde DNS’in nerede tutulduğunu ve DS kaydının nasıl taşınacağını ayrıca kontrol edin. Alan adı Transferi Nasıl Yapılır? Adım Adım Rehber başlığındaki taşıma adımlarına DNSSEC kontrolü eklemek, sonradan çıkabilecek SERVFAIL sorunlarını azaltır.

Panel üzerinden DNSSEC kurulumu

Yönetilen DNS servislerinde işlem çoğunlukla üç parçalıdır: DNSSEC’i yetkili DNS sağlayıcısında etkinleştirmek, oluşan DS bilgisini registrar’a girmek ve dışarıdan doğrulamak. Bazı registrar’lar API entegrasyonu sayesinde DS kaydını otomatik ekler.

Panel DS bilgisi istiyorsa genellikle şu alanları görürsünüz:

• Key tag
• Algorithm
• Digest type
• Digest

Bu değerleri elle yazarken tek bir karakter hatası bile zinciri bozabilir. Kopyalama sırasında başta veya sonda boşluk kalmadığını kontrol edin. DS kaydını registrar’a eklemeden önce DNS sağlayıcısının ürettiği değerle karşılaştırın; eski anahtara ait bilgiyi kullanmayın.

Birden fazla DS kaydı görüyorsanız hepsini gelişigüzel silmeyin. Eski ve yeni anahtarın birlikte geçerli olduğu kontrollü geçişler olabilir. Sağlayıcının anahtar döndürme prosedürünü izleyin. Kendi anahtarlarınızı yönetmiyorsanız, panelin otomatik DNSSEC akışı genellikle daha az el işi ve daha az hata demektir.

Linux üzerinden DNSSEC doğrulama

DNS şikâyetlerinde panele güvenmeden önce ben dig ile dışarıdan bakarım. Temel sorgu şöyle:

dig example.com A +dnssec

Çıktıda RRSIG kaydını görmek, sunucunun imza bilgisini döndürdüğünü gösterir. Cevap bölümündeki ad bayrağı ise sorguyu yapan resolver’ın cevabı doğruladığını belirtir. +dnssec tek başına doğrulama yapmaz; bu ayrım sık atlanıyor.

DS kaydını üst bölgeden kontrol etmek için:

dig example.com DS +short

Buradaki digest değerini DNS sağlayıcısının yayımladığı DNSKEY özetiyle karşılaştırabilirsiniz. Yetkili sunucuları doğrudan sorgulamak için önce nameserver listesini alın:

dig example.com NS +short
dig @ns1.example-dns.net example.com DNSKEY +dnssec

İlk komut yetkili sunucuları, ikinci komut ise bu sunucunun DNSKEY ve imza bilgisini gösterir. Örnek alan adını kendi alan adınızla, nameserver değerini de gerçek sunucunuzla değiştirin.

Yerel resolver’ın DNSSEC doğrulamasını daha belirgin görmek için delv kullanabilirsiniz:

delv example.com A

Doğrulama başarılıysa çıktıda güven zincirine ilişkin bilgi görürsünüz. broken trust chain, no valid signature veya benzeri bir hata alırsanız DS, DNSKEY ve RRSIG değerlerini birlikte inceleyin. Yalnızca A kaydına bakmak sorunun kaynağını gizleyebilir.

Etkinleştirdikten sonra hangi testleri yaparım?

Kontrolü yalnızca kendi bilgisayarınızdan yapmayın. Farklı recursive resolver’lar, mobil internet ve kurumsal ağlar üzerinden sorgu gerçekleştirin. Önbellekler farklı sürelerde yenilenebildiği için değişiklikten hemen sonra bütün cevapların aynı olmasını beklemek doğru değildir.

Benim pratik test sıram şu:

1. Alan adının A ve AAAA kayıtlarını sorgulayın.
2. MX kayıtlarının doğrulandığını kontrol edin; e-posta akışını unutmayın.
3. TXT kayıtlarını sorgulayın ve SPF, DKIM ile alan adı doğrulama kayıtlarının döndüğünü görün.
4. DS kaydını TLD seviyesinden kontrol edin.
5. DNSSEC doğrulaması yapan bir resolver üzerinden dig veya delv çalıştırın.
6. En az iki yetkili nameserver’ın aynı DNSKEY ve imza durumunu verdiğini doğrulayın.

Web sitesi açılıyor diye kontrolü bitirmeyin. Birçok ekip A kaydına bakıp MX ve TXT tarafını unutuyor. E-posta teslimatı veya alan adı doğrulaması kullanan servisler, zincirdeki bir sorunu tarayıcıdan önce gösterebilir.

SERVFAIL gördüğünüzde ilk bakacağınız yerler

DNSSEC kaynaklı hata çoğu zaman “site tamamen kapalı” gibi görünür. Önce sorunun bütün istemcilerde mi, yoksa belirli resolver’larda mı yaşandığını ayırın. Farklı doğrulayıcıları karşılaştırmak için:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Ardından şu ihtimalleri kontrol edin:

• Registrar’daki DS kaydı eski DNS sağlayıcısına ait olabilir.
• DNS sağlayıcısı değişmiş, fakat yeni DNSKEY bilgisi üst bölgeye işlenmemiş olabilir.
• Bir kayıt değiştirilmiş, fakat yeni RRSIG imzası üretilmemiş olabilir.
• DNS sunucusunun saat bilgisi hatalı olabilir. RRSIG kayıtlarının geçerlilik aralığı vardır; ciddi saat sapması doğrulamayı bozabilir.
• Yetkili nameserver’lardan biri eski zone dosyasını yayımlıyor olabilir.
• DNSSEC anahtar döndürme işlemi yarıda kalmış olabilir.

Bu komutlarla iki farklı doğrulayıcının aynı cevabı verip vermediğini karşılaştırdık.

Geçici çözüm olarak DS kaydını silmek bazen önerilir. Bu işlem doğrulamayı kapatır ve yanlış yapılandırmanın neden olduğu erişim sorununu kaldırabilir; DNSSEC korumasından da vazgeçmiş olursunuz. Önce hatanın kaynağını bulun. Erişilebilirlik baskısı nedeniyle DS kaldırılırsa kararı kayda alın ve düzeltme tamamlanınca DNSSEC’i yeniden kurun.

Benim Proxmox lab’ındaki KSK döndürme hatasında dig +trace ile kökten başlayıp TLD ve yetkili sunuculara kadar zinciri izledim. DS yeni anahtarı gösteriyordu, fakat yetkili sunuculardan biri eski DNSKEY kümesini yayımlıyordu. Test alanıydı; üretimde aynı işlem için değişiklik planı ve geri dönüş kaydı olmadan ilerlemem.

DNSSEC’in sınırları ve bakım işi

DNSSEC güçlü bir doğrulama katmanıdır, fakat registrar hesabınızı korumaz. Hesap ele geçirilirse saldırgan nameserver’ları değiştirebilir veya DS kaydını yönetebilir. Registrar hesabında çok faktörlü kimlik doğrulama kullanın, kurtarma e-posta adresini koruyun ve yetkili kişileri sınırlayın.

DNSSEC web sunucusundaki açıkları da kapatmaz. WordPress eklentiniz eskiyse, yönetici parolanız 123456 ise veya sunucunuzda yanlış izinler varsa DNSSEC bunların hiçbirini düzeltmez. Yalnızca DNS kaydının doğru IP’ye işaret ettiğini doğrular; o IP’de çalışan uygulamanın güvenli olduğunu kanıtlamaz.

Yanlış imzalanmış bir kayıt, imzasız bir kayıttan daha sert sonuç doğurabilir; doğrulayan resolver cevabı reddeder. DNSSEC anahtarlarını, imza sürelerini ve DS değişikliklerini izleyin. Kendi DNS altyapınızı yönetiyorsanız değişiklikleri loglayın, alarm üretin ve geri dönüş adımını önceden yazın.

Nameserver performansı, TTL değerleri ve resolver davranışı önemini korur. DNS Performansını Ölçmek ve İyileştirmek: Anycast, Çoklu DNS Sağlayıcı ve Health Check Mimarisi başlığında bu konuları farklı bir açıdan ele alıyoruz. DNSSEC imza ekler; kötü tasarlanmış bir DNS mimarisini kendiliğinden hızlı veya dayanıklı yapmaz.

Alan adınız için uygulanabilir bir DNSSEC planı

Küçük bir WordPress sitesi için tercihim, DNSSEC desteği ve anahtar döndürme otomasyonu bulunan bir DNS sağlayıcısı kullanmak. Önce mevcut zone kayıtlarını dışarı alırım, DNSSEC’i sağlayıcı tarafında açarım, oluşan DS bilgisini registrar’a girerim ve farklı resolver’larla doğrulama yaparım. Değişikliği tarih, DS digest ve sağlayıcı bilgisiyle kayıt altına alırım.

Birden fazla site veya e-ticaret altyapısı yönetiyorsanız süreç daha sıkı olmalı. DNS sağlayıcısının bakım duyurularını takip edin, registrar erişimini tek kişinin hesabına bırakmayın ve DS değişiklikleri için onay mekanizması kullanın. DNS değişikliği tek satır gibi görünür; yanlış satır müşterilerin e-posta, web sitesi ve üçüncü taraf API erişimlerini aynı anda etkileyebilir.

Taşıma planına şu maddeleri ekleyin:

• Mevcut DS ve DNSKEY değerlerini kaydetmek
• Yeni yetkili DNS sunucusunda DNSSEC durumunu doğrulamak
• DS kaydını yalnızca yeni anahtar hazır olduktan sonra değiştirmek
• Eski DNS sağlayıcısını hemen kapatmamak
• Farklı resolver’larla A, AAAA, MX ve TXT sorguları yapmak
• İmzaların geçerliliği ve nameserver tutarlılığı için izleme kurmak

Evdeki lab’da test alanını birkaç dakika erişilemez duruma sokmam üretimde işime yarayan bir hataydı. Müşteri yoktu, kahvem vardı. Üretimde DNSSEC değişikliğini bakım planı, doğrulama adımları ve geri dönüş kaydı olmadan yapmıyorum.

Sık Sorulan Sorular

DNSSEC nedir, her alan adı için gerekli midir?

DNSSEC, DNS cevaplarının yetkili kaynaktan geldiğini ve değiştirilmediğini doğrulayan bir güvenlik katmanıdır. Her alan adı için zorunlu değildir; alan adı ele geçirme, sahte DNS cevabı ve kritik e-posta kayıtlarının değiştirilmesi risklerini azaltmak isteyen siteler için değerlidir.

DNSSEC web sitesini yavaşlatır mı?

DNS cevaplarına imza ve doğrulama bilgileri eklendiği için yanıt boyutu artabilir. Düzgün yapılandırılmış bir DNS hizmetinde bu durum genellikle kullanıcı tarafından fark edilen bir web sitesi yavaşlığı oluşturmaz. Nameserver performansı, TTL ve resolver seçimi ayrıca değerlendirilmelidir.

DNSSEC açınca SSL sertifikasına hâlâ ihtiyaç var mı?

Evet. DNSSEC DNS kayıtlarının doğruluğunu, SSL/TLS ise tarayıcı ile sunucu arasındaki bağlantının şifrelenmesini ve sunucu kimliğini korur. Farklı katmanlarda çalıştıkları için birbirlerinin alternatifi değildir.

DNSSEC sonrası alan adım SERVFAIL veriyor, ne yapmalıyım?

Önce registrar’daki DS kaydını, yetkili sunuculardaki DNSKEY ve ilgili RRSIG kayıtlarını karşılaştırın. dig +trace, dig +dnssec ve farklı resolver sorguları zincirin hangi noktasında koptuğunu gösterebilir. DS kaydını silmek yalnızca kontrollü bir acil durum seçeneği olmalıdır.