Kurumsal DNS Mimarisi: Split-Horizon, Resolver ve Dış Alan Adı

Hat sağlam, firewall yeşil, ping çalışıyor; ama kullanıcı hiçbir siteyi açamıyor. Sahada bu tablonun arkasından çoğu zaman DNS çıkar. Kurumların büyük kısmında DNS, domain controller’ın üzerinde kendiliğinden çalışan bir servis gibi görülür; oysa şube erişimi, internet çıkışı, SaaS performansı ve e-posta teslimatı aynı zincire bağlıdır. Aşağıda konuya ağ ekibinin gözünden bakıyoruz: iç çözümleme zinciri, split-horizon, dış alan adının barındırılması, TTL ve DNSSEC kararları, arızada dig ve nslookup ile katman ayırma. Active Directory DNS’in günlük işletimi (scavenging, bölge replikasyonu) kapsam dışında.

Resolver ve yetkili sunucu: iki ayrı rol

DNS’te iki farklı rol vardır. Tasarım hatalarının çoğu, bu iki rolün düşünülmeden aynı sunucuya yüklenmesinden doğar.

İnternete açık bir sunucu hem dış bölgeniz için yetkili yanıt verip hem de herkese özyinelemeli çözümleme yapıyorsa elinizde açık resolver (open resolver) var demektir. Bu sunucu DNS amplifikasyon saldırılarında yansıtıcı olarak kullanılır, önbellek zehirleme yüzeyi büyür ve bir gün operatörden kötüye kullanım bildirimi gelir. Kural basit: internetten erişilen sunucu yalnızca yetkili yanıt verir, özyineleme yalnızca iç ağdan gelen sorgulara açıktır. BIND’de bunu recursion ve allow-recursion ayarları belirler; Windows DNS’te dış bölgeyi barındıran sunucuda özyinelemeyi kapatırsınız. Dışarıdan bir dig @genel-ip example.org testi bu açığı bir dakikada gösterir.

İç çözümleme: forwarder, koşullu yönlendirme, root hints

Tipik yapıda istemciler DHCP ile iç DNS sunucularını, çoğunlukla domain controller’ları alır. İç sunucu kendi bölgesinde olmayan adlar için iki yoldan birini kullanır:

• Root hints: Sunucu kök sunuculardan başlayıp çözümlemeyi kendisi yapar. Dış bağımlılık azdır; ama sunucunun internete UDP ve TCP 53 ile doğrudan çıkabilmesi gerekir. TCP 53’ün kapalı unutulması, büyük yanıtlarda ve DNSSEC’te aralıklı hatalar üretir.
• Forwarder: Sorgular operatörün veya seçtiğiniz bir resolver hizmetinin sunucularına iletilir. Ortak önbellek ve merkezi filtreleme kolaylaşır; karşılığında yukarı akıştaki sunucunun erişilebilirliğine ve politikasına bağlanırsınız.

Çift operatörlü yapılarda sahada en sık gördüğümüz hata, forwarder olarak yalnızca bir operatörün resolver’ının yazılmasıdır. Operatör resolver’ları çoğunlukla yalnızca kendi IP bloklarından gelen sorgulara yanıt verir. Birincil hat düşüp trafik ikinci operatöre geçtiğinde forwarder susar ve “internet var ama hiçbir site açılmıyor” şikâyeti başlar. Failover çalışmıştır. Ad çözümleme çalışmıyordur. Bu yüzden çift internet hattı ve failover tasarımı yazısındaki test adımlarına DNS çözümleme testini mutlaka ekleyin.

Koşullu yönlendirme (conditional forwarding), belirli bir bölgenin sorgularını belirli sunuculara gönderir. Şirket birleşmesinde iş ortağının iç bölgesi, site-to-site tünelin arkasındaki bir tedarikçi alanı veya bulut sağlayıcısının özel DNS bölgesi için kullanılır. Tünel kapalıyken hedef sunuculara ulaşılamaz ve istemci her sorguda zaman aşımı kadar bekler; kullanıcı bunu “uygulama dondu” diye bildirir. AD DNS tarafındaki forwarder ve bölge ayarları için sistem tarafındaki Active Directory DNS yapılandırması rehberine bakabilirsiniz.

Ağ tarafındaki tamamlayıcı kontrol, çıkış kuralıdır. İstemcilerin internete doğrudan 53 numaralı porta gitmesine izin verirseniz iç DNS politikası (koşullu yönlendirme, split-horizon, filtreleme) kolayca atlanır ve arızada hangi istemcinin hangi resolver’ı kullandığını bilemezsiniz. DNS çıkışını firewall’da yalnızca iç resolver’lara açın.

Split-horizon DNS tasarımı

Split-horizon (split-brain) DNS, aynı adın sorgulayan tarafa göre farklı yanıt vermesidir. Örneğin portal.example.com internetten sorulduğunda firewall’daki genel IP’yi (203.0.113.20), iç ağdan sorulduğunda sunucunun özel IP’sini (10.10.20.15) döndürür. İç kullanıcı firewall üzerinden dolaşmadan sunucuya doğrudan gider. Aynı sonuca NAT ile ulaşmanın yolları ve sınırları kurumsal NAT tasarımı yazısında hairpin başlığı altında var.

Uygulamada üç yol vardır:

1. Tam kopya iç bölge: İç DNS’te example.com için ayrı bir bölge açılır. En çok sorun çıkaran yöntem budur: iç bölge bu adın tek yetkilisi olduğu için dış bölgedeki www, mail, autodiscover gibi kayıtlar içeriye de eklenmezse iç kullanıcılar onları çözemez. Her dış değişiklik iki yerde yapılmak zorundadır ve bir gün biri unutulur.
2. Tek kayıtlık (pinpoint) bölge: İç DNS’te yalnızca portal.example.com adında bir bölge açılır, bölgenin kendi adına (@) özel IP’yi gösteren bir A kaydı yazılır. Geri kalan her ad internetten normal çözülür. Bakım yükü en düşük yöntem budur.
3. Görünümler (views): BIND gibi sunucularda tek sunucu, sorgunun kaynak adresine göre farklı bölge dosyası sunar. İç ve dış kayıt aynı yerde yönetilir; ama yanlış eşleşen bir kaynak ağı iç adresleri internete sızdırır. ACL’ler sık gözden geçirilmeli.

Sıfırdan kuruyorsanız iç Active Directory alanı için sahip olduğunuz alan adının bir alt alanını (corp.example.com gibi) seçin; split-horizon ihtiyacı en aza iner. .local multicast DNS’e ayrılmıştır, tescil edilmemiş uydurma uzantılar ise ileride gerçek bir üst düzey alana dönüşebilir. İkisi de sonradan pahalıya patlar.

Dış alan adı için yetkili DNS barındırma

Dış bölgenin nerede durduğu, web sitesi ve e-posta erişilebilirliğinin en zayıf halkası olabilir. RFC 2182, bir bölgenin yetkili sunucularının farklı ağlarda ve coğrafi olarak ayrık konumlarda olmasını önerir. Aynı kabindeki iki sunucu bu öneriyi karşılamaz.

Gizli birincil (hidden primary) modelinde bölge dosyası iç ağdaki bir sunucuda tutulur ve NS kayıtlarında görünmez; internete yalnızca bölge transferiyle güncellenen ikincil sunucular yanıt verir. Transferi TSIG anahtarıyla kısıtlayın ve izin verilen adresleri açıkça yazın. Hangi modeli seçerseniz seçin, kayıt kuruluşu hesabını ve DNS yönetim hesabını ayrı ayrı MFA ile koruyun. Bu hesaplara giren biri tüm web ve e-posta trafiğinizi istediği yere yönlendirebilir. Parola tek savunma olmamalı.

TTL stratejisi ve değişiklik planı

TTL, bir kaydın resolver önbelleklerinde ne kadar tutulacağını belirler. Uzun TTL sorgu yükünü ve çözümleme gecikmesini azaltır, kısa TTL değişikliklerin hızlı yayılmasını sağlar. Kalıcı olarak çok kısa TTL kullanmak yerine değişikliği planlamak daha sağlıklıdır:

1. Değişecek kaydın mevcut TTL değerini not edin (örnek: 86400 saniye).
2. TTL’i düşürün (örnek: 300 saniye) ve en az eski TTL süresi kadar bekleyin; yoksa eski değer önbelleklerde uzun süre kalır.
3. Kaydı değiştirin; hem yetkili sunuculardan hem de birkaç farklı resolver’dan doğrulayın.
4. Geri dönüş ihtimali kalmayınca TTL’i normal değerine çıkarın.

