Windows DNS’te Stub Zone Kullanımı ve Senaryoları

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

Kurumsal ortamlarda DNS mimarisi kurarken en çok karşılaştığım sorulardan biri şu oluyor: “Stub zone’u ne zaman kullanalım, delegation mı daha iyi?” Bu sorunun cevabı aslında oldukça bağlam bağımlı, ama stub zone’ların neden var olduğunu ve hangi senaryolarda sizi kurtarabileceğini anlatırken, bunları gerçekten kullandığım yerlerden örnekler vermek istiyorum.

Stub Zone Nedir, Nasıl Çalışır?

Stub zone, bir DNS bölgesinin tam kopyasını tutmak yerine yalnızca o bölgenin NS kayıtlarını ve SOA kaydını saklayan özel bir bölge türüdür. Basitçe söylemek gerekirse: Stub zone, “bu soruları şu sunuculara sor” bilgisini barındırır. Tam bir secondary zone gibi zone transfer yapmaz, sadece yetkili name server bilgilerini periyodik olarak günceller.

Bunu bir benzetmeyle açıklayayım: Bir şehrin rehberini ezberlemenize gerek yok, sadece o şehrin danışma masasının numarasını bilmeniz yeterli. Stub zone da tam olarak bu işi yapar. Bir sorgu geldiğinde, “bu soruyu ben çözemem ama şu sunuculara sor, onlar yetkili” der.

Stub zone içinde şu kayıtlar bulunur:

  • SOA kaydı: Bölgenin başlangıç yetkisi kaydı
  • NS kayıtları: Bölgeyi yöneten name server isimleri
  • A kayıtları (glue records): NS sunucularının IP adresleri, stub zone’un asıl kritik parçası budur

Peki bu neden önemli? Çünkü DNS forwarder tanımladığınızda, o forwarder’ın IP adresini elle girip takip etmeniz gerekir. NS kayıtları değiştiğinde forwarder’ı güncellemezseniz çözümleme bozulur. Stub zone bu süreci otomatikleştirir.

Delegation ile Farkı

Bu iki kavramı karıştırmak çok kolay, özellikle göreve yeni başlayanlar için. İkisi de “bu zone için başka sunucuları sor” diyor gibi görünse de aralarında temel farklar var.

Delegation:

  • Parent zone’daki NS ve glue kayıtları statiktir
  • NS sunucuları değiştiğinde parent zone’u elle güncellemeniz gerekir
  • Genellikle internete açık DNS hiyerarşisinde kullanılır
  • Zone verisi parent zone içinde saklanır

Stub Zone:

  • NS bilgileri periyodik olarak kaynak sunucudan çekilir, otomatik güncellenir
  • Master sunucu değiştiğinde stub zone kendini günceller
  • Kurumsal iç ağlarda, özellikle birleşme/satın alma senaryolarında çok kullanışlıdır
  • Ayrı bir zone dosyası olarak tutulur

Kısaca: Delegation statik, stub zone dinamiktir. Bu dinamiklik stub zone’un en büyük avantajı.

Gerçek Dünya Senaryoları

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

Geçen yıl bir holding bünyesindeki iki şirketin DNS altyapısını birleştirmek zorunda kaldım. Şirket A’nın domain’i sirket-a.local, Şirket B’ninki sirket-b.local idi. Her iki şirkette de bağımsız Active Directory altyapısı mevcuttu ve iki ağ VPN üzerinden birbirine bağlıydı.

Klasik çözüm conditional forwarder kullanmak olurdu, ama buradaki sorun şuydu: Şirket B’deki DNS sunucuları değişebiliyordu, DR tatbikatları yapılıyordu ve sunucu IP’leri zaman zaman değişiyordu. Conditional forwarder’ları her seferinde iki tarafta da güncellemek hem iş yükü hem de hata riski yaratıyordu.

Çözüm olarak her iki tarafta stub zone kullandım. Şirket A’nın DNS sunucusunda sirket-b.local için stub zone oluşturdum, master olarak Şirket B’nin primary DNS sunucusunu gösterdim. Tersi de geçerliydi.

