DNS A kaydı çalışıyor, PTR oluşmuyor: ters bölge ve kayıt dökümü rehberi

DNS yönetiminde “associated PTR oluşturulamadı” uyarısı, her zaman A kaydının da başarısız olduğunu göstermez. İsimden adrese çözümleme ile adresten isme çözümleme ayrı kayıtlardır. Bu ayrımı yapmak, gereksiz sunucu veya etki alanı değişikliklerini önler.

1. İleri sorguyu doğrula
2. Ters bölgeyi bul
3. Yazma yetkisini incele
4. Kaydı karşılaştır
5. Önbelleği ayır
6. Kayıt dökümünü sakla

A ve PTR kayıtlarının yönünü ayırın

A kaydı bir adı IPv4 adresine çözer. PTR kaydı ters sorgu bölgesinde adresin bir ada karşılığını tutar. İleri kayıt eklenirken PTR oluşturma seçeneğinin işaretlenmesi, doğru ters bölgenin varlığını veya yazılabilir olmasını garanti etmez.

Ters bölgenin hangi DNS sunucusunda yetkili olduğu ve ilgili ağ aralığını nasıl temsil ettiği incelenmelidir. Her ağın mutlaka basit bir /24 ters bölgeyle yönetildiğini varsaymayın; alt delegasyon veya farklı yönetim sınırları bulunabilir.

Yetkili cevap ile istemci önbelleğini karşılaştırın

İstemci, önbellekteki eski cevabı gösterebilir. Yetkili DNS sunucusuna doğrudan sorgu ile istemcinin normal sorgusunu karşılaştırın. Örneklerde kullanılan batuhanyazici.com alanı anlatım içindir; PTR için çıkan sonucun boş olması tek başına web sitesinin çalışmadığını göstermez.

Resolve-DnsName batuhanyazici.com -Type A
$adres = (Resolve-DnsName batuhanyazici.com -Type A | Where-Object IPAddress | Select-Object -First 1).IPAddress
if ($adres) { Resolve-DnsName $adres -Type PTR }
Get-DnsClientCache | Select-Object -First 20

Sorunu anlamak için ilk aşamada bütün DNS önbelleğini temizlemek gerekmez. Önce mevcut cevabı kaydetmek, yanlış sonucun hangi katmanda oluştuğunu göstermeye yardımcı olur.

PTR oluşturulamıyorsa bölge ve izinleri kontrol edin

Adresin ait olduğu ters bölgenin yüklü ve güncellenebilir olduğunu doğrulayın. Dinamik güncellemenin güvenli olarak sınırlandırıldığı ortamlarda, istemci veya DHCP hizmetinin kayıt oluşturma yetkisi önemlidir. Aynı kayıt üzerinde kalan eski sahiplik de güncellemeyi etkileyebilir.

Doğru kaydı yalnızca yetkili sunucuda değiştirin. Bir ikincil sunucuda kayıt düzenlemeye çalışmak veya yanlış ters bölgede PTR açmak, gerçek problemi gizler. Elle kayıt eklenirse ileri kayıtla tutarlılığını ve zaman içindeki bakımını da planlayın.

Taşıma öncesi yalnızca adres listesi değil kayıt envanteri alın

Alan adı taşınırken A kayıtları kadar CNAME, MX, TXT, SRV ve mevcut delegasyonlar da önemlidir. Mail doğrulama kayıtlarının veya uygulama keşif kayıtlarının unutulması, web sitesi açıldığı halde başka işlevlerin bozulmasına neden olabilir.

TTL, kayıt türü, ad, hedef ve varsa öncelik bilgilerini döküme dahil edin. İhracat dosyasının kritik altyapı bilgisi taşıdığını unutmayın; blog eki olarak yayımlamayın. DNS bölgesi dışa aktarımı ile Active Directory sistem durumu yedeği aynı şey değildir.

Get-DnsServerResourceRecord -ZoneName "lab.batuhanyazici.com" |
    Select-Object HostName,RecordType,TimeToLive,RecordData
Export-DnsServerZone -Name "lab.batuhanyazici.com" -FileName "lab-dns-oncesi.dns"

Kapanışta tutarlılığı tekrar ölçün

Kaydı ekledikten sonra hem yetkili cevap hem normal istemci sorgusu kontrol edilir. Uygulama gerçekten ters çözümlemeye ihtiyaç duyuyorsa onun davranışı da test edilmelidir.

• A ve PTR yönleri doğru anlaşılmış.
• Doğru ters bölge ve yetkili sunucu kullanılmış.
• Eski ve yeni cevapların hangi kaynaktan geldiği belirlenmiş.
• Taşıma öncesi/sonrası kritik kayıtlar karşılaştırılmış.
• İç kayıt dökümleri özel alanda saklanmış.

İlgili çalışma notları

• Domain Controller geçişi: FSMO aktarımından önce ve sonra ne doğrulanmalı?
• SQL Server bağlantısı: DNS, port, TLS ve sürüm bilgisini doğru ayırmak
• GPO uygulanmıyor: bağlantı, kapsam ve öncelik sırasını doğru incelemek