Kurumsal Ağlarda Private DNS Yapılandırması

Bir yönetici, ekibinin VPN bağlıyken iç uygulamalara ulaşamadığını fark eder. Kimlik doğrulama eksiksiz, tünel kurulu; ancak tarayıcı erp.sirket.local adresini çözemiyor. Sorun tünelin kendisinde değildir: DNS sorguları iç name server'a ulaşmıyor ya da yanlış sunucuya yönleniyor. Private DNS yapılandırmasındaki tek bir boşluk, ağ altyapısının geri kalanını işlevsiz kılmaya yeter.

Kurumsal ağlarda DNS yönetimi, genel DNS yönetiminden temelden ayrılır. İnternet'e açık alan adlarının kayıtlarını bir sağlayıcıda tutarken, şirket içi sunucu adlarını, uygulama uç noktalarını ve servis tanımlarını yalnızca iç ağdan erişilebilen bir name server'da barındırırsınız. Bu iki katmanlı yapı doğru kurulmadığında VPN kullanıcıları, bulut iş yükleri ve farklı ofisler için sürekli sorun üretir; üstelik her arıza farklı bir belirtiye sahip olduğundan teşhis güçleşir.

Active Directory tabanlı DNS, Windows oturumuna bağlı ofisler için yeter; CoreDNS konteyner ve servis keşfinde daha esnek kalır. Split-horizon aynı adı içerde farklı IP'ye çevirir. VPN'de tünel DNS sızıntısı, iç adı dış resolver'a düşürür; sızıntı public resolver kullanıldığında daha da görünür olur.

Active Directory Entegrasyonlu DNS: Temeli Anlamak

Active Directory kurulumlarında DNS, yalnızca bir isim çözümleme servisi değil, domain'in taşıyıcısıdır. AD DS (Active Directory Domain Services) kurulumu sırasında Windows, seçilen domain adı için birincil zone'u otomatik oluşturur; domain controller'lar bu zone'u kendi zone verisiyle birbirine replika eder. DDNS (Dynamic DNS) desteği sayesinde bir makine domain'e katıldığında A kaydı otomatik güncellenir, siz ek bir işlem yapmadan sunucu adları çözümlenebilir hale gelir.

Replication kapsamı kritik bir karardır. AD-integrated zone'lar üç kapsamda çalışabilir: yalnızca domain controller'lar, tüm AD sunucuları veya belirli bir site. Çok siteli bir yapıda hangi DC'nin hangi zone verisini barındırdığını bilmemek, sahte "kayıt bulunamadı" hatalarına yol açar; bir ofisteki kayıt diğerine henüz yayılmamış olabilir. Replication gecikmesi varsayılan yapılandırmada 15 dakikaya kadar uzayabilir; bu pencere public DNS propagation ile karıştırılmamalıdır. ve zaman duyarlı kayıt değişikliklerinde bu gecikmeyi hesaba katmayanlar şaşırır.

Yalnızca Windows sunucu barındıran küçük ortamlarda AD-integrated DNS yeterlidir. Linux iş yükleri veya konteyner altyapısı eklendiğinde yapı karmaşıklaşır; servis keşfi API subdomain katmanına taşınır. O noktada ikinci bir seçenek gündeme gelir; ama bu iki sistemin birbirine forwarder zinciriyle bağlandığı hibrit düzenlemeler de giderek yaygınlaşıyor.

Split-Horizon DNS: Aynı Domain, İki Farklı Yanıt

Split-horizon (veya split-brain) DNS, aynı alan adı için ağ konumuna göre farklı yanıtlar üretir. Örneğin erp.sirket.com.tr, iç ağdan sorgulanan istemciye 10.0.1.50 dönerken dış ağdan sorgulanan birine 203.0.113.10 döner. İç kullanıcılar yük dengeleyiciyi veya güvenlik duvarını atlar; dış kullanıcılar genel IP üzerinden erişir.

Bu yapı, aynı domain adını hem iç hem dış dünyada kullanmak isteyenler için kaçınılmazdır. Farklı domain adları kullansaydınız, yani iç için sirket.local ve dış için sirket.com.tr deseydiniz, split-horizon'a gerek kalmazdı; Azure tarafında aynı ayrım private zone ile kurulur, ama o zaman sertifika yönetimi, uygulama yapılandırmaları ve kullanıcı URL alışkanlıkları ayrı bir karmaşa yaratır.

