Windows DNS Zone Transfer Yapılandırması

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

Zone transfer konusu, DNS altyapısında en çok ihmal edilen ama en kritik parçalardan biri. Özellikle birden fazla DNS sunucusu olan ortamlarda “çalışıyor zaten” mantığıyla bırakılan yapılandırmalar, hem güvenlik açığı hem de operasyonel kaos kaynağı olabiliyor. Bu yazıda Windows DNS üzerinde zone transfer’ı sıfırdan yapılandırmayı, güvenli hale getirmeyi ve sorunları çözmeyi ele alacağız.

Zone Transfer Nedir ve Neden Önemlidir

Primary DNS sunucunuzdaki zone verilerinin Secondary sunuculara aktarılması işlemi olan zone transfer, yüksek erişilebilirlik için temel gereksinimdir. Birincil sunucu çöktüğünde ikincil sunucu devreye girmeli ve güncel kayıtları servis edebilmelidir. Bunu sağlamanın yolu, zone transfer’ın doğru yapılandırılmasıdır.

Windows DNS Server iki tür zone transfer destekler:

  • Full Zone Transfer (AXFR): Tüm zone verisi transfer edilir. İlk kurulumda veya verinin tutarsız hale geldiği durumlarda kullanılır.
  • Incremental Zone Transfer (IXFR): Yalnızca son transferden bu yana değişen kayıtlar aktarılır. Büyük zone’larda performans açısından kritiktir.

Bunlara ek olarak, zone transfer’ı tetikleyen SOA (Start of Authority) kayıtlarındaki seri numarası mantığını anlamak gerekiyor. Secondary sunucu belirli aralıklarla Primary’nin SOA kaydını sorgular; kendi seri numarasından büyük bir değer görürse transfer başlatır.

Lab Ortamı ve Senaryo

Anlatacaklarımı somut bir senaryo üzerinden götüreceğim. Şirket içinde aşağıdaki yapı mevcut:

  • DC01 (10.10.1.10): Primary DNS, Active Directory Integrated Zone ile sirket.local zone’unu barındırıyor.
  • DNS02 (10.10.1.20): Secondary DNS, yalnızca DNS rolü kurulu, AD üyesi değil.
  • DNS03 (10.10.2.10): Disaster Recovery lokasyonundaki ikincil sunucu.

Bu yapıda AD Integrated zone varken neden secondary DNS kuralım diye sorabilirsiniz. AD replikasyonu olmayan bir lokasyona (DNS03 gibi) veya AD üyesi olmayan bir sunucuya zone verisi aktarmak gerektiğinde klasik zone transfer kaçınılmaz oluyor.

Windows DNS’de Zone Transfer Yapılandırması

Grafik Arayüz ile Yapılandırma

DNS Manager’ı açın (dnsmgmt.msc), ilgili zone’a sağ tıklayın ve Properties’e gidin. “Zone Transfers” sekmesi tam aradığınız yer.

Üç seçenek sunuluyor:

  • Allow zone transfers to any server: Açık devre. Test ortamı dışında asla seçmeyin.
  • Only to servers listed on the Name Servers tab: NS kayıtlarında tanımlı sunuculara izin verir. Çoğu zaman yeterli.
  • Only to the following servers: Elle tanımladığınız IP listesine göre çalışır. En güvenli ve kontrollü seçenek.

GUI kullanışlı ama ölçeklenebilir değil. Onlarca zone’unuz varsa PowerShell ile çalışmak hem hızlı hem tekrarlanabilir.

PowerShell ile Zone Transfer Yapılandırması

Mevcut zone’un transfer ayarlarını görüntülemek için:

Get-DnsServerZone -Name "sirket.local" | Select-Object ZoneName, ZoneType, SecondaryServers, SecureSecondaries

Bu çıktıda SecureSecondaries alanı kritik. Dört değer alabilir:

  • TransferAnyServer: Herkese izin ver (0)
  • TransferToZoneNameServer: NS kayıtlarındaki sunuculara izin ver (1)
  • TransferToSecureServers: Sadece belirtilen sunuculara izin ver (2)
  • NoTransfer: Transfer tamamen kapalı (3)

Secondary sunucuları ve transfer politikasını yapılandırmak:

Set-DnsServerPrimaryZone -Name "sirket.local" `
    -SecureSecondaries TransferToSecureServers `
    -SecondaryServers "10.10.1.20","10.10.2.10" `
    -Notify Notify `
    -NotifyServers "10.10.1.20","10.10.2.10"

