DNS RPZ ile Kurumsal DNS Firewall: Tehdit Bloklama ve Operasyon

Kurum içinde “DNS sadece isim çözer” gibi görülür; sahada DNS çoğu zaman en iyi politika enjeksiyon noktasıdır. Çünkü malware, phishing, yanlış proxy ve “gizli dışa çıkış” senaryolarının büyük kısmı ilk olarak isim çözümleme katmanında iz bırakır.

RPZ (Response Policy Zone) yaklaşımı, recursive resolver’ın “cevabı değiştirme / engelleme” kabiliyetiyle kurumsal bir DNS firewall katmanı kurmanı sağlar. En kritik fark: bunu yaparken istemciyi kırmadan, istisna yönetimini kaybetmeden ve operasyonu sürdürülebilir tutarak ilerlersin.

RPZ hangi problemi çözer?

RPZ ile resolver şu tür kararlar alabilir:

• Belirli domainleri NXDOMAIN döndür (blokla)
• Belirli domainleri “sinkhole” IP’sine çöz (kısıtlı karantina)
• Bazı kayıt tiplerini (özellikle A/AAAA) politika ile bastır

Bu sayede:

• kullanıcıların malware C2’ye gitme ihtimali düşer
• phishing domainleri ilk adımda kesilir
• “güvenli egress” yaklaşımında DNS, ağ politikasının parçasına dönüşür

Mimaride doğru konum: Recursive resolver katmanı

RPZ’yi recursive resolver üzerinde kurgula:

• İstemci ayarı net: DHCP/AD/MDM ile “kurumsal resolver” zorunlu
• Resolver sayısı en az 2 (site/region bazlı HA)
• Resolver log’ları tek pipeline’a akar (SIEM + metrik)

RPZ’yi authoritative DNS tarafına “yan iş” gibi eklemek genelde iyi sonuç vermez; çünkü politika ownership’i resolver/edge operasyonunun parçasıdır.

Politika kaynağı: feed + yerel istisna

Sahada sürdürülebilir model iki katmanlıdır:

1. Upstream threat feed (ticari veya açık kaynak listeler) → otomatik güncelleme
2. Yerel istisna/allowlist → ticket ile, süreli (TTL’li) ve denetlenebilir

Örnek: BIND üzerinde RPZ (konsept)

RPZ mantığını göstermek için sade bir örnek (prod’da kendi standardınla uyumlu hale getir):

// named.conf (örnek)
response-policy { zone "rpz.local"; } break-dnssec yes;

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

Örnek RPZ zone dosyası:

$TTL 60
@ IN SOA rpz.local. hostmaster.rpz.local. (1 3600 600 86400 60)
  IN NS  rpz.local.

; Blok: phishing domain
bad-example.com          CNAME   .
*.bad-example.com        CNAME   .

; Sinkhole: telemetri için kontrollü yönlendirme (içte bir HTTP 204 servisine)
telemetry-test.example   A       10.60.10.10

Notlar:

• CNAME . yaklaşımı çoğu kurulumda “policy NXDOMAIN” gibi davranır.
• Sinkhole kullanıyorsan, kayıt altına aldığın ve güvenli tuttuğun bir IP’ye çöz.

Operasyonel runbook: “RPZ devreye alma” nasıl yapılır?

Ben sahada aşağıdaki sırayla ilerliyorum:

1. Pilot halka: küçük bir OU/VLAN/site üzerinde resolver zorunlu
2. Gözlem: 48–72 saat “ne kırılıyor” raporu (top NXDOMAIN, top blocked, top exceptions)
3. İstisna akışı: ticket şablonu + süre + owner + geri alma
4. Rollout: ring1 → ring2 → tüm kullanıcılar
5. Denetim: istisnaları periyodik temizle (90 gün kuralı)

İstisna ticket şablonu (minimum)

• Domain/FQDN (wildcard gerekiyorsa gerekçe)
• Etkilenen uygulama / iş süreci
• Owner (ekip) + onaylayan
• Süre (ör. 7 gün) + “kalıcı olacaksa” kalıcılaştırma aksiyonu
• Alternatif: uygulamayı proxy/allowlist üzerinden çözme seçeneği var mı?

Ölçüm: RPZ “çalışıyor mu” nasıl anlarsın?

Minimum metrik seti:

• blocked_qps (zaman serisi)
• top_blocked_domains (cardinality kontrolü ile)
• Resolver SERVFAIL oranı (yanlış politika DNS’i kırabilir)
• İstisna sayısı (zamanla artıyorsa model bozuluyor olabilir)
• Resolver latency p95/p99

Log’larda özellikle şu alanlar altın değerinde:

• kaynak IP / cihaz kimliği (mümkünse)
• query name + query type
• policy hit (RPZ)
• response code

Güvenliğin yanında “kırmama” disiplini

RPZ’yi güvenlik katmanı olarak görürken iki üretim gerçeğini unutma:

• Bazı SaaS’lar çok agresif domain üretir (CDN, telemetry, A/B test)
• Bazı eski uygulamalar DNS timeouts’larını “uygulama hatası” diye maskeler

Bu yüzden:

• wildcard blokları çok dikkatli kullan
• RPZ değişikliklerini “change” gibi yönet (önce küçük halka)
• rollback planı yaz (tek satır: policy zone’larını kapatıp reload)

Sonuç

RPZ ile kurumsal DNS firewall kurmak, ağ güvenliğini “perimeter cihazı” ile sınırlı olmaktan çıkarıp isim çözümleme katmanına taşır. Asıl başarı teknik ayarda değil; istisna disiplini, gözlemlenebilirlik ve sahiplik modelindedir. Bu üçü oturduğunda RPZ; phishing/malware riskini düşüren, aynı zamanda operasyon ekibine de güçlü bir sinyal üreten bir kontrol düzlemi haline gelir.