BIND ile DNS Sunucu Kurulumu

Kendi alan adınızın DNS kayıtlarını başka bir sağlayıcının paneline emanet etmek yerine doğrudan kendi sunucunuzda tutmak istediğinizde karşınıza çıkan araç neredeyse her zaman BIND olur. İnternetin en eski ve en yaygın DNS yazılımı olan BIND (Berkeley Internet Name Domain), bugün hâlâ yetkili isim sunucularının önemli bir bölümünü çalıştırıyor. Bir hosting sağlayıcısının nameserver'ları, kurumsal bir ağın iç DNS altyapısı veya kendi VDS'inizde barındırdığınız birkaç alan adı için sağlam, denenmiş bir çözüm arıyorsanız BIND9 tam olarak bu iş için tasarlanmıştır.

Bu rehberde sıfırdan bir yetkili DNS sunucusunu ayağa kaldıracağız. Önce yetkili ve özyineli DNS arasındaki farkı netleştirecek, ardından BIND9'u kuracak, named.conf yapılandırmasını ve bir bölge (zone) dosyasını elle yazacağız. SOA kaydındaki seri numarasının neden bu kadar önemli olduğunu, A, MX, NS ve CNAME kayıtlarının nasıl tanımlandığını göreceğiz. Son olarak named-checkzone ile yapılandırmayı doğrulayıp dig ile sorgu atarak her şeyin çalıştığını kanıtlayacağız. Baştan söyleyeyim; DNS'te en küçük yazım hatası bile bölgenin tamamını yüklenmez hâle getirir, o yüzden her adımda doğrulama alışkanlığını beraber kuracağız.

Yetkili DNS ile Özyineli DNS Arasındaki Fark#

BIND'i yapılandırmadan önce hangi rolü üstleneceğine karar vermek şart, çünkü bu iki rol tamamen farklı davranışlar ve tamamen farklı güvenlik sonuçları doğurur. Yetkili (authoritative) bir DNS sunucusu, belirli bir alan adının kayıtlarının resmi kaynağıdır. ornek.com için yetkili sunucu, o alan adının A, MX, TXT gibi kayıtlarını "ben biliyorum, kesin cevap bu" diyerek verir. DNS'in nasıl çalıştığını daha derinlemesine merak ediyorsanız DNS nedir yazısı temel kavramları adım adım anlatıyor.

Özyineli (recursive) bir sunucu ise sizin adınıza gidip cevabı bulan çözümleyicidir. Bilgisayarınız bir siteyi açmak istediğinde önce özyineli sunucuya sorar; o da kök sunuculardan başlayıp ilgili yetkili sunucuya kadar zinciri takip eder ve cevabı size döner. Google'ın 8.8.8.8'i ya da Cloudflare'in 1.1.1.1'i tipik özyineli çözümleyicilerdir.

Bir yetkili DNS sunucusu kurarken özyinelemeyi mutlaka kapatmanız gerekir. Aksi hâlde sunucunuz internetteki herkese açık bir açık çözümleyici (open resolver) hâline gelir ve DNS amplifikasyon saldırılarında bir silah olarak kullanılabilir. Bu rehberdeki hedefimiz sadece kendi alan adlarımıza cevap veren, dışarıdan gelen özyineli sorgulara kapalı bir yetkili sunucudur.

BIND9 Kurulumu#

BIND9 tüm büyük Linux dağıtımlarının depolarında hazır olarak bulunur. Debian ve Ubuntu tarafında paket bind9, RHEL ailesinde (Rocky, AlmaLinux, CentOS) ise bind adıyla gelir.

Debian veya Ubuntu bir sunucuda kurulum şu şekildedir:

# Paket listesini güncelle ve BIND'i kur
sudo apt update
sudo apt install -y bind9 bind9utils bind9-doc

# Servisin durumunu kontrol et
sudo systemctl status named

RHEL tabanlı bir dağıtımda ise:

sudo dnf install -y bind bind-utils
sudo systemctl enable --now named

Kurulumdan sonra ana yapılandırma dosyalarının yerini bilmek işinizi çok kolaylaştırır. Debian/Ubuntu'da yapılandırma /etc/bind/ altında modüler dosyalara bölünmüştür, RHEL ailesinde ise çoğunlukla tek bir /etc/named.conf kullanılır.