Taşıma gecesi sorun çıkaran şey genellikle 2. adımın atlanmasıdır: TTL bir gün önce değil, beş dakika önce düşürülür ve eski IP bir gün daha bazı kullanıcılara dönmeye devam eder. Negatif önbelleği de hesaba katın: henüz oluşturulmamış bir adı sorgulayan resolver, NXDOMAIN yanıtını SOA kaydındaki değerlere göre (RFC 2308) bir süre önbellekte tutar. Yeni kaydı eklemeden önce “bakalım var mı” diye sorgulamak, kayıt eklendikten sonra bir süre “bulunamadı” yanıtı almanıza yol açar. MX ve NS değişikliklerinde bu süreleri ayrıca hesaplayın.

DNSSEC temelleri

DNSSEC, yanıtın yolda değiştirilmediğini dijital imzalarla doğrular (RFC 4033–4035). İki tarafı vardır:

• İmzalama (yetkili taraf): Bölge anahtarlarla imzalanır, her kayıt kümesi için RRSIG oluşur; anahtarın özeti (DS kaydı) kayıt kuruluşu üzerinden üst bölgeye yayınlanır.
• Doğrulama (resolver tarafı): Resolver imza zincirini kökten itibaren kontrol eder. İmza geçersizse istemciye SERVFAIL döner.

Kurumsal ağ için düşük maliyetli ilk adım, iç resolver’larda doğrulamayı açmaktır. Dış bölgeyi imzalamak ise bir işletme süreci ister: anahtar yenileme takvimi, DNS sağlayıcısı değişirken DS kaydının doğru sırayla güncellenmesi ve izleme. DS kaydı eski anahtarı gösterirken bölgeyi yeni anahtarla imzalarsanız, doğrulama yapan her resolver için alan adınız erişilemez olur. Hata sizde değil gibi görünür. Ama sizdedir. Split-horizon kullanıyorsanız iç görünüm imzasız kalacağından, iç resolver’ın bu bölgeyi yetkili olarak barındırdığından ya da istisnanın tanımlı olduğundan emin olun (Unbound’da domain-insecure, BIND’de validate-except).

Şubelerde çözümleme gecikmesi

Şube istemcileri her sorgu için WAN üzerinden merkezdeki DNS sunucusuna gidiyorsa, her yeni bağlantı tünel gecikmesi kadar yavaşlar. WAN kesildiğinde şubenin yerel interneti çalışsa bile kimse ad çözemez. Şube boyutuna göre seçenekler: şubede bir domain controller veya önbellekli resolver konumlandırmak, şube firewall’unun DNS proxy özelliğini iç resolver’lara yönlendirmek ya da en azından istemcilere iki farklı merkezi resolver vermek. Bu kararı şube ağı standart tasarımı içinde şablona yazın; her şube açılışında aynı tartışma yeniden yapılmasın.

Yerel internet çıkışı (local breakout) olan şubelerde ikinci bir etki daha var. CDN ve SaaS sağlayıcıları yanıtı çoğunlukla sorguyu yapan resolver’ın konumuna göre seçer. Trafik şubeden çıkarken DNS sorgusu merkezden çıkıyorsa kullanıcı merkeze yakın bir uç noktaya yönlendirilebilir ve “SaaS şubede yavaş” şikâyeti gelir. DNS çıkış noktasıyla trafik çıkış noktasının uyumunu kontrol edin.

dig ve nslookup ile doğrulama

Arıza anında ilk iş, sorunun hangi katmanda olduğunu ayırmaktır: yetkili sunucu mu, iç resolver mı, delegasyon mu, DNSSEC mi? Aşağıdaki komutlar bu ayrımı birkaç dakikada yapar. Örneklerde 10.10.0.10 iç resolver, ns1.example.net dış yetkili sunucudur.

# Yetkili sunucudan özyinelemesiz sorgu: kaydın kaynağındaki değer
dig @ns1.example.net portal.example.com A +norecurse

# İç resolver ne döndürüyor? (split-horizon kontrolü)
dig @10.10.0.10 portal.example.com A +short

# Kökten itibaren delegasyon zinciri
dig portal.example.com A +trace