Windows ortamında split-horizon şöyle kurulur: genel DNS sağlayıcınızda sirket.com.tr için normal kayıtlarınız dururken, iç DNS sunucunuzda da aynı domain için ayrı bir zone oluşturursunuz. İç zone yalnızca iç istemcilere yanıt verdiği için dış kayıtlarla çakışmaz. İç zone'da tanımlamadığınız bir kayıt var olmamış gibi görünür; iç DNS sunucusu o kaydı dış sağlayıcıya sormaz, doğrudan NXDOMAIN döner. Bu nedenle iç zone oluştururken, o domain altında kullanılan tüm kayıtların kopyasını ya da yönlendirmesini eklemeniz gerekir.

İç zone'da yalnızca ihtiyaç duyduğunuz kayıtları ekleyip geri kalanını unutursanız, iç kullanıcılar bu kayıtlara hiç ulaşamaz. Split-horizon zone'unu eksik kayıtlarla oluşturmak, sıfır kayıt oluşturmaktan daha kötü sonuç doğurabilir; çünkü sorun belli bir kullanıcı grubunu rastgele etkiler ve tespiti güçleşir.

CoreDNS ile Hafif ve Esnek Private DNS

CoreDNS, Go ile yazılmış modüler bir DNS sunucusudur; Kubernetes kümelerinin varsayılan DNS bileşeni olarak yaygınlaşmıştır. Şirket içi kullanımda AD-integrated DNS'e sağlam bir alternatif sunar; özellikle Linux ağırlıklı ortamlarda ya da konteyner iş yüklerinin dominant olduğu yapılarda.

CoreDNS, tek bir yapılandırma dosyasıyla (Corefile) yönetilir. İç zone'lar için yerel dosya ya da etcd backend kullanılabilir; dış sorgular ise forward direktifiyle yukarı yönlendirilen resolver'lara iletilir. Aşağıda basit bir split-horizon örneği:

sirket.com.tr {
    file /etc/coredns/zones/sirket.com.tr.db
    log
}

. {
    forward . 1.1.1.1 8.8.8.8
    cache 300
    log
}

Bu yapılandırmada sirket.com.tr için gelen sorgular yerel zone dosyasından yanıtlanır; diğer tüm sorgular öne yönlendirilen sunuculara gider. CoreDNS'in avantajı, her plugin'in zincire eklenip çıkarılabildiği modüler mimarisidir. Dezavantajı Active Directory ile doğrudan entegrasyonunun olmamasıdır; DDNS güncellemelerini kendiniz yönetmeniz gerekir. Az sayıda sunucunun bulunduğu ortamlarda bu ek iş yükü önemsiz görünebilir, ama yüzlerce makinenin olduğu yapılarda kayıt tutarlılığını elle yönetmek gerçekten zorlaşır.

CoreDNS, kurumsal hibrit bulut mimarisinde de kullanışlıdır. Şirket içi kurulumun yanı sıra bulut tarafında da CoreDNS örneği çalıştırarak iki yönde zone servisi verebilirsiniz. Google Cloud DNS ile zone yönetimi konusunda da benzer bir ayrım söz konusudur; public zone'lar ile private zone'lar farklı kurallarla yapılandırılır ve iç sorgular zone'a göre ayrıştırılır.

VPN Üzerinden DNS: Neden Çözümleme Başarısız Olur?

Çözümleme başarısız olur. Ama neden?

VPN istemcisi tüneli kurduğunda işletim sistemi DNS sunucu listesini değiştirmeli ve arama domain'lerini (search domain) güncellemelidir. Sorun genellikle bu adımda çıkar: istemci iç DNS sunucusunu alır ama sorguları o sunucuya yönlendirmez ya da iç DNS sunucusuna ulaşır ama erp gibi kısa adları erp.sirket.com.tr'ye çevirmek için gereken search domain tanımlı değildir.

Split DNS yapılandırmasında, split tunneling ile birlikte, yalnızca iç ağa ait sorgular tünelden geçer; geri kalan sorgular yerel internet bağlantısı üzerinden gider. Bu yaklaşım bant genişliğini korur, ama yanlış yapılandırıldığında DNS sızıntısı (DNS leak) yaratır: iç kaynaklara ait sorgular iç olmayan bir sunucuya gider ve bu sunucu NXDOMAIN döner ya da daha kötüsü genel IP'ye çözümler.

