Linux'ta BIND9 ile DNS Sunucu Kurulumu ve Yapılandırma

Bir sunucunun web hizmeti sorunsuz çalışsa bile DNS çözümlemesi bozuksa kullanıcı hiçbir şeye erişemez. Tarayıcı alan adını IP adresine çeviremediği için istek sunucuya hiç ulaşmaz. BIND9 ile kendi DNS sunucunuzu kurduğunuzda bu çeviri işini üçüncü taraf bir sağlayıcıya değil, doğrudan kendinize bağlarsınız. Bu rehberde BIND9'u sıfırdan kurup çalışan bir bölge (zone) tanımına ulaşana kadar izlenecek adımları anlatıyoruz.

BIND9, açılımıyla Berkeley Internet Name Domain, ISC (Internet Systems Consortium) tarafından geliştirilen bir DNS sunucu yazılımıdır ve neredeyse her Linux dağıtımının resmi paket deposunda bulunur. İki farklı rolde çalışabilir: kendi bölgeleriniz için yetkili (authoritative) yanıt verebilir ya da istemciler adına internete sorgu gönderen özyineli (recursive) bir çözümleyici olabilir. Bu iki rolü tek bir süreçte birleştirmek güvenlik açısından risklidir; bir sunucunun ya yetkili yanıt vermesi ya da sorgu yönlendirmesi beklenir, ikisini aynı anda üstlenmesi önerilmez.

BIND9 Kurulumu Nasıl Yapılır

Debian ve Ubuntu tabanlı dağıtımlarda kurulum tek komutla tamamlanır:

sudo apt update
sudo apt install bind9 bind9utils bind9-doc

RHEL, CentOS ve Fedora ailesinde paket adı bind olarak geçer:

sudo dnf install bind bind-utils

Kurulum tamamlandıktan sonra servisin durumunu kontrol edin:

sudo systemctl status named
sudo systemctl enable named

Debian ailesinde servis çoğunlukla bind9 adıyla, RHEL ailesinde ise named adıyla kayıtlıdır; iki dağıtım arasında geçiş yaparken bu isim farkı en sık karışıklığa yol açan noktadır. systemctl list-units | grep -i bind komutu, sisteminizde servisin hangi isimle çalıştığını doğrudan gösterir. Kurulum bittiğinde named -v ile sürüm numarasını öğrenip dağıtımınızın deposundaki BIND9 sürümünü ISC'nin güncel duyurularıyla karşılaştırabilirsiniz; paket yöneticisi genelde birkaç ay gerideki bir sürümü sunar ve bu fark, özellikle kritik bir güvenlik açığı duyurulduğunda önem kazanır.

Yapılandırma Dosyaları Nerede ve Ne İşe Yarar

BIND9'da yapılandırma tek dosyada durmaz; birbirini include eden birden çok dosyaya dağılmıştır. Debian tabanlı sistemlerde bu dosyaların tümü /etc/bind/ dizininde bulunur. Zincirin başında named.conf adlı ana dosya yer alır ve diğer tüm dosyaları oradan çağırır.

Üç dosya farklı görev üstlenir. Genel davranışı, yani recursion açık mı, hangi forwarder'lar kullanılacak ve sunucu hangi adreslerde dinleyecek gibi ayarları named.conf.options belirler. Kendi tanımladığınız bölgeler named.conf.local içinde listelenir. localhost ve root hint gibi BIND9'un kendi varsayılan bölgeleri ise named.conf.default-zones dosyasında durur. Bu ayrımın pratik bir faydası vardır: kendi bölgeleriniz üzerinde çalışırken sistemin varsayılan ayarlarına kazara dokunma ihtimali ortadan kalkar.

Pratikte en sık elle düzenlenen blok forwarders ayarıdır; sunucu kendi bilmediği bir sorguyla karşılaştığında bu bloktaki adreslere yönlendirme yapar. Aşağıdaki örnek, böyle bir yapılandırmayı gösteriyor:

options {
    directory "/var/cache/bind";
    recursion yes;
    allow-recursion { 127.0.0.1; 10.0.0.0/24; };
    forwarders {
        1.1.1.1;
        9.9.9.9;
    };
    dnssec-validation auto;
    listen-on { any; };
};

