Split-Horizon DNS Nedir

Aynı alan adının, soruyu kimin sorduğuna göre farklı bir IP adresi döndürmesi ilk bakışta tuhaf gelebilir. Oysa kurumsal ağların büyük çoğunluğunda tam olarak bu yapılır. Ofisteki bir çalışan portal.sirket.com yazdığında yerel ağdaki sunucunun özel IP adresine (10.0.0.20 gibi) yönlendirilirken, dışarıdan aynı adresi çözümleyen bir müşteri veya gezgin çalışan genel IP adresini (185.x.x.x gibi) alır. Bu iki farklı cevabı tek bir alan adı için üretebilmenin adı split-horizon DNS'tir; literatürde split-brain DNS olarak da geçer.

Bu yazıda split-horizon DNS'in ne işe yaradığını, hangi problemleri çözdüğünü ve gerçek dünyada nasıl kurgulandığını kıdemli bir sistem yöneticisinin gözünden anlatacağım. BIND'ın view bloklarından dnsmasq ve Unbound ile yapılan basit çözümlere, iç ve dış zone dosyalarının nasıl ayrıştığından bu mimarinin hangi tuzakları barındırdığına kadar uygulamalı örneklerle ilerleyeceğiz. DNS'in temel çalışma mantığını hatırlamak isterseniz DNS nedir yazısına da göz atabilirsiniz; bu makale onun üzerine bir katman ekliyor.

Split-Horizon DNS Tam Olarak Nedir#

Klasik bir DNS sunucusu, kendisine gelen sorguya kimin sorduğuna bakmaksızın hep aynı cevabı verir. A kaydı 185.10.20.30 ise, dünyanın neresinden sorarsanız sorun cevap bu olur. Split-horizon DNS bu davranışı bozar: sunucu, sorguyu gönderen istemcinin kaynak IP adresine (ya da bazı senaryolarda ağ arayüzüne) bakarak farklı bir zone verisi devreye sokar. Böylece tek bir isim, birden fazla "görünüm" (view) altında farklı cevaplar üretir.

Buradaki "horizon" (ufuk) kelimesi mecazi. Her ufuk, ağın bir tarafını temsil eder: bir tarafta iç ağ (LAN, VPN, sunucu segmentleri), diğer tarafta genel internet. Sunucu, her sorguyu ait olduğu ufka göre yanıtlar. En yaygın kurgu iki ufuklu (dahili ve harici) olsa da, üç veya daha fazla ufuk tanımlamak mümkündür; örneğin misafir Wi-Fi ağı ayrı bir görünüme, yönetim ağı bambaşka bir görünüme bağlanabilir.

Önemli bir ayrım: split-horizon DNS bir güvenlik duvarı değildir. İç IP'yi gizlemek erişimi engellemez, yalnızca kolaylaştırmayı ve yönlendirmeyi düzenler. Gerçek erişim kontrolünü ağ katmanında (WAF, DDoS koruma, güvenlik duvarı kuralları) yaparsınız; DNS burada trafiği doğru kapıya gönderen bir yönlendirici gibi çalışır.

Neden İhtiyaç Duyulur: Çözdüğü Problemler#

Bir sistem yöneticisi olarak bu mimariyi önerdiğimde genelde şu üç ihtiyaçtan en az biri masadadır.

Hairpin/NAT sorununu ortadan kaldırmak. İç ağdaki bir kullanıcı, genel IP üzerinden kendi sunucusuna ulaşmaya çalıştığında paket önce dışa çıkıp güvenlik duvarında geri döner (NAT hairpin / loopback). Birçok yönlendirici bunu ya hiç desteklemez ya da performansı düşürür. İç kullanıcıya doğrudan özel IP'yi verirseniz trafik hiç dışarı çıkmaz; hem hızlı hem de yönlendiricinin hairpin desteğine bağımsız olur.

İç kaynakları internetten gizlemek. db.sirket.com, backup.sirket.com, vcenter.sirket.com gibi yalnızca içeriden kullanılan isimlerin genel DNS'te hiç görünmemesi gerekir. Harici görünümde bu kayıtları hiç yayınlamazsanız, dışarıdan bir saldırgan zone transfer veya alt alan adı tarama ile bu isimleri keşfedemez. Saldırı yüzeyini daraltmanın basit ama etkili bir yoludur.

