Domain ve DNS Bilgi Rehberi
PCB devresi üzerinde tek giriş noktasından iç ve dış zone'a ayrılan DNS yönlendirme topolojisi

Split-Horizon DNS Nedir? İç ve Dış Ağda Farklı Çözümleme

Aynı domain adı, şirket ağının içinden sorgulandığında iç sunucuyu, dışarıdan sorgulandığında ise genel IP'yi döndürüyor olabilir. Bu split-horizon DNS'in — bazen split-brain DNS de denir — temel işlevidir: aynı zone için iki farklı yanıt kümesi, sorgunun geldiği ağa göre ayrı ayrı sunulur. Mekanizma doğru kurulduğunda görünmez biçimde çalışır; yanlış kurulduğunda ise iç ağdan ulaşılamaması gereken servisleri dışa açar ya da dış kullanıcıların dahili adreslere yönlendirilmesine neden olur.

Senaryo şu şekilde somutlaşır: bir şirketin mail.sirket.com adresi dışarıdan 93.184.216.34 genel IP'sine çözümlenirken, iç ağdan yapılan aynı sorgu 192.168.1.10 özel IP'sini döndürür. Dış kullanıcı genel internet üzerinden erişirken, iç ağdaki çalışan yerel ağ trafiği üzerinden aynı domain'e ulaşır. DNS katmanında bu ayrım yoksa iç kullanıcı da internet üzerinden genel IP'ye gider — gereksiz yere bant genişliği tüketir, NAT sorunlarıyla karşılaşabilir ve bazı yapılandırmalarda servise hiç ulaşamaz.

Split-horizon'ın nasıl uygulandığı, hangi DNS altyapısını kullandığınıza göre önemli ölçüde değişir.

Split-horizon DNS'in teknik temeli: view mekanizması

Split-horizon'ın en yaygın uygulaması BIND (Berkeley Internet Name Domain) üzerindeki view yapılandırmasıdır. BIND'de view, gelen sorgunun kaynak IP'sine göre farklı zone verisi sunmayı sağlayan bir konteynerdir. Aynı domain için birden fazla view tanımlarsınız; her view kendi zone dosyasına sahiptir ve belirli kaynak IP aralıklarından gelen sorgulara yanıt verir.

acl "internal" {
    192.168.0.0/16;
    10.0.0.0/8;
    172.16.0.0/12;
};

view "internal-view" {
    match-clients { internal; };
    recursion yes;

    zone "sirket.com" {
        type master;
        file "/etc/bind/zones/sirket.com.internal";
    };
};

view "external-view" {
    match-clients { any; };
    recursion no;

    zone "sirket.com" {
        type master;
        file "/etc/bind/zones/sirket.com.external";
    };
};

Bu yapılandırmada internal ACL (access control list), RFC 1918 özel IP bloklarını kapsar. İç ağdan gelen sorgular internal-view'a yönlenir ve sirket.com.internal zone dosyasından yanıt alır. Dışarıdan gelen her sorgu ise external-view'a düşer ve sirket.com.external zone dosyasını kullanır. İki zone dosyası bağımsız olarak yönetilir; bir zone'daki değişiklik diğerini etkilemez.

recursion yes iç view'da açıktır çünkü iç kullanıcıların genel internet domain'lerini de çözümleyebilmesi gerekir. Dış view'da recursion no zorunludur; açık bırakılırsa sunucu herkese açık özyinelemeli çözümleyici haline gelir ve kötüye kullanıma maruz kalır. Bu BIND split-horizon yapılandırmasının en sık yapılan hatalarından biridir.

İç ve dış zone dosyalarının içeriği: ne fark eder

Split-horizon'ın değeri, iki zone dosyasının birbirinden anlamlı biçimde farklılaşmasında yatar. Basit bir senaryo üzerinden göstermek gerekirse:

$TTL 300
@   IN SOA ns1.sirket.com. admin.sirket.com. (
        2026042801 ; Serial
        3600       ; Refresh
        900        ; Retry
        604800     ; Expire
        300 )      ; Negative TTL

@       IN NS   ns1.sirket.com.
mail    IN A    192.168.1.10    ; iç mail sunucusu
www     IN A    192.168.1.20    ; iç web sunucusu
vpn     IN A    192.168.1.1     ; VPN gateway (yalnızca iç)
$TTL 3600
@   IN SOA ns1.sirket.com. admin.sirket.com. (
        2026042801 ; Serial
        3600       ; Refresh
        900        ; Retry
        604800     ; Expire
        300 )      ; Negative TTL

@       IN NS   ns1.sirket.com.
mail    IN A    93.184.216.34   ; genel mail sunucusu IP
www     IN A    93.184.216.35   ; genel web sunucusu IP
; vpn kaydı dış zone'da yok — kasıtlı olarak gizli

İki zone dosyası arasındaki farklar kasıtlıdır. İç zone'da vpn.sirket.com kaydı varken dış zone'da yoktur; bu, VPN adresinin genel DNS sorgularında görünmemesini sağlar. TTL değerleri de farklılaşabilir: iç zone'da 300 saniye, dış zone'da 3600 saniye kullanmak, iç değişikliklerin hızlı yayılmasını sağlarken dış önbellekleme süresini daha uzun tutar.

Windows DNS ve diğer uygulamalar

Split-horizon BIND'e özgü değildir. Windows Server DNS, dns.exe servisi üzerinden split-horizon'ı farklı bir yaklaşımla destekler: ayrı DNS zone'ları ayrı ağ arayüzlerine ya da dinleme adreslerine bağlanır. İç ağ arayüzünde dinleyen zone iç kayıtları, genel arayüzde dinleyen zone dış kayıtları sunar. Yapılandırma BIND kadar esnek değildir ama kurumsal Windows ortamlarında Active Directory entegrasyonuyla birlikte kullanılır.

PowerDNS, Unbound ve Knot DNS de view benzeri mekanizmalar sunar; söz dizimi farklılaşır ama temel mantık aynıdır. Bazı router'lar ve UTM cihazları (Fortinet, pfSense gibi) embedded DNS üzerinden split-horizon yapabilir; bu özellikle küçük ve orta ölçekli kurumsal ağlarda DNS altyapısını basitleştirir.

Cloudflare ve SaaS DNS sağlayıcılarında split-horizon

Cloudflare DNS gibi bulut tabanlı yetkili DNS sağlayıcıları, geleneksel split-horizon'ı doğrudan desteklemez. Bu sağlayıcılar yalnızca yetkili (authoritative) DNS'i yönetir; iç ağ sorgularını görmezler. Cloudflare'in sunduğu kayıtlar herkese açıktır.

Bulut DNS kullanırken split-horizon'ı uygulamanın standart yöntemi, iç ağa ayrı bir DNS sunucusu konumlandırmaktır. Bu sunucu — BIND, Unbound veya Windows DNS olabilir — yalnızca iç ağdan gelen sorgulara yanıt verir ve iç zone'ları yönetir. Dış sorgular ise Cloudflare veya benzeri bir sağlayıcıya gider. İki katman birbirinden bağımsız çalışır; senkronizasyon gerektirmez.

# İç zone sirket.com için yerel zone
zone "sirket.com" {
    type master;
    file "/etc/bind/zones/sirket.com.internal";
};

# Diğer tüm sorgular için Cloudflare'e forwarder
options {
    forwarders {
        1.1.1.1;
        1.0.0.1;
    };
    forward only;
};

Bu yapıda iç BIND sunucusu, sirket.com için yerel zone dosyasını kullanır. Başka domain'ler için gelen sorgular Cloudflare'e iletilir. İç kullanıcıların DNS sunucusu olarak bu BIND örneği ayarlanır; dış kullanıcılar Cloudflare üzerindeki kayıtları görür. İki set tamamen bağımsızdır.

Yanlış yapılandırma senaryoları ve teşhis

Split-horizon kurulumlarında en sık karşılaşılan sorun, iç ve dış zone'ların yanlışlıkla birbirine karışmasıdır. Bunun iki tipik biçimi vardır.

Birinci senaryo: iç adresler dış zone'a sızmak. Zone dosyaları kopyalanarak oluşturulduğunda, iç kayıtlar (192.168.x.x, 10.x.x.x) dış zone'a dahil edilebilir. Dış kullanıcılar bu adreslere erişemez ama adresler görünür olur ve iç ağ topolojisi sızdırılmış olur.

İkinci senaryo: iç DNS sunucusunda recursion dışa açık bırakmak. Bu durumda dış kaynaklardan gelen DNS sorguları iç sunucu üzerinden çözümlenir; sunucu açık çözümleyici (open resolver) haline gelir ve DDoS amplification saldırılarında araç olarak kullanılabilir.

Teşhis için en pratik yöntem, hem iç hem de dış ağdan aynı domain'i sorgulamak ve yanıtları karşılaştırmaktır:

# İç ağdan (iç DNS sunucusuna doğrudan sorgu):
$ dig @192.168.1.53 mail.sirket.com A +short
192.168.1.10

# Dış ağdan (Cloudflare üzerinden):
$ dig @1.1.1.1 mail.sirket.com A +short
93.184.216.34

# İç sunucuda recursion kontrolü (dış bir domain ile):
$ dig @192.168.1.53 google.com A +short
# Yanıt geliyorsa recursion açık — iç kullanıcılar için gerekli
# Ama dış kaynaklardan bu sunucuya erişim engellenmiş olmalı

Dış erişim engelini doğrulamak için iç sunucunun genel IP'si üzerinden sorgulama yapmak gerekir. Yanıt geliyorsa güvenlik duvarı kuralları gözden geçirilmelidir; iç DNS sunucusu yalnızca iç ağ aralıklarından gelen sorgulara yanıt vermelidir.

Split-horizon, DNS sorunlarını teşhis etmeyi zorlaştırabilir. Bir kullanıcı "domain çözümlenmiyor" diye rapor ettiğinde, sorunun hangi zone'dan kaynaklandığını belirlemek için önce o kullanıcının hangi DNS sunucusunu kullandığını ve hangi view'a düştüğünü bulmak gerekir. Bunun için dig sorgusuna +identify veya +comments parametresi eklemek, hangi sunucunun yanıt verdiğini gösterir. İki zone arasındaki tutarsızlıkları takip etmek için zone seri numaralarını (Serial) güncel tutmak ve değişiklikleri her iki zone'a uygulamayı alışkanlık haline getirmek uzun vadede operasyonel yükü önemli ölçüde azaltır.

İlgili Yazılar