-Notify Notify parametresi, zone değiştiğinde Primary’nin secondary sunuculara aktif bildirim göndermesini sağlar. Bu olmadan secondary sunucu SOA sorgu aralığını (default 15 dakika) beklemek zorunda kalır. Kritik değişikliklerin hızla yayılması için notify şart.

Secondary Zone Oluşturma

DNS02 sunucusunda secondary zone oluşturma işlemi:

Add-DnsServerSecondaryZone -Name "sirket.local" `
    -ZoneFile "sirket.local.dns" `
    -MasterServers "10.10.1.10" `
    -ComputerName "DNS02"

Zone başarıyla eklendikten sonra manuel transfer tetikleyebilirsiniz:

Start-DnsServerZoneTransfer -Name "sirket.local" `
    -ComputerName "DNS02" `
    -FullTransfer

-FullTransfer parametresini koymazsanız sistem önce IXFR dener, başarısız olursa AXFR’ye düşer. Sorun giderme sırasında direkt AXFR ile başlamak durumu netleştirir.

SOA Kayıt Parametrelerinin Ayarlanması

Zone transfer davranışını belirleyen SOA parametrelerini de doğru yapılandırmak gerekiyor:

Set-DnsServerSOA -Name "sirket.local" `
    -ComputerName "DC01" `
    -PrimaryServer "dc01.sirket.local." `
    -ResponsiblePerson "dnsadmin.sirket.local." `
    -SerialNumber 2024010101 `
    -RefreshInterval 00:15:00 `
    -RetryDelay 00:10:00 `
    -ExpireLimit 1.00:00:00 `
    -MinimumTimeToLive 00:01:00

Bu parametrelerin ne anlama geldiğini bilmek, arıza anında karar vermenizi kolaylaştırır:

  • RefreshInterval: Secondary’nin Primary’ye “seri numaran değişti mi?” diye bakma sıklığı. 15 dakika makul bir değer.
  • RetryDelay: Primary’ye ulaşılamazsa retry aralığı. Refresh’ten küçük olmalı.
  • ExpireLimit: Secondary Primary’ye belirtilen süre ulaşamazsa zone’u “expired” olarak işaretler ve yanıt vermeyi durdurur. 1 gün çoğu ortam için uygun.
  • MinimumTimeToLive: Negative caching süresi. Var olmayan kayıtların ne kadar süre önbellekte tutulacağı.

SOA seri numarasını güncellemeden zone’da değişiklik yaparsanız secondary sunucular güncellemeyi almaz. Windows DNS bunu otomatik yönetir ama bazı script tabanlı DNS güncellemelerinde gözden kaçabilir.

TSIG ile Güvenli Zone Transfer

Production ortamında zone transfer’ı açık IP kısıtlamasıyla bırakmak yetmez. TSIG (Transaction Signature) ile şifreli imzalama eklemek özellikle farklı ağ segmentleri veya DMZ üzerinden geçen transferlerde önemlidir.

Windows DNS, TSIG’i doğrudan GUI’dan desteklemiyor. Bu iş için dnscmd aracını kullanmak gerekiyor:

dnscmd DC01 /Config sirket.local /SecureSecondaries 2
dnscmd DC01 /Config sirket.local /SecondaryServers "10.10.1.20 10.10.2.10"

Windows’un native TSIG desteği BIND kadar olgun değil. Gerçekten güçlü TSIG ihtiyacı varsa ve ortamınızda Linux tabanlı secondary sunucular da varsa, bu konuya ayrıca zaman ayırmanızı öneririm. Ancak saf Windows ortamlarında IP tabanlı kısıtlama artı firewall kuralları genellikle yeterli kabul edilen düzey.

Firewall Kurallarının Yapılandırılması

DNS zone transfer, standart DNS sorgularından farklı çalışır. Normal DNS sorguları UDP 53 üzerinden gider; zone transfer ise TCP 53 kullanır. Bu ayrımı bilmeden kurulan firewall kuralları zone transfer’ı sessizce bloklar ve siz saatlerce neden çalışmadığını araştırırsınız.

Windows Firewall üzerinde gerekli kuralı eklemek:

New-NetFirewallRule -DisplayName "DNS Zone Transfer Inbound" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 53 `
    -RemoteAddress "10.10.1.20","10.10.2.10" `
    -Action Allow `
    -Profile Domain,Private

