DNS (Domain Name System), websitelerin ve sunucuların nasıl yapılandırılması gerektiğini öğrenirken anlaması, kavraması zor bir konu olarak karşımıza çıkmaktadır. Günümüzdeki çoğu insan hosting firmalarından veya domainlerini kayıt ettirdikleri yerden sağlanan DNS sunucusu hizmetini kullanmaktadırlar, ancak kendimizin DNS sunucusu oluşturması durumunda bunun bazı avantajları bulunmaktadır.

Bu dokümanda Ubuntu 16.04 üzerinde caching ve forwarding olarak kullanabileceğiniz Bind9 DNS sunucusu kurulumu ve yapılandırılmasını anlatacağız.

Gereksinimler

Öncelikle Bind kurulumu ve kullanımına geçmeden önce CloudEOS‘ a kayıt olarak iki adet Ubuntu 16.04 sunucunuzu oluşturmalısınız.

Kuruluma başlamadan önce Ubuntu sunucular için güvenlik açısından sudo yetkilerine sahip bir kullanıcı oluşturmanızı tavsiye ediyoruz.

Yeni Kullanıcı Ekleme

Sisteme size verilen şifre ve root kullanıcısı ile giriş yaptıktan sonra

$ adduser yenikullanici

ile kullanıcı oluşturmuş oluyoruz.

$ usermod -aG sudo yenikullanici

komutu ile de oluşturduğumuz kullanıcıya sudo yetkilerini vermiş olduk. Şimdi Bind yapılandırma adımlarına bu oluşturduğumuz sudo haklı kullanıcı ile devam edeceğiz.

Bu dokümanı anlatırken kullanacağımız örnek iki sunucu bilgileri aşağıdaki gibidir. Sizin kullanacağınızı sanal sunucuların ip adresleri aşağıdaki ip adreslerine göre farklılık gösterecektir.

DNS Sunucusu (dnsServer - 185.153.251.X)
İstemci Sunucu (client - 185.153.251.Y)

Caching DNS Sunucusu

İlk yapılandırmamız gereken sunucu caching DNS sunucusu olacaktır. Bu tip sunucular çözücü olarak da bilinmektedirler çünkü istekleri tekrar tekrar ele alırlar ve genellikle DNS verilerini diğer sunucular üzerinden arayarak bulmaya çalışırlar.

Caching DNS sunucusu istemcinin isteklerini ararken istemciye cevap döner ve daha sonra bu cevabı kendi lokal cache’ inde de barındırır. Bu şekilde sonraki benzer bir istekte bu cevaplar arasında uygun olan kullanılır bu şekilde sorguyu ararken gidiş-dönüş zamanı azaldığı için daha hızlı cevap verir.

Forwarding DNS Sunucusu

İkinci yapılandırmamız gereken sunucu forwarding DNS sunucusudur. Forwarding DNS sunucusu, istemci açısından caching DNS suncusuna yakındır ama mekanizması ve iş hacmi oldukça farklıdır.

Forwarding DNS sunucusu, istemciler için DNS çözüm zamanını geliştirme bakımından benzer avantajları sunmaktadır. Ancak verdikleri cevapları cache’lemezler her seferinde tekrar forward edip sorarlar. Kısaca gelen tüm istekleri dışarıdaki resolving sunuculara yönlendirir ve gelen cevapları daha sonra kullanmak için saklarlar.

DNS Sunucusu Üzerine Bind Kurulumu

Yukarıdaki hangi yapılandırmayı seçerseniz seçin, ilk adım Bind DNS uygulamasını kurmak şeklinde olacaktır.

Bind yazılım paketi Ubuntu default paket deposunda bulunmaktadır. Aşağıdaki şekilde kuruluma başlayabiliriz.

dnsServer$ sudo apt-get update
dnsServer$ sudo apt-get install bind9 bind9utils bind9-doc

Yukarıdaki komut ile Bind bileşenleri kurulmuş oldu, şimdi sunucumuzu yapılandırmaya başlayabiliriz. Forwarding sunucuları atlama noktası olarak Caching sunucu ayarlarını kullanabilir, bu yüzden yapılandırmamıza Caching sunucu olarak devam edeceğiz.

Caching DNS Sunucu Yapılandırılması

