Bildiğiniz gibi teknoloji dünyasında DNS’ in çok özel bir yeri vardır. Çünkü siz kabloları donanımları kurup hadi çalışmaya başlayalım dediğiniz andan itibaren devreye giren ve hiç kurumsal olarak bu işler ile uğraşmamış olan son kullanıcılar için bile “internet” anlamına gelen DNS servisine olan hâkimiyetiniz aslında diğer ürünlerine olan hâkimiyetinizde göstermektedir.
Active Directory gibi DNS ile çalışan bir ürün için tabiki DNS candır diyebiliriz. Ancak DNS sadece Active Directory gibi bir ürün için değil, Exchange Server, Lync Server ve aklınıza gelebilecek daha pek çok ürün için çok kritik bir servisidir.
Temel olarak sunduğu destekler nedeni ile pek önemsenmeyebilir. Zaten çalışıyor noktasında dikkat etmemiş olabilirsiniz, ancak ne kadar çok bilgi o kadar çok çözüm yolu demektir.
Split DNS, yukarıda bahsettiğim gibi bir özellik aslında. Normal şartlarda bu konuyu bilmeseniz de aslında pek çok sistemi çalıştırabilirsiniz, ancak biliyor olmanız size özellikle kurumsal yapılarda çok büyük karizma sağlayacaktır.
Peki, nedir bu Split DNS? Aslında eminim ki bir kısmınızın hali hazırda bildiği, kullandığı ancak teknik ismini bilmediği bir şey bu.
Split DNS’ i en güzel senaryo ile anlatabiliriz.
Yukarıdaki senaryoda öncelikle normal bir dns isim çözümlemesi nasıl ilerliyor onu anlatmak istiyorum. External bir istemci makine www.cozumpark.com web sitesini açmak istiyor ise öncelikle bu domain’ den sorumlu name server’ dan aldığı ip adresi ile iletişime geçer, yani web server’ a ulaşıyor.
Benzer bir durum internal client içinde geçerlidir. Şirket içerisinde bulunan bir istemci de benzer şekilde bu web adresine ulaşmak için local dns sunucusuna gider ve bu domain için www kaydını sorar, local dns üzerinde “cozumpark.com” isminde bir zone olmadığı için bu dns de forward edildiği veya root dns lerden cozumpark için tanımlı name server’ a ulaşır ve ardından aldığı web server ip adresini istemciye iletir.
Buraya kadar normal bir DNS çalışma mantığı vardır. Peki Split DNS durumunda işler nasıl yürüyor. Split DNS durumunda siz şirket içerisindeki DNS sunucusuna bir zone açıyorsunuz ve bunun ismini “cozumpark.com” olarak tanımlıyorsunuz. İşte tam bu noktada artık bu alan adını artık iki farklı dns sunucu tutuyor. Tabiki bunlardan internete açık olan herkesin ulaşabileceği register olan name server. Sizin şirket içerisindeki sunucu ise size özel hizmet eden bir sunucudur.
Bu yeni yapıda artık şirket içerisindeki bilgisayarlar DNS cevaplarını internet üzerindeki name server’ dan değil, şirket içerisindeki sizin local DNS’ ten almaya başlar.
Ancak burada önemli bir nokta vardır. Siz şirket içerisindeki DNS üzerinde “cozumpark.com” isminde bir zone açarsanız, internet üzerinde ne kadar A kaydı var ise bunları içeriye de tanımlamanız gerekli.
Örneğin cozumpark.com için aşağıdaki kayıtlar internet üzerindeki name server da tanımlı.
A Record – www – 88.12.12.13
A Record – mail – 88.12.12.14
A Record – ftp – 88.12.12.15
Böyle bir durumda siz içerideki DNS üzerinde de bu kayıtların tamamını açmanız gerekli. Aksi halde sistem şöyle çalışır;
Örneğin sadece www kaydı açtınız ve istediğiniz bir ip ye yönlendirdiniz ( ister gerçek ip adresi isterseniz şirket içerisindeki bir web sitesi, bu konumuz değil şu anda ). Sistem sorunsuz çalışıyor.
Peki, birisi ftp adresine bağlanmak isterse ne olacak? Bu istek te local DNS’ e gelecek, local dns önce cache dosyasına, sonra host dosyasına bakacak, bunlar standart davranışlar. Sonra bu bir DNS sunucusu olduğu için zone isimlerini kontrol edecek, eğer cozumpark.com isminde bir zone olmasayı forward dnslere veya root lara gidecektir. Ancak siz “cozumpark.com” isminde bir zone açtığınız için haklı olarak bu zone içerisinde ftp ismindeki A kaydını arayacak, ancak siz açmadığınız için bulamayacak ve istemciye böyle bir kayıt yok şeklinde dönecek.
Peki, neden böyle bir şeye ihtiyaç duyarsınız, Bu noktada ise Exchange Server’ dan örnek vermek istiyorum.
Örneğin Exchange Server için bildiğiniz gibi OWA, Outlook Anywhere, OAB vb pek çok servis için URL adresleri tanımlamak gerekmektedir. Outlook Anywhere tek bir end point yani tek bir URL kullanmaktadır. Siz diyelim ki kendi şirket ortamınız için Outlook anwhere adresi olarak “mail.cozumpark.com” olarak bir tanım girdiniz.
Exchange 2013 de bildiğiniz gibi artık Outlook için RPC/TCP ( MAPI ) bağlantısı yok, tüm bağlantı RPC over http üzerinden gerçekleşmekte yani tüm Outlook bağlantıları aslında Outlook anywhere kullanmaktadır.
Düşünün ki şirket içerisinde 5000 tane Outlook var. Bu Outlook ları açtığınız anda bunlar mail.cozumpark.com’ u soracaklar, çünkü sizin Outlook anywhere end point URL adresiniz bu. Ama şirket dışından gelenler için bir sorun yokken şirket içerisindeki tüm Outlook programları da birden firewall üzerinden posta kutularına bağlanmaya başlayacaklardır.
Çünkü sizin kurumsal olarak sahip olduğunuz name server üzerinde kullanıcıların mail sistemine bağlanmasını sağlayan Outlook Anywhere URL adresi ( mail.cozumpark.com için A kaydı mail= x.x.x.x ) şirketin veya mail sunucusunun bulunduğu lokasyonun real ip adresini işaret etmektedir. Bu nedenle kullanıcı nerede olursa olsun bu şekilde gereksiz bir trafik oluşacaktır.
Bunu sadece Exchange 2013 olarak düşünmeyin, mesela sertifika tarafındaki name space sayısını düşürmek için OWA, OAB, ECP ve benzeri URL adreslerini;
https://casserver01.cozumpark.com – internal URL
https://mail.cozumpark.com – External URL
Durumundan aşağıdaki gibi bir duruma çeviriyorlar;
https://mail.cozumpark.com – İnternal URL
https://mail.cozumpark.com – External URL
Çünkü bu durumda sertifika içerisinde artık casserver01 gibi ek bir isim için ücret ödemeyecektir. Böyle bir senaryoda da aslında tüm kullanıcıların trafiği yine firewall üzerinden geçecektir.
Özetle bu ve benzeri pek çok ürün ve servis için ( Lync vb yani işin temelinde aslında şirket içinde sunulan bir hizmet için geçerli bir durumdur ) Split DNS çözümü kullanılması önerilen bir durumdur.
Bu konuda ki uygulamalar için ise ayrı bir makale yazacağım.
Bir sonraki makalemde görüşmek üzere.