Eğer aralarında dedicated bir DNS sunucusu varsa ve bu sunucu domain üyesi değilse Profile parametresinde Public da eklemeniz gerekebilir. Bir kez gördüm, external secondary sunucu zone transfer alamıyordu; sorun sadece profile seçimiydi.

Sorun Giderme

nslookup ile Hızlı Doğrulama

nslookup -type=SOA sirket.local 10.10.1.20

Bu sorgu secondary sunucudan SOA kaydını çeker. Dönen seri numarası primary ile eşleşiyorsa transfer güncel demektir. Farklı bir seri numarası görüyorsanız transfer gerçekleşmemiş veya gecikmiş.

Resolve-DnsName ile PowerShell Doğrulaması

Resolve-DnsName -Name "sirket.local" -Type SOA -Server "10.10.1.20" | 
    Select-Object Name, SerialNumber, PrimaryServer

DNS Debug Logging

Transfer sorunlarını derinlemesine araştırmak için DNS debug logging açılabilir. Production’da daima dikkatli kullanın; log dosyası hızla büyür.

Set-DnsServerDiagnostics -ComputerName "DC01" `
    -EnableLoggingToFile $true `
    -LogFilePath "C:WindowsSystem32dnsdns.log" `
    -MaxMBFileSize 500 `
    -ZoneTransfer $true `
    -Queries $false `
    -Answers $false

-ZoneTransfer $true ile sadece transfer olaylarını logluyoruz, genel sorgu trafiğini değil. Bu şekilde log dosyası makul boyutta kalır ve sorunlu transferleri netlik içinde görürsünüz.

Log dosyasını grep benzeri bir şekilde taramak için:

Get-Content "C:WindowsSystem32dnsdns.log" | 
    Select-String "AXFR|IXFR|ZONE TRANSFER" | 
    Select-Object -Last 50

Active Directory Integrated Zone’larda Zone Transfer

AD Integrated zone’larda durum biraz farklıdır. Tüm domain controller’lar aynı zone verisini AD replikasyonu üzerinden alır; aralarında klasik zone transfer gerçekleşmez. Ancak bu zone’dan non-AD secondary sunuculara veri aktarımı için yine standart zone transfer mekanizması kullanılır.

AD Integrated zone’un replikasyon kapsamını kontrol etmek:

Get-DnsServerZone -Name "sirket.local" | 
    Select-Object ZoneName, ReplicationScope, DirectoryPartitionName

ReplicationScope değerleri:

  • Forest: Tüm forest’taki DC’lere replike edilir
  • Domain: Yalnızca mevcut domain’deki DC’lere
  • Legacy: Eski DNS’e özgü AD partition’ı

Bir ortamda DNS02 secondary sunucusu zone transfer alamıyordu. Uzun araştırmanın sonunda anladık ki zone Forest scope ile replike olduyor ama DNS02 domain üyesi değil. Zone transfer için ayrıca IP tabanlı izin verilmesi gerekiyordu. AD replikasyonu olan DC’lere izin gerekmez; ama bunun dışındaki sunuculara gerektir. Bu iki mekanizmayı birbirine karıştırmak yaygın bir hata.

Notify Yapılandırmasının İncelikleri

Notify mekanizması düzgün yapılandırılmadığında zone değişiklikleri secondary sunuculara dakikalarca, hatta onlarca dakika geç ulaşabilir. Özellikle sık değişen zone’larda bu operasyonel sorunlara yol açar.

Mevcut notify ayarlarını görmek:

Get-DnsServerZone -Name "sirket.local" | 
    Select-Object ZoneName, Notify, NotifyServers

Notify değerleri:

  • NoNotify: Bildirim gönderilmez, secondary SOA polling yapar
  • Notify: Yalnızca Name Servers sekmesindeki sunuculara bildirim gönder
  • NotifyServers: Elle tanımlanan IP listesine bildirim gönder

Notify ayarını güncellemek:

Set-DnsServerPrimaryZone -Name "sirket.local" `
    -Notify NotifyServers `
    -NotifyServers "10.10.1.20","10.10.2.10"

Burada ince bir nokta var: Notify ve NotifyServers birbirinden bağımsız parametreler. -Notify NotifyServers dediğinizde sistem liste kullanacağını anlıyor; -NotifyServers ile de listeyi belirliyorsunuz. İkisini birlikte kullanmayı unutmayın.

Çoklu Zone’lar için Toplu Yapılandırma

Onlarca zone olan ortamlarda her birini tek tek yapılandırmak yerine toplu script kullanmak daha mantıklı:

