Unbound’da Forward Zone ile Upstream DNS Yönlendirme

Yazar:komut.io ekibi Unbound DNS Sunucusu Kurulum ve Yönetimi
0 Yorum

Bir DNS sunucusu kurduğunuzda eninde sonunda şu soruyla yüzleşirsiniz: “Hangi sorgular nereye gitsin?” Unbound’un forward zone özelliği tam da bu soruyu yanıtlamak için var. Yıllarca BIND, dnsmasq ve Unbound ile uğraştıktan sonra şunu söyleyebilirim: forward zone’ları doğru yapılandırmak, DNS altyapınızın hem performansını hem de güvenliğini doğrudan etkiler. Bu yazıda Unbound’da forward zone ile upstream DNS yönlendirmesini gerçek dünya senaryolarıyla ele alacağız.

Forward Zone Nedir ve Neden Gereklidir?

Unbound varsayılan olarak recursive bir çözümleyicidir. Yani bir sorgu geldiğinde root sunuculara gider, oradan TLD sunucularına, oradan yetkili sunuculara ulaşarak cevabı kendisi bulur. Bu harika bir yaklaşım ama her zaman istediğiniz şey değildir.

Forward zone, belirli bir DNS bölgesi için gelen sorguları kendiniz çözmek yerine başka bir DNS sunucusuna iletmek demektir. Örneğin:

  • Şirket içi .corp.example.com sorgularını iç DNS sunucunuza yönlendirmek
  • Tüm dış sorguları Cloudflare veya Quad9 gibi bir upstream sunucuya göndermek
  • Belirli bölgeler için farklı resolver’lar kullanmak

Dnsmasq ile bu işi yapıyorsanız ve Unbound’a geçiyorsanız, konsept aynı ama sözdizimi farklı. Şaşırmayın, birkaç satır yapılandırmayla halloluyor.

Temel Yapılandırma Dosyası Yapısı

Unbound’un ana yapılandırma dosyası genellikle /etc/unbound/unbound.conf konumundadır. Modern dağıtımlarda ise bu dosya /etc/unbound/unbound.conf.d/ dizinindeki parçalı yapılandırmaları include eder. Ben her zaman parçalı yapıyı tercih ederim, nedenini birazdan anlayacaksınız.

# Mevcut yapılandırma yapısını inceleyelim
ls -la /etc/unbound/
cat /etc/unbound/unbound.conf | grep include

Tipik bir Unbound kurulumunda şu yapıyı görmek normaldir:

# /etc/unbound/unbound.conf içeriği
server:
    # Temel ayarlar buraya gelir

include: "/etc/unbound/unbound.conf.d/*.conf"

Eğer sisteminizde bu include direktifi yoksa manuel olarak eklemenizi öneririm. Böylece her forward zone için ayrı bir dosya tutabilir, değişiklikleri izole edebilirsiniz.

İlk Forward Zone: Tüm Sorguları Upstream’e Yönlendirme

En basit senaryodan başlayalım. Unbound’u bir caching resolver olarak kullanmak istiyorsunuz ve tüm sorguları Cloudflare’e yönlendirmek istiyorsunuz.

# /etc/unbound/unbound.conf.d/forward-all.conf
forward-zone:
    name: "."
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com
    forward-tls-upstream: yes

Burada name: "." ifadesi root zone anlamına gelir, yani tüm sorgular bu kurala tabidir. @853 portu DNS over TLS (DoT) kullandığımızı belirtir. #cloudflare-dns.com kısmı ise TLS sertifika doğrulaması için gerekli hostname’dir.

Bu yapılandırmayı test etmeden önce mutlaka sözdizimini kontrol edin:

# Yapılandırma sözdizimini doğrula
unbound-checkconf /etc/unbound/unbound.conf

# Servisi yeniden başlat
systemctl restart unbound

# Çalışıyor mu kontrol et
systemctl status unbound