Bu rehberin geri kalanında Debian/Ubuntu yerleşimini örnek alacağım; RHEL kullanıyorsanız yolları yukarıdaki tabloya göre uyarlamanız yeterli olacaktır.

named.conf ve Genel Seçeneklerin Yapılandırılması#

İlk iş, sunucumuzu yetkili moda almak ve özyinelemeyi kapatmak. named.conf.options dosyasını açıp seçenekleri şu şekilde düzenleyelim:

sudo nano /etc/bind/named.conf.options

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

    // Bu bir yetkili sunucu; özyinelemeyi kapatıyoruz
    recursion no;
    allow-recursion { none; };

    // Bölge transferini yalnızca ikincil sunucuya izinli kıl
    allow-transfer { none; };

    // Hangi IP'lerde dinlensin
    listen-on { any; };
    listen-on-v6 { any; };

    // Sürüm bilgisini gizle (bilgi sızıntısını azaltır)
    version "not disclosed";

    dnssec-validation auto;
};

Buradaki recursion no; ve allow-recursion { none; }; satırları, bir önceki bölümde bahsettiğimiz açık çözümleyici riskini ortadan kaldırır. allow-transfer { none; }; ise bölge dosyanızın tamamını izinsiz kişilerin çekmesini engeller; ikincil (slave) bir sunucunuz olduğunda buraya yalnızca onun IP'sini yazarsınız.

Şimdi kendi bölgemizi tanımlayacağımız yere geçelim. named.conf.local dosyasına alan adımızı ve onun bölge dosyasının yolunu ekliyoruz:

sudo nano /etc/bind/named.conf.local

zone "ornek.com" {
    type master;
    file "/etc/bind/zones/db.ornek.com";
};

Burada type master; bu sunucunun ornek.com için birincil yetkili sunucu olduğunu, file satırı da kayıtların tutulacağı bölge dosyasının yolunu belirtir. Bölge dosyalarını düzenli tutmak için ayrı bir dizin oluşturmak iyi bir alışkanlıktır:

sudo mkdir -p /etc/bind/zones

Bölge (Zone) Dosyası ve SOA Seri Numarası#

Bölge dosyası, alan adınıza ait tüm DNS kayıtlarının yaşadığı yerdir. Yapısı ilk bakışta kalabalık görünse de mantığı oturunca çok nettir. Örnek bir db.ornek.com dosyası oluşturalım:

sudo nano /etc/bind/zones/db.ornek.com

$TTL    86400
@       IN      SOA     ns1.ornek.com. hostmaster.ornek.com. (
                        2026071001      ; Serial (seri numarası)
                        3600            ; Refresh (yenileme)
                        1800            ; Retry (yeniden deneme)
                        1209600         ; Expire (geçerlilik)
                        86400 )         ; Negative Cache TTL

; Alan adının isim sunucuları
@       IN      NS      ns1.ornek.com.
@       IN      NS      ns2.ornek.com.

; İsim sunucularının IP adresleri
ns1     IN      A       203.0.113.10
ns2     IN      A       203.0.113.11

; Ana alan adı ve www
@       IN      A       203.0.113.20
www     IN      A       203.0.113.20

; E-posta yönlendirmesi
@       IN      MX  10  mail.ornek.com.
mail    IN      A       203.0.113.30

Dosyanın en kritik parçası SOA (Start of Authority) kaydıdır. İlk satırdaki hostmaster.ornek.com. aslında [email protected] e-posta adresidir; DNS söz diziminde @ yerine nokta kullanılır. Parantez içindeki değerler ikincil sunucuların bölgeyi ne sıklıkta senkronize edeceğini belirler.

Bu değerlerin içinde en çok dikkat gerektireni seri numarasıdır (serial). İkincil sunucular birincil sunucudaki seri numarasına bakarak bölgenin güncellenip güncellenmediğini anlar. Yaygın ve okunaklı bir kural, YYYYMMDDnn biçimini kullanmaktır; yani 2026071001 değeri "10 Temmuz 2026 tarihinin ilk düzenlemesi" anlamına gelir. Bölge dosyasında her değişiklik yaptığınızda seri numarasını mutlaka artırmalısınız. Bunu unutursanız ikincil sunucular değişikliği görmez ve dünyanın bir yarısı eski kayıtları, diğer yarısı yeni kayıtları görmeye başlar.