# Sirket A'nin DNS sunucusunda calistirin
# Sirket B'nin zone'u icin stub zone olusturma
Add-DnsServerStubZone `
    -Name "sirket-b.local" `
    -MasterServers "10.20.0.10" `
    -PassThru

Artık Şirket B tarafında DNS sunucusu değişse bile, stub zone periyodik olarak NS kayıtlarını güncelliyor ve çözümleme kesintisiz devam ediyor.

Senaryo 2: Bölgesel DNS Sunucusu Olan Büyük WAN Mimarisi

İkinci senaryom çok lokasyonlu bir perakende zinciriyle ilgiliydi. Merkez ofis Ankara’da, şubeler İstanbul, İzmir ve Bursa’da. Her lokasyonda yerel bir DNS sunucusu var, ama tüm zone yönetimi merkezden yapılıyor.

Şube DNS sunucularının her sorgu için Ankara’ya gitmesi hem latency sorununa hem de WAN hattı üzerinde gereksiz yüke yol açıyordu. Şube lokasyonları kendi yerel kaynaklarını çözümlüyor, ama merkezdeki merkez.sirket.local zone’una ait sorgular için de hızlı yanıt almaları gerekiyordu.

Bu durumda şube sunucularında merkez.sirket.local için stub zone oluşturduk. Şube sunucusu artık merkezdeki DNS’in NS kayıtlarını biliyor ve sorguları doğrudan ilgili sunucuya yönlendiriyor, forwarder zinciri olmadan.

# Istanbul subesi DNS sunucusunda calistirin
Add-DnsServerStubZone `
    -Name "merkez.sirket.local" `
    -MasterServers "192.168.1.10", "192.168.1.11" `
    -ReplicationScope "Forest" `
    -PassThru

# Olusturulan stub zone'u dogrulama
Get-DnsServerZone -Name "merkez.sirket.local" | 
    Select-Object ZoneName, ZoneType, MasterServers

Senaryo 3: DMZ ve İç Ağ DNS Ayrımı

DMZ’de web sunucuları barındıran, ama iç ağ kaynaklarına da erişmesi gereken uygulamaların olduğu bir ortamda çalışmıştım. DMZ’deki DNS sunucusu tüm iç zone’ları bilmiyordu, her şeyi iç ağdaki DNS’e forwarder olarak iletiyordu. Bu hem güvenlik açısından (iç DNS yapısını tamamen ifşa etmek) hem de performans açısından sorunluydu.

Çözüm: DMZ DNS sunucusuna sadece gerekli iç zone’lar için stub zone ekledik. Böylece DMZ sunucusu yalnızca ihtiyacı olan zone’ların NS bilgilerine sahip oldu, iç ağın tam zone yapısına erişimi olmadı.

# DMZ DNS sunucusunda, yalnizca gerekli zone icin stub zone
Add-DnsServerStubZone `
    -Name "uygulama.sirket.local" `
    -MasterServers "10.0.1.5" `
    -ZoneFile "uygulama.sirket.local.dns" `
    -PassThru

Burada dikkat edin: DMZ sunucusu AD-integrated zone kullanamıyorsa ZoneFile parametresini kullanmalısınız. AD-integrated yapıda ise ReplicationScope kullanabilirsiniz.

Windows DNS’te Stub Zone Oluşturma

DNS Manager GUI ile Oluşturma

Grafik arayüzden oluşturmak isteyenler için adımlar şöyle:

  • DNS Manager’ı açın (dnsmgmt.msc)
  • Sunucunuza sağ tıklayın, “New Zone” seçin
  • Zone Type ekranında “Stub zone” seçeneğini işaretleyin
  • Replication scope seçin (AD-integrated için)
  • Zone adını girin
  • Master DNS sunucu IP adresini ekleyin
  • Sihirbazı tamamlayın

PowerShell ile Toplu Stub Zone Yönetimi

Birden fazla stub zone yönetmek için PowerShell çok daha verimli. Özellikle 10’dan fazla zone’unuz varsa GUI ile uğraşmak vakit kaybı.

# Birden fazla stub zone tanimlamak icin
$stubZones = @(
    @{Name = "bolge1.sirket.local"; Master = "10.10.1.10"},
    @{Name = "bolge2.sirket.local"; Master = "10.10.2.10"},
    @{Name = "bolge3.sirket.local"; Master = "10.10.3.10"}
)

foreach ($zone in $stubZones) {
    try {
        Add-DnsServerStubZone `
            -Name $zone.Name `
            -MasterServers $zone.Master `
            -ReplicationScope "Forest" `
            -ErrorAction Stop
        Write-Host "Basarili: $($zone.Name)" -ForegroundColor Green
    }
    catch {
        Write-Host "Hata: $($zone.Name) - $_" -ForegroundColor Red
    }
}

Mevcut Stub Zone’ları Listeleme ve İnceleme

# Tum stub zone'lari listele
Get-DnsServerZone | Where-Object { $_.ZoneType -eq "Stub" } | 
    Select-Object ZoneName, MasterServers, ZoneType, IsDsIntegrated

# Belirli bir stub zone'un detaylarini goruntule
Get-DnsServerZone -Name "sirket-b.local" | 
    Format-List *

# Stub zone'daki NS kayitlarini goruntule
Get-DnsServerResourceRecord -ZoneName "sirket-b.local" -RRType NS

Stub Zone Güncelleme ve Yenileme

Stub zone’lar varsayılan olarak belirli aralıklarla güncellenir, ama manuel olarak tetiklemek isterseniz:

# Stub zone'u manuel olarak guncelle
Invoke-DnsServerZoneRefresh -Name "sirket-b.local"

# Guncelleme sonrasi durum kontrolu
$zone = Get-DnsServerZone -Name "sirket-b.local"
Write-Host "Son degisiklik: $($zone.LastZoneTransferAttempt)"
Write-Host "Durum: $($zone.ZoneTransferStatus)"

Stub Zone Sorunlarını Giderme

Bu kısım aslında en değerli kısım, çünkü kitaplarda yazmayanları anlatıyorum.

Sorun 1: Stub Zone NS Kayıtlarını Çekemiyor

En sık karşılaştığım sorun bu. Stub zone oluşturuldu ama NS kayıtları gelmiyor. Nedenleri şunlar olabilir:

  • Master sunucuya erişim yok (firewall, routing sorunu)
  • Master sunucu zone transferine izin vermiyor
  • Zone adı yanlış yazılmış
# Master sunucuya erisimi test et
Test-NetConnection -ComputerName "10.20.0.10" -Port 53

# DNS sorgusunu manuel test et
Resolve-DnsName -Name "sirket-b.local" -Type NS -Server "10.20.0.10"

# Zone transfer testi (nslookup ile)
# nslookup acin:
# server 10.20.0.10
# set type=NS
# sirket-b.local

Sorun 2: Stub Zone Eski Bilgileri Tutuyor

Zaman zaman stub zone güncellenmediği için eski NS IP adreslerini gösteriyor. Bu durumda önce zone’u temizleyip yeniden yüklemek gerekebilir.

# Stub zone'u kaldir ve yeniden ekle
Remove-DnsServerZone -Name "sirket-b.local" -Force

# Kisa bir bekleme
Start-Sleep -Seconds 5

# Yeniden olustur
Add-DnsServerStubZone `
    -Name "sirket-b.local" `
    -MasterServers "10.20.0.10" `
    -ReplicationScope "Forest" `
    -PassThru

Sorun 3: AD Replication Üzerinden Stub Zone Dağıtımı

AD-integrated stub zone’lar forest genelinde replike edilmek üzere ayarlandığında, bazı domain controller’larda görünmeyebilir. Bu genellikle AD replication sorunuyla ilgilidir.

# AD replikasyon durumunu kontrol et
repadmin /showrepl

# DNS partition replikasyonunu kontrol et
repadmin /showrepl * /csv | ConvertFrom-Csv | 
    Where-Object { $_.'Source DSA' -ne "" } | 
    Select-Object 'Source DSA', 'Naming Context', 'Number of Failures'

# DC'lerdeki DNS zone'lari karsilastir
$dcs = (Get-ADDomainController -Filter *).HostName
foreach ($dc in $dcs) {
    Write-Host "=== $dc ===" -ForegroundColor Cyan
    Get-DnsServerZone -ComputerName $dc | 
        Where-Object { $_.ZoneType -eq "Stub" } | 
        Select-Object ZoneName
}

Stub Zone Kullanırken Dikkat Edilmesi Gerekenler

Yıllar içinde öğrendiğim bazı kritik noktalar var, bunları listeleyeyim:

  • Master sunucu erilebilirliği: Stub zone’un master sunucusu erişilemez olursa, NS bilgileri eskiir ve çözümleme bozulabilir. Bu yüzden birden fazla master tanımlamak her zaman daha güvenli.
  • Stub zone, recursive resolution yapmaz: Stub zone sadece nereye gidileceğini söyler. Sorgulayan sunucu ilgili NS’e gidip sorguyu kendisi tamamlamak zorundadır. Bu beklenen davranış ama bazen “neden stub zone ekledim de çözüm yine de olmadı” sorusunun cevabı burada yatıyor.
  • Circular dependency riski: Stub zone master sunucusunun ismini çözümleyebilmek için de DNS’e ihtiyaç duyuluyorsa, döngüsel bağımlılık oluşabilir. Bu yüzden master sunucuyu her zaman IP adresiyle tanımlayın, isim ile değil.
  • Firewall kuralları: Zone transfer için TCP 53’ün açık olması gerekir. UDP 53 sorgu için yeterli ama transfer için değil. Bu basit ama sıkça unutulan bir nokta.
  • Stub zone AD-integrated olduğunda: Zone verileri DNS uygulama partition’ında saklanır. ForestDnsZones ya da DomainDnsZones partition seçimi, zone’un hangi DC’lere replike edileceğini belirler. Domain genelinde paylaşılacak stub zone’lar için ForestDnsZones daha mantıklı.
  • Monitoring: Stub zone’ların güncel olup olmadığını takip etmek gerekir. Sessizce eskiyen bir stub zone, saatlerce süren kesintilere yol açabilir. DNS sunucusu event log’larını düzenli izlemek şart.

Conditional Forwarder mı, Stub Zone mu?

Bu soruyu sık sık alıyorum. Hızlı bir karar çerçevesi çizeyim:

Conditional forwarder kullanın:

  • Hedef zone’un NS sunucuları nadiren değişiyorsa
  • Basit ve hızlı bir çözüm yeterliyse
  • AD replication ile tüm DC’lere yaymanız gerekiyorsa (conditional forwarder’lar da AD-integrated olabilir)
  • Karşı taraf zone’unuza zone transfer izni vermiyorsa

Stub zone kullanın:

  • NS sunucuları değişebilecekse ve otomatik güncelleme istiyorsanız
  • Sık değişen DNS altyapısı olan partner/şube ağlarıyla çalışıyorsanız
  • Birleşme/satın alma senaryolarında geçici veya kalıcı DNS entegrasyonu yapıyorsanız
  • Karşı taraf zone transfer iznini veriyorsa

Aslında ikisi de aynı temel sorunu çözüyor: “Bu zone için hangi sunucuya gideyim?” Farkı operasyonel: biri statik, biri dinamik.

Pratik İzleme ve Otomasyon

Üretim ortamında stub zone’ların sağlığını izlemek için basit bir script kullanıyorum. Bu script hem NS kayıtlarını kontrol ediyor hem de master sunuculara erişimi doğruluyor.

# Stub zone saglik kontrolu
function Test-StubZoneHealth {
    param(
        [string]$DnsServer = $env:COMPUTERNAME
    )
    
    $stubZones = Get-DnsServerZone -ComputerName $DnsServer | 
        Where-Object { $_.ZoneType -eq "Stub" }
    
    foreach ($zone in $stubZones) {
        Write-Host "`nZone: $($zone.ZoneName)" -ForegroundColor Yellow
        
        # NS kayitlarini kontrol et
        $nsRecords = Get-DnsServerResourceRecord `
            -ZoneName $zone.ZoneName `
            -RRType NS `
            -ComputerName $DnsServer `
            -ErrorAction SilentlyContinue
        
        if ($nsRecords) {
            Write-Host "  NS Kayit Sayisi: $($nsRecords.Count)" -ForegroundColor Green
        } else {
            Write-Host "  UYARI: NS kayitlari bulunamadi!" -ForegroundColor Red
        }
        
        # Master sunuculara erisim testi
        foreach ($master in $zone.MasterServers) {
            $test = Test-NetConnection -ComputerName $master -Port 53 -WarningAction SilentlyContinue
            if ($test.TcpTestSucceeded) {
                Write-Host "  Master $master : ERISELEBILIR" -ForegroundColor Green
            } else {
                Write-Host "  Master $master : ERISEMIYOR" -ForegroundColor Red
            }
        }
    }
}