Şirket İçi DNS Yönlendirmesi: Gerçek Hayat Senaryosu

Şimdi daha ilginç bir senaryoya geçelim. Diyelim ki şirketinizin Windows Active Directory ortamı var ve .corp.sirket.local gibi bir iç domain kullanıyorsunuz. Bu sorguların iç DNS sunucularınıza gitmesi, dış sorguların ise upstream resolver’a gitmesi gerekiyor.

Bunu yanlış yapılandırdığınızda ne olur? Iç hostname’leri çözemediniz, kullanıcılar dosya sunucularına ulaşamadı, IT’ye telefonlar yağmaya başladı. O yüzden dikkatli olun.

# /etc/unbound/unbound.conf.d/internal-zones.conf

# Şirket iç domain'i için yönlendirme
forward-zone:
    name: "corp.sirket.local"
    forward-addr: 192.168.1.10
    forward-addr: 192.168.1.11
    forward-first: no

# Ters DNS için de yönlendirme (iç IP bloğu)
forward-zone:
    name: "168.192.in-addr.arpa"
    forward-addr: 192.168.1.10
    forward-addr: 192.168.1.11
    forward-first: no

forward-first: no parametresine dikkat edin. Bu, Unbound’un forward zone yapılandırmasında belirtilen sunuculardan cevap alamazsa kendi recursive çözümlemesine geçmeyeceği anlamına gelir. İç domain’ler için bu davranış genellikle istediğiniz şeydir; iç sunucu cevap vermiyorsa recursive çözümleme yine de işe yaramayacak, kullanıcıya hatalı bir cevap döneceğine SERVFAIL dönsün daha iyi.

forward-first: yes Ne Zaman Kullanılır?

forward-first: yes seçeneği ise şu anlama gelir: Önce belirttiğim upstream sunucuya sor, cevap gelmezse ya da hata dönerse sen kendin çöz. Bu ne zaman işe yarar?

Örneğin bir ISP’nin local mirror’larını kullanmak istiyorsunuz ama ISP’nin DNS’i bazen yanıt vermeyebilir. Yedek olarak root sunuculara dönebilmek istiyorsunuz.

# /etc/unbound/unbound.conf.d/isp-forward.conf
forward-zone:
    name: "."
    forward-addr: 217.x.x.x    # ISP DNS sunucusu
    forward-first: yes          # Cevap gelmezse recursive çöz

Pratikte bu yapıyı pek önermem. Ya tam forward kullanın, ya da tamamen recursive. Karma yaklaşımlar beklenmedik davranışlara yol açabiliyor.

DNS over TLS ile Güvenli Yönlendirme

Günümüzde upstream sunucularla şifresiz iletişim kurmak kabul edilebilir bir durum değil. DNS sorguları plain-text giderse ISP seviyesinde dinlenebilir, manipüle edilebilir. DoT kullanımı bu riski ortadan kaldırır.

# /etc/unbound/unbound.conf.d/forward-tls.conf
forward-zone:
    name: "."
    # Cloudflare DoT
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com
    # Quad9 DoT (yedek)
    forward-addr: 9.9.9.9@853#dns.quad9.net
    forward-addr: 149.112.112.112@853#dns.quad9.net
    forward-tls-upstream: yes

DoT yapılandırmasının çalışması için server bloğunda birkaç şeyin doğru tanımlanmış olması gerekir:

# /etc/unbound/unbound.conf.d/server-tls.conf
server:
    # TLS için sertifika doğrulama
    tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"
    
    # Debian/Ubuntu için alternatif yol
    # tls-cert-bundle: "/etc/pki/tls/certs/ca-bundle.crt"

Debian ve RHEL tabanlı sistemlerde sertifika demet dosyasının yolu farklıdır. Yanlış yol belirtirseniz TLS doğrulaması başarısız olur ve Unbound upstream’e bağlanamaz.

Yapılandırmayı Test Etme

