DNS Conditional Forwarder ve Stub Zone Yapılandırması

İki farklı şirketi aynı DNS altyapısı üzerinde yönetmek zorunda kaldığınızda, ya da merkez ofis ile şubeler arasında DNS çözümlemesinin düzgün çalışması gerektiğinde, “conditional forwarder mı kurayım, stub zone mu?” sorusu kaçınılmaz olarak karşınıza çıkıyor. Ben bu ikisini yıllarca karıştırdım, hatta bazı ortamlarda yanlış tercih yüzünden saatlerce uğraştım. Bu yazıda her ikisini de gerçek dünya senaryolarıyla açıklayacağım.

Temel Kavramlar: Ne Yaparlar, Nasıl Çalışırlar

Önce zihinsel modeli oturtmak lazım. DNS’in bir sorguyu nasıl çözdüğünü biliyorsunuz ama şunu hatırlatayım: Windows DNS sunucusu, kendi zone’larında bulamadığı bir sorgu için ya forwarder’a gider, ya recursive olarak root’tan başlar, ya da belirli bir kurala göre başka bir sunucuya yönlenir.

Conditional Forwarder tam olarak şunu yapar: “Bu domain’e ait sorgular gelirse, git şu IP’deki sunucuya sor, benim işim değil.” DNS sunucusu o domain hakkında hiçbir şey bilmez, sadece nereye soracağını bilir. Cevabı alır, önbelleğe atar, işi biter.

Stub Zone ise biraz daha akıllıca bir yapı. Bir zone’un sadece NS kayıtlarını ve o NS’lerin A kayıtlarını (glue records) tutar. DNS sunucunuz o zone için yetkili sunucuların kim olduğunu bilir ve sorguyu doğrudan oraya iletir. Ama asıl fark şu: Zone değiştiğinde, yani karşı taraf yeni bir NS sunucusu eklediğinde veya IP değiştiğinde, stub zone otomatik olarak güncellenir. Conditional forwarder’da ise siz gidip IP’yi elle değiştirmek zorundasınız.

Senaryo 1: Şirket Birleşmesi Sonrası DNS Entegrasyonu

Diyelim ki şirketiniz başka bir firmayı satın aldı. Eski şirketin domain’i partner.local, sizinki merkez.local. İki Active Directory ormanı arasında bir trust kurdunuz ama kullanıcılar birbirlerinin kaynaklarına isimle erişemiyor. Firewall’dan da DNS trafiğine izin verildi ama hala çalışmıyor.

Bu senaryoda conditional forwarder tam ihtiyacınız olan şey. Yapılandırma basit:

# Merkez.local DNS sunucusunda partner.local için conditional forwarder ekle
Add-DnsServerConditionalForwarderZone `
    -Name "partner.local" `
    -MasterServers 10.20.1.10, 10.20.1.11 `
    -ForwarderTimeout 5 `
    -ReplicationScope "Forest"

Karşı tarafta da aynısını yapıyorsunuz:

# Partner.local DNS sunucusunda merkez.local için conditional forwarder ekle
Add-DnsServerConditionalForwarderZone `
    -Name "merkez.local" `
    -MasterServers 192.168.1.10, 192.168.1.11 `
    -ForwarderTimeout 5 `
    -ReplicationScope "Forest"

ReplicationScope "Forest" parametresine dikkat edin. Bu, tanımladığınız conditional forwarder’ın tüm forest’taki DC’lere Active Directory replikasyonu ile otomatik dağıtılacağı anlamına geliyor. Bunu atlarsanız, diğer site’lardaki DNS sunucularında elle tekrar yapmanız gerekir. Yıllarca bu hatayı yapan sysadmin’ler gördüm.

Mevcut conditional forwarder’ları doğrulamak için:

# Tüm conditional forwarder'ları listele
Get-DnsServerZone | Where-Object {$_.ZoneType -eq "Forwarder"} | 
    Select-Object ZoneName, MasterServers, ForwarderTimeout, IsDsIntegrated

Senaryo 2: Çok Şubeli Yapıda Stub Zone Kullanımı