Yaygın yapılandırma hatalarından biri, VPN sunucu tarafında pushed DNS sunucusunun eksik ya da yanlış belirtilmesidir. OpenVPN'de push "dhcp-option DNS 10.0.0.1" satırı istemciye iç DNS sunucuyu bildirmelidir. WireGuard'da ise DNS satırı peer konfigürasyonunun içine yazılır; unutulursa istemci kendi yerel DNS sunucusunu kullanmaya devam eder. Kurumsal VPN çözümlerinde bu ayar genellikle profil XML dosyasında bulunur ve merkezi olarak dağıtılır; bunu tek tek makineye manuel uygulamak hataya açıktır.

Search domain listesi, VPN üzerinden kısa ad çözümlemesinin çalışıp çalışmadığını belirler. İstemciye sirket.com.tr search domain'i gönderilmezse, kullanıcı erp yazdığında bu ad hiçbir zaman erp.sirket.com.tr'ye dönüşmez. Özellikle macOS ve Linux sistemlerde /etc/resolv.conf veya systemd-resolved yapılandırmasının bu değeri doğru alıp almadığını kontrol etmek gerekir.

Uzak ofisler arasındaki site-to-site VPN senaryolarında sorun farklı görünür. İki ofis arasında tünel kurulu olsa bile, her ofisteki DNS sunucusu karşı tarafın zone'unu tanımıyorsa çapraz ofis isim çözümlemesi yine başarısız olur. Çözüm, conditional forwarding kullanmaktır.

Conditional Forwarding ve Stub Zone: Doğru Aracı Seçmek

Conditional forwarding, belirli bir DNS domain'i için sorguları önceden tanımlı bir sunucuya yönlendirir. ofis-ankara.sirket.com.tr için gelen sorgular Ankara ofisinin DNS sunucusuna iletilirken, ofis-istanbul.sirket.com.tr için olanlar İstanbul sunucusuna gider. Ana DNS sunucusu her iki zone'u barındırmak zorunda kalmaz; sadece yönlendirme kuralını bilmesi yeter.

Stub zone ise conditional forwarding'in daha dinamik bir türüdür. Hedef zone'un yalnızca NS kayıtlarını kopyalar; bu NS kayıtları zamanla değişirse stub zone otomatik güncellenir. Conditional forwarding'de hedef IP adresini elle girmek gerekir, değişirse güncelleme zorunludur. Kararlı ve uzun süre değişmeyecek ortamlarda conditional forwarding sade ve öngörülebilirdir; sık değişen ve merkezi yönetimi tercih edilen büyük ortamlarda stub zone avantaj sağlar.

Birden fazla şirketin birleştiği yapılarda, iki AD ormanı arasında conditional forwarding kurulur; bu sayede her orman kendi yetkisini korurken çapraz çözümleme mümkün olur. Azure DNS ile domain yönetimi yapılandırmasında da aynı mantık geçerlidir; Azure Private DNS zone'u ile on-premises DNS arasında forwarder zinciri kurulur ve her halkanın doğru çalışması gerekir.

Hibrit Bulut Ortamında Private DNS Genişletmesi

Şirket içi sunucuların yanı sıra bulut sanal makineleri de aynı iç domain'i kullanmak istiyorsa, DNS altyapısının buluta taşınması ya da köprülenmesi gerekir. İki yaklaşım vardır: bulut sağlayıcısının sunduğu private DNS zone servisini kullanmak ya da kendi DNS sunucunuzu bulut ağında da çalıştırmak.

Azure Private DNS Zones, VNet'e bağlı kaynakların özel domain adlarıyla çözümlenmesine olanak tanır. On-premises ağdan Azure'a VPN ya da ExpressRoute bağlantısı varsa, on-premises DNS sunucusu ilgili zone'u Azure DNS'e yönlendirmeli; Azure DNS de kendi Private Resolver örneği üzerinden sorguları almalıdır. Bu zincirde bir halka eksikse şirket içi makineler bulut kaynaklarını çözemez ya da bulut VM'leri şirket içi kaynakları göremez.

Kendi name server'ınızı bulut VM'inde çalıştırmak daha fazla kontrol sağlar, ama yüksek erişilebilirlik için en az iki sunucu kurmanız, her ikisinin de güncel zone verisiyle çalışmasını sağlamanız gerekir. Özel nameserver kurulumu konusunda da belirtildiği gibi, name server çiftleri arasındaki zone transferinin sağlıklı çalışması, tüm yapının dayanıklılığını belirler; bulut ortamındaki ağ güvenlik grupları ve internal routing bu süreci etkileyen ek değişkenler getirir.