Yapılandırmayı test etmek için unbound-control ve dig araçlarını kullanın:

# Unbound istatistiklerini ve durumunu kontrol et
unbound-control status

# Belirli bir sorgunun nasıl çözümlendiğini izle
dig @127.0.0.1 google.com +stats

# TLS bağlantısını doğrula
dig @1.1.1.1 -p 853 +tls google.com

# Önbelleği temizle ve tekrar dene
unbound-control flush_zone "."
dig @127.0.0.1 example.com

Özellikle +stats bayrağı çok değerli bilgi verir. Query time, sunucu adresi ve port numarasını gösterir. Forward zone doğru çalışıyorsa query time değeri recursive çözümlemeden daha düşük olmalıdır çünkü upstream sunucu büyük ihtimalle kendi önbelleğinden yanıtlıyordur.

Split-DNS Yapılandırması

Bu konu, kurumsal ortamlarda sıkça karşılaştığım ama yeterince belgelenmemiş bir alan. Split-DNS, aynı domain adı için iç ve dış ağlarda farklı cevaplar döndürmek demek. Unbound bunu forward zone ile zarif bir şekilde halleder.

Senaryo: uygulama.sirket.com için dışarıdan load balancer IP’si görünmeli, içeriden ise doğrudan uygulama sunucusu IP’si.

# /etc/unbound/unbound.conf.d/split-dns.conf

# İç ağdan gelen sorgular için local data
server:
    local-data: "uygulama.sirket.com. A 10.0.1.50"
    local-data-ptr: "10.0.1.50 uygulama.sirket.com"

# Dış sorgular için forward (eğer iç veri bulunamazsa)
forward-zone:
    name: "sirket.com"
    forward-addr: 192.168.1.10    # İç yetkili DNS sunucusu
    forward-addr: 192.168.1.11

Bu yapıda Unbound önce local-data tanımlarına bakar, bulamazsa forward zone’a yönlendirir.

Windows Active Directory Ortamında Unbound

Active Directory ortamları özel dikkat gerektirir. AD, Kerberos, LDAP ve çeşitli servisler için DNS SRV kayıtlarına yoğun şekilde bağımlıdır. Bu kayıtların yanlış çözümlenmesi sessiz sedasız büyük sorunlara yol açar.

# /etc/unbound/unbound.conf.d/ad-forward.conf

# AD domain için forward
forward-zone:
    name: "ad.sirket.com"
    forward-addr: 10.0.0.1       # AD DNS 1
    forward-addr: 10.0.0.2       # AD DNS 2
    forward-first: no

# AD'nin kullandığı MSDCS subdomain
forward-zone:
    name: "_msdcs.ad.sirket.com"
    forward-addr: 10.0.0.1
    forward-addr: 10.0.0.2
    forward-first: no

# Ters DNS yönlendirmesi
forward-zone:
    name: "0.10.in-addr.arpa"
    forward-addr: 10.0.0.1
    forward-addr: 10.0.0.2
    forward-first: no

_msdcs zone’unu ayrıca belirtmek önemlidir. Bazı Unbound versiyonlarında parent zone forward tanımı subdomain’leri kapsamayabiliyor. Güvende olmak için kritik subzone’ları ayrıca tanımlayın.

Çoklu Upstream ile Yük Dağılımı ve Yedeklilik

Tek bir upstream sunucuya bağımlı olmak doğru değil. Unbound, birden fazla forward addr tanımladığınızda bunları round-robin mantığıyla kullanır ve bir sunucu yanıt vermezse diğerine geçer.

# /etc/unbound/unbound.conf.d/forward-redundant.conf
forward-zone:
    name: "."
    # Birincil: Cloudflare DoT
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com
    # İkincil: Quad9 DoT
    forward-addr: 9.9.9.9@853#dns.quad9.net
    forward-addr: 149.112.112.112@853#dns.quad9.net
    # Üçüncül: Google DoT (acil durum)
    forward-addr: 8.8.8.8@853#dns.google
    forward-addr: 8.8.4.4@853#dns.google
    forward-tls-upstream: yes