Şimdi farklı bir senaryo. Üç farklı lokasyonunuz var: İstanbul merkez, Ankara şube, İzmir şube. Her lokasyonda kendi DNS sunucuları mevcut. Merkez’deki DNS sunucuları tüm zone’lara yetkili, şube DNS’leri ise sadece kendi zone’larına yetkili.

Bu yapıda stub zone, conditional forwarder’dan daha uygun bir tercih. Nedeni şu: Merkez’e yeni bir DNS sunucusu eklediğinizde, şubelerdeki stub zone’lar bunu otomatik öğrenecek. Conditional forwarder’da ise IP listesini elle güncellemeniz gerekir.

Ankara şubesindeki DNS sunucusunda İstanbul merkez zone’u için stub zone oluşturma:

# Stub zone oluştur - Ankara DNS sunucusunda çalıştırılır
Add-DnsServerStubZone `
    -Name "merkez.local" `
    -MasterServers 10.0.1.10, 10.0.1.11 `
    -ReplicationScope "Domain" `
    -PassThru

Stub zone’un düzgün yüklenip yüklenmediğini kontrol edelim:

# Stub zone detaylarını göster
Get-DnsServerZone -Name "merkez.local" | 
    Select-Object ZoneName, ZoneType, MasterServers, LastZoneTransferAttempt, LastSuccessfulZoneTransfer

Burada önemli bir nokta var: Stub zone, zone transfer mekanizmasını kullanır. Yani karşı taraftaki primary DNS sunucusu, zone transfer’a izin vermek zorunda. Eğer zone transfer’ı kısıtladıysanız, stub zone IP’lerini açıkça izin listesine eklemeniz gerekiyor.

Merkez DNS sunucusunda zone transfer iznini yapılandırma:

# merkez.local zone'u için transfer iznini yapılandır
# Sadece belirtilen IP'lere transfer izni ver
Set-DnsServerPrimaryZone `
    -Name "merkez.local" `
    -SecureSecondaries TransferToSecureServers `
    -SecondaryServers 10.1.1.10, 10.2.1.10  # Ankara ve Izmir DNS IP'leri

Conditional Forwarder ile Stub Zone Arasında Karar Vermek

Bu sorunun net bir cevabı var aslında, ama çoğu yerde muğlak anlatılıyor. Şöyle düşünün:

Conditional Forwarder tercih edin:

Hedef domain’in DNS altyapısı üzerinde kontrolünüz yok (partner firma, bulut servis sağlayıcısı, vs.)
Hedef domain’in NS kayıtlarının otomatik senkronize edilmesine ihtiyaç duymuyorsunuz
Basit bir “git şu IP’ye sor” mantığı yeterliyse
Zone transfer izni almanız mümkün değilse
Hızlı kurulum gerekiyorsa

Stub Zone tercih edin:

Hedef DNS altyapısı sizin kontrolünüzdeyse veya zone transfer izni alabiliyorsanız
Hedef tarafın NS kayıtları değişebiliyorsa ve bunu takip etmek istemiyorsanız
Daha dinamik ve self-maintaining bir yapı istiyorsanız
Birden fazla NS sunucusu olan büyük bir ortamda çalışıyorsanız

DNS Debuggıng: Bir Şeyler Ters Gidince Ne Yaparsınız

Kurulumu yaptınız, test ediyorsunuz ama çalışmıyor. İlk refleks ping atmak olur, ama yanlış yaklaşım. Doğrudan nslookup veya Resolve-DnsName kullanın:

# Belirli bir DNS sunucusunu kullanarak sorgula
Resolve-DnsName -Name "fileserver.partner.local" -Server 192.168.1.10 -Type A

# Daha detaylı debug için
nslookup -debug fileserver.partner.local 192.168.1.10

DNS sunucusunun conditional forwarder’ı kullanıp kullanmadığını anlamak için DNS debug logging’i aktive edebilirsiniz. Ama dikkat: Production ortamda bu özellik disk I/O’yu ciddi şekilde artırır, log dosyasını izleyin.

# DNS debug logging'i etkinleştir
Set-DnsServerDiagnostics `
    -Answers $true `
    -SendPackets $true `
    -Queries $true `
    -QueriesToForwarders $true `
    -LogFilePath "C:WindowsSystem32dnsdns.log" `
    -MaxMBFileSize 100

Log’u izledikten sonra mutlaka kapatın:

# Debug logging'i devre disi birak
Set-DnsServerDiagnostics -All $false

Active Directory Entegre Zone’larda Dikkat Edilmesi Gerekenler

Active Directory integrated zone kullanıyorsanız, hem conditional forwarder hem de stub zone için bazı özel durumlar söz konusu.

Replikasyon scope seçimi kritik. Forest, Domain veya Legacy seçenekleri var. Eğer tek domain’li bir forest’ta çalışıyorsanız Domain yeterli. Birden fazla domain varsa ve tüm domainlerdeki DNS sunucularının bu forwarder’ı bilmesini istiyorsanız Forest seçin.

Replikasyon durumunu kontrol etmek için:

# AD replikasyon durumunu kontrol et
repadmin /showrepl

# DNS zone'larının replikasyon durumunu kontrol et
Get-DnsServerZone | 
    Where-Object {$_.IsDsIntegrated -eq $true} | 
    Select-Object ZoneName, ReplicationScope, IsDsIntegrated

Bazen replikasyon sağlıklı görünmesine rağmen forwarder’lar diğer DC’lere geçmez. Bu durumda zone’u elle force replicate etmek gerekebilir:

# DNS verilerinin replikasyonunu zorla
repadmin /syncall /AdeP

# Belirli bir DC'ye replikasyonu zorla
repadmin /replicate DC02 DC01 "DC=DomainDNSZones,DC=merkez,DC=local"

Split-Brain DNS Senaryosu ve Conditional Forwarder

Bir de şöyle bir durum var: Hem iç ağdan hem de internetten erişilen servisleriniz olduğunu düşünelim. mail.sirketiniz.com adresi dışarıdan public IP ile çözümlenirken, içeriden private IP ile çözümlenmeli. Bunu split-brain (veya split-horizon) DNS ile çözebilirsiniz ama bazen sadece belirli subzone’lar için bu gerekir.

Mesela Office 365 hybrid yapıda autodiscover kaydı hem iç hem dışta farklı yere işaret ediyor olabilir. Bu durumda iç DNS’te bir primary zone oluşturup sadece ilgili kaydı override edebilirsiniz. Ya da conditional forwarder ile belirli bir subdomain için iç DNS sunucusuna yönlendirebilirsiniz:

# Belirli bir subdomain icin internal DNS'e yonlendir
Add-DnsServerConditionalForwarderZone `
    -Name "autodiscover.sirketiniz.com" `
    -MasterServers 192.168.1.10 `
    -ReplicationScope "Forest"

Bu yaklaşım bazen daha temiz bir çözüm sunar, özellikle tüm zone’u iç DNS’te yönetmek istemediğinizde.

PowerShell ile Toplu Yapılandırma

Birden fazla şube veya partner için aynı işlemi tekrar tekrar yapmak zorundaysanız, PowerShell’in gücünü kullanın. Bir CSV dosyasından okuyarak toplu conditional forwarder ekleme:

# forwarders.csv dosyasi ornegi:
# DomainName,PrimaryDNS,SecondaryDNS
# partner1.local,10.10.1.10,10.10.1.11
# partner2.local,10.20.1.10,10.20.1.11

$forwarders = Import-Csv -Path "C:Scriptsforwarders.csv"

foreach ($item in $forwarders) {
    $masterServers = @($item.PrimaryDNS)
    if ($item.SecondaryDNS -ne "") {
        $masterServers += $item.SecondaryDNS
    }
    
    try {
        Add-DnsServerConditionalForwarderZone `
            -Name $item.DomainName `
            -MasterServers $masterServers `
            -ReplicationScope "Forest" `
            -ErrorAction Stop
        
        Write-Host "Basarili: $($item.DomainName)" -ForegroundColor Green
    }
    catch {
        Write-Host "Hata: $($item.DomainName) - $($_.Exception.Message)" -ForegroundColor Red
    }
}

Var olan forwarder’ları yedeklemek de kritik önem taşır. Sistem yeniden kurulumu veya migration öncesi:

# Tum conditional forwarder'lari export et
$forwarderZones = Get-DnsServerZone | 
    Where-Object {$_.ZoneType -eq "Forwarder"}

