TTL Değeri Nedir? Active Directory ve DNS Ortamlarında TTL Yönetimi

yazar

Ağ yönetiminde ve özellikle Active Directory ortamlarında işler sarpa sardığında, genellikle göz ardı edilen ama aslında her şeyin merkezinde yer alan bir kavramla karşılaşırsınız: TTL (Time to Live). Yıllarca sistem yöneticiliği yaptıktan sonra şunu rahatlıkla söyleyebilirim; TTL’yi doğru anlamadan DNS sorunlarını çözmek, replikasyon problemlerini debug etmek ya da Active Directory’nin neden tutarsız davrandığını anlamak neredeyse imkansız.

TTL Nedir ve Neden Bu Kadar Önemli?

TTL, bir verinin bellekte, önbellekte ya da ağda ne kadar süre geçerli kalacağını belirleyen sayısal bir değerdir. Bu değer, bağlama göre farklı anlamlar taşır. DNS söz konusu olduğunda saniye cinsinden ifade edilir ve bir DNS kaydının önbelleklerde ne kadar süre tutulacağını belirler. IP paketlerinde ise bu değer, paketin ağ üzerinde kaç router atlayabileceğini gösterir.

Active Directory yönetimi açısından TTL’yi üç farklı katmanda düşünmek gerekir:

  • DNS TTL: AD DNS kayıtlarının istemci ve DNS sunucuları tarafından ne kadar önbellekleneceği
  • Kerberos Ticket TTL: Bilet geçerlilik süresi ve yenileme politikaları
  • AD Replication TTL: Nesne değişikliklerinin replikasyon sürecindeki ömrü

Her birinin sistem üzerinde farklı etkileri var ve her birini ayrı ayrı ele alacağız.

DNS TTL Değerini Anlamak

DNS Önbellekleme Mekanizması

Bir istemci bilgisayar bir hostname’i çözdüğünde, DNS sunucusundan aldığı cevap içinde o kaydın TTL değeri de gelir. İstemci bu cevabı, TTL süresi dolana kadar kendi önbelleğinde tutar. Bu süre içinde aynı hostname için yeni bir DNS sorgusu yapmaz, direkt önbellekteki değeri kullanır.

Örneğin dc01.contoso.local için TTL değeri 3600 saniye (1 saat) olarak ayarlandıysa, bir istemci bu kaydı bir kez çözdükten sonra 1 saat boyunca aynı IP adresini kullanmaya devam eder. Bu süre içinde DC’nin IP adresi değişirse, istemci bunu 1 saat boyunca fark etmez.

Windows’ta mevcut DNS önbelleğini görüntülemek için:

ipconfig /displaydns

DNS önbelleğini temizlemek için:

ipconfig /flushdns

Belirli bir hostname için DNS sorgusunu TTL değeriyle birlikte görmek için:

nslookup -debug dc01.contoso.local

Active Directory DNS Kayıtlarının Varsayılan TTL Değerleri

Windows Server’da Active Directory ile entegre DNS bölgelerinde varsayılan TTL değeri 3600 saniye (1 saat) olarak gelir. Bu değer, bölgenin SOA (Start of Authority) kaydında tanımlanır.

SOA kaydını PowerShell ile kontrol etmek için:

Get-DnsServerZone -Name "contoso.local" | Select-Object ZoneName, ZoneType
Get-DnsServerResourceRecord -ZoneName "contoso.local" -RRType Soa

AD ortamında tüm DC kayıtlarının TTL değerlerini listelemek için:

Get-DnsServerResourceRecord -ZoneName "contoso.local" -RRType A | 
    Where-Object {$_.HostName -like "_msdcs*" -or $_.HostName -like "dc*"} | 
    Select-Object HostName, TimeToLive, RecordData

TTL Değeri Değiştirme

Bölge genelinde varsayılan TTL değerini değiştirmek için DNS Manager üzerinden SOA kaydını düzenleyebilir ya da PowerShell kullanabilirsiniz:

$zone = "contoso.local"
$soaRecord = Get-DnsServerResourceRecord -ZoneName $zone -RRType Soa
$newSoaRecord = $soaRecord.Clone()
$newSoaRecord.TimeToLive = [System.TimeSpan]::FromSeconds(1800)
Set-DnsServerResourceRecord -ZoneName $zone -OldInputObject $soaRecord -NewInputObject $newSoaRecord

Belirli bir A kaydının TTL değerini değiştirmek için:

$zoneName = "contoso.local"
$recordName = "webserver01"
$oldRecord = Get-DnsServerResourceRecord -ZoneName $zoneName -Name $recordName -RRType A
$newRecord = $oldRecord.Clone()
$newRecord.TimeToLive = [System.TimeSpan]::FromSeconds(300)
Set-DnsServerResourceRecord -ZoneName $zoneName -OldInputObject $oldRecord -NewInputObject $newRecord
Write-Host "TTL degeri 300 saniyeye guncellendi."

Gerçek Dünya Senaryosu: DC Geçişi Sırasında TTL Yönetimi

Birkaç yıl önce büyük bir kurumda domain controller geçişi yapıyorduk. Eski DC’nin görevlerini yeni bir sunucuya taşıyacaktık. İşin can sıkıcı kısmı şuydu; geçiş sonrasında bazı istemciler hala eski DC’ye bağlanmaya çalışıyordu. Sabahları gelen “giriş yapamıyorum” şikayetleri tam olarak bu yüzden geliyordu.

Sorunun köküne inince TTL değerlerinin 24 saat olarak ayarlandığını gördük. Yani geçiş yapılmasına rağmen istemciler 24 saat boyunca eski IP adresini kullanmaya devam ediyordu.

Doğru yaklaşım şu olmalıydı:

  • Geçişten 48 saat önce TTL değerlerini 300 saniyeye (5 dakika) indirmek
  • Geçişi gerçekleştirmek
  • Geçiş sonrası tüm trafiğin yeni DC’ye yöneldiğini doğrulamak
  • TTL değerlerini tekrar normal seviyeye (3600 saniye) çıkarmak

Bu yaklaşım, DNS önbellekleme sorununu büyük ölçüde ortadan kaldırır.

Kerberos Ticket TTL ve Active Directory

Kerberos’ta TTL Kavramı

Active Directory’de kimlik doğrulama Kerberos protokolüne dayanır ve bu protokolde TTL kavramı bilet geçerlilik süresi olarak karşımıza çıkar. Kerberos biletleri iki farklı süreyle tanımlanır:

  • Maximum Ticket Lifetime: Bir TGT (Ticket Granting Ticket) biletinin maksimum geçerlilik süresi
  • Maximum Ticket Renewal Lifetime: Bir biletin yenilenebileceği maksimum toplam süre

Windows Server’da varsayılan değerler şöyledir:

  • Maximum Ticket Lifetime: 10 saat
  • Maximum Ticket Renewal Lifetime: 7 gün
  • Maximum Clockskew (Zaman Sapması): 5 dakika

Bu değerleri Group Policy üzerinden yönetebilirsiniz: Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy

PowerShell ile mevcut Kerberos politikasını görüntülemek için:

Get-ADDefaultDomainPasswordPolicy | Select-Object MaxTicketAge, MaxRenewAge, MaxClockSkew

Kerberos Zaman Senkronizasyonu Sorunu

Kerberos’un en kritik TTL bağımlılığı zaman senkronizasyonudur. Eğer bir istemci ile DC arasındaki saat farkı 5 dakikayı geçerse, Kerberos kimlik doğrulaması başarısız olur. Bu durum “Kerberos pre-authentication failed” hatası olarak karşınıza çıkar.

Domain ortamında zaman senkronizasyonunu kontrol etmek için:

w32tm /query /status
w32tm /query /peers

Saat farkını test etmek için:

w32tm /monitor /computers:dc01.contoso.local,dc02.contoso.local /nowarn

Eğer bir istemcide zaman senkronizasyonu zorla yaptırmak gerekiyorsa:

net stop w32tm
w32tm /unregister
w32tm /register
net start w32tm
w32tm /resync /force

DNS Dinamik Kayıt TTL Sorunları

Scavenging ve TTL İlişkisi

Active Directory ortamında DNS scavenging (eskimiş kayıtları temizleme) özelliği devreye girdiğinde, TTL değerleri kritik bir rol oynar. Scavenging, belirli bir süre güncellenmemiş DNS kayıtlarını otomatik olarak siler.

Bu mekanizmanın iki önemli parametresi var:

  • No-Refresh Interval: Kayıtların güncellenmeyeceği süre (varsayılan 7 gün)
  • Refresh Interval: Kayıtların yenilenip silinebileceği süre (varsayılan 7 gün)

Yani bir kayıt 14 günden uzun süre güncellenmezse scavenging tarafından silinebilir. Bu, TTL değerleriyle karıştırılmamalıdır. TTL önbellekleme süresiyle ilgiliyken, scavenging kayıt yaşam döngüsüyle ilgilidir.

DNS scavenging ayarlarını PowerShell ile kontrol etmek için:

Get-DnsServerScavenging
Get-DnsServerZoneAging -ZoneName "contoso.local"

Scavenging’i etkinleştirmek için:

Set-DnsServerScavenging -ScavengingState $true -ScavengingInterval 7.00:00:00 -ApplyOnAllZones
Set-DnsServerZoneAging -ZoneName "contoso.local" -Aging $true -NoRefreshInterval 7.00:00:00 -RefreshInterval 7.00:00:00

IP Paket TTL ve AD Replikasyonu

Hop Count TTL

IP paketlerinde TTL değeri, paketin ağda kaç router atlayabileceğini belirler. Her router bir paketin TTL değerini 1 azaltır. TTL sıfıra ulaştığında paket düşürülür ve gönderene ICMP “Time Exceeded” mesajı gönderilir.

Windows’ta varsayılan IP TTL değeri 128‘dir. Linux sistemlerde bu değer genellikle 64‘tür.

Mevcut TTL değerini görmek için basit bir ping testi yeterli:

ping dc01.contoso.local -i 1

-i parametresi TTL değerini manuel olarak belirler. Bu sayede kaç hop sonra paketin düşürüldüğünü test edebilirsiniz.

Traceroute ile hop sayısını ve her noktadaki gecikmeyi görmek için:

tracert dc01.contoso.local

AD replikasyonu açısından, iki site arasındaki replikasyon bağlantısında çok fazla hop varsa (örneğin 15+ hop), bu durum replikasyon gecikmelerine yol açabilir. TTL değeri bu hop’ların önüne geçebilir.

AD Replikasyon TTL Kontrolü

Active Directory replikasyonunda sorun yaşandığında, önce temel kontrolleri yapmak gerekir:

repadmin /showrepl
repadmin /replsummary
repadmin /showlag * dc01.contoso.local

Replikasyon sorunlarında DNS kayıt TTL’leri kritik rol oynar. Eğer bir DC’nin IP adresi değiştiyse ve eski TTL süresi dolmadan önce diğer DC’ler bu değişikliği göremediyse, replikasyon başarısız olur.

Pratik TTL Optimizasyon Stratejileri

Farklı Ortamlar İçin TTL Tavsiyeleri

Üretim ortamı (stabil):

  • DC A ve SRV kayıtları: 600-3600 saniye
  • Kritik servis kayıtları: 300-600 saniye
  • Normal workstation kayıtları: 1200-3600 saniye

Değişim/geçiş dönemleri:

  • Değişimden 48 saat önce tüm TTL değerlerini 300 saniyeye indirin
  • Değişimden 2-4 saat sonra stabilleşince TTL’yi tekrar artırın

Test ortamı:

  • Tüm kayıtlar için 60-300 saniye ideal
  • Hızlı test döngüleri için düşük TTL avantaj sağlar

Toplu TTL Değişikliği

Bir zone içindeki tüm A kayıtlarının TTL değerini toplu olarak değiştirmek gerektiğinde şu script işe yarar:

$zoneName = "contoso.local"
$newTTL = [System.TimeSpan]::FromSeconds(300)

$records = Get-DnsServerResourceRecord -ZoneName $zoneName -RRType A
foreach ($record in $records) {
    $newRecord = $record.Clone()
    $newRecord.TimeToLive = $newTTL
    try {
        Set-DnsServerResourceRecord -ZoneName $zoneName -OldInputObject $record -NewInputObject $newRecord
        Write-Host "Guncellendi: $($record.HostName) - Yeni TTL: 300 saniye"
    } catch {
        Write-Warning "Hata: $($record.HostName) - $($_.Exception.Message)"
    }
}
Write-Host "Islem tamamlandi."

TTL Kaynaklı Yaygın Active Directory Sorunları

Sorun 1: Eski DC IP’sine Bağlanan İstemciler

Belirtiler:

  • “The specified domain either does not exist or could not be contacted” hatası
  • Bazı istemciler domain’e girerken sorun yaşıyor, bazıları giremiyor
  • Tutarsız kimlik doğrulama sorunları

Çözüm adımları:

  • ipconfig /displaydns ile önbellekte hangi DC IP’lerinin olduğunu kontrol edin
  • Eski IP’nin hala DNS’te kaydının olup olmadığını doğrulayın
  • ipconfig /flushdns ile önbelleği temizleyin
  • DNS kaydının TTL değerini kontrol edin

Sorun 2: Kerberos Hataları Sonrası Gecikmiş Düzelme

Kerberos biletleri TTL tabanlı çalıştığından, bir sorun yaşandıktan sonra bile mevcut biletler TTL süresi dolana kadar geçerli kalmaya devam eder. Bu nedenle şifre değişikliği veya hesap kilitleme sonrasında kullanıcının anlık olarak etkilenmemesi normaldir. Ancak bu durum güvenlik açığı olarak değerlendirilmelidir.

Belirli bir kullanıcının aktif Kerberos biletlerini sıfırlamak için:

klist purge

Tüm kullanıcıların biletlerini uzaktan temizlemek için (domain admin yetkisiyle):

klist -li 0x3e7 purge

Sorun 3: SRV Kayıtlarının Önbelleğe Alınması

Domain Controller’lar, Active Directory servislerini duyurmak için SRV kayıtları kullanır. Bu kayıtlar da TTL değerine sahiptir ve önbelleklenebilir. Bir DC kapatıldığında, istemciler SRV kaydı TTL süresi dolana kadar o DC’ye bağlanmaya çalışmaya devam edebilir.

SRV kayıtlarını sorgulamak için:

nslookup -type=SRV _ldap._tcp.dc._msdcs.contoso.local
nslookup -type=SRV _kerberos._tcp.contoso.local

TTL Değerlerini İzleme ve Monitoring

Proaktif İzleme Yaklaşımı

TTL sorunlarını reaktif değil proaktif olarak yönetmek gerekir. Bunun için düzenli kontroller yapılmalıdır.

DNS sağlık durumunu otomatik kontrol eden basit bir script:

$domainName = "contoso.local"
$dcList = Get-ADDomainController -Filter * | Select-Object -ExpandProperty HostName

foreach ($dc in $dcList) {
    $aRecord = Get-DnsServerResourceRecord -ZoneName $domainName -Name ($dc -split ".")[0] -RRType A -ErrorAction SilentlyContinue
    if ($aRecord) {
        $ttlSeconds = $aRecord.TimeToLive.TotalSeconds
        if ($ttlSeconds -gt 3600) {
            Write-Warning "UYARI: $dc icin TTL cok yuksek: $ttlSeconds saniye"
        } elseif ($ttlSeconds -lt 60) {
            Write-Warning "UYARI: $dc icin TTL cok dusuk: $ttlSeconds saniye"
        } else {
            Write-Host "OK: $dc - TTL: $ttlSeconds saniye" -ForegroundColor Green
        }
    } else {
        Write-Warning "HATA: $dc icin A kaydi bulunamadi!"
    }
}

Event Log İzleme

DNS ve Kerberos TTL sorunları Windows Event Log’a yazılır. İzlenmesi gereken event ID’ler:

  • Event ID 4 (DNS): DNS sunucu servisi başlatma/durdurma
  • Event ID 414 (DNS): Zone yükleme hatası
  • Event ID 4771 (Security): Kerberos ön kimlik doğrulama başarısız
  • Event ID 4769 (Security): Kerberos servis bileti istendi

Bu event’leri PowerShell ile sorgulamak için:

Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4771]]" -MaxEvents 20 | 
    Select-Object TimeCreated, Message | 
    Format-List

Sonuç

TTL değeri, ilk bakışta basit bir sayı gibi görünse de Active Directory ortamlarında pek çok kritik sürecin merkezinde yer alır. DNS önbellekleme, Kerberos kimlik doğrulama, replikasyon sağlığı ve IP paket yönlendirmesi; hepsi TTL kavramıyla doğrudan ilişkilidir.

Yıllarca sistem yöneticiliği yaptıktan sonra öğrendiğim en önemli ders şu: Planlı değişiklikler öncesinde TTL değerlerini düşürün, değişiklik sonrası stabilleşince tekrar artırın. Bu basit pratik, DC geçişlerinde, IP değişikliklerinde ve servis migrasyonlarında saatler sürebilecek hata ayıklama süreçlerini ortadan kaldırır.

Bunun dışında:

  • DNS scavenging ve TTL değerlerinin birbirini etkilediğini unutmayın
  • Kerberos zaman senkronizasyonu, TTL tabanlı bir güvenlik mekanizmasıdır ve ihmal edilmemeli
  • Monitoring scriptlerini üretime almadan önce test ortamında deneyin
  • Troubleshooting sırasında her zaman önce DNS önbelleğini temizleyip yeniden test edin

TTL’yi doğru yönetmek, Active Directory ortamınızın güvenilirliğini ve performansını doğrudan etkiler. Sorularınız veya kendi deneyimleriniz varsa yorum bırakın, hep birlikte öğrenelim.

Yorum yapın