Şimdi Bind’ ı caching DNS sunucusu olarak yapılandıracağız. Bu yapılandırma sunucuyu kullanıcılardan ve diğer sistemlerden gelen sorguları TTL değerlerine göre cache’leyerek gelen sorgulara hızlı cevap vermesini sağlayacaktır.

Bind ayar dosyaları default olarak /etc/bind altında bulunmaktadır. Şimdi bu dizine geçiş yapalım.

dnsServer$ cd /etc/bind

Caching DNS sunucusu için sadece named.conf.option dosyasında düzenleme yapmamız yeterlidir. Aşağıdaki şekilde dosya içine giriş yapalım.

dnsServer$ sudo nano named.conf.options

Okunabilirlik açısından yorum satırlarının silinmesi sonrası ilgili dosya aşağıdaki gibi gözükmektedir.

options {
directory "/var/cache/bind";

dnssec-validation auto;

auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};

Caching olarak yapılandırma için ilk adım ACL’ i (Access Control List) ayarlamaktır.

options bloğu üzerinde acl adında yeni bir blok oluşturacağız.

acl safeClients {
};

options {
...

Bu blokta izinli, bizim açımızdan güvenli olan kullanıcıların DNS sunucusunu kullanması için IP adresi veya network tanımlaması yapacağız. Örneğimizde sunucu ve istemci makinelerimiz aynı /24 subnet’ inde olduğu için aşağıdaki gibi /24 olarak tüm IP bloğuna izin vererek devam edeceğiz. Bunu dış taraflar olmadan kendi istemcileriniz için de ayarlamanız gerekmektedir. Ayrıca localhost ve localnets’ i de ekleyeceğiz.

acl safeClients {
185.153.251.0/24;
localhost;
localnets;
};

options {
...

Şu anda istekleri çözülebilecek bir istemci ACL’ sine sahibiz. Şu anda options bloğuna aşağıdaki satırları ekleyeceğiz.

...

options {
directory "/var/cache/bind";

recursion yes;
allow-query { safeClients; };
...

Daha sonrasında dosyayı kaydederek çıkıyoruz.

Forwarding DNS Sunucunun Yapılandırılması

Eğer yapınız için forwarding DNS sunucusu daha uygun ise caching yerine bunu kolayca ayarlayabiliriz.

Daha önce caching DNS sunucusu için üzerinde ayar yaptığımız named.conf.options dosyasına giriş yapalım ve düzenlemeye devam edelim.

dnsServer$ sudo nano named.conf.options
acl safeClients {
185.153.251.0/24;
localhost;
localnets;
};

options {
directory "/var/cache/bind";

recursion yes;
allow-query { safeClients; };

dnssec-validation auto;

auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};

Güvenli olan istemcilerin sorgularını cevaplamak için aynı ACL listesini kullanmaya devam edeceğiz. Ancak ayarlarımız da bazı değişiklikler yaparak tekrar tekrar sorgulara cevap verilmesinin önüne geçeceğiz.

Bunun için recursion ayarını no olarak değiştirmeyeceğiz forwarding sunucu yine yetkili olmadığı domain’ler için recursion, cevap verme işlemlerine devam edecek. Biz burada gelen istekleri caching sunucularına yönlendireceğiz.

...

options {
directory "/var/cache/bind";

recursion yes;
allow-query { safeClients; };

forwarders {
8.8.8.8;
8.8.4.4;
};
...

Daha sonra forward değişkenini only olarak ayarlayacağız ve bu şekilde kendisi istekleri çözmek için çabalamasın, gelen istekleri yönlendirsin şeklinde ayarlamış olacağız.

...

options {
directory "/var/cache/bind";

recursion yes;
allow-query { safeClients; };

forwarders {
8.8.8.8;
8.8.4.4;
};
forward only;

dnssec-validation auto;

auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};

En son değişikliği dnssec parametresini oluşturarak yapmalıyız. Şu andaki forwarding DNS sunucusu ayarları sebebi ile log’ da bazı hatalar gözükebilir.

Jul 19 12:25:44 cache named[2512]: error (chase DS servers) resolving 'in-addr.arpa/DS/IN': 8.8.8.8#53
Jul 19 12:25:44 cache named[2512]: error (no valid DS) resolving '111.111.111.111.in-addr.arpa/PTR/IN': 8.8.4.4#53

Bu durumdan kaçınmak için dnssec-validation değerini yes olarak ve dnssec-enabled değerini yes olarak ayarlamak gerekmektedir.

...

forward only;

dnssec-enable yes;
dnssec-validation yes;

auth-nxdomain no; # conform to RFC1035
...

Daha sonrasında dosyayı kaydederek çıkıyoruz.

Yapılandırma Testi ve Bind’ ı Yeniden Başlatma

Şimdi yapınıza uygunluğuna göre caching DNS sunucusu veya forwarding DNS sunucusu olarak kullanabileceğiniz ayarlar tanımlamasını yaptık ve şimdi hangisini tercih ettiyseniz onu aktif etme işlemini yapacağız.

Bunun için Bind servisi yeniden başlatmadan önce ayarlarımızı aşağıdaki komut ile kontrol edelim.

dnsServer$ sudo named-checkconf

Eğer tüm ayarlamalarınız doğru ise hiçbir çıktı dönmeyecektir.

Eğer herhangi bir hata dönerse ilgili ayarlarınızı kontrol edip düzeltmelisiniz.

Hata almadıysanız Bind servisini yeniden başlatarak değişikliklerin aktif hale gelmesini sağlayacağız.

dnsServer$ sudo systemctl restart bind9

Eğer UFW güvenlik duvarınız aktif ise istemci isteklerine cevap verilmesi için sunucunuz üzerinden DNS trafiğine izin vermeniz gerekmektedir.

dnsServer$ sudo ufw allow Bind9

Daha sonrasında logları kontrol ederek herşeyin doğru çalıştığından emin olalım.

dnsServer$ sudo journalctl -u bind9 -f

Şimdi yeni bir terminal açarak istemci makinemize giriş yapalım.

İstemci Makine Yapılandırılması

Giriş yaptığınız istemci makinesinin DNS sunucusu üzerinde yaptığınız ayarlarda ki ACL listesinde olduğundan emin olmalısınız ki DNS isteklerini gönderebilelim.

Bunun için /etc/resolv.conf dosyasında düzenleme yapacağız.

client$ sudo nano /etc/resolv.conf

Dosyayı aşağıdaki şekilde düzenleyelim. Siz burada kendi sunucunuzun ip adresini gireceksiniz.

nameserver 185.153.251.X
# nameserver 195.142.2.132
# nameserver 195.142.2.133

Daha sonra dosyayı kaydedip çıkalım.

Bazı araçlar yardımı ile şu anda isteklerimizin çözülüp çözülmediğini kontrol edelim.

ping komutu ile birlikte alan adlarına erişim olup olmadığını kontrol edelim.

client$ ping -c 1 google.com
PING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms

Yukarıdaki çıktıdan anlayacağımız üzere DNS sunucumuzu kullanarak google.com’ a erişebiliyoruz.

Daha ayrıntılı bilgi istersek bunun için de dig aracını kullanabiliriz. Farklı bir alan adı ile testimizi yapalım.

client$ dig linuxfoundation.org
; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35417
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org. IN A

;; ANSWER SECTION:
linuxfoundation.org. 6017 IN A 140.211.169.4

;; Query time: 33 msec
;; SERVER: 185.153.251.X#53(185.153.251.X)
;; WHEN: Wed Jul 19 12:34:41 EDT 2014
;; MSG SIZE rcvd: 64

Yukarıda gördüğünüz üzere istek 33 milisaniyede alındı. Eğer aynı isteği tekrarlarsak veri cache’ ten geleceği için bu sürenin düştüğünü göreceksiniz.

client$ dig linuxfoundation.org
; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35417
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org. IN A

;; ANSWER SECTION:
linuxfoundation.org. 6017 IN A 140.211.169.4

;; Query time: 1 msec
;; SERVER: 185.153.251.X#53(185.153.251.X)
;; WHEN: Wed Jul 19 12:35:13 EDT 2014
;; MSG SIZE rcvd: 64

Cache’ lenen cevaplar önemli ölçüde hızlı döndüğünü görmüş olduk.

Ayrıca reverse lookup testi yapabiliriz. Bunun için son kullandığımız komuttan kullanabileceğimiz 140.211.169.4 IP’ sinden yararlanacağız.

client$ dig -x 140.211.169.4
; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 140.211.169.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61516
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;4.169.211.140.in-addr.arpa. IN PTR

;; ANSWER SECTION:
4.169.211.140.in-addr.arpa. 3402 IN CNAME 4.0-63.169.211.140.in-addr.arpa.
4.0-63.169.211.140.in-addr.arpa. 998 IN PTR load1a.linux-foundation.org.

;; Query time: 31 msec
;; SERVER: 185.153.251.X#53(185.153.251.X)
;; WHEN: Wed Jul 19 12:36:03 EDT 2014
;; MSG SIZE rcvd: 117

Gördüğünüz üzere reverse lookup’ ta başarılı şekilde dönmektedir.

DNS sunucusuna geri dönerek testler esnasında log’ lara düşen herhangi bir hata olup olmadığını kontrol edelim. Aşağıdaki gibi bir hata ile de karşılaşabilirsiniz.

dnsServer$ sudo journalctl -u bind9 -f
...
Jul 19 11:26:23 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.net/A/IN': 2001:dc0:4001:1:0:1836:0:140#53
Jul 19 11:27:14 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.com/A/IN': 2001:503:a83e::2:30#53
Jul 19 11:28:25 cache named[2004]: error (network unreachable) resolving 'sns-pb.isc.org/AAAA/IN': 2001:500:f::1#53
Jul 19 11:29:43 cache named[2004]: error (network unreachable) resolving 'ns3.nic.fr/A/IN': 2a00:d78:0:102:193:176:144:22#53

Yukarıdaki hatanın sebebi sunucu IPv6 için yapılandırılmamasına rağmen IPv6 bilgilerini çözmeyi denemesinden kaynaklanmaktadır. Bu durumu Bind’ a sadece IPv4 kullan diyerek çözebilirsiniz.

Bunun için Bind9′ un başladığı systemd biriminde değişiklik yapmanız gerekmektedir.

dnsServer$ sudo systemctl edit --full bind9

Dosya içinde ExecStart satırının sonuna -4 değerini girerek sadece IPv4 kullanımı olacak şekilde kısıt belirleyebiliriz.

[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target

[Service]
ExecStart=/usr/sbin/named -f -u bind -4
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop

[Install]
WantedBy=multi-user.target

Dosyayı kaydederek çıkıyoruz.

Systemd daemon’ u ve Bind9 ‘ u yeniden yükleyerek değişikliklerin alınmasını sağlayalım.

dnsServer$ sudo systemctl daemon-reload
dnsServer$ sudo systemctl restart bind9

Tekrar kontrol ettiğinizde benzer sorunların devam etmediğini gözlemleyebilirsiniz.

İstemci DNS Ayarlarının Kalıcı Olarak Ayarlanması

Daha öncesinde /etc/resolv.conf üzerinde yaptığımız değişiklikler istemci sunucunuz yeniden başladığında kaybolacak ayarlardır. Bunların kalıcı olması için bazı ek düzenlemeler yapacağız.

Eğer istemci makineniz Debian veya Ubuntu üzerinde çalışıyorsa ayarlarınızın kalıcı olması için /etc/network/interfaces dosyasında değişiklikler yapacağız.

client$ sudo nano /etc/network/interfaces
...

iface eth0 inet static
address 185.153.251.Y
netmask 255.255.255.0
gateway X.X.X.X
dns-nameservers 185.153.251.X

...

Dosyayı kaydederek çıkalım. Bu sayede istemci makinesi kapanıp açılsa da ayarlar aynı şekilde korunacaktır.

Eğer istemci makineniz CentOS veya Fedora üzerinde çalışıyorsa ayarlarınızın kalıcı olması için /etc/network/interfaces dosyasında değişiklikler yapacağız.

client$ sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0
... 
DNS1=185.153.251.X 
...

Dosyayı kaydederek çıkalım. Bu sayede istemci makinesi kapanıp açılsa da ayarlar aynı şekilde korunacaktır.

Bu dokümanda, makalede yazan komutları, çözümleri uygulamak tamamen kullanıcının kendi sorumluluğunda ve insiyatifinde olan bir konudur, mevcut komutların uygulanması ile doğabilecek, oluşabilecek her türlü sorumluluk ve sonuçlar kullanıcının kendisine aittir, CloudEOS’ un bu konuda herhangi bir sorumluluğu bulunmamaktadır.