$secondaryServers = @("10.10.1.20", "10.10.2.10")
$zones = Get-DnsServerZone | Where-Object { $_.ZoneType -eq "Primary" -and $_.IsAutoCreated -eq $false }

foreach ($zone in $zones) {
    Write-Host "Yapılandırılıyor: $($zone.ZoneName)"
    
    Set-DnsServerPrimaryZone -Name $zone.ZoneName `
        -SecureSecondaries TransferToSecureServers `
        -SecondaryServers $secondaryServers `
        -Notify NotifyServers `
        -NotifyServers $secondaryServers
    
    Write-Host "$($zone.ZoneName) tamamlandi." -ForegroundColor Green
}

Bu script’i önce test ortamında çalıştırın ve IsAutoCreated -eq $false filtresini koruyun; aksi halde _msdcs, TrustAnchors gibi otomatik oluşturulan zone’ları da etkileyebilirsiniz.

Zone Transfer Sağlığını İzleme

Monitoring açısından zone transfer başarısızlıklarını yakalamanın en pratik yolu Windows Event Log’u kullanmak. DNS Server event log’unda zone transfer ile ilgili kritik event ID’leri:

  • 6527: Zone transfer tamamlandı
  • 6528: Zone transfer başlatıldı
  • 6529: Zone transfer başarısız
  • 6000: DNS Server başlatıldı

Bu event’leri izlemek için:

Get-EventLog -LogName "DNS Server" -EntryType Error,Warning -Newest 100 | 
    Where-Object { $_.EventID -in @(6527, 6528, 6529) } | 
    Select-Object TimeGenerated, EventID, Message | 
    Format-List

Zabbix, PRTG veya Nagios kullanıyorsanız bu event ID’leri izleme sistemine eklemek, zone transfer sorunlarını proaktif olarak yakalamanızı sağlar. Uyarı almadan önce kullanıcıların DNS sorununu yaşaması, sysadmin’in kabul edemeyeceği bir senaryo.

İpuçları ve Dikkat Edilmesi Gerekenler

Yıllar içinde topladığım birkaç pratik not:

  • Seri numarası yönetimi: Manuel düzenleme yapıyorsanız seri numarasını her zaman artırın. YYYYMMDDNN formatı (örneğin 2024030101) yönetimi kolaylaştırır.
  • Zone transfer ile replikasyon karışıklığı: AD DC’ler arası zone verisi AD replikasyonu üzerinden gider. Zone transfer klasik secondary-primary ilişkisi içindir. İkisini karıştırmak yapılandırma hatalarına yol açar.
  • TCP 53 firewall açılmadan zona transfer çalışmaz: Bu en yaygın tuzak. UDP 53 açık olabilir, DNS sorguları geliyordur; ama TCP 53 kapalıysa transfer sessizce başarısız olur.
  • Secondary zone expired olduğunda: ExpireLimit dolduğunda secondary sunucu zone’u invalid olarak işaretler ve sorgulara SERVFAIL döner. Bu durumda manuel FullTransfer tetiklemek gerekir.
  • Stub zone alternatifi: Sadece NS ve SOA kayıtlarını tutmanız yeterliyse stub zone daha hafif bir alternatif. Tüm kayıtları taşımak yerine yetki bilgisini güncel tutmak istediğinizde kullanışlı.

Sonuç

Windows DNS üzerinde zone transfer yapılandırması görünürde basit ama detayları olan bir konu. Primary-secondary ilişkisini doğru kurmak, güvenli transfer politikası seçmek, SOA parametrelerini optimize etmek ve notify mekanizmasını aktif kullanmak; bunların hepsi birbirini tamamlayan parçalar.

En sık yapılan hata, çalışıyor görünen ama güvensiz olan bir yapılandırmayı sorgulamadan bırakmak. “Any server” modunda zone transfer açık olan, TCP 53 dünyanın her yerine açık olan, notify kapalı olduğu için 15 dakika gecikmeyle güncellenen secondary sunucular gerçek ortamlarda karşılaştığım tablolar.

Bugün yapılacak en iyi yatırım: mevcut ortamınızdaki zone’ların SecureSecondaries değerini kontrol etmek, gereksiz transfer izinlerini kaldırmak ve notify mekanizmasının aktif olduğunu doğrulamak. Bu üç adım bile DNS altyapınızın hem güvenliğini hem güvenilirliğini ciddi ölçüde artırır.

Bir yanıt yazın

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