Burada bir nüans var. Unbound tüm bu sunucuları paralel sorgulamaz, sırayla dener. Birincisi yanıt verirse ikincisine gitmez. Birincisi timeout olursa ikincisini dener. Timeout süresi server bloğundaki timeout parametresiyle ayarlanabilir.

Hata Ayıklama: En Sık Karşılaşılan Sorunlar

Yıllarca DNS sorunlarıyla boğuştuktan sonra şunu öğrendim: sorunların yüzde sekseninin kaynağı ya yanlış IP adresi ya yanlış port ya da firewall kuralıdır.

Forward zone çalışmıyor ama yapılandırma doğru görünüyorsa:

# Unbound log seviyesini artır
# /etc/unbound/unbound.conf içine ekle:
server:
    verbosity: 2
    log-queries: yes

# Logları izle
journalctl -u unbound -f

# Veya log dosyasına yazıyorsa
tail -f /var/log/unbound/unbound.log

Network erişimini test et:

# Upstream sunucuya erişilebilirlik testi
nc -zv 1.1.1.1 853
nc -zv 9.9.9.9 853

# TCP üzerinden DNS sorgusu (firewall testi)
dig @1.1.1.1 +tcp google.com

# TLS el sıkışmasını test et
openssl s_client -connect 1.1.1.1:853 -servername cloudflare-dns.com

Sık karşılaşılan hata durumları:

  • SERVFAIL dönüyorsa: Forward zone’daki sunucu IP’sini veya portu kontrol edin. TLS kullanıyorsanız sertifika bundle yolunu doğrulayın.
  • NXDOMAIN dönüyorsa: Upstream sunucu sorguyu alıyor ama domain gerçekten yok. Forward zone çalışıyor demektir.
  • Timeout oluyor: Firewall port 853’ü engelliyor olabilir. Port 53 ile deneyin, fark varsa firewall sorunu.
  • Yavaş yanıt süresi: Upstream sunucu coğrafi olarak uzakta ya da yüklü olabilir. Alternatif sunucu deneyin.

Yapılandırmaları Dinamik Olarak Yönetmek

Büyük ortamlarda forward zone’ları elle yönetmek zorlaşır. unbound-control ile bazı işlemler restart gerektirmeden yapılabilir:

# Belirli bir zone'u önbellekten temizle
unbound-control flush_zone "corp.sirket.local"

# Tüm önbelleği temizle
unbound-control flush_all

# Çalışan yapılandırmayı yeniden yükle (reload)
unbound-control reload

# Forward zone ekle (kalıcı değil, restart'ta kaybolur)
unbound-control forward_add +i corp.sirket.local 192.168.1.10

# Mevcut forward zone'ları listele
unbound-control list_forwards

unbound-control reload komutu servisi durdurmadan yapılandırmayı yeniden okur. Bu production ortamlar için kritik bir özelliktir. Ancak şunu da söyleyeyim: reload bazen tüm değişiklikleri tam olarak uygulamayabilir. Şüpheniz varsa tam restart yapın.

Performans Optimizasyonu

Forward zone kullanıyorsanız cache etkinliğini artırmak önemlidir:

# /etc/unbound/unbound.conf.d/performance.conf
server:
    # Önbellek boyutunu artır
    msg-cache-size: 64m
    rrset-cache-size: 128m
    
    # Prefetch: TTL dolmadan yenile
    prefetch: yes
    prefetch-key: yes
    
    # Paralel sorgu sayısı
    num-threads: 4
    
    # EDNS buffer boyutu
    edns-buffer-size: 1232
    
    # Negative cache TTL sınırı
    cache-min-ttl: 300
    cache-max-ttl: 86400

