Unbound ile Bölgesel DNS Cache ve Forwarder Ayrıştırma

Kurumsal ağlarda DNS sorunlarının önemli bölümü aslında isim çözme başarısızlığından değil, yanlış forwarder seçimi ve kontrolsüz cache davranışından kaynaklanır. Kullanıcı ağı, uygulama segmenti ve yönetim koridoru aynı resolver’a bağlandığında bir noktadan sonra hangi sorgunun nereye gittiğini okumak zorlaşır. Unbound bu işi karmaşıklaştırmadan çözmek için güçlü bir araçtır: farklı erişim ağları için ayrı policy, ayrı forward zone ve kontrollü cache davranışı tanımlayabilirsiniz.

Kurulum hedefi

Bu rehberde şu örnek senaryoyu kuruyoruz:

• 10.10.0.0/16 kullanıcı ağı internet çözümlemesi için genel forwarder kullanacak.
• 10.20.0.0/16 uygulama ağı iç zone’lar için kurumsal DNS’e, diğer kayıtlar için kontrollü dış forwarder’a gidecek.
• 10.30.0.0/16 yönetim ağı yalnızca iç zone çözebilecek.

Bu yapı tek Unbound örneğiyle başlanabilecek kadar basit, ama segment bazlı davranışı gösterecek kadar da gerçekçidir.

Örnek yapılandırma

Minimal unbound.conf örneği şöyle olabilir:

server:
  interface: 0.0.0.0
  port: 53
  do-ip4: yes
  do-ip6: no
  access-control: 10.10.0.0/16 allow
  access-control: 10.20.0.0/16 allow
  access-control: 10.30.0.0/16 allow
  access-control: 0.0.0.0/0 refuse
  prefetch: yes
  cache-min-ttl: 60
  cache-max-ttl: 900
  logfile: "/var/log/unbound.log"
  verbosity: 1

view:
  name: "users"
  view-first: yes
  access-control-view: 10.10.0.0/16 users
  forward-zone:
    name: "."
    forward-addr: 1.1.1.1
    forward-addr: 1.0.0.1

view:
  name: "apps"
  view-first: yes
  access-control-view: 10.20.0.0/16 apps
  forward-zone:
    name: "corp.internal."
    forward-addr: 10.50.0.10
  forward-zone:
    name: "."
    forward-addr: 9.9.9.9

view:
  name: "admin"
  view-first: yes
  access-control-view: 10.30.0.0/16 admin
  local-zone: "." refuse
  forward-zone:
    name: "corp.internal."
    forward-addr: 10.50.0.10

Burada dikkat edilmesi gereken nokta view-first davranışıdır. İstemci önce eşleşen görünümle işlenir; böylece aynı resolver üzerinde bağlama göre farklı forwarder politikaları uygulanır.

Neden TTL değerlerini sıkı tutuyoruz?

Kurumsal ortamlarda çok uzun TTL ilk bakışta performans kazanımı gibi görünür; fakat değişiklik ve incident anlarında cache etkisini büyütür. Özellikle entegrasyon uçları, failover kayıtları veya bakım sırasında değişen servis isimleri için kısa ama anlamlı TTL daha güvenlidir. Yukarıdaki örnekte cache-max-ttl: 900 ile cache’i sonsuza bırakmıyoruz; yine de resolver seviyesinde gereksiz yükü azaltıyoruz.

Günlük operasyon için testler

Kurulumdan sonra şu testleri ayrı istemci ağlarından çalıştırın:

dig @resolver-ip example.com
dig @resolver-ip app01.corp.internal
dig @resolver-ip txt suspicious-domain.test

Beklenen davranış şu olmalı:

• Kullanıcı ağı iç zone’u çözmemeli.
• Uygulama ağı hem iç zone’u hem kontrollü dış kayıtları çözebilmeli.
• Yönetim ağı dış internet çözümlemesi yapamamalı.

Bu testleri sadece başarılı cevap üzerinden değil, doğru reddedilme davranışı üzerinden de değerlendirin.

Log ve gözlem önerisi

Unbound tek başına geniş observability sunmaz; ama doğru yerlere bağlandığında yeterli sinyali verir. Ben şu alanların merkezi log hattına taşınmasını öneriyorum:

• İstemci IP veya segment etiketi
• Sorgu adı ve türü
• Cevap kodu
• Gecikme ve upstream hedefi

Bu sayede DNS cache isabet oranı ile politika ihlali davranışını aynı tabloda görebilirsiniz. Özellikle yönetim segmentinde dış isim çözme denemeleri değerli bir sinyal üretir.

Yaygın hata: Her segment için yeni resolver açmak

Büyük kurumlarda bu bazen gerekli olabilir; ancak çoğu ekip çok erken parçalanmaya gidiyor. Önce politika ayrıştırmasını aynı araç üzerinde kurup davranışı görünür kılmak daha sağlıklı. Ölçek veya regülasyon gereği ayrım gerekiyorsa sonrasında fiziksel ayrıştırmaya geçebilirsiniz.

Sonuç

Unbound ile bölgesel DNS cache ve forwarder ayrıştırma, çözümleme katmanını okunabilir bir ağ kontrolüne dönüştürür. Tek bir resolver yazılımı üzerinde segment bazlı erişim, farklı forwarder yolları ve kontrollü cache davranışı kurarak hem güvenliği hem teşhis kabiliyetini artırabilirsiniz. Özellikle kurumsal uygulama ve yönetim ağlarında bu yaklaşım sessiz ama etkili bir altyapı kazanımı sağlar.