Bir de dosyadaki noktaya dikkat edin. ns1.ornek.com. gibi sonu noktayla biten adlar tam nitelikli (FQDN) kabul edilir. Sonundaki noktayı unutursanız BIND, bölgenin adını sona ekler ve ns1.ornek.com.ornek.com. gibi bozuk bir kayıt oluşur. Bu, yeni başlayanların en sık düştüğü tuzaktır.

A, MX, NS ve CNAME Kayıt Türleri#

Bölge dosyasındaki her satır bir kayıttır ve her kaydın türü ayrı bir işe yarar. En sık kullanacağınız türleri kısaca gözden geçirelim.

A kaydı bir adı IPv4 adresine bağlar. Yukarıdaki dosyada www IN A 203.0.113.20 satırı www.ornek.com isteklerini o IP'ye yönlendirir. IPv6 kullanıyorsanız aynı işi AAAA kaydı yapar.

NS kaydı alan adının yetkili isim sunucularını belirtir. Bu kayıtlar hem bölge dosyanızda hem de alan adınızı yönettiğiniz kayıt kuruluşunun (registrar) panelinde tutarlı olmalıdır. Registrar tarafında nameserver'ları değiştirme sürecini adım adım görmek isterseniz nameserver değiştirme rehberi tam da bunu anlatıyor.

MX kaydı e-postaların hangi sunucuya teslim edileceğini söyler. Baştaki sayı (10) önceliktir; küçük sayı daha yüksek önceliğe sahiptir. Bir MX kaydının işaret ettiği ad her zaman bir A kaydına çözümlenmeli, asla bir CNAME'e işaret etmemelidir.

CNAME kaydı bir adı başka bir ada takma ad olarak bağlar. Örneğin bir CDN kullanıyorsanız:

blog    IN      CNAME   www.ornek.com.
shop    IN      CNAME   magaza.harici-servis.com.

CNAME için altın kural şudur; aynı ad üzerinde CNAME ile başka bir kayıt (A, MX, TXT) bir arada bulunamaz ve alan adının kökünde (@) CNAME kullanılamaz. Kök için takma ad davranışı istiyorsanız sağlayıcıya özgü ALIAS/ANAME kayıtlarına ya da doğrudan A kaydına yönelmelisiniz.

named-checkzone ile Doğrulama ve Servisin Başlatılması#

BIND'in en sevdiğim yanı, yapılandırmayı canlıya almadan önce sözdizimini denetleyebilmenizdir. named-checkconf genel yapılandırmayı, named-checkzone ise tek bir bölge dosyasını denetler. Servisi yeniden başlatmadan önce bu iki komutu çalıştırma alışkanlığı, çökmüş bir DNS'le uğraştığınız gecelerden sizi kurtarır.

# Genel yapılandırmayı denetle (çıktı yoksa sorun yok)
sudo named-checkconf

# Bölge dosyasını denetle
sudo named-checkzone ornek.com /etc/bind/zones/db.ornek.com

İkinci komut başarılıysa şuna benzer bir çıktı görürsünüz:

zone ornek.com/IN: loaded serial 2026071001
OK

loaded serial satırının seri numaranızla eşleştiğini görmek, dosyanın gerçekten yüklendiğinin en somut kanıtıdır. Bir hata varsa komut size tam olarak hangi satırda ve ne tür bir problem olduğunu söyler; örneğin unuttuğunuz bir noktayı ya da yanlış yazılmış bir kaydı anında yakalar.

Doğrulama temizse servisi yeniden yükleyebiliriz:

sudo systemctl reload named
sudo systemctl status named --no-pager

Bir de sunucunuzun güvenlik duvarında 53 numaralı portu hem UDP hem TCP için açmayı unutmayın; DNS sorguları genelde UDP kullanır ama büyük cevaplar ve bölge transferleri TCP'ye düşer.

# UFW kullanıyorsanız
sudo ufw allow 53/tcp
sudo ufw allow 53/udp

# firewalld kullanıyorsanız
sudo firewall-cmd --permanent --add-service=dns
sudo firewall-cmd --reload

dig ile Test ve Güvenlik Notları#