prefetch: yes seçeneği, cache’deki bir kaydın TTL’inin yüzde onu kaldığında arka planda upstream’den taze kaydı çeker. Kullanıcı hiçbir zaman cache miss yaşamaz, her zaman hızlı yanıt alır. DNS performansı konusunda en fark yaratan tek parametre budur.

Güvenlik Notları

Forward zone’ları yapılandırırken güvenlik perspektifini de akılda tutmak gerekir:

DNSSEC ile forward zone birlikte kullanımı:

# /etc/unbound/unbound.conf.d/dnssec.conf
server:
    # DNSSEC doğrulamasını etkinleştir
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    
    # Forward zone ile DNSSEC uyumu
    # forward-tls-upstream: yes kullanıyorsanız
    # harden-dnssec-stripped: yes ekleyin
    harden-dnssec-stripped: yes

Önemli bir uyarı: Eğer DoT ile forward kullanıyorsanız ve upstream sunucu DNSSEC destekliyorsa sorun yok. Ancak iç DNS sunucularına forward yapıyorsanız ve bu sunucular DNSSEC imzalamıyorsa harden-dnssec-stripped: yes false-positive SERVFAIL’lara neden olabilir. İç zone’lar için DNSSEC doğrulamasını domain bazında kapatmanız gerekebilir.

Gerçek Bir Kurumsal Senaryo: Her Şeyi Bir Arada

Şimdi gerçekçi bir kurumsal yapıyı özetleyelim. Elimde böyle bir yapılandırma varken her yeni kurulumda başlangıç noktası olarak kullanıyorum:

# /etc/unbound/unbound.conf.d/kurumsal-forward.conf

# 1. Şirket iç domain'i -> AD DNS
forward-zone:
    name: "sirket.local"
    forward-addr: 10.0.0.10
    forward-addr: 10.0.0.11
    forward-first: no

# 2. Şirket public domain'i (intranet) -> İç DNS
forward-zone:
    name: "intranet.sirket.com"
    forward-addr: 10.0.0.10
    forward-addr: 10.0.0.11
    forward-first: no

# 3. Ters DNS - RFC1918 blokları -> İç DNS
forward-zone:
    name: "10.in-addr.arpa"
    forward-addr: 10.0.0.10
    forward-addr: 10.0.0.11
    forward-first: no

forward-zone:
    name: "168.192.in-addr.arpa"
    forward-addr: 10.0.0.10
    forward-addr: 10.0.0.11
    forward-first: no

# 4. Geri kalan her şey -> Cloudflare DoT
forward-zone:
    name: "."
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com
    forward-addr: 9.9.9.9@853#dns.quad9.net
    forward-tls-upstream: yes

Bu yapıda sıra önemlidir. Unbound en uzun eşleşen zone’u kullanır. sirket.local için gelen sorgu, . zone’u yerine sirket.local zone’una eşleşir. Yani daha spesifik olanlar öncelik alır; bunu aklınızda tutun.

Sonuç

Unbound’da forward zone yapılandırması göründüğünden daha güçlü bir araç. Temel kullanım basit birkaç satırdan ibaret, ama iç DNS yönlendirmesi, split-DNS, DoT ile güvenli iletim ve DNSSEC entegrasyonu gibi katmanlar ekledikçe gerçek anlamda sağlam bir DNS altyapısına kavuşuyorsunuz.

En önemli nokta şu: Hangi sorgunun nereye gideceğini önceden kağıda dökün. Sonra yapılandırmayı yazın, test edin, logları inceleyin. DNS sorunları çoğunlukla sessiz olur; yanlış cevap veriyor ama fark edilmiyor. dig, unbound-control ve verbosity artırılmış loglar bu noktada en iyi arkadaşlarınızdır.

Production ortamına almadan önce mutlaka unbound-checkconf ile sözdizimini doğrulayın ve en az bir istemciden dig ile test edin. Beş dakikalık test, gece yarısı gelen destek çağrısından çok daha değerlidir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir