DNS Güvenliği Rehberi: DNSSEC Doğrulama, DoT/DoH ve RPZ ile Zararlı Alan Adı Engelleme

DNS, bir kurumun en sessiz ama en kritik bağımlılığıdır. Her oturum açma, her API çağrısı, her güncelleme kontrolü önce bir ad çözümlemesiyle başlar. Aynı nedenle DNS, saldırganın da en çok işine yarayan katmandır: komuta kontrol trafiği burada gizlenir, oltalama alan adları burada çözümlenir, veri sızdırma burada tünellenir.

Bu rehber DNS'i üç ayrı eksende ele alır: cevabın doğruluğunu koruyan DNSSEC, sorgunun gizliliğini koruyan DoT/DoH ve zararlı alan adlarını engelleyen RPZ. Üçü farklı sorunları çözer; biri diğerinin yerine geçmez. Örnek yapılandırmalar Unbound ve BIND 9 üzerinden verilmiştir ve önce test ortamında denenmelidir.

1. DNS saldırı yüzeyi

Saldırı	Ne yapar?	Doğru karşı önlem
Cache poisoning	Çözümleyicinin önbelleğine sahte kayıt yerleştirir	DNSSEC doğrulama, kaynak port rastgeleliği, 0x20
On-path manipülasyon	Şifresiz UDP/53 cevabını yolda değiştirir	DoT/DoH (istemci-çözümleyici arası), DNSSEC
NXDOMAIN hijack	Olmayan alan adını reklam/oltalama sayfasına yönlendirir	Kendi çözümleyicini işletmek, DNSSEC
DNS tünelleme	Sorgu/cevap alanlarında veri sızdırır veya C2 taşır	Sorgu telemetrisi, uzunluk/entropi analizi, RPZ
Domain shadowing	Ele geçirilmiş bölgede alt alan adı oluşturur	Kayıt şirketi MFA, registry lock, bölge izleme
Rezolver açığa çıkması	Açık çözümleyici DDoS yansıtmasında kullanılır	access-control, rate limit, RRL
Uzun TTL kötüye kullanımı	Zararlı kayıt önbellekte uzun süre kalır	TTL üst sınırı, hızlı önbellek boşaltma yeteneği

Tabloda görüldüğü gibi tek bir kontrol tüm satırları kapatmaz. DNSSEC tünellemeyi engellemez; DoH önbellek zehirlenmesini çözmez; RPZ kriptografik doğrulama yapmaz.

2. Önce kendi çözümleyicinizi işletin

Kurum içi istemcilerin doğrudan internetteki genel çözümleyicilere çıkması, hem görünürlüğü hem kontrolü ortadan kaldırır. Güvenlik açısından doğru mimari, iç ağda denetlenen bir çözümleyici katmanı ve dışarıya yalnız bu katmanın çıkmasıdır.

İstemciler yalnız kurum çözümleyicilerini kullanabilmelidir.
Güvenlik duvarında istemcilerden dışarıya doğrudan 53/UDP, 53/TCP, 853/TCP ve bilinen DoH uç noktaları kapatılmalıdır.
Yetkili (authoritative) sunucu ile çözümleyici (recursive) rolleri aynı örnekte birleştirilmemelidir.
Çözümleyici yalnız iç ağdan sorgu kabul etmelidir.
Tüm sorgular merkezî bir toplayıcıya aktarılmalıdır.

Unbound tarafında en temel erişim sınırı şu şekildedir:

CODE TERMINAL

server:
    interface: 10.10.0.53
    access-control: 0.0.0.0/0 refuse
    access-control: 10.0.0.0/8 allow
    access-control: 127.0.0.0/8 allow
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-below-nxdomain: yes
    qname-minimisation: yes
    minimal-responses: yes

qname-minimisation, RFC 9156 ile tanımlanan ve üst seviye sunuculara tam alan adı yerine yalnız gereken etiketi gönderen davranıştır. Yetkili sunucuların gördüğü bilgi miktarını azaltır ve varsayılan olarak açık tutulmalıdır.

3. DNSSEC doğrulama: cevabın bütünlüğü

DNSSEC, DNS cevaplarını imzalayarak "bu cevap gerçekten bu bölgenin sahibinden mi geldi ve yolda değiştirildi mi?" sorusunu kriptografik olarak yanıtlar. Gizlilik sağlamaz; cevap yine açık metindir. Doğrulamanın değeri, çözümleyicide açık olmasındadır.

Unbound'da doğrulama, kök güven çıpasının tanımlanmasıyla etkinleşir:

CODE TERMINAL

server:
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    val-permissive-mode: no
    val-log-level: 1
    aggressive-nsec: yes

BIND 9'da karşılığı şudur:

CODE TERMINAL

options {
    dnssec-validation auto;
    qname-minimization relaxed;
    recursion yes;
    allow-query { internal; };
};

Doğrulamanın gerçekten çalıştığı, bilerek bozulmuş imza barındıran test alan adlarıyla sınanmalıdır. Doğru yapılandırılmış bir çözümleyici bu sorguya SERVFAIL döner:

CODE TERMINAL

dig @10.10.0.53 dnssec-failed.org +dnssec
dig @10.10.0.53 example.com +dnssec | grep -E "flags:|ad;|SERVFAIL"

Cevaptaki ad (authenticated data) bayrağı, çözümleyicinin doğrulamayı yaptığını gösterir. Bayrak yoksa doğrulama devre dışıdır ya da bölge imzalı değildir.

Sık yapılan hata: doğrulama açıldıktan sonra bazı iç alan adları çözülmeyince `val-permissive-mode: yes` açmak. Bu ayar, doğrulama hatasını yalnız günlüğe yazar ve cevabı yine de teslim eder; yani korumayı fiilen kapatır. Doğru çözüm, iç bölgeleri istisna listesine almak veya iç DNS'i düzgün imzalamaktır.

CODE TERMINAL

server:
    domain-insecure: "corp.internal"
    local-zone: "corp.internal." transparent

DNSSEC'in kapsamı konusunda gerçekçi olmak gerekir: doğrulama yalnız çözümleyici ile yetkili sunucu arasındaki cevabın bütünlüğünü korur. Çözümleyici ile istemci arasındaki "son adım" güvenliği ayrı bir konudur ve DoT/DoH ile ele alınır.

4. DoT ve DoH: sorgunun gizliliği

RFC 7858 ile tanımlanan DNS over TLS (853/TCP) ve RFC 8484 ile tanımlanan DNS over HTTPS, istemci ile çözümleyici arasındaki sorguları şifreler. Böylece yereldeki bir gözlemci hangi alan adının sorulduğunu göremez.

Bu iki protokolü kurumsal ortamda değerlendirirken iki farklı senaryo ayrılmalıdır:

Senaryo	Etki	Öneri
Kurum çözümleyicisi DoT/DoH sunar	İç trafikte sorgu gizliliği artar, görünürlük korunur	Tercih edilen model
İstemci doğrudan dış DoH sağlayıcısına çıkar	Kurum DNS görünürlüğünü ve RPZ engelini kaybeder	Politika ile kapatılmalı
Tarayıcı kendi DoH'unu açar	Uç nokta DNS politikası atlanır	Kurumsal politika ile yönetilmeli
Çözümleyici yukarı akışta DoT kullanır	ISP seviyesinde izleme azalır	Doğrulanmış sağlayıcıyla uygulanabilir

Unbound'da çözümleyicinin istemcilere DoT sunması:

CODE TERMINAL

server:
    interface: 10.10.0.53@853
    tls-service-key: "/etc/unbound/tls/dns.key"
    tls-service-pem: "/etc/unbound/tls/dns.pem"
    tls-port: 853

Yukarı akışta şifreli iletim isteniyorsa yönlendirme bölümü kullanılır:

CODE TERMINAL

forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 9.9.9.9@853#dns.quad9.net

Kritik nokta: `forward-addr` satırındaki `#sunucu.adı` kısmı sertifika adı doğrulaması içindir. Bu kısım yazılmazsa bağlantı şifreli olur ama karşı tarafın kimliği doğrulanmaz; ortadaki adam saldırısına karşı beklenen koruma elde edilmez.

Şifreli DNS, sorgunun içeriğini yoldaki gözlemciden gizler; çözümleyiciden gizlemez. Yani güven, sorguyu çözen tarafa aktarılmış olur. Bu nedenle kurumsal ortamda tercih edilmesi gereken model, dış sağlayıcıya çıkmak değil, kendi çözümleyicinizi şifreli hale getirmektir.

5. RPZ ile zararlı alan adı engelleme