# Kullanim
Test-StubZoneHealth -DnsServer "dns01.sirket.local"

Sonuç

Stub zone’lar, DNS yönetiminde göz ardı edilen ama doğru senaryoda kullanıldığında ciddi operasyonel yük azaltan bir özelliktir. Özellikle dinamik NS yapılarına sahip çok lokasyonlu ortamlarda, şirket birleşmelerinde ve DMZ senaryolarında conditional forwarder’a göre çok daha yönetilebilir bir çözüm sunar.

Temel mesaj şu: Eğer karşı tarafın DNS sunucuları değişmeyecekse conditional forwarder yeterlidir ve daha basittir. Ama “NS değiştiğinde ne olur?” sorusunun cevabı “elle güncellememiz gerekir” ise, stub zone’a geçmeyi ciddi olarak değerlendirin.

Zone transfer iznini açmak bazen kurumsal politikalara takılabilir. Bu durumda karşı tarafla iletişime geçin, zira stub zone’un çektikleri yalnızca NS ve SOA kayıtlarıdır, tam zone içeriği değil. Bu genellikle güvenlik kaygılarını azaltır ve iznin alınmasını kolaylaştırır.

Son olarak, üretim ortamına almadan önce test ortamında deneyin. DNS hataları bazen saat sürer fark edilmeden, ama kullanıcılar her şeyin bozuk olduğunu ilk dakikada söyler. Stub zone sağlık izlemesini standart monitoring altyapınıza dahil etmek, gece sizi uyandıracak o telefon aramalarını önemli ölçüde azaltacaktır.

Bir yanıt yazın

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