Microsoft 365 kullanan kurumlar için dikkat edilmesi gereken özel bir nokta vardır. Autodiscover ve diğer servis CNAME'leri hem iç hem dış zone'da tanımlı olmalıdır; yoksa iç kullanıcılar Outlook profilini otomatik kuramaz. Microsoft 365 için MX ve SPF kayıtları dışarıdan görünen zone'u etkilerken, iç zone'daki Autodiscover kaydını ayrıca eklemeniz gerekir; bu iki zone'un senkronize tutulmaması sıkça atlanır.

Sorun Giderme: Hangi Komut Neyi Gösterir?

DNS sorunlarını teşhis ederken önce hangi sunucunun yanıt verdiğini anlayın.

Windows'ta nslookup erp.sirket.com.tr komutu o anda yapılandırılmış DNS sunucusunu kullanır. Sorgunun hangi sunucudan yanıt geldiğini görmek için nslookup erp.sirket.com.tr 10.0.0.1 şeklinde sunucu IP'sini açıkça belirtin. Linux'ta dig @10.0.0.1 erp.sirket.com.tr aynı işi görür; +short parametresiyle yalnızca IP döndürülür, +trace ile delegasyon zinciri takip edilir.

# Belirli bir sunucuya sorgu göndermek
dig @10.0.0.1 erp.sirket.com.tr A

# Zone transferini test etmek (yetkilendirme varsa)
dig @10.0.0.1 sirket.com.tr AXFR

# TTL değerini kontrol etmek
dig @10.0.0.1 erp.sirket.com.tr A +ttl

# Yanıt veren sunucuyu görmek
dig erp.sirket.com.tr A +identify

VPN bağlıyken sorgu başarısız oluyorsa, önce tünel üzerinden iç DNS sunucusuna ulaşılıp ulaşılmadığını kontrol edin. Ping yanıt veriyorsa DNS sorgu paketleri yine de kaybolabilir; güvenlik duvarı kuralları UDP 53'ü engelliyor olabilir. Yanıt vermiyorsa sorun DNS katmanında değil, yönlendirme ya da güvenlik politikasındadır. Bu ayrımı yapmadan DNS yapılandırmasına müdahale etmek zaman kaybettirir.

Windows sistemlerde DNS önbelleği çözümlemeyi gizleyebilir. ipconfig /flushdns komutu önbelleği temizler; ardından yapılan test gerçek DNS yanıtını yansıtır. Linux'ta systemd-resolved kullanan sistemlerde resolvectl flush-caches aynı işi görür. Temizleme sonrası sorun ortadan kalkarsa, değişen kaydın TTL süresi dolmadan önce istemcilere yansımadığını anlarsınız; çözüm ya TTL'i düşürmektir ya da bir sonraki yapılandırma değişikliğinden önce TTL'i erkenden kısmaktır.

Windows DNS sunucusunda dcdiag /test:DNS komutu AD-integrated ortamlarda kayıt tutarsızlıklarını, replikasyon hatalarını ve zone yetki sorunlarını bir arada gösterir. Uzun süre bakımsız kalan AD-integrated kurulumlarında bu araç şaşırtıcı tutarsızlıkları gün yüzüne çıkarır.

Private DNS altyapısı, tek seferlik kurulup bırakılan bir bileşen değildir. Yeni sunucular eklendikçe, VPN profilleri güncellendikçe, bulut iş yükleri değiştikçe zone dosyaları ve forwarder listeleri de güncel tutulmalı; aksi halde eski yapılandırma kalıntıları sessizce birikerek büyük bir arıza anında kendini gösterir. Zone içeriklerini versiyon kontrolüne almak, CoreDNS kullanılıyorsa Corefile'ı git reposunda tutmak, AD-integrated ortamlarda ise zone export'larını düzenli almak bu riski fark edilir biçimde azaltır.

Domain portföyü yönetimi bağlamında da görüldüğü üzere, DNS kayıtlarının takibi yalnızca dış görünürlük için değil, iç altyapı sağlığı için de geçerlidir. Private zone'larınızdaki artık kayıtlar, çakışan isimler ve hatalı forwarder tanımları büyük bir kesinti anında bir arada sorun yaratır. Küçük ekipler için yılda bir kez yapılan zone denetimi bile bu birikim riskini belirgin ölçüde düşürür.

Split-horizon, conditional forwarding ve VPN DNS yapılandırması ayrı ayrı yönetilebilir konulardır; ancak üçü birlikte tasarlanmadan kurulursa birbirinin sorununu yaratan bir döngü oluşur. Baştan bütüncül düşünülmüş bir yapı hem kurulum sürecini kısaltır hem de sonraki her değişikliği daha az riskli kılar.