Kurumsal DNS Mimarisi Nasıl Planlanır?
Kurumsal DNS mimarisi yalnız sunucu seçmekten ibaret değildir; farklı DNS rollerini uygun güvenlik ve ağ sınırlarına yerleştirir. Amaç, istemci çözümlemesini, iç ad alanını, internete açık alan adlarını ve dış sorgu çıkışını gereksiz ortak yetkilerden ayırmaktır.
İç yetkili DNS kurumsal kayıtların yetkili kaynağıdır; recursive resolver (özyinelemeli DNS çözümleyicisi) istemciler adına yanıt arar ve önbellek kullanır; DNS forwarder (DNS yönlendirici) sorguları belirlenmiş üst recursive resolver'lara aktarır; kamuya açık yetkili DNS ise yalnız yayımlanan dış bölgeler için yanıt verir. Bu roller aynı ürün ailesinde çalışabilse de her rolün erişim politikasını, sorumlu ekibini ve ortak arızalardan etkilenme riskini ayrı değerlendirin.
Mimari, istemcilerin yalnız kurumsal recursive resolver'lara erişmesini, iç kayıtların internetten görünmemesini ve kamuya açık yetkili sunucuların genel çözümleme hizmeti vermemesini sağlamalıdır. NIST’in (National Institute of Standards and Technology) Mart 2026’da yayımladığı SP 800-81 Rev. 3 rehberi de yetkili DNS ve recursive resolver rollerine farklı güvenlik politikaları uygulanmasını önerir. Yedeklilik, izleme, değişiklik yönetimi ve geri dönüş prosedürünü tasarımın başında belirleyin.
Kurumsal DNS İçin Rol, Ad Alanı, Yedeklilik ve Sorumluluk Planı
- İç yetkili DNS, recursive resolver, DNS forwarder ve kamuya açık yetkili DNS rollerini ayrı güven sınırlarında tanımlayın.
- İstemci ağlarını yalnız recursive resolver katmanına yönlendirin; yetkili sunucuları genel istemci çözümlemesinden ayırın.
- İç ve dış ad alanını, aynı adın iki ağda farklı yanıt verip vermeyeceğini ve her bölgenin kayıt sorumlusunu önceden belirleyin.
- Her kritik rol için aynı arızadan etkilenmeyecek yedek sistemler, izleme ve belgelenmiş bir devralma yolu kurun.
- Erişim kontrolü, güncelleme yetkisi, sorgu günlükleri, yama, kapasite ve geri dönüş için sorumlu ekipleri açıkça belirleyin.
Kurumsal DNS Bileşenlerinin Görevleri
Aynı yazılım birden çok DNS rolünü destekleyebilir; yine de süreç, ağ arayüzü, güvenlik politikası veya yönetilen hizmet sınırlarını açıkça ayırın.
İç Yetkili DNS
İç yetkili DNS, yalnız kurum içinde kullanılan bölge ve kayıtların yetkili kaynağıdır. Uygulama, dizin, veri tabanı, yönetim arayüzü ve benzeri iç adlar burada tutulabilir; bu sunucu istemciler adına internet alan adlarını çözmemelidir.
İç yetkili katmana sorgu erişimi çoğu yapıda recursive resolver katmanından, yönetim erişimi ise ayrı bir idari ağdan gelir. Dinamik güncelleme gerekiyorsa kaynak sistemler açıkça yetkilendirilir; ağdaki her cihazın kayıt yazmasına izin verilmez.
Recursive Resolver
Recursive resolver, kullanıcı cihazları ve uygulamalar adına DNS yanıtını bulur, sonucu önbelleğe alır ve yapılandırılmışsa DNSSEC doğrulaması yapar. İstemci ağlarının doğrudan kök, üst düzey alan veya dış yetkili sunucularla konuşması yerine sorguları bu katmanda toplamak, politikayı ve izlemeyi tek merkezden yönetmeyi kolaylaştırır.
Recursive resolver erişimini yalnız onaylı kurumsal ağlar, VPN istemcileri veya kimliği doğrulanmış servislerle sınırlandırın. İnternete açık recursive resolver, sorgu kötüye kullanımı ve yansıtma saldırıları için risk oluşturur.
İstemci veya şube bağlantısında DoT (DNS over TLS) ya da DoH (DNS over HTTPS) kullanılıyorsa sertifika doğrulamasını, onaylı DNS sunucusu listesini ve başarısızlık davranışını merkezi politikayla yönetin. Tarayıcı veya uygulamanın seçtiği farklı bir DoH hizmeti kurumsal çözümleme ve filtreleme katmanını atlayabilir.
DNS Forwarder
DNS forwarder, sorguları kökten başlayarak çözmek yerine belirlenmiş üst recursive resolver'lara iletir. Merkezi çıkış denetimi, kayıt politikası, protective DNS (koruyucu DNS) ile zararlı alan adı filtreleme veya şubelerin tek bir çözümleme katmanına bağlanması gibi gereksinimlerde kullanılabilir.
DNS forwarder zorunlu değildir; recursive resolver, iterative (yinelemeli) sorgularla çözümlemeyi doğrudan yürütebilir. DNS forwarder kullanılıyorsa bu hizmeti tüm kurum için tek hata noktası haline getirmeyin ve hangi sorguların hangi üst sisteme gönderildiğini belgeleyin.
Kamuya Açık Yetkili DNS
Kamuya açık yetkili DNS, kurumun internetten erişilmesi gereken bölgelerine ait yetkili yanıtları verir. Bu katmanda özyinelemeli çözümlemeyi kapatın, iç bölgeleri yüklemeyin ve yalnız gerekli DNS trafiğini kabul edin.
Birincil bölge verisinin nerede üretildiği ile internetten sorgu alan ikincil sunucuların nerede çalıştığı ayrı kararlar olabilir. Hidden primary modelinde birincil sunucu, kamuya açık NS kayıtlarında listelenmez; bölge verisini yalnız yetkilendirilmiş ikincil sunuculara aktarır. Kritik internet alanlarını aynı veri merkezi, ağ geçidi veya yetkili DNS sağlayıcısındaki arızaya bağlı kalmayacak coğrafi ve ağsal konumlara dağıtın.
DNS Rollerinin Sorgu ve Yönetim Trafiği
Tablo, DNS sorgularını gönderen tarafları ve her rolün ihtiyaç duyabileceği ek bağlantıları ayrı gösterir. Sorgulara dönen yanıtları da trafik kurallarına dahil edin; bölge aktarımı ve yönetim bağlantıları için normal istemci sorgularından ayrı erişim kuralları tanımlayın. Bu başlangıç modelini kurumun risk profiline göre uyarlayın.
| Rol | Sorgu Kaynağı | Gerekli Ek Bağlantılar | Temel Kısıt |
|---|---|---|---|
| İç yetkili DNS | Kurumsal recursive resolver'lar | Onaylı bölge aktarım eşleri ve yönetim servisleri | Genel özyinelemeli çözümleme ve internetten erişim kapalı |
| Recursive resolver | İstemci ağları, sunucu ağları ve VPN | İç yetkili DNS, DNS forwarder veya internet DNS hiyerarşisi | Yalnız onaylı istemcilere özyinelemeli çözümleme |
| DNS forwarder | Onaylı recursive resolver'lar veya şube DNS sunucuları | Belirlenmiş üst recursive resolver'lar | Sorgu kabulü yalnız izin verilen kaynaklarla sınırlı |
| Kamuya açık yetkili DNS | İnternetteki recursive resolver'lar | Onaylı bölge aktarım eşleri ve yönetim düzlemi | İç bölge yok, özyinelemeli çözümleme kapalı |
Yönetim düzlemini DNS sorgu düzleminden ayrıca koruyun. Yapılandırma, anahtar, bölge verisi ve günlük sistemlerine erişimi son kullanıcı ağından değil, kimliği doğrulanmış yönetim ağı veya kontrollü otomasyon kanalı üzerinden verin.
Güvenlik duvarı kuralları yalnız UDP için 53 numaralı port iznine indirgenmemelidir. Büyük yanıtlar, bölge aktarımı ve bazı doğrulama durumları TCP kullanımını gerektirir; gerekli kaynak ve hedef çiftleri için UDP ve TCP akışlarını birlikte değerlendirin.
İç ve Dış Ad Alanı ile Split-Horizon DNS
Ad alanı kararı, daha sonra yapılacak bütün bölge delegasyonlarını ve kayıt sahipliğini etkiler. Kurumun sahip olduğu bir alan adının ayrılmış alt alanını iç sistemler için kullanmak, gelecekteki ad çakışmalarını ve sertifika ya da hizmet keşfi sorunlarını azaltabilir.
Aynı tam alan adının iç ve dış ağda farklı yanıt vermesi gerekiyorsa split-horizon DNS kullanılabilir. Bu yöntem bazı erişim senaryolarını çözer ancak iki görünümde kayıt tutarlılığını sağlama, test ve hata ayıklama işlerini artırır. Bu nedenle yalnız ayrı iç ve dış yanıtlar gerçekten gerekiyorsa tercih edin.
DNS Rollerine Göre Erişim ve Güvenlik Politikaları
Tek bir genel güvenlik ayarı bütün DNS rollerine uymaz. Yetkili sunucuda veri bütünlüğü ve aktarım kontrolü, recursive resolver'da istemci yetkilendirmesi ve sorgu kötüye kullanımı, yönetim düzleminde ise kimlik doğrulama ile değişiklik kaydı önceliklidir.
- Özyinelemeli çözümleme erişimi: Erişime izin verilen istemci ağlarını, VPN adresi havuzlarını ve servis ağlarını açıkça tanımlayın; internetten gelen yetkisiz çözümleme taleplerini reddedin.
- Bölge aktarımı: AXFR (tam bölge aktarımı) ve IXFR (artımlı bölge aktarımı) işlemlerini yalnız tanımlı aktarım eşlerine açın. TSIG (Transaction Signature) gibi mekanizmalarla kaynağın yetkisini ve mesaj bütünlüğünü doğrulayın; başarısız denemeleri izleyin.
- Dinamik güncelleme: Kayıt yazabilen sistemlerin yetkisini bölge, ad ve kayıt türü düzeyinde sınırlandırın. TSIG kullanılıyorsa istemci gruplarına yalnız gerekli güncellemeleri yapabilen ayrı anahtarlar verin; ortak ve süresiz yönetici bilgileri kullanmayın.
- Yama ve sertleştirme: DNS yazılımını, işletim sistemini ve bağımlılıkları düzenli bakım pencerelerinde güncelleyin; kullanılmayan servisleri kapatın.
- Oran sınırlama: Kamuya açık yetkili katmanda ve gerekli iç katmanlarda olağan dışı sorgu hızlarını sınırlayan kontroller uygulanabilir; eşikleri normal trafiği ölçerek belirleyin.
Recursive Resolver'da DNSSEC Doğrulaması ve Yetkili Bölge İmzalama
Recursive resolver tarafında DNSSEC doğrulaması, imzalı bölgelerden gelen verinin güven zincirini kontrol eder. Kamuya açık yetkili DNS tarafında ise bölge imzalama, anahtar saklama, anahtar değişimi ve üst bölgedeki DS (Delegation Signer) kaydının bölgenin DNSSEC anahtarıyla eşleşmesi ayrı bir işletim sürecidir.
İç bölgelerde DNSSEC uygulanabilir; ancak doğrulamanın başlayacağı güvenilir kaydın, yani trust anchor’ın (güven çıpasının) dağıtımı ve anahtar yaşam döngüsü ayrıca planlanmalıdır. DNSSEC gizlilik sağlamaz ve yanlış anahtar ya da DS değişikliği doğru kayıtların da doğrulanamamasına yol açabilir; geri dönüş adımları önceden test edilmelidir.
Sorgu Günlükleri ve Veri Saklama
DNS günlükleri olay inceleme ve kapasite analizi için değerlidir ancak kullanıcıların eriştiği alan adları hakkında ayrıntı içerebilir. Kaydedilecek günlük alanlarını, erişim yetkilerini ve saklama süresini belirlenen amaç için gereken düzeyle sınırlayın.
Recursive resolver için sorgu hacmi, yanıt kodları, gecikme ve doğrulama hataları çoğu işletim ihtiyacını karşılayabilir. Tam sorgu içeriğinin sürekli tutulması gerekiyorsa gerekçeyi, erişim denetimini ve silme süresini ayrıca onaylayın.
Ortak Arıza Noktaları, Yedek Sistemler ve Felaket Kurtarma
Her kritik DNS rolü en az iki bağımsız sistem üzerinde çalışmalı; ancak yalnız sunucu sayısı yeterli kabul edilmemelidir. Bu sistemler aynı sanallaştırma kümesi, güç hattı, ağ anahtarı, güvenlik duvarı, internet çıkışı veya yönetim hesabı gibi ortak arıza noktalarını paylaşabilir.
İç recursive resolver'lar farklı ağ bölgelerine dağıtılmalı ve istemcilerin birden fazla adres kullanması test edilmelidir. İç yetkili DNS sunucularındaki bölge verisini, yetkilendirilmiş sunucular arasında bölge aktarımı yaparak veya DNS yazılımının desteklediği eşitleme yöntemini kullanarak güncel tutun. Kamuya açık yetkili sunucular ise farklı ağlarda ve mümkünse farklı coğrafi konumlarda çalışmalıdır.
Felaket kurtarma planı yalnız yedek dosya bulundurmak değildir. Bölge verisi, yapılandırma, erişim politikaları, DNSSEC anahtarları ve otomasyon bağımlılıkları için kabul edilebilir veri kaybını gösteren RPO’yu (Recovery Point Objective) tanımlayın. Hizmetin ne kadar sürede geri döneceğini ise RTO’yla (Recovery Time Objective) belirleyin.
Geri dönüş planı, önceki yapılandırma ve bölge sürümüne kontrollü dönüşü içermelidir. DNS önbellekleri eski veya hatalı kayıtları TTL dolana kadar kullanabilir; bu nedenle geri dönüşün bütün istemcilere anında yansımasını beklemeyin.
Rol Bazlı İzleme, Kapasite ve Değişiklik Yönetimi
DNS hizmetinin çalışıyor görünmesi tek başına sağlıklı olduğu anlamına gelmez. İzleme, her rolün gerçek görevini düzenli sorgularla sınamalı ve sonuçları altyapı ölçümleriyle birlikte değerlendirmelidir.
- Recursive resolver için yanıt süresi, SERVFAIL oranı, DNSSEC doğrulama hataları, önbellek davranışı, eş zamanlı sorgu ve kaynak kullanımını izleyin.
- Yetkili katman için bölge seri numarası, ikincil sunuculardaki bölge verisinin güncelliği, aktarım başarısı, yetkili yanıt oranı ve dış erişilebilirliği kontrol edin.
- DNS forwarder için üst recursive resolver erişimi, zaman aşımı, alternatif yol devralması ve bekleyen sorgu sayısını ölçün.
- Tek bir toplam eşik kullanmak yerine alarmları rol, bölge, istemci ağı ve hata koduna göre ayırın.
Kapasite planı normal ortalamaya değil, yoğun saatlere ve arıza anındaki devralma yüküne göre yapılmalıdır. DNSSEC doğrulaması, büyük yanıtlar, TCP oturumları, çok çeşitli sorgular ve saldırı trafiği işlemci, bellek ve ağ gereksinimini artırabilir.
Değişiklikleri sürüm geçmişi tutulan bir kaynakta saklayın, teknik incelemeden geçirin ve önce test ortamında doğrulayın. Kritik bölge, recursive resolver politikası veya yönlendirme değişikliğinde uygulama öncesi kontrolü, uygulama sonrası sorgu testini ve geri dönüş koşulunu aynı değişiklik kaydında tutun.
Mevcut Envanterden Kurumsal DNS Mimarisine Geçiş
Ürün, işletim sistemi ve hizmet modeli seçimini rol ayrımı, erişim ve yedeklilik kararlarından sonra yapın. Mevcut DNS yapısını yeni mimariye geçirmek için şu adımları izleyin.
- Mevcut alan adlarını, iç bölgeleri, recursive resolver'ları, DNS forwarder'ları, kamuya açık yetkili DNS hizmetlerini ve istemci erişim yollarını envanterleyin.
- Her rolü hangi bileşenin üstleneceğini belirleyin; güven seviyesini, iş birimi sorumlusunu, teknik sorumluyu ve destek sorumlusunu kaydedin.
- İç ve dış ad alanı kararını verin; iki görünüm kullanılacaksa kayıt sorumlularını ve test yöntemini yazın.
- İstemci, recursive resolver, iç yetkili DNS, DNS forwarder, kamuya açık yetkili DNS ve yönetim düzlemi arasındaki izinli trafik akışlarını çizin.
- Özyinelemeli çözümleme, bölge aktarımı, dinamik güncelleme, yönetim erişimi, günlük tutma ve oran sınırlama politikalarını rol bazında tanımlayın.
- Her kritik rol için aynı arızadan etkilenmeyecek altyapıyı, kapasiteyi, izlemeyi, yedeklemeyi ve devralma testini planlayın.
- Değişiklik, acil müdahale, felaket kurtarma ve geri dönüş prosedürlerini gerçek sorgularla tatbik edin.
- Mimariyi belirli aralıklarla yeniden değerlendirin; büyük ağ veya uygulama değişikliklerinden, bulut geçişlerinden ya da şirket birleşmelerinden sonra da bu değerlendirmeyi tekrarlayın.
