Kurumsal ağlarda “DNS kontrolü” yıllarca basit bir varsayıma dayanıyordu: istemci UDP/53 (ve bazen TCP/53) ile kurum resolver’ına gider; proxy/firewall/DNS filtreleme katmanı trafiği görür, kayıt tutar, gerektiğinde engeller. DoH (DNS over HTTPS), DoT (DNS over TLS) ve DoQ (DNS over QUIC) bu varsayımı değiştirir.
Bu değişiklik “DNS’i şifreledik, bitti” değildir. Kurum açısından iki soruyu aynı anda doğurur:
- Politika: İstemciler “kendi resolver’ını” seçip kurum politikasını bypass edebilir mi?
- Görünürlük: DNS sinyali kaybolursa incident triage, threat hunting ve egress kontrolü nasıl yapılır?
Bu yazıda ürün bağımsız, operasyon odaklı bir çerçeve sunuyorum: DoH/DoT/DoQ’yu yasaklamak veya serbest bırakmak ikilemine sıkışmadan, kontrollü geçiş tasarlamak.
1) Tehdit modeli: DoH/DoT/DoQ neyi değiştiriyor?
Kurumsal tarafta değişenler:
- DNS telemetry (domain, query tipi, NX ratio, resolver davranışı) artık “ağ cihazı” tarafından kolay okunamayabilir.
- Bazı istemci uygulamaları hardcoded resolver veya “secure DNS” ayarıyla kurum resolver’ını bypass eder.
- DoH trafiği HTTPS içine gömüldüğü için, sıradan port engelleme ile ayrıştırmak zorlaşır (özellikle büyük sağlayıcı endpoint’leri).
Değişmeyenler:
- Kurum hâlâ egress sınırından sorumludur: “hangi endpoint’e hangi cihaz neden gidiyor?”
- Incident anında hâlâ aynı soru sorulur: “Bu istemci hangi domaine gitti, ne zaman gitti, hangi IP’ye çözüldü?”
2) Kurumsal hedefi seç: kontrol mü, uyumluluk mu, kullanıcı deneyimi mi?
DoH/DoT/DoQ politikası tek cümlelik “aç/kapat” kararı değil. Tipik hedefler:
- Güvenlik: Malware / phishing domain’leri engelle, DNS tunneling sinyallerini gör.
- Uyumluluk: Kayıt tut, olayda delil üret.
- Performans: Edge resolver cache verimini artır, gecikmeyi düşür.
- Mahremiyet: İç ağda bile DNS metadata’sını minimize et.
Bu hedefler çakışabilir. Bu yüzden “tek ürün” yerine tasarım prensibi koyun.
3) Mimari seçenekler: 3 pratik model
Model A — Kurum içi resolver + açık DoH/DoT/DoQ kapalı (strict)
- Egress’te 853/TCP (DoT) ve 784/UDP (DoQ) gibi portları kontrol etmek nispeten kolaydır.
- DoH (443) ise “HTTPS” içinde olduğu için daha zordur; burada yaklaşım çoğu zaman known DoH endpoint listesi + SNI/ALPN politikası gibi tekniklere kayar (ürüne göre değişir).
Risk: Eğer politikayı “tam engel” ile uygularsanız, yanlış eşik müşteri kaybına (veya operasyon bypass kültürüne) yol açabilir.
Model B — Kurum resolver’ı DoH/DoT sunar (managed)
İstemcilere “secure DNS” açma ihtiyacı doğduğunda en iyi çözüm: kurumun kendi resolver katmanının DoH/DoT desteği.
Kazanç:
- Şifreli taşıma + kurum politikası aynı anda sağlanır.
- DNS telemetry ve audit kaybolmaz; “görünürlük” korunur.
Model C — Split policy: yönetilen cihazlar vs yönetilmeyen cihazlar
- Yönetilen cihazlar: kurum resolver + kimlik/politika (MDM/EDR ile)
- Yönetilmeyen: misafir ağ, BYOD → ayrı politika, ayrı resolver
Bu model “herkesi aynı kurala sokma” hatasını engeller.
4) Görünürlük: DNS log’u yoksa bile sinyal üretebilirsin
DNS log’u kaybolduğunda elinizde kalan veri:
- Egress firewall/proxy log’ları (IP/port, SNI, cert metadata)
- NetFlow/IPFIX/sFlow (akış düzeyi)
- Endpoint telemetry (EDR, browser policy event’leri)
- Resolver tarafında (varsa) query log’ları
Ama hedefiniz şu olmalı: DNS’i tekrar görünür yapmak için “paketi çözmek” değil, karar vermeye yetecek sinyali üretmek.
Pratikte şu metrikler çok değerli:
doh_requests_total(tanımlı endpoint’lere giden 443 trafiği)dns_fail_open_events(politika bypass / fallback)nx_ratiove “domain entropy” (tunneling şüphesi için proxy sinyali)
5) Operasyon runbook’u: DoH/DoT/DoQ incident’inde ne kontrol ederim?
5.1 Belirti: “Bazı kullanıcılar siteye giremiyor”
- DNS mi, TLS mi? (SNI/sertifika hatası mı, resolve edememe mi?)
- İstemci “secure DNS” açık mı? (browser/OS policy)
- Kurum resolver’ı mı kullanıyor, public DoH mu?
- Egress politikası DoH endpoint’lerini yanlış mı sınıflandırdı?
5.2 Belirti: “DNS log’ları kayboldu / SIEM korelasyonu bozuldu”
- DNS sinyali hangi katmandan toplanıyordu? (resolver mı, firewall mı, proxy mi?)
- Yeni bir istemci güncellemesi DoH’u default açtı mı?
- “Managed DoH” (kurum endpoint’i) var mı? Yoksa planla.
5.3 Belirti: “Şüpheli veri sızdırma / DNS tunneling”
- Domain entropy / query pattern anomali var mı?
- Akış hacmi normal DNS profilinden sapıyor mu? (bytes/query)
- İstemci bazında DoH trafiği patladı mı?
6) Kapanış: Şifreli DNS’i düşman değil, tasarım girdisi yap
DoH/DoT/DoQ’yu “ya yasakla ya serbest bırak” diye ele almak çoğu kurumda ya bypass kültürü üretir ya da görünürlük kaybına yol açar. Doğru yaklaşım:
- Kurum resolver’ını kontrol düzlemi yap
- Yönetilen cihazlarda “managed secure DNS” modeline yönel
- Görünürlük için “paket çözme” yerine karar sinyali üret
- Runbook ve metrikleri ilk günden kur
Şifreli DNS dünyasında başarı, DNS’i gizlemek değil; DNS davranışını operasyonel olarak yönetilebilir kılmaktır.