Trafiği coğrafi/topolojik olarak optimize etmek. Aynı servisin iç ve dış kopyaları farklı yerlerde durabilir. Örneğin bir güncelleme aynası (mirror) ya da CDN uç noktası içeride ayrı, dışarıda ayrı olabilir. Split-horizon ile her istemciyi kendisine en yakın kopyaya bağlarsınız.

Aşağıdaki tablo iç ve dış görünümün tipik olarak nasıl farklılaştığını özetliyor.

Dikkat edilirse bazı kayıtlar yalnızca bir tarafta var. db içeride görünür ama dışarıda hiç yok; vpn ise tam tersi. İşte split-horizon'un asıl gücü budur: aynı zone iki farklı gerçekliği anlatır.

BIND ile view Blokları: Klasik Yaklaşım#

Split-horizon deyince akla ilk gelen çözüm BIND'ın view mekanizmasıdır. BIND, named.conf içinde tanımlanan view bloklarını yukarıdan aşağı değerlendirir; sorgu kaynağı match-clients listesine ilk uyan view'in zone'ları kullanılır. Sıralama kritiktir çünkü ilk eşleşen kazanır.

Önce iç ağı tanımlayan bir ACL ve iki ayrı zone dosyası hazırlarız.

# İç ağ aralıklarını tek bir ACL'de topla
acl "ic-aglar" {
    10.0.0.0/8;
    172.16.0.0/12;
    192.168.0.0/16;
    localhost;
};

# /etc/bind/named.conf.local
view "dahili" {
    match-clients { ic-aglar; };
    recursion yes;                 # iç kullanıcılar özyineleme yapabilir
    zone "sirket.com" {
        type master;
        file "/etc/bind/zones/sirket.com.ic";
    };
};

view "harici" {
    match-clients { any; };        # geri kalan herkes
    recursion no;                  # dışa özyineleme kapalı (otoriter)
    zone "sirket.com" {
        type master;
        file "/etc/bind/zones/sirket.com.dis";
    };
};

İç zone dosyası, LAN'a özgü özel IP'leri ve yalnızca içeride görünmesini istediğiniz kayıtları içerir.

; /etc/bind/zones/sirket.com.ic
$TTL 300
@   IN  SOA ns1.sirket.com. hostmaster.sirket.com. (
        2026071001 ; serial
        3600 900 1209600 300 )
    IN  NS  ns1.sirket.com.

portal  IN  A   10.0.0.20
posta   IN  A   10.0.0.25
db      IN  A   10.0.0.40      ; yalnızca içeride
www     IN  A   10.0.0.10

Dış zone dosyası ise internete açık genel IP'leri barındırır ve db gibi hassas kayıtları hiç içermez.

; /etc/bind/zones/sirket.com.dis
$TTL 3600
@   IN  SOA ns1.sirket.com. hostmaster.sirket.com. (
        2026071001 ; serial
        3600 900 1209600 3600 )
    IN  NS  ns1.sirket.com.

portal  IN  A   185.10.20.30
posta   IN  A   185.10.20.31
vpn     IN  A   185.10.20.32   ; yalnızca dışarıda
www     IN  A   185.10.20.30

Yapılandırmayı canlıya almadan önce mutlaka doğrulayın; sözdizimi hatası tüm DNS servisini düşürebilir.

named-checkconf
named-checkzone sirket.com /etc/bind/zones/sirket.com.ic
named-checkzone sirket.com /etc/bind/zones/sirket.com.dis
rndc reload

Kritik bir kural: BIND'da bir kez view tanımladıysanız, named.conf içindeki her zone bir view'in içinde olmalıdır. Bir zone'u view dışında bırakırsanız BIND başlamaz. Bu, view'e geçerken en sık karşılaşılan hatalardan biridir.

dnsmasq ve Unbound ile Daha Hafif Çözümler#