# SOA seri numarası: ikincil sunucular güncel mi?
dig @ns1.example.net example.com SOA +short
dig @ns2.example.net example.com SOA +short

# DNSSEC doğrulaması: yanıtta "ad" bayrağı aranır
dig @10.10.0.10 example.com A +dnssec

# Windows tarafında eşdeğerleri
nslookup -type=SOA example.com 10.10.0.10
Resolve-DnsName -Name portal.example.com -Type A -Server 10.10.0.10

Çıktıyı okurken: SOA seri numaraları sunucular arasında farklıysa bölge transferi çalışmıyordur. +trace çıktısında üst bölgedeki NS kayıtlarıyla bölgenizin kendi NS kayıtları uyuşmuyorsa delegasyon tutarsızdır; listelenen bir sunucu bölge için yetkili yanıt vermiyorsa (aa bayrağı yok veya REFUSED) “lame delegation” var demektir. Doğrulayan resolver SERVFAIL döndürüyor ama +cd (checking disabled) ile sorgu başarılıysa sorun büyük olasılıkla DNSSEC zincirindedir. Önce yetkiliyi sorgulayın, sonra resolver’ı.

Tasarım kontrol listesi

• İnternete açık sunucularda özyineleme kapalı; iç resolver’lar yalnızca iç ağlara açık.
• Forwarder her iki internet hattından erişilebilir; failover testinde DNS çözümleme kontrol ediliyor.
• Split-horizon yöntemi seçilmiş; dış kayıt değişikliklerinin iç tarafa nasıl yansıyacağı yazılı.
• Dış bölgenin en az iki yetkili sunucusu farklı ağlarda; kayıt kuruluşu ve DNS hesapları MFA ile korunuyor.
• TTL düşürme adımı değişiklik prosedürüne eklenmiş.
• DNSSEC kullanılıyorsa anahtar yenileme ve sağlayıcı değişikliği prosedürü yazılı.
• İstemcilerin internete doğrudan DNS çıkışı kısıtlanmış.

DNS mimarisini hat yapısı ve şube tasarımıyla birlikte ele almak isterseniz kurumsal network danışmanlığı ve internet hat yönetimi sayfalarımıza bakabilirsiniz. Protokolün temel kavramları için birincil kaynaklar RFC 2182 ve RFC 4033.

Sık sorulan sorular

İç alan adı olarak .local kullanmak sorun mu?

Evet, önermiyoruz. .local, RFC 6762 ile multicast DNS’e ayrılmıştır; macOS, Linux ve bazı yazıcılar bu uzantıyı önce mDNS ile çözmeye çalışır, sonuçta gecikme veya çözümleme hatası görülür. Bu ad için genel kabul gören bir sertifika da alınamaz. Sahip olduğunuz alan adının bir alt alanını (örneğin corp.example.com) kullanın.

Split-horizon DNS mi, NAT hairpin mi?

Çoğu kurumda split-horizon tercih edilir: iç kullanıcı sunucuya özel IP ile doğrudan gider, firewall’da ek çeviri ve gereksiz trafik oluşmaz. Hairpin, iç DNS’e müdahale edilemeyen veya kayıt sayısının çok az olduğu durumlarda pratik bir alternatiftir. Hangisini seçerseniz seçin, hangi kaydın nerede tutulduğunu yazılı hale getirin.

Forwarder olarak operatörün DNS sunucusunu kullanmak doğru mu?

Çalışır, ama çift hatlı yapıda operatör resolver’ı çoğunlukla yalnızca kendi IP bloğundan gelen sorgulara yanıt verir; hat değiştiğinde çözümleme kesilir. Root hints ile kendi recursive çözümlemenizi yapmak ya da her iki hattan erişilebilen, kayıt ve filtreleme politikası bilinen bir resolver hizmeti seçmek daha öngörülebilirdir.

DNSSEC iç ağda da gerekli mi?

Asıl kazanım, iç resolver’ın internetteki imzalı bölgeleri doğrulamasıdır; bunu açmanın maliyeti düşüktür. İç bölgeleri imzalamak anahtar yönetimi ister ve genellikle sınırlı fayda sağlar. Dış alan adınızı imzalıyorsanız, split-horizon’daki iç görünümün doğrulayan resolver tarafından hatalı işaretlenmediğini test edin.