Sunucu ayakta; şimdi gerçekten doğru cevaplar verdiğini dig ile kanıtlayalım. dig, DNS sorgularının İsviçre çakısıdır ve bind9utils / bind-utils paketiyle birlikte gelir. Sorguyu doğrudan kendi sunucumuza yönlendirmek için @ işaretini kullanıyoruz:

# Kendi sunucumuzdan A kaydını sorgula
dig @203.0.113.10 www.ornek.com A +short

# MX kayıtlarını sorgula
dig @203.0.113.10 ornek.com MX

# Yetkili cevabın "aa" bayrağını taşıdığını doğrula
dig @203.0.113.10 ornek.com SOA +noall +comments

İlk komut 203.0.113.20 döndürüyorsa A kaydınız çalışıyor demektir. SOA sorgusunun cevabında flags satırında aa (authoritative answer) bayrağını görmelisiniz; bu, sunucunuzun bu bölge için gerçekten yetkili konuştuğunun işaretidir.

Güvenlik tarafında birkaç noktayı asla atlamayın. Birincisi, özyinelemenin kapalı olduğunu dışarıdan test edin. Kendi alan adınız dışında bir alanı sorgulayınca sunucu cevap vermemeli, yalnızca yetkisiz olduğunu belirtmelidir:

# Bu sorgu REFUSED dönmeli; cevap verirse açık çözümleyicisiniz demektir
dig @203.0.113.10 google.com A

Cevapta status: REFUSED görüyorsanız harika; sunucunuz açık çözümleyici değil. İkincisi, bölge transferlerini kısıtlı tuttuğunuzdan emin olun; allow-transfer { none; }; ayarı bir yabancının tüm kayıt listenizi çekmesini engeller. Üçüncüsü, sunucu üzerinde çalışan diğer servisleri (web, veritabanı) DNS'ten ayrı düşünün; kritik bir altyapı olan DNS'i tercihen ayrı bir VDS sunucu üzerinde çalıştırmak, bir servisteki sorunun diğerini etkilemesini önler. DNS altyapınızın önüne bir DDoS koruma katmanı koymak da amplifikasyon ve sel saldırılarına karşı ek bir kalkan sağlar.

Son olarak; kendi BIND sunucunuzu işletmek size tam kontrol verir ama aynı zamanda 7/24 sorumluluk demektir. İki ayrı ağda konumlanmış en az iki nameserver (ns1 ve ns2) çalıştırmak, düzenli yedek almak ve seri numarası disiplinini korumak bu işin olmazsa olmazlarıdır. Yönetim yükünü üstlenmek istemiyorsanız yönetilen bir çözüm çoğu senaryoda daha huzurludur.

Sıkça Sorulan Sorular#

BIND kurmak için mutlaka iki sunucu mu gerekiyor?#

Teknik olarak tek bir yetkili sunucuyla da çalışabilirsiniz, ancak bu ciddi bir risktir. RFC'ler ve pratik gelenek, bir alan adı için en az iki bağımsız isim sunucusu (ns1 ve ns2) bulundurmayı önerir. Tek sunucu çöktüğünde ya da bakıma girdiğinde alan adınız tamamen erişilmez hâle gelir; e-postalar teslim edilemez ve siteniz açılmaz. İdeali, birincil (master) ve ikincil (slave) sunucularınızı farklı fiziksel konumlarda veya en azından farklı ağlarda barındırmaktır.

Bölge dosyasını değiştirdim ama değişiklik yansımıyor, sorun ne olabilir?#

En sık sebep, SOA kaydındaki seri numarasını artırmayı unutmanızdır. İkincil sunucular yalnızca seri numarası büyüdüğünde bölgeyi yeniden çeker, aynı kalırsa değişikliği görmezler. Önce seri numarasını artırdığınızdan, ardından sudo named-checkzone ile dosyayı doğrulayıp sudo systemctl reload named çalıştırdığınızdan emin olun. İkinci sık sebep ise DNS önbelleğidir; kaydın TTL süresi dolana kadar çözümleyiciler eski değeri tutabilir, bu yüzden dig ile doğrudan kendi yetkili sunucunuza sorarak değişikliği anında test edin.

recursion no ayarı neden bu kadar önemli?#