BIND, tam yetenekli ama ağır bir sunucudur. Küçük bir ofis ağı ya da tek bir yönlendirici üzerinde split-horizon davranışı yeterliyse dnsmasq genellikle fazlasıyla iş görür. dnsmasq view mantığı taşımaz; bunun yerine belirli isimleri yerel olarak sabit IP'ye bağlar, geri kalanı yukarı akış (upstream) sunuculara iletir. İç ağda çalıştığı için istemciler zaten yalnızca iç cevapları alır.

# /etc/dnsmasq.conf — iç ağın DNS'i
# İç isimleri özel IP'ye sabitle
address=/portal.sirket.com/10.0.0.20
address=/posta.sirket.com/10.0.0.25
address=/db.sirket.com/10.0.0.40

# Geri kalan her şeyi genel çözümleyiciye ilet
server=1.1.1.1
server=9.9.9.9

Bu kurguda dış dünya, otoriter sunucularınızdaki genel kayıtları görür; iç ağdaki cihazlar ise DHCP ile dnsmasq'ı DNS olarak alır ve özel IP'leri çözer. Böylece BIND view'lerini hiç kurmadan pratikte split-horizon elde edersiniz.

Daha modern bir alternatif Unbound'dur. Unbound, local-zone ve local-data yönergeleriyle belirli isimleri geçersiz kılar; hem doğrulayıcı çözümleyici (DNSSEC) hem de yerel override görevi görür.

# /etc/unbound/unbound.conf.d/ic.conf
server:
    local-zone: "sirket.com." transparent
    local-data: "portal.sirket.com. 300 IN A 10.0.0.20"
    local-data: "posta.sirket.com. 300 IN A 10.0.0.25"
    local-data: "db.sirket.com. 300 IN A 10.0.0.40"

Aşağıdaki tablo üç aracın split-horizon açısından karşılaştırmasını veriyor.

Kurumsal, gerçek çok görünümlü bir yapı gerekiyorsa BIND; basit "içeride farklı IP" ihtiyacı için dnsmasq ya da Unbound genellikle daha bakımı kolay bir seçimdir.

Uygulama Katmanında Yansıması: Web Sunucusu ve TLS#

Split-horizon DNS'i kurduğunuzda iş DNS'te bitmez. Aynı alan adı iki farklı IP'ye, dolayısıyla potansiyel olarak iki farklı sunucuya gidiyorsa, uygulama katmanında da tutarlılık sağlamanız gerekir. En sık takılınan nokta TLS sertifikasıdır: iç sunucu ve dış sunucu aynı alan adına hizmet verdiği için ikisinin de geçerli bir sertifikaya ihtiyacı vardır. Aksi halde iç kullanıcılar sürekli sertifika uyarısı görür.

Örneğin iç ağdaki bir Nginx, portal.sirket.com için genel IP'yle aynı sertifikayı sunmalıdır. Let's Encrypt sertifikasını dış sunucuda üretip iç sunucuya kopyalamak ya da DNS-01 doğrulamasıyla iç sunucuda ayrıca üretmek işe yarar.

# İç ağdaki Nginx — dış ile aynı alan adına hizmet eder
server {
    listen 443 ssl;
    server_name portal.sirket.com;

    ssl_certificate     /etc/ssl/sirket/portal.fullchain.pem;
    ssl_certificate_key /etc/ssl/sirket/portal.key;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
    }
}

TLS tarafını dert etmek istemiyorsanız SSL sertifikası yönetimini bize bırakabilir, iç ve dış uçlarda tutarlı sertifikaları tek yerden yönetebilirsiniz. Sertifika değişikliği yaptığınızda iki tarafı da güncellemeyi unutmayın; en sık yaşanan "iç ağda süresi dolmuş sertifika" sorunu buradan çıkar.

Bir başka detay TTL değeridir. İç kayıtlarda düşük TTL (örneğin 300 saniye) kullanmak, taşınma ve bakım anlarında değişikliğin hızlı yayılmasını sağlar. Dış kayıtlarda ise önbelleklemeden faydalanmak için daha yüksek TTL tercih edilebilir. Yukarıdaki zone örneklerinde bu ayrımı bilinçli olarak koydum.

Tipik Tuzaklar ve İzleme#

Split-horizon zarif bir çözümdür ama sessizce yanlış cevap veren bir DNS'i teşhis etmek zordur. Sık karşılaştığım tuzaklar şunlar.

İç ve dış zone'ların birbirinden sürüklenmesi (drift). İki ayrı dosyayı elle yönettiğiniz için birine kayıt ekleyip diğerini unutmak çok kolay. www kaydını dışta güncelleyip içte eski bıraktığınızda, ofisteki kullanıcılar yanlış sunucuya gider. Çözüm: zone'ları bir şablondan üreten bir betik ya da Ansible/Terraform ile tek kaynaktan yönetmek. Elle iki dosya düzenlemek uzun vadede hataya davetiyedir.

Serial numarasını artırmayı unutmak. BIND'da zone değiştirdiğinizde SOA serial'ini artırmazsanız ikincil (secondary) sunucular güncellemeyi almaz. Tarih tabanlı YYYYMMDDNN formatı disiplinli kalmayı kolaylaştırır.

Split-horizon'u güvenlik sanmak. İç IP'yi gizlemek güzel ama saldırgan zaten pasif keşifle ya da sertifika şeffaflık (CT) loglarından alt alan adlarını bulabilir. DNS'i görünmez yapmak, arkadaki servisi korumasız bırakma bahanesi olamaz. Erişim kontrolünü mutlaka ağ ve uygulama katmanında sürdürün.

Doğru cevabın döndüğünü teyit etmek için her iki taraftan sorgu atarak test edin.

# İç DNS'ten sorgula — özel IP beklenir
dig @10.0.0.53 portal.sirket.com +short
# 10.0.0.20

# Genel çözümleyiciden sorgula — genel IP beklenir
dig @1.1.1.1 portal.sirket.com +short
# 185.10.20.30

Üretim ortamında bu kontrolü bir izleme senaryosuna bağlamak en sağlıklısıdır. İki uçtan periyodik dig çalıştırıp beklenen cevabı doğrulayan basit bir kontrol, sessiz drift'i erken yakalar. Sunucu tarafını profesyonel eller yönetsin isterseniz sunucu yönetimi hizmetimiz bu tür DNS ve izleme kurgularını da kapsar.

Kimler Kullanmalı ve Ne Zaman Gereksizdir#

Her ağın split-horizon DNS'e ihtiyacı yoktur. Basit bir kişisel site ya da tek sunuculu bir WordPress kurulumu için bu mimari gereksiz karmaşıklıktır; tek bir genel IP herkese yeter. Bir alan adı satın alıp (domain) tek bir web hosting paketine yönlendirdiğinizde işiniz biter.

Buna karşılık şu durumlarda split-horizon ciddi değer üretir: birden fazla iç servisi (posta, veritabanı, dosya sunucusu, iç portal) olan kurumsal ağlar; NAT hairpin sorunu yaşayan ofisler; iç ve dış kopyaları ayrı duran servisler; ve iç isimleri internetten gizlemesi gereken güvenlik odaklı yapılar. Bu senaryolarda genellikle bir VDS ya da sanal sunucu üzerinde kendi çözümleyicinizi çalıştırmak mantıklıdır.

Nameserver kayıtlarını nasıl değiştireceğinizden emin değilseniz nameserver değiştirme rehberimiz temel adımları anlatıyor. Split-horizon, o temel yapının üzerine kurulan ileri bir katman olduğu için önce alan adınızın otoriter DNS'inin sağlam oturduğundan emin olun.

Sıkça Sorulan Sorular#

Split-horizon DNS ile split-brain DNS aynı şey mi?#

Evet, ikisi de aynı mimariyi anlatan eş anlamlı terimlerdir. "Split-horizon" daha çok ufuk/görünüm vurgusu yaparken "split-brain" tek isim iki farklı beyin çağrışımı taşır; teknik olarak fark yoktur. BIND belgeleri genelde "view" kelimesini kullanır, ağ literatüründe her iki isme de rastlarsınız. Hangi terimi görürseniz görün kastedilen, aynı alan adı için sorgunun kaynağına göre farklı cevap döndürmektir.

Split-horizon DNS bir güvenlik önlemi sayılır mı?#

Tek başına gerçek bir güvenlik katmanı değildir, saldırı yüzeyini daraltan yardımcı bir önlemdir. İç isimleri genel DNS'ten gizlemek keşfi zorlaştırır ama erişimi engellemez; saldırgan IP'yi başka yollarla öğrenebilir. Bu yüzden split-horizon'u asla güvenlik duvarı, kimlik doğrulama veya WAF gibi katmanların yerine koymayın. Onu, savunmanın yalnızca bir parçası olarak değerlendirin.

İç ve dış zone'ları senkron tutmanın en iyi yolu nedir?#

İki dosyayı elle düzenlemek yerine tek bir kaynaktan üretmek en sağlıklı yöntemdir. Ortak kayıtları bir şablonda tutup içe ve dışa özel IP'leri değişken olarak enjekte eden bir betik ya da Ansible/Terraform kurgusu drift riskini büyük ölçüde ortadan kaldırır. Ayrıca her iki taraftan dig ile periyodik doğrulama yapan basit bir izleme, unutulan bir güncellemeyi erkenden yakalar. Elle yönetim küçük ölçekte kabul edilebilir olsa da büyüdükçe otomasyona geçmek şart olur.

dnsmasq split-horizon için yeterli mi yoksa BIND mı gerekir?#

İhtiyacınızın ölçeğine bağlıdır. Küçük bir ofiste yalnızca birkaç iç ismi özel IP'ye bağlamak istiyorsanız dnsmasq fazlasıyla yeterli ve bakımı çok kolaydır. Ancak kaynak IP'ye göre gerçekten farklı zone verisi sunmak, birden fazla ufuk tanımlamak ya da DNSSEC'i tam desteklemek istiyorsanız BIND'ın view mekanizması doğru araçtır. Orta ölçekte Unbound'un local-data override'ı da iyi bir denge sunar.

Split-horizon kurunca TLS sertifikası sorunu yaşar mıyım?#

Yaşayabilirsiniz, çünkü aynı alan adı hem iç hem dış sunucuya gittiği için ikisinde de geçerli sertifika bulunmalıdır. İç sunucuda sertifika yoksa ya da süresi dolmuşsa iç kullanıcılar tarayıcı uyarısı görür. Çözüm, dış sunucudaki sertifikayı iç sunucuya kopyalamak veya DNS-01 doğrulamasıyla iç uçta ayrıca üretmektir. Sertifika yönetimini tek yerden düzenlemek isterseniz bizim SSL çözümlerimiz iki uçlu kurgularda da işinizi kolaylaştırır.

Küçük bir web sitesi için split-horizon DNS gerekli mi?#

Hayır, çoğu küçük site için gereksiz bir karmaşıklıktır. Tek bir genel IP üzerinden çalışan basit bir site ya da blog için split-horizon hiçbir fayda sağlamaz, aksine yönetim yükü ekler. Bu mimari, birden çok iç servisi olan kurumsal ağlar, NAT hairpin sorunu yaşayan ofisler ve iç isimlerini gizlemesi gereken yapılar için mantıklıdır. İhtiyacınız tek bir siteyi yayınlamaksa uygun bir hosting paketiyle işiniz görülür.

Kapanış#

Split-horizon DNS, tek bir alan adını iç ve dış dünyaya farklı gerçeklerle sunmanın zarif bir yoludur: iç kullanıcıya hızlı ve doğrudan özel IP, dış kullanıcıya güvenli genel IP. Doğru kurulduğunda NAT hairpin dertlerini bitirir, iç servisleri gözlerden uzak tutar ve trafiği en verimli yola sokar. Yanlış kurulduğunda ise sessizce yanlış cevap veren, teşhisi zor bir DNS'e dönüşebilir; bu yüzden zone senkronizasyonu, serial disiplini ve iki uçlu izleme şarttır.

Kurumsal DNS altyapınızı sağlam bir zemine oturtmak istiyorsanız, VDS veya sanal sunucu çözümlerimizle kendi çözümleyicinizi çalıştırabilir, sunucu yönetimi hizmetimizle bu tür ileri kurguların bakımını uzman ekibimize bırakabilirsiniz. Alan adınızı, hosting'inizi ve SSL'inizi tek çatı altında yöneterek iç ve dış görünümlerinizin her zaman tutarlı kalmasını sağlarız. Clou.TR olarak, planlamadan üretime kadar her adımda yanınızdayız.