DNS kurulumu yalnızca sunucuya bir rol eklemek değildir. Hangi isimler için yetkili olduğunuz, hangi sorguları başka çözümleyiciye göndereceğiniz ve hangi istemcilerin hizmeti kullanabileceği belirlenmelidir. Yanlış bir DNS tasarımı, çalışan ağ bağlantısını uygulama kesintisi gibi gösterebilir. Doğru kurulmuş bir hizmet ise kimlik doğrulamadan uygulama erişimine kadar birçok sürecin anlaşılır biçimde işlemesini sağlar.
Bu rehber Windows Server 2025 veya 2022 üzerinde bağımsız bir laboratuvar DNS sunucusunu ele alır. Active Directory kurulumuyla oluşan AD-entegre zone'larda saklama, replikasyon ve dinamik güncelleme tercihleri farklıdır. Örnek lab.example.com zone'u ve 10.30.10.0/24 ağı yalnızca anlatım içindir; mevcut yetkili DNS altyapısının üzerine aynı isimli zone oluşturmayın.
1. Yetkili sunucu ile çözümleyiciyi ayırın
Yetkili DNS, yönettiğiniz alanın kayıtlarını sunar. Özyinelemeli çözümleme ise istemci adına farklı alanlardaki cevapları bulmaya çalışır. Aynı sunucu bazı ortamlarda iki rolü de üstlenebilir, ancak erişim ve güvenlik kararı buna göre verilmelidir. Kurumsal istemciler için hazırlanmış çözümleyiciyi denetimsiz biçimde internete açmak uygun bir başlangıç değildir.
Önce IP adresini, dinlenecek ağ arayüzünü, izin verilen istemci ağlarını ve dış sorgu politikasını yazın. Birden fazla ağ kartı varsa DNS'in hangilerinde hizmet vereceğini ayrıca değerlendirin. Aynı bilgisayarda başka bir ürünün DNS hizmeti çalışıyorsa port ve hizmet çakışmalarını çözmeden ilerlemeyin.
2. Rolü yükleyin ve ilk zone'u oluşturun
Yönetici PowerShell oturumunda DNS rolü yönetim araçlarıyla kurulabilir. Microsoft DNS hızlı başlangıç dokümanı, rol kurulumunu ve çözümleyici ayarlarının kapsamını açıklar. Aşağıdaki örnek dosya tabanlı bir primary zone içindir; AD-entegre zone örneği değildir.
Install-WindowsFeature DNS -IncludeManagementTools
Add-DnsServerPrimaryZone -Name "lab.example.com" -ZoneFile "lab.example.com.dns"
Add-DnsServerPrimaryZone -NetworkId "10.30.10.0/24" -ZoneFile "10.30.10.in-addr.arpa.dns"Forward lookup zone isimden adrese, reverse lookup zone ise adresten isme sorgular için kullanılır. Ters kayıt her uygulamanın çalışması için zorunlu değildir, ancak izleme ve sorun gidermede fayda sağlayabilir. Reverse zone oluşturmak, bütün mevcut A kayıtları için otomatik PTR üretildiği anlamına gelmez.
3. Örnek kaydı ekleyin ve belirli sunucuyu sorgulayın
Laboratuvar uygulama sunucusunun 10.30.10.50 olduğunu varsayalım. Zone oluşturulduktan sonra A kaydını ve uygun reverse zone mevcutsa PTR kaydını ekleyebilirsiniz. Testi önce açıkça belirttiğiniz DNS sunucusuna yöneltin; böylece istemcinin önbelleğinden veya başka bir çözümleyiciden gelen cevabı yeni kurulumun sonucu sanmazsınız.
Add-DnsServerResourceRecordA -ZoneName "lab.example.com" -Name "app01" -IPv4Address "10.30.10.50" -CreatePtr
Resolve-DnsName app01.lab.example.com -Server 10.30.10.10
Resolve-DnsName 10.30.10.50 -Type PTR -Server 10.30.10.10Cevapta beklediğiniz IP'yi, kayıt türünü ve sorguladığınız sunucuyu kontrol edin. Ardından bir istemci üzerinden aynı ismi çözümleyin. Sunucuda doğru cevap almak, istemcinin gerçekten bu DNS'i kullandığını kanıtlamaz. DHCP seçenekleri, statik ayarlar ve VPN profilleri ayrı ayrı kontrol edilmelidir.
4. Dış sorgu ve koşullu yönlendirmeyi planlayın
İç zone'lar dışında kalan adlar için root hints veya kurumsal olarak onaylanmış forwarder düzeni kullanılabilir. Forwarder listesine erişilebilir olmayan adresler eklemek, bazı sorguların gecikmesine neden olabilir. Dış ad çözümleme ihtiyacı yoksa buna uygun daha sınırlı bir rol tasarlanabilir.
Koşullu forwarder, belirli bir alanın sorgularını o alanı bilen çözümleyiciye göndermek için kullanılabilir. İş ortağı veya farklı forest ile entegrasyonda faydalıdır; fakat karşı tarafın bütün kayıtlarını kendi zone'unuza kopyalamanın yerine geçen kontrollü bir tasarım olarak düşünülmelidir. Hedef sunucular, erişim yolları ve sorumlular belgelenmelidir.
5. Güncelleme ve zone aktarımı ayarlarını daraltın
Kayıtları kimlerin ekleyebileceğini ve değiştirebileceğini belirleyin. Bağımsız laboratuvar zone'unun dinamik güncelleme davranışı ile AD-entegre zone'un güvenli güncellemesi aynı değildir. Sırf istemci kaydı oluşmuyor diye erişim kurallarını gereğinden fazla genişletmek yerine kimlik, zone türü ve güncelleme yolunu inceleyin.
Zone aktarımı gerekiyorsa alıcıları bilinen ikincil sunucularla sınırlandırın. Kullanılmayan aktarım yetkilerini açık bırakmayın. İç servis adları, ağ yapısı hakkında bilgi taşıyabilir. Yetki tasarımını yalnızca yazma hakkı üzerinden değil, veri paylaşımının kapsamı üzerinden de değerlendirin.
Önbellek nedeniyle eski cevap gelirse
TTL, bir cevabın önbellekte ne kadar süre kullanılabileceğini etkiler. Kaynak kaydı değiştirmek, bütün istemcilerde aynı anda yeni cevabın görüleceği anlamına gelmez. Önce yetkili cevabın doğru olduğunu belirleyin; sonra aradaki çözümleyicileri ve istemci önbelleğini inceleyin. Her sorunda bütün önbellekleri temizlemek, hatanın nerede olduğunu anlamayı zorlaştırabilir.
Bir web uygulamasını başka IP'ye taşırken DNS ile uygulama hazırlığını aynı değişiklik planında tutun. Yeni sunucunun sertifikası, host adı ve ağ erişimi tamamlanmadan yalnızca A kaydını değiştirmek başarısız bir geçişe yol açabilir. Geri dönüşte hangi kaydın eski değere alınacağı da yazılı olmalıdır.
Kabul kontrol listesi
- Yetkili olunan zone'lar ve çözümleme kapsamı tanımlandı.
- Örnek A ve PTR sorguları doğru sunucuda sınandı.
- İstemci DNS ayarları ve dış sorgu davranışı doğrulandı.
- Güncelleme ve zone aktarımı yetkileri sınırlandı.
- Kritik kayıt değişiklikleri ve geri dönüş yöntemi belgelendi.
CieloSync ile DNS'i tekil bir servis yerine bütün altyapının bağımlılığı olarak değerlendirebilirsiniz. Yönetilen sistemler hakkında bilgi alın veya kurulum ihtiyacınızı paylaşın.