$exportData = foreach ($zone in $forwarderZones) {
    $zoneInfo = Get-DnsServerZone -Name $zone.ZoneName
    [PSCustomObject]@{
        ZoneName = $zone.ZoneName
        MasterServers = ($zoneInfo.MasterServers.IPAddressToString -join ";")
        ReplicationScope = $zone.ReplicationScope
        IsDsIntegrated = $zone.IsDsIntegrated
    }
}

$exportData | Export-Csv -Path "C:Backupdns_forwarders_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation
Write-Host "Toplam $($exportData.Count) conditional forwarder export edildi."

Güvenlik Boyutu: DNS Hijacking ve Forwarder Güvenliği

Conditional forwarder yapılandırmasında güvenliği göz ardı etmemek lazım. Özellikle şunu düşünün: Forwarder olarak tanımladığınız IP’ler doğru sunuculara mı ait? DNS hijacking saldırılarında saldırganlar önce forwarder IP’lerini değiştirmeyi hedefler.

DNS sunucularınızdaki forwarder değişikliklerini izlemek için Windows Event Log’u kullanabilirsiniz. DNS Server eventi 6001 ve 6002 zone değişikliklerini kaydeder. Kritik ortamlarda bu eventleri SIEM’e besleyin.

Ayrıca, conditional forwarder olarak tanımladığınız sunucuların DNSSEC destekleyip desteklemediğini kontrol edin. Destekliyorsa validation’ı aktive etmek ek bir güvenlik katmanı sağlar.

Sık Yapılan Hatalar

Yıllarca bu sistemleri yönetirken en çok karşılaştığım sorunları listeleyelim:

Forwarder timeout çok düşük ayarlanmış: Varsayılan 5 saniyedir ama yavaş WAN bağlantılarında bu yetersiz kalabilir. 10-15 saniyeye çıkarmayı deneyin.
Stub zone için zone transfer izni verilmemiş: Stub zone kurup neden çalışmıyor diye saatlerce uğraşan meslektaşlar gördüm. Transfer iznini her zaman kontrol edin.
ReplicationScope yanlış seçilmiş: Domain scope seçip neden diğer site’lardaki DC’lerde forwarder görünmüyor diye vakit harcamayın.
Çakışan zone’lar: Hem primary zone hem de aynı isimde conditional forwarder tanımlamak. DNS sunucusu kendi yetkili olduğu zone için forwarder’ı kullanmaz, bu beklenen davranış ama karışıklık yaratıyor.
Cache temizlenmemiş: Yapılandırma değişiklikten sonra eski cache’lenmiş cevaplar sorun çıkarabilir. Clear-DnsServerCache komutunu kullanın ama production’da dikkatli olun.

# DNS sunucusu cache'ini temizle
Clear-DnsServerCache -Force

# Belirli bir kayit icin cache'i kontrol et
Get-DnsServerCache | Where-Object {$_.RecordData -like "*partner*"}

Sonuç

DNS conditional forwarder ve stub zone, karmaşık görünen ama pratikte oldukça mantıklı iki mekanizma. Aralarındaki temel fark şu şekilde özetlenebilir: Conditional forwarder “ben bu konuda hiçbir şey bilmiyorum, git şu adrese sor” derken, stub zone “bu domain’e kimin yetkili olduğunu biliyorum ve bilgimi güncel tutuyorum” diyor.

Küçük ve statik ortamlarda conditional forwarder yeterli ve hatta tercih edilmesi gereken çözüm. Dinamik, büyük ve kendi kontrolünüzdeki altyapılar için stub zone daha sağlam bir yapı sunuyor. İkisini de doğru senaryoda kullandığınızda DNS yönetimini çok daha öngörülebilir hale getiriyorsunuz.

Son bir pratik öneri: Bu yapılandırmaları yaptıktan sonra mutlaka belgelendirin. Hangi domain için neden hangi çözümü tercih ettiğinizi yazın. Altı ay sonra gece 2’de alarm aldığınızda o dokümanı okuyacak kişi muhtemelen yine siz olacaksınız.

Windows Server DNS Conditional Forwarder ve Stub Zone Yapılandırması