Leoman’s blog

Bildiğiniz üzere BIND dünya üzerinde en çok kullanılan ve popüler olan DNS sunucusudur. Bu üstünlük Domain Name System [1] protokolünün ortaya koyulduğu 1983 yılınını takip eden 1984 yılında geliştirilmeye başlanmış olması gibi gözükse de bu kadarla da sınırlı değildir. Bu popülerliğin arkasında yatan etkenlerden biri de yeterince esnek bir yapıya sahip olmasından da geliyor.

Esnek derken?
Esnek bir yapı derken BIND size neler sağlayabilir? Daha önceki blog girdilerimden birinde bahsettiğim gibi mysql-bind [2] gibi bir veritabanı sürücüsü ile zone’larınızı MySQL üzerinde tutabilirsiniz. Yine Dynamically Loadable Zones [3] (DLZ) ile farklı veri kaynakları üzerinde (MySQL, PostgreSQL, File system, ODBC, LDAP) zone’larınızı saklayabilirsiniz. DNS Spliting ile isteyeceğiniz herhangi bir kaynağa isteyeceğiniz herhangi bir cevabı döndürebilirsiniz.

Split DNS mi?
Çok basit bir değiş ile aynı alan adı için yapılan DNS sorgulamasında isteği yapan kaynak IP adreslerine göre değişik IP cevapları verme işlemine split-horizon/split-view/split-brain [4] DNS adını veriyoruz. Bir çok DNS sununucu tarafından desteklenen bu metot [5] BIND’ın içerisinde de ön tanımlı olarak desteklenmektedir.

Nasıl?

Bind konfigrasyonu içerisinde bunu anlatan ifade “view”‘dır. Oluşturacağınız view bloklarına göre [6] istediğiniz kaynaklara istediğiniz cevapları döndürebilirsiniz.

01
view "local" {
02
	match-clients { 192.168.0.0/24; };
03
	recursion yes;
04
	.
05
	.
06
	.
07
	.
08
	zone "domain.tld" {
09
		type master;
10
		file "virt/db.domain.tld.conf.local";
11
	};
12
};
13
view "others" {
14
	match-clients { any; };
15
	recursion no;
16
	.
17
	.
18
	.
19
	.
20
	.
21
 	zone "domain.tld" {
22
 		type master;
23
 		file "virt/db.domain.tld.conf";
24
 	};
25
 };

Bunun gibi bir named.conf konfigürasyonu ile yapılandıracağımız DNS sunucumuza 192.168.0 ile başlayan bir client’tan gelecek istek dahilinde db.domain.tld.conf.local konfigürasyon dosyamızın içerindeki zone tanımlamaları geçerli olacak ve bu clientlar aynı zamanda recursive query’ler için de kullanabilecekler, bunun haricinde olan tüm IP adresleri bu DNS sunucuya recursive query’ler için kullanmazkan domain.tld isteklerinde db.domain.tld.conf konfigürasyon dosyası içerisinde tanımlı olan zone’lara göre cevap alacaklar.

Daha düzenli konfigürasyon ve daha anlaşılır olması için şöyle bir örnek senaryo çizebiliriz. Elimizde Internet üzerinde çalışacak bir proje geliştiren bir ekip bütünü var. İki farklı lokasyonda VPN ile birbirine bağlı ve ofisler birbirine erişebiliyor. Ekip aynı ofisi paylaşan yazılım geliştiriciler ve geliştiricilerin kullandığı sunucu, geliştiriciler ile aynı ofisi paylaşan test ekibi, ikinci lokasyonda bulunan pre-live izleyicileri ve yine ikinci lokasyonda bulunan test ekibi.
Bu coğrafik olarak dağıtık fakat aynı network içinde çalışan ofis örneğinde dev.newapp.com’a istek gönderen her ekibin farklı sunucuya erişmesini şu şekilde sağlarız.

Öncelikle DNS sunucumuza bir Access Control List (ACL)’leri (istek yapan IP kaynaklarını belirleyen) alt bir konfigürasyon dosyası oluşturmakla başlayalım.  Bunun için /etc/bind9/named.conf.acls adında bir dosya oluşturarak içerisine ilgili acl listelerini oluşturuyoruz.

01
acl "developers" {
02
 	#developerlara ait IP blogu
03
 	192.168.0.0/26;
04
};<br />
05
acl "testers" {
06
 	#ofis 1 test ekibine ait IP blogu
07
 	192.168.0.64/26;
08
 	#ofis 2 test ekibine ait IP blogu
09
 	192.168.1.128/26;
10
};
11
acl "managers" {
12
	#sirket yoneticilerin ait ip blogu
13
 	192.168.1.0/26;
14
}; 

Bu işlemin ardından sırasıyla zone detaylarının yer alacağı konfigürasyon dosyalarını yaratıyoruz.

01
/* db.dev.newapp.com.developers */
02
dev.newapp.com.        	600   IN      SOA     nsdev.newapp.com. sysadm.newapp.com. (
03
                         2011022101 ; Serial
04
                         600 ; Refresh
05
                         600 ; Retry
06
                         600 ; Expire
07
                         600 ); Negative Cache TTL ;
08
                IN      NS      nsdev.newapp.com.
09
		IN      A       192.168.0.128
10
www		IN      A       192.168.0.128 

01
/* db.dev.newapp.com.testers */
02
dev.newapp.com.        	600   IN      SOA     nsdev.newapp.com. sysadm.newapp.com. (
03
                         2011022101 ; Serial
04
                         600 ; Refresh
05
                         600 ; Retry
06
                         600 ; Expire
07
                         600 ); Negative Cache TTL ;
08
                IN      NS      nsdev.newapp.com.<br />
09
		IN      A       88.88.88.88
10
www		IN      A       88.88.88.88

01
/* db.dev.newapp.com.prelive */
02
dev.newapp.com.        	600   IN      SOA     nsdev.newapp.com. sysadm.newapp.com. (
03
                         2011022101 ; Serial
04
                         600 ; Refresh
05
                         600 ; Retry
06
                         600 ; Expire
07
                         600 ); Negative Cache TTL ;
08
                IN      NS      nsdev.newapp.com.
09
		IN      A       88.88.88.99
10
www		IN      A       88.88.88.99 

Bu dosyaların arından varolan named.conf’unuzunu içerisine öncelikle named.conf.acls dosyasını include etmeniz ve her üç durum için de ayrı bir view eklemeniz yeterli olacaktır.

01
view "developers-view" {
02
  	match-clients { "developers"; };
03
	zone "dev.newapp.com" {
04
 		type master;
05
 		file "db.dev.newapp.com.developers";
06
 	};
07
};
08
view "testers-view" {
09
	match-clients { "testers"; };
10
  	zone "dev.newapp.com" {
11
 		type master;
12
 		file "db.dev.newapp.com.testers";
13
 	};
14
};
15
view "prelive-view" {
16
  	match-clients { "managers"; };
17
 	 	zone "dev.newapp.com" {
18
 		type master;
19
 		file "db.dev.newapp.com.prelive";
20
 	};
21
};

[1] http://tr.wikipedia.org/wiki/DNS
[2] http://mysql-bind.sourceforge.net/
[3] http://bind-dlz.sourceforge.net/
[4] http://en.wikipedia.org/wiki/Split-horizon_DNS
[5] http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software#Feature_matrix
[6] http://www.isc.org/files/arm96.html#id2549625