Response Policy Zone, çözümleyicinin belirli alan adlarına verdiği cevabı politikayla değiştirmesini sağlar. Tehdit istihbaratı beslemelerini bir DNS bölgesi gibi taşıyabilmesi ve bölge transferiyle güncellenebilmesi en güçlü yanıdır.

BIND 9 tarafında tanım:

CODE TERMINAL

options {
    response-policy {
        zone "rpz.local" policy given;
        zone "rpz.threatfeed" policy given;
    } qname-wait-recurse no
      break-dnssec no;
};

zone "rpz.local" {
    type master;
    file "/etc/bind/rpz.local.db";
    allow-query { none; };
};

Bölge dosyası normal bir zone dosyasıdır; sağ taraf politikayı belirler:

CODE TERMINAL

$TTL 60
@   IN SOA rpz.local. admin.corp.example. (
        2026091601 3600 900 604800 60 )
    IN NS  localhost.

; NXDOMAIN döndür
kotu-alanadi.example        CNAME   .
*.kotu-alanadi.example      CNAME   .

; Sinkhole IP'sine yönlendir
c2-panel.example            A    10.10.0.9
*.c2-panel.example          A    10.10.0.9

; Politikadan muaf tut (walled garden)
musteri-portali.example     CNAME   rpz-passthru.

Buradaki üç davranış ayrımı önemlidir. CNAME . NXDOMAIN üretir ve en sessiz seçenektir. Sinkhole IP'sine yönlendirme ise daha değerlidir: engellenen isteği yapan istemciyi tespit edebilirsiniz.

Sinkhole'u gözlemleyin. Boşluğa yönlendirmek yerine, sinkhole adresinde bağlantıyı kabul edip kaydeden basit bir dinleyici çalıştırmak, hangi iç makinenin hangi zararlı alan adına ne sıklıkta ulaşmaya çalıştığını gösterir. Engelleme bir tespit fırsatıdır; yalnız bir duvar değildir.

6. break-dnssec ve passthru tuzakları

RPZ tanım gereği cevabı değiştirir; bu da DNSSEC doğrulamasıyla çelişir. `break-dnssec no` ayarı, DNSSEC doğrulaması yapan istemcilerin manipüle edilmiş cevabı reddetmesine yol açabilir ve RPZ kuralı beklendiği gibi görünmez.

RPZ ve DNSSEC'in birlikte davranışını mutlaka test ortamında doğrulayın.
Kritik iş uygulamalarının alan adlarını passthru listesine alarak yanlış pozitif riskini düşürün.
Beslemeleri doğrudan üretime bağlamadan önce "yalnız günlükle" modunda bir süre izleyin.
Engelleme listelerinin kaynağını, güncellenme sıklığını ve yanlış pozitif geçmişini belgeleyin.
Acil durumda tek bir kuralı hızlı kaldırabileceğiniz bir süreç tanımlayın.
Engellenen sorguları SIEM'e ayrı bir olay tipi olarak gönderin.

Tehdit beslemesi kalitesi doğrudan operasyonel yüke dönüşür. Aşırı geniş bir liste, kısa sürede güveni kaybettirir ve tüm RPZ katmanının kapatılmasıyla sonuçlanır.

7. DNS telemetrisi ve tehdit avcılığı

Engelleme kadar önemli olan, sorgu kayıtlarının toplanması ve analiz edilmesidir. DNS günlükleri, uç noktaya ajan kurulamayan ortamlarda bile davranışsal sinyal üretir.

Unbound'da sorgu günlüğü:

CODE TERMINAL

server:
    log-queries: yes
    log-replies: yes
    log-tag-queryreply: yes
    logfile: "/var/log/unbound/unbound.log"

BIND 9'da ayrı bir kanal kullanmak, güvenlik günlüklerini işletim günlüklerinden ayırır:

CODE TERMINAL

logging {
    channel query_log {
        file "/var/log/named/queries.log" versions 10 size 100m;
        severity info;
        print-time yes;
    };
    category queries { query_log; };
    category rpz { query_log; };
};

Avcılık sırasında aranacak kalıplar:

Tek bir istemciden aynı üst alan adına yüksek hacimli, benzersiz alt alan adı sorguları (tünelleme sinyali).
Alışılmadık uzunlukta ve yüksek entropili etiketler.
Çok kısa TTL'li ve sık değişen A kayıtları (fast flux).
Yeni kaydedilmiş alan adlarına ilk kez yapılan çözümlemeler.
Normal iş saatleri dışında düzenli aralıklarla tekrar eden sorgular (beaconing).
TXT ve NULL kayıt tiplerinde olağandışı hacim.
Kurum çözümleyicisini atlayarak dışarıya çıkma denemeleri.

Bu sinyallerin hiçbiri tek başına kanıt değildir. Değerleri, aynı istemcide birkaçının aynı zaman aralığında birleşmesindedir.

8. Yetkili sunucu tarafı

Kendi alan adınızı yayınlıyorsanız savunma sorumluluğu çift yönlüdür. Bölgenizin imzalanması, kullanıcılarınızı sizin adınıza yapılacak manipülasyondan korur.

Bölgeyi DNSSEC ile imzalayın ve DS kaydını kayıt şirketinde doğru yayımlayın.
Anahtar döndürme sürecini otomatikleştirin ve takvime bağlayın.
Kayıt şirketi hesabında MFA ve mümkünse registry lock kullanın.
Bölge transferini yalnız TSIG ile yetkilendirilmiş ikincil sunuculara açın.
Yetkili sunucuda özyineleme (recursion) kapalı olmalıdır.
Response Rate Limiting ile yansıtma saldırılarında kullanılmayı zorlaştırın.
Kullanılmayan alt alan adı kayıtlarını silin; sarkan CNAME'ler devralma riski yaratır.

Yetkili sunucuda özyinelemeyi kapatmak ve oran sınırlamak temel bir yapılandırmadır:

CODE TERMINAL

options {
    recursion no;
    allow-transfer { key tsig-secondary; };
    rate-limit {
        responses-per-second 15;
        window 5;
    };
};

9. Devreye alma sırası

Bu katmanların hepsini aynı gün açmak, bir sorun çıktığında hangi değişikliğin sebep olduğunu belirsizleştirir. Aşağıdaki sıra hem riski hem geri dönüş maliyetini düşürür.

Sorgu telemetrisini açın ve iki hafta boyunca temel davranışı ölçün.
Çözümleyiciyi erişim listesiyle sınırlayın ve açık çözümleyici olmadığını dışarıdan doğrulayın.
DNSSEC doğrulamasını açın; iç bölgeler için istisnaları tanımlayın.
Doğrulamanın çalıştığını bozuk imzalı test alan adıyla kanıtlayın.
RPZ'yi önce yalnız günlük modunda devreye alın, yanlış pozitifleri ölçün.
RPZ'yi engelleme moduna alın ve passthru listesini sürüm kontrolüne bağlayın.
Çözümleyiciye DoT sunun ve istemcileri buraya yönlendirin.
İstemcilerin dış DNS ve DoH uç noktalarına çıkışını güvenlik duvarında kapatın.
Engellenen sorgu olaylarını SIEM'de tespit kuralına bağlayın.

10. Sık yapılan hatalar

DNSSEC'in gizlilik sağladığını sanmak; sağlamaz, yalnız bütünlük ve köken doğrulaması verir.
DoH kullanıldığı için kurumun DNS güvenliğinin tamam sayılması; DoH yalnız taşıma katmanını korur.
Doğrulama hatalarını permissive mode ile susturmak.
Yukarı akış DoT'ta sertifika adı doğrulamasını atlamak.
RPZ listelerini test etmeden üretime almak.
Sinkhole trafiğini kaydetmeyip tespit fırsatını kaçırmak.
Yetkili ve çözümleyici rollerini aynı sunucuda birleştirmek.
İstemcilerin kurum çözümleyicisini atlamasını engellememek.
Sarkan CNAME kayıtlarını temizlememek.

Sonuç

DNS güvenliği tek bir ürünle değil, birbirini tamamlayan üç kontrolle kurulur: DNSSEC cevabın doğruluğunu, DoT/DoH sorgunun gizliliğini, RPZ ise bilinen zararlı alan adlarının engellenmesini sağlar. Bu üçünü ölçülebilir telemetriyle birleştirdiğinizde DNS, saldırganın saklandığı bir katman olmaktan çıkıp savunmanın en erken uyarı veren sensörüne dönüşür.

Resmî kaynaklar

TR Siber Ekibi Yazar · X

Kaynak bağlantısı ← Ana sayfaya dön