Çünkü özyinelemesi açık ve internete kapısı açık bir DNS sunucusu, açık çözümleyici (open resolver) hâline gelir ve DNS amplifikasyon saldırılarında saldırganların işini görür. Saldırgan küçük bir sorguyu sizin sunucunuz üzerinden kurbanına devasa bir cevaba dönüştürerek onu boğar; bu süreçte sizin sunucunuzun IP'si de kötü listelere düşebilir. Yetkili bir sunucunun özyinelemeye ihtiyacı yoktur, çünkü görevi yalnızca kendi bölgelerine cevap vermektir. Bu nedenle recursion no; ve allow-recursion { none; }; ayarları bir tercih değil, zorunluluktur.

CNAME ile A kaydını aynı ad için birlikte kullanabilir miyim?#

Hayır, bu DNS standartlarına aykırıdır ve BIND büyük olasılıkla bölgeyi yüklemeyi reddeder. Bir ad üzerinde CNAME varsa, o ad için başka hiçbir kayıt türü (A, MX, TXT dahil) bulunamaz. Ayrıca alan adının kökünde, yani @ üzerinde CNAME kullanamazsınız çünkü kökte zaten SOA ve NS kayıtları vardır. Kök alan adını bir CDN veya harici servise yönlendirmek istiyorsanız ya doğrudan A kaydı kullanın ya da sağlayıcınızın sunduğu ALIAS/ANAME türü özel bir kayda başvurun.

Kendi BIND sunucumu kurmak yerine hazır bir DNS hizmeti kullanmalı mıyım?#

Bu tamamen kaynaklarınıza ve ihtiyacınıza bağlı bir karardır. Kendi BIND sunucunuz size mutlak kontrol, DNSSEC üzerinde tam yetki ve öğrenme fırsatı sunar; birçok alan adını yöneten hosting sağlayıcıları veya ileri düzey kurumsal ihtiyaçlar için mantıklıdır. Ancak yönetimi 7/24 dikkat, güncelleme takibi, güvenlik sıkılaştırması ve yedeklilik gerektirir. Yalnızca birkaç alan adınız varsa ve operasyonel yükle uğraşmak istemiyorsanız, çoğu hosting ve alan adı paketiyle gelen yönetilen DNS panelleri fazlasıyla yeterli ve çok daha risksizdir.

dig komutunda "aa" bayrağını görmüyorsam ne yapmalıyım?#

aa yani authoritative answer bayrağının olmaması, sorguladığınız sunucunun o bölge için yetkili olmadığını gösterir. Önce dig @sunucu_ip alan_adi SOA sorgusunu doğrudan kendi sunucunuza yönelttiğinizden emin olun; başka bir çözümleyiciye sorarsanız zaten aa göremezsiniz. Ardından named.conf.local içinde bölge tanımının doğru olduğunu ve named-checkzone çıktısında bölgenin sorunsuz yüklendiğini kontrol edin. Bölge dosyası bir hata yüzünden yüklenememişse BIND o bölge için yetkili cevap veremez; sudo systemctl status named ve /var/log/syslog günlükleri size nedenini söyleyecektir.

Kapanış#

Buraya kadar geldiyseniz artık kendi yetkili DNS sunucunuzu ayağa kaldırmanın tüm parçalarına sahipsiniz; yetkili ile özyineli rolü ayırt etmeyi, BIND9'u kurmayı, named.conf ve bölge dosyasını yazmayı, SOA seri numarasını disiplinli yönetmeyi ve named-checkzone ile dig ikilisiyle her şeyi doğrulamayı öğrendiniz. En büyük tavsiyem, her değişiklikten önce doğrulama, her değişiklikten sonra seri numarasını artırma alışkanlığını kaslarınıza yerleştirmeniz; DNS'te sorunların büyük çoğunluğu bu iki basit disiplinle en baştan önlenir.

DNS altyapınızı sağlam bir zeminde çalıştırmak istiyorsanız Clou.TR'nin yüksek performanslı VDS sunucu ve sanal sunucu seçenekleri BIND için ideal bir ev sunar; yönetim yükünü paylaşmak isterseniz sunucu yönetimi hizmetimiz sıkılaştırma ve izlemeyi üstlenir. Yeni bir alan adı almak, mevcut bir alanı taşımak veya barındırma ihtiyaçlarınız için de alan adı ve hosting sayfalarımıza göz atabilir; kritik altyapınızı DDoS koruma katmanıyla güvenceye alabilirsiniz. Aklınıza takılan her şey için destek ekibimiz yanınızda.