Split-Horizon DNS Nedir?

Split-horizon DNS, aynı alan adı için sorgunun geldiği ağa veya istemci grubuna göre farklı DNS yanıtları üreten bir yapıdır. İç ağdaki kullanıcı özel bir IP adresini gösteren DNS yanıtı alırken internetteki kullanıcı aynı ad için genel bir IP adresi, farklı bir kayıt veya kayıt bulunmadığını belirten bir yanıt görebilir.
Bu yaklaşım, kurum içi servisleri özel ağda tutarken kullanıcıların aynı adlandırma düzenini kullanmasına yardımcı olur. Uzaktan çalışan istemciler de VPN bağlantısı üzerinden yalnız belirli alan adlarının DNS sorgularını kurumun DNS sunucularına gönderebilir.
Split-horizon DNS yalnız iki DNS sunucusu çalıştırmak anlamına gelmez. Asıl belirleyici unsur, her sorgu için hangi kayıt kümesinin sunulacağının ve istemci sorgularının bu kayıtları sunan DNS hizmetine nasıl ulaşacağının tanımlanmasıdır.
İç ve Dış Görünümler Nasıl Oluşur?
Split-horizon yanıtları, aynı DNS adının iç ve dış ağ için farklı yetkili kayıt kümelerine sahip olmasından doğar. İstemcide veya sorguyu işleyen DNS sunucusunda uygulanan politika, sorgunun uygun kayıt kümesine ulaşmasını sağlar. VPN ortamlarında yetkili görünüm ile alan adına göre DNS sunucusu seçimi birlikte kullanılabilir.
Bu farklılık, IPv4 adresini gösteren A ve IPv6 adresini gösteren AAAA kayıtlarıyla sınırlı değildir. Bir adı başka bir ada bağlayan CNAME, posta sunucusunu belirten MX ve metin bilgisi taşıyan TXT kayıtları da görünümler arasında farklı olabilir. DNS yöneticisi her kayıt farkının neden gerekli olduğunu belgelemelidir; gereksiz ayrışma iki veri kümesinin zamanla uyumsuz hale gelme riskini artırır.
Yetkili DNS Görünümü
Yetkili DNS sunucusu, bir alan adının kayıtlarını yayımlayan kaynaktır. DNS yöneticisi aynı DNS adı için iki ayrı kayıt kümesi tutabilir. Örneğin iç taraftaki recursive resolver (özyinelemeli DNS çözümleyicisi) hizmetinden gelen sorguya özel veriyi, internet tarafındaki recursive resolver hizmetinden gelen sorguya genel veriyi sunabilir.
Yetkili sunucu çoğu zaman doğrudan son kullanıcıyı değil, onun adına sorgu yapan recursive resolver hizmetini görür. Görünüm seçimi, yetkili sunucunun gördüğü kaynak IP adresine, sorgunun ulaştığı sunucu adresine veya yapılandırmada tanımlanan diğer eşleştirme kurallarına bağlı olabilir.
DNS Sorgu Politikası ve VPN
Recursive resolver, istemci adına DNS yanıtını bulur ve önbelleğe alabilir. Alan adına göre DNS sunucusu seçimi yapıldığında istemci, kurumsal alan adlarının sorgularını kurumun DNS sunucularına; diğer sorguları ise yerel veya genel kullanıma açık DNS sunucularına gönderir.
VPN bağlantılarında bu model, yalnız kurum alan adlarının sorgularının VPN içindeki DNS hizmetine yönlendirilmesini sağlayabilir. Politika alan adı kapsamını, kullanılacak DNS sunucusunu ve bağlantı koşulunu doğru eşleştirmezse istemci genel yanıt alabilir, iç adı çözemeyebilir veya iç sorguyu istenmeyen bir dış DNS sunucusuna gönderebilir.
Split-Horizon DNS Kullanım Alanları
Split-horizon DNS, aynı hizmet adının farklı ağlarda uygun sunucuyu göstermesi gerektiğinde kullanılır. Tipik senaryolar şunlardır:
- Kurumsal uygulamalar: Aynı uygulama adı iç ağda özel IP adresine, dış ağda genel bir geçide yönlenebilir.
- Yalnız iç ağda çalışan servisler: Dosya, yönetim veya geliştirme hizmetlerinin adları yalnız iç görünümde bulunabilir.
- VPN kullanıcıları: VPN istemcisi kurumsal alan adlarının sorgularını VPN'in DNS sunucularına, genel internet adlarının sorgularını başka DNS sunucularına gönderebilir.
- Aşamalı hizmet geçişleri: İç kullanıcılar yeni altyapıya yönlendirilirken dış kullanıcılar geçici olarak mevcut hizmeti kullanabilir.
Bu yapı, iç servislerin internete açılmasını gerektirmez. DNS yanıtı erişim yetkisi değildir; ağ yöneticisi ayrıca güvenlik duvarı, kimlik doğrulama ve ağ erişim denetimleri uygulamalıdır.
Split-Horizon DNS ile GeoDNS Arasındaki Farklar
Her iki yaklaşım da aynı alan adına farklı yanıt verebildiği için benzer görünür, ancak amaçları aynı değildir. Split-horizon DNS genellikle güven sınırı, ağ üyeliği veya istemci politikası üzerinden iç ve dış görünümü ayırır.
GeoDNS ise çoğunlukla kullanıcının coğrafi bölgesine, recursive resolver hizmetinin konumuna veya hizmete yakınlığa göre genel kullanıma açık uç noktalar arasında seçim yapar. Bir yapı hem coğrafi yönlendirme hem iç-dış görünüm kullanabilir; ağ yöneticisi yine de bu iki yönlendirme politikasını ayrı yönetmelidir.
Split-Horizon DNS Yapılandırmasındaki İşletim Riskleri
Split-horizon DNS'in en zor tarafı farklı yanıt üretmek değil, istemcinin her koşulda doğru görünümü almasını sağlamaktır. Sorunlar çoğunlukla DNS politikası, önbellek ve ağ yönlendirmesi arasındaki uyumsuzluktan doğar.
Yanlış Görünümün Seçilmesi
İç ağdaki bir istemci genel kullanıma açık DNS sunucusunu kullanırsa dış yanıtı alabilir. Dış istemciye yanlışlıkla iç yanıt dönmesi ise özel adların veya özel IP adreslerinin görünür hale gelmesine yol açabilir; bu adresler erişilebilir olmasa bile gereksiz bilgi açığa çıkar.
Kaynak IP adresine dayalı seçim, sorgu arada bir DNS forwarder (DNS yönlendirici) veya ortak recursive resolver üzerinden geçiyorsa beklenmeyen sonuç verebilir. Görünüm kuralı son kullanıcıyı değil, yetkili sunucunun gerçekten gördüğü sorgu kaynağını temel almalıdır.
DNS Önbelleği ve TTL Değerlerinin Görünümlere Etkisi
TTL, DNS kaydının önbellekte normal olarak ne kadar süre geçerli kalacağını saniye cinsinden belirtir. Kayıt daha erken silinebilir; bazı recursive resolver hizmetleri ise kesinti sırasında eski veriyi belirli koşullarla kullanabilir. İç ve dış sorgular ortak önbellekte yeterli ayrım olmadan işlenirse bir görünümün yanıtı başka istemci grubuna taşınabilir. Bu risk, kullanılan recursive resolver hizmetine ve önbellek paylaşımının nasıl yapılandırıldığına bağlıdır.
Ağa veya VPN'e yeni bağlanan cihaz da önceki bağlantıdan kalan DNS yanıtını bir süre kullanabilir. Yapılandırmayı değiştiren yönetici, yetkili kayıtların yanı sıra istemci ve recursive resolver önbelleklerini de hesaba katmalıdır.
VPN ve Ağ Yolu Uyumsuzluğu
Bir adın iç IP adresine çözülmesi, paketin otomatik olarak iç ağa ulaşacağı anlamına gelmez. DNS politikası kurumsal yanıt verirken ilgili özel ağ yolu VPN üzerinden tanımlanmamışsa bağlantı yine başarısız olur.
Tersi durumda ağ yolu mevcut olsa bile sorgu genel kullanıma açık DNS sunucusuna giderse istemci dış uç noktaya bağlanabilir. Ağ yöneticisi, DNS seçimini ve trafik yönlendirmesini aynı erişim politikasına göre planlamalıdır.
Gizlilik ve Sorgu Sızıntısı
DNS sorgusunun hangi sunucuya gönderildiği, sorgu adlarını kimlerin görebileceğini etkiler. İç alan adlarının genel kullanıma açık DNS sunucularına sızması; yanlış yedek sunucuya geçiş, istemciye özel DNS ayarı veya kurumsal politikayı atlayan uygulama ayarı nedeniyle ortaya çıkabilir. Örneğin DoH (DNS over HTTPS) kullanan bir tarayıcı, kendi DNS sunucusunu seçerek işletim sisteminin veya VPN'in kurallarını atlayabilir. Sorgunun şifrelenmesi, doğru sunucuya gönderildiğini tek başına göstermez.
Ağ yöneticisi bu nedenle split-horizon DNS yapısını yalnız bir erişim sorunu olarak ele almamalıdır. Yönetici ayrıca hangi sorguların hangi DNS yolundan geçtiğini ve bu yoldaki tarafların hangi adları görebildiğini değerlendirmelidir.
DNS Yanıtını ve Bağlantıyı Birlikte Kontrol Etme
Sorun giderirken yetkili kayıt ile istemci politikasını aynı şey saymak hatalı sonuç verir. Yetkili DNS hangi kaydın yayımlandığını belirler; recursive resolver bu kaydı bulur ve önbelleğe alabilir; istemci politikası ise sorgunun hangi DNS sunucusuna gönderileceğini seçer.
Testten önce her alan adı ve kayıt türü için beklenen iç ve dış yanıtları belgeleyin. Testleri iç ağ, genel internet ve VPN bağlantısı üzerinden ayrı ayrı yapın. Ağ yöneticisi, bir split-horizon DNS hatasının kaynağını şu adımlarla daraltabilir:
- İstemcinin sorguyu hangi DNS sunucusuna gönderdiğini belirleyin ve iç sorguların beklenmeyen dış sunuculara gitmediğini kontrol edin.
- Yanıtın hangi yetkili görünümden geldiğini ve beklenen kayıtlarla eşleştiğini doğrulayın.
- Yanıtlanan IP adresine giden ağ yolunun test edilen bağlantıda kullanılabildiğini kontrol edin.
- Eski yanıtın istemci veya recursive resolver önbelleğinde kalıp kalmadığını değerlendirin.