allow-recursion, gözden kaçırılmaması gereken bir güvenlik satırıdır. any değeriyle bırakılırsa sunucu herkese açık bir özyineli çözümleyiciye (open resolver) dönüşür ve bu durum sunucuyu DNS amplification saldırılarında kullanılan bir araca çevirebilir. Bu alana yalnızca güvendiğiniz ağ bloklarını yazın; küçük bir ofis ya da ev kurulumunda bu çoğunlukla tek bir yerel alt ağla sınırlıdır.

Bir Bölge (Zone) Nasıl Tanımlanır

named.conf.local dosyasına, yönetmek istediğiniz her alan adı için ayrı bir zone bloğu eklemeniz gerekir:

zone "ornek.local" {
    type master;
    file "/etc/bind/zones/db.ornek.local";
    allow-transfer { 192.168.1.20; };
};

type master direktifi, sunucunun bu bölgede birincil ve yetkili kaynak olduğunu bildirir. Bir ikincil sunucu kuracaksanız bunun yerine type slave yazıp masters yönergesiyle birincil sunucunun IP adresini belirtmeniz gerekir; birincildeki her değişiklikte ikincil sunucu kendi kopyasını otomatik tazeler. Bölge dosyasını sıfırdan yazmak yerine örnek dosyayı zones dizinine kopyalayarak başlamak daha pratiktir:

sudo mkdir -p /etc/bind/zones
sudo cp /etc/bind/db.local /etc/bind/zones/db.ornek.local

Bir bölge dosyası her zaman SOA (Start of Authority) kaydıyla açılır, geri kalan satırlarda diğer kayıt türleri sıralanır:

$TTL    604800
@       IN      SOA     ns1.ornek.local. admin.ornek.local. (
                              3         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns1.ornek.local.
ns1     IN      A       192.168.1.10
@       IN      A       192.168.1.10
www     IN      A       192.168.1.10
mail    IN      A       192.168.1.11
@       IN      MX      10 mail.ornek.local.

Her düzenlemeden sonra serial numarasını artırmanız gerekir. İkincil sunucular güncel bir bölge kopyasına ihtiyaç olup olmadığını bu sayıyı karşılaştırarak belirler. Serial'ı tarih biçiminde yazmak (2026070301 gibi) yaygındır; bu sayede hem artan bir sıra izlenir hem de son değişikliğin ne zaman yapıldığı bir bakışta görülür. Serial güncellenmeden bölge dosyası değiştirilirse ikincil sunucular fark etmeden eski kayıtları sunmayı sürdürür; sorun uzun süre gözden kaçabilir.

Kayıt türlerinin birbirine karıştırılması da yaygın bir hatadır. En sık kullanılan altı türü aşağıdaki tabloda topladık:

Kök alan adında (@) bir CNAME kaydı tanımlamaya çalışmak BIND9'da hataya neden olur. Kökte A ya da AAAA kaydı kullanmanız, CNAME'i ise sadece www gibi alt alan adlarında tercih etmeniz gerekir.

Yapılandırmayı Test Etmek ve Servisi Yeniden Başlatmak

Değişiklikleri servise yansıtmadan önce doğrulamanız için BIND9 iki ayrı kontrol aracı sağlar. Bu ikisini restart öncesinde çalıştırmak, tek bir bozuk bölgenin bütün DNS hizmetini kesintiye uğratmasını engeller:

sudo named-checkconf
sudo named-checkzone ornek.local /etc/bind/zones/db.ornek.local

named-checkzone komutu serial numarasını, SOA yapısını ve sözdizimini denetler; bir hata bulursa satır numarasıyla birlikte bildirir. Her iki komut da hatasız tamamlandığında servisi güvenle yeniden başlatabilirsiniz:

sudo systemctl restart named
sudo journalctl -u named -f

journalctl komutunun çıktısında bölge yüklenirken oluşan hataları anlık olarak izleyebilirsiniz. Çıktıda "zone ornek.local/IN: loaded serial" satırını görürseniz bölge sorunsuz yüklenmiş demektir. Çözümlemenin gerçekten çalıştığını doğrulamanın en güvenilir yolu dig komutunu kullanmaktır:

dig @127.0.0.1 www.ornek.local
dig @127.0.0.1 ornek.local MX

ANSWER SECTION'da beklediğiniz kaydı göremiyorsanız önce serial numarasını artırıp artırmadığınızı, ardından named-checkzone çıktısında bir hata olup olmadığını kontrol edin. İstemci tarafında /etc/resolv.conf dosyasındaki nameserver satırının, test ettiğiniz sunucuyu işaret ettiğinden emin olun; aksi halde sorgu farklı bir DNS'e gider ve site aslında çalışırken "çalışmıyor" gibi görünür. Aynı makinede birden fazla ağ arayüzü varsa bu ayrıntı kolayca gözden kaçar.

Güvenlik ve Erişim Kontrolü

Bir DNS sunucusunu internete açık bırakmak, doğru kısıtlamalar yapılmadan risklidir. allow-query ve allow-recursion yönergeleriyle kimlerin sorgu yapabileceğini ve kimlerin özyineli çözümleme isteyebileceğini ayrı ayrı sınırlayın:

options {
    allow-query { any; };
    allow-recursion { 10.0.0.0/24; };
    allow-transfer { none; };
    version "not disclosed";
};

allow-transfer { none; } satırı, bölge transferini varsayılan olarak tamamen kapalı tutar. Bu listeye yalnızca gerçekten ikincil sunucu olarak çalışan makinelerin IP adresini ekleyin. Aksi durumda bölgenizin tüm kayıtları dışarıdan dig axfr komutuyla tek seferde çekilebilir; bu da alt alan adı yapınızı ve iç ağ düzeninizi dışarıya sızdıran ciddi bir güvenlik açığıdır. version direktifini gizli tutmak, saldırganın hedef alacağı BIND9 sürümünü baştan bilmesini engeller. Bu tek başına yeterli bir savunma değildir, ama diğer önlemlerin üzerine eklenen ek bir katmandır.

DNSSEC, DNS yanıtlarını kriptografik imzayla doğrulayan bir uzantı kümesidir ve sahte yanıtların önbelleğe yerleşmesini (cache poisoning) engeller. dnssec-validation auto; direktifi, sunucunun aldığı yanıtları bu imzalara göre denetlemesini sağlar. Bölgenizi kendiniz imzalamak isterseniz dnssec-keygen ve dnssec-signzone araçlarıyla ayrı bir imzalama süreci kurmanız gerekir. Bu adım genelde canlıya geçmeden önce planlanır ve düzenli anahtar rotasyonunu da beraberinde getirir. Yapılandırma seçeneklerinin tamamını ve sürüm notlarını görmek için ISC'nin resmi BIND9 dokümantasyonu en güvenilir kaynaktır.

Zaman içinde artık kullanılmayan A ve CNAME kayıtlarının birikmesi DNS altyapınızı dağınıklaştırır; kayıtları belirli aralıklarla gözden geçirip temizlemek bunu önler. named-checkzone komutunu her değişiklikten sonra rutin olarak çalıştırmak, küçük bir yazım hatasının bütün bölgeyi devre dışı bırakmasını önleyen en düşük maliyetli güvenlik adımıdır. Bu küçük disiplin alışkanlığı, ileride yaşanabilecek büyük bir kesinti riskini baştan ortadan kaldırır.

Yazan Celil Uyanikoglu

Bilgisayar mühendisiyim; 25 yılı aşkın süredir bilgi işlem sektörünün içindeyim. Bu blogu 2020'de, işimde her gün karşılaştığım sorunların çözümlerini bir yere yazmak için açtım: Linux, güvenlik, tarayıcılar, yapay zeka araçları. Yazdığım her rehberi önce kendi bilgisayarımda ya da sunucumda deniyorum; çalıştığını görmediğim adımı yayınlamam. Hatalı ya da eskimiş bir şey görürsen iletişim sayfasından yaz — düzeltirim.