DNS Zone Dosyası Nedir

Bir alan adının internette nasıl davranacağını belirleyen bütün kurallar tek bir yerde toplanır ve o yerin adı zone dosyasıdır. Web sitenizin hangi sunucuda barındığını, e-postalarınızın nereye teslim edileceğini, alan adınızı hangi nameserver'ların temsil ettiğini ve doğrulama için hangi metinleri yayınladığınızı; hepsini bu düz metin dosyasının satırları söyler. Bir DNS panelinde "A kaydı ekle" ya da "MX kaydını değiştir" dediğinizde arka planda değişen şey, aslında bu dosyadır. Panel sadece o dosyayı sizin adınıza düzenleyen bir arayüzdür.

Bu rehberde zone dosyasının içine bakacağız. Bir bölgenin (zone) tüm kayıtlarının nasıl tek bir metin dosyasında saklandığını, $TTL ve $ORIGIN gibi direktiflerin ne işe yaradığını, SOA kaydının neden zone'un kalbi sayıldığını ve bir kayıt satırının hangi alanlardan oluştuğunu tek tek göreceğiz. Ardından BIND için gerçekçi ve eksiksiz bir örnek zone dosyası inceleyip, bu dosyayı komut satırından doğrulamayı, servise yeniden yüklemeyi ve bir sunucudan diğerine taşırken export/import etmeyi ele alacağız. Amaç, bir panelin arkasındaki ham dosyayı gördüğünüzde onu rahatça okuyup düzenleyebilecek seviyeye gelmenizdir.

Zone Dosyası Nedir ve Neyi Barındırır?#

DNS terminolojisinde bir zone (bölge), tek bir yönetim otoritesi altındaki alan adının ve onun altındaki kayıtların tamamıdır. ornek.com bir zone'dur; bu zone'un içinde kök alan adının A kaydı, www alt alan adı, e-posta için MX kayıtları, güvenlik için TXT kayıtları ve yönetimsel SOA/NS kayıtları birlikte yaşar. Bu bölgenin tüm kayıtlarını disk üzerinde tutan düz metin dosyasına ise zone dosyası (ya da zone file / bölge dosyası) denir. BIND, PowerDNS, NSD gibi yetkili nameserver yazılımları açılışta bu dosyayı okur ve içindeki kayıtları belleğe alarak gelen sorguları yanıtlar.

Zone dosyasının en önemli özelliği, bir alan adının tüm gerçeğini tek bir yerde toplamasıdır. Web sitenizin IP'sini, posta sunucunuzu, alt alan adlarınızı ve doğrulama kayıtlarınızı ayrı ayrı yerlerde değil, sıralı ve okunabilir satırlar halinde aynı dosyada görürsünüz. Bu yüzden bir DNS sorununu teşhis ederken zone dosyasını okuyabilmek büyük avantajdır; panelin sadeleştirilmiş kutucuklarının gizlediği ayrıntıları (TTL, SOA serial, satır sırası) ham dosyada net biçimde görürsünüz. DNS'in genel çalışma mantığına ve çözümleme sürecine bütünsel bakmak isterseniz DNS nedir rehberimiz sağlam bir zemin sunar; bu yazı ise doğrudan dosyanın kendisine odaklanıyor.

Zone Dosyasının Anatomisi: Direktifler ve Kayıtlar#

Bir zone dosyası iki tür satırdan oluşur: direktifler ve kaynak kayıtları (resource records). Direktifler $ işaretiyle başlar ve bir kayıt değil, dosyanın nasıl yorumlanacağını söyleyen ayarlardır. Kaynak kayıtları ise gerçek DNS verisini taşıyan satırlardır (A, MX, TXT ve benzeri). Ayrıca noktalı virgülle (;) başlayan satırlar yorumdur ve nameserver tarafından tamamen görmezden gelinir; bunları dosyayı okuyan insanlar için not düşmek amacıyla kullanırsınız.

En sık karşılaşacağınız iki direktif $TTL ve $ORIGIN'dir:

• $TTL — Dosyadaki kayıtlar için varsayılan Time To Live değerini saniye cinsinden belirler. Bir kayıt satırı kendi TTL'ini açıkça yazmazsa, bu varsayılan değer geçerli olur. RFC 1035 sonrası standartta $TTL direktifi dosyanın en üstünde beklenir; yoksa modern BIND uyarı verir.
• $ORIGIN — Tam nitelikli olmayan (sonu nokta ile bitmeyen) adların sonuna eklenecek alan adını belirler. $ORIGIN ornek.com. tanımlandığında dosyada geçen www adı otomatik olarak www.ornek.com. haline gelir. $ORIGIN yazılmazsa, zone'un adı (BIND yapılandırmasında tanımlanan ad) origin olarak kullanılır.

TTL kavramının kendisi ve neden bu kadar önemli olduğu başlı başına bir konudur; süreyi doğru seçmek propagasyon ve önbellekleme davranışını belirler. Bu konuda derinleşmek isterseniz TTL nedir rehberimize göz atabilirsiniz.

; Dosyanın başındaki direktifler
$TTL 3600
$ORIGIN ornek.com.

; Bu satırdan sonra 'www' yazmak 'www.ornek.com.' anlamına gelir

Bir de sıkça kafa karıştıran sondaki nokta kuralı vardır. Bir adın sonunda nokta varsa (mail.ornek.com.), bu ad tam nitelikli (FQDN) kabul edilir ve olduğu gibi kullanılır. Nokta yoksa (mail), nameserver adın sonuna $ORIGIN değerini ekler. Bu tek karakterlik fark, zone dosyalarındaki en yaygın hataların kaynağıdır: hedefin sonuna nokta koymayı unutmak, mail.ornek.com yerine mail.ornek.com.ornek.com gibi anlamsız bir adın oluşmasına yol açar.

SOA Kaydı: Zone'un Kalbi#

Her zone dosyası tam olarak bir SOA (Start of Authority) kaydıyla başlar. SOA, o bölgenin "kimlik kartıdır": zone'un birincil nameserver'ını, yöneticinin e-posta adresini ve ikincil sunucularla senkronizasyonu yöneten zamanlama değerlerini taşır. Bir zone dosyasında SOA yoksa ya da birden fazla varsa, nameserver dosyayı geçersiz sayar ve zone yüklenmez.

@   IN  SOA   ns1.clou.tr. hostmaster.ornek.com. (
              2026071001  ; serial  (seri numarası)
              7200        ; refresh (yenileme aralığı)
              3600        ; retry   (yeniden deneme)
              1209600     ; expire  (geçerlilik süresi)
              3600 )      ; minimum (negatif önbellek TTL'i)

Buradaki alanların anlamı, günlük yönetimde işinize yarayacak kadar önemli olduğundan tek tek bakalım:

Bu değerlerden pratikte en çok ilgileneceğiniz alan serial numarasıdır. İkincil (slave) nameserver'lar, birincilin serial'ini kendi kopyalarındakiyle karşılaştırır; birincilin serial'i daha büyükse "zone değişmiş" diye anlar ve transfer başlatır. Yaygın kural, serial'i YYYYMMDDnn biçiminde tarih tabanlı yazmaktır (yıl-ay-gün-günün kaçıncı düzenlemesi). Dosyayı elle düzenleyip serial'i artırmayı unutursanız, değişikliğiniz ikincil sunuculara hiç yansımaz; bu, "kaydı düzelttim ama hiçbir şey değişmedi" şikâyetinin gizli nedenlerinden biridir. Yönetici e-posta adresindeki ilk noktanın aslında bir @ olduğuna da dikkat edin: hostmaster.ornek.com., [email protected] demektir.

Kayıt Satırlarının Söz Dizimi#

SOA'dan sonra gelen her satır bir kaynak kaydıdır ve hepsi aynı beş alanlı iskeleti izler:

[AD]   [TTL]   [SINIF]   [TÜR]   [VERİ]

• AD (name): Kaydın hangi ada ait olduğu. @ kök alan adını (origin) temsil eder; www, mail gibi değerler alt alan adlarıdır. Boş bırakılırsa bir önceki satırın adı devam eder.
• TTL: Bu kayda özel önbellek süresi. Yazılmazsa $TTL direktifindeki varsayılan kullanılır.
• SINIF (class): İnternet kayıtları için neredeyse her zaman IN (Internet). Pratikte başka bir değer görmezsiniz.
• TÜR (type): Kaydın türü; A, AAAA, CNAME, MX, TXT, NS, SRV ve benzeri.
• VERİ (rdata): Kaydın asıl içeriği; bir IP adresi, bir hedef alan adı ya da bir metin.

Birkaç somut örnekle bakalım:

; AD    TTL    SINIF TÜR   VERİ
@       3600   IN    A     185.12.34.56
www     3600   IN    CNAME ornek.com.
mail    3600   IN    A     185.12.34.57
@       3600   IN    MX 10 mail.ornek.com.
@              IN    TXT   "v=spf1 a mx ip4:185.12.34.56 ~all"

Alanların sıralaması esnektir: TTL ile SINIF'ın yeri değişebilir, TTL yazılmayabilir. Ama tür ve veri her zaman en sonda olmalıdır. MX ve SRV gibi bazı türler, veri kısmında ek sayısal parametreler taşır: MX kaydındaki 10 bir önceliktir (sayı küçüldükçe öncelik artar), SRV kaydı ise öncelik ağırlık port hedef biçiminde dört değer içerir. TXT kayıtlarının verisi çift tırnak içine alınır ve 255 karakterden uzun metinler (uzun DKIM anahtarları gibi) parantez içinde birden fazla tırnaklı parçaya bölünür. Kayıt tiplerinin her birinin görev alanına daha geniş bir bakış için DNS kayıt tipleri rehberimiz ayrıntılı örnekler içeriyor.

BIND ile Örnek Bir Zone Dosyası#

Şimdi tüm parçaları birleştirip ornek.com için gerçekçi, eksiksiz bir zone dosyası kuralım. Bu, BIND'in /etc/bind/zones/db.ornek.com gibi bir yolda tutacağı türden tipik bir dosyadır:

$TTL 3600
$ORIGIN ornek.com.

; --- SOA: bölgenin yönetim bilgileri ---
@       IN  SOA   ns1.clou.tr. hostmaster.ornek.com. (
                  2026071001  ; serial
                  7200        ; refresh
                  3600        ; retry
                  1209600     ; expire
                  3600 )      ; minimum

; --- Yetkili nameserver'lar ---
@       IN  NS    ns1.clou.tr.
@       IN  NS    ns2.clou.tr.

; --- Kök alan adı ve www ---
@       IN  A     185.12.34.56
@       IN  AAAA  2a01:4f8:1c1c:abcd::1
www     IN  CNAME ornek.com.

; --- Alt alan adları ---
blog    IN  A     185.12.34.56
panel   IN  A     185.12.34.60
mail    IN  A     185.12.34.57

; --- E-posta yönlendirmesi ---
@       IN  MX 10 mail.ornek.com.
@       IN  MX 20 yedek-mail.ornek.com.

; --- E-posta güvenliği (SPF / DKIM / DMARC) ---
@                   IN  TXT  "v=spf1 a mx ip4:185.12.34.56 ~all"
default._domainkey  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."
_dmarc              IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

Bu dosyayı satır satır okuyabiliyorsanız aslında panelin bütün kutucuklarını da okuyabiliyorsunuz demektir. Dikkat edilecek noktalar şunlar: kök alan adı (@) doğrudan A ve AAAA ile çözülüyor çünkü kök alan adına CNAME konulamaz; www bir CNAME olarak kök alan adını takip ediyor, böylece sunucu IP'si değişirse yalnızca kök A kaydını güncellemek yeterli oluyor. MX kaydının işaret ettiği mail, bir CNAME değil gerçek bir A kaydına sahip; çünkü MX bir CNAME'e işaret edemez. ns1.clou.tr. ve _dmarc gibi tam adreslerin sonundaki noktalara ise özellikle dikkat edin: nokta olmasaydı $ORIGIN eklenir ve adlar bozulurdu.

Zone Dosyasını Doğrulama ve Yeniden Yükleme#

Ham bir zone dosyasını elle düzenlemenin en büyük riski, küçük bir sözdizimi hatasının (unutulan bir nokta, eksik bir tırnak, artırılmamış bir serial) tüm bölgeyi yüklenemez hale getirmesidir. Bu yüzden BIND, dosyayı servise vermeden önce kontrol edebileceğiniz bir doğrulama aracı sunar: named-checkzone. Bu komut, zone adını ve dosya yolunu alıp dosyanın geçerli olup olmadığını ve yüklenen serial numarasını söyler.

# Zone dosyasının söz dizimini ve tutarlılığını doğrula
named-checkzone ornek.com /etc/bind/zones/db.ornek.com

# Başarılıysa şuna benzer bir çıktı alırsınız:
# zone ornek.com/IN: loaded serial 2026071001
# OK

Doğrulama başarılıysa değişikliği servise bildirmek için BIND'i yeniden yüklersiniz. Tüm servisi yeniden başlatmak yerine rndc reload kullanmak daha zariftir; yalnızca değişen zone'ları yeniden okur ve kesintiye yol açmaz:

# Tek bir zone'u yeniden yükle (tercih edilen)
rndc reload ornek.com

# Ya da yapılandırma dosyalarını da doğrula ve tümünü yenile
named-checkconf && rndc reload

Bir alışkanlık edinin: her düzenlemede önce SOA serial'ini artırın, sonra named-checkzone ile doğrulayın, en son rndc reload yapın. Bu üç adımlı ritim, hem bozuk bir dosyanın canlıya çıkmasını hem de artırılmamış serial yüzünden ikincil sunucuların güncellenmemesini engeller. Kendi yetkili nameserver'ınızı BIND ile kurmayı baştan sona görmek isterseniz BIND DNS sunucu kurulumu rehberimiz tüm süreci anlatıyor. Bu tür kök seviye kontrolü için sunucunuzda tam yetkiye sahip olmanız gerekir; paylaşımlı hosting yerine bir VDS ya da sanal sunucu bu esnekliği verir.

Zone Dosyasını Export ve Import Etme#

Zone dosyasının düz metin olmasının en pratik faydası, bir sunucudan diğerine taşımanın son derece kolay olmasıdır. Bir alan adını yeni bir sunucuya taşırken tüm kayıtları elle yeniden yazmak yerine, mevcut zone dosyasını export edip hedef sunucuya import edebilirsiniz. cPanel ve WHM gibi paneller "BIND zone file" formatında dışa/içe aktarma seçeneği sunar; bu format, yukarıda gördüğünüz ham dosyanın ta kendisidir.

Sunucuya doğrudan erişiminiz varsa, canlı bir zone'un mevcut halini dig'in AXFR (zone transfer) ya da tam sorgu çıktısıyla dosyaya dökebilirsiniz:

# Yetkili sunucudan tüm zone'u BIND formatında al (izin varsa)
dig @ns1.clou.tr ornek.com AXFR > ornek.com.zone

# Ya da mevcut dosyayı doğrudan hedef sunucuya kopyala
scp /etc/bind/zones/db.ornek.com root@yeni-sunucu:/etc/bind/zones/

Import tarafında ise dosyayı hedef sunucuya yerleştirip BIND yapılandırmasına yeni bir zone bloğu eklersiniz. Aşağıdaki named.conf.local parçası, taşınan dosyayı hedef sunucuda tanıtır:

zone "ornek.com" {
    type master;
    file "/etc/bind/zones/db.ornek.com";
    allow-transfer { 185.12.34.99; };  // ikincil nameserver
};

Taşımadan sonra iki noktayı mutlaka kontrol edin. Birincisi, dosyadaki nameserver (NS) ve SOA satırlarının yeni sunucunuzu gösterdiğinden emin olun; eski panelden gelen dosyada hâlâ önceki sağlayıcının nameserver'ları yazıyor olabilir. İkincisi ve en kritiği: bir zone dosyası, alan adının nameserver'ları o sunucuyu işaret etmedikçe internette hiçbir işe yaramaz. Dosyayı mükemmel biçimde taşısanız bile, alan adı hâlâ eski nameserver'ları kullanıyorsa dünya kayıtları oradan sorgular. Bu geçişin domain tarafındaki adımlarını nameserver değiştirme rehberimizde adım adım anlattık. Taşıma sürecinde kesintiyi en aza indirmek istiyorsanız, işi bize bırakabileceğiniz site taşıma ve sunucu yönetimi hizmetlerimiz bu TTL ve nameserver senkronizasyonunu sizin adınıza planlar.

Zone Dosyasında Sık Yapılan Hatalar#

Ham zone dosyalarıyla çalışırken en çok zaman kaybettiren hatalar aslında birkaç başlıkta toplanır. Bunları önceden bilmek, saatlerce süren yanlış teşhisin önüne geçer.

Bu hataların çoğu, dosyayı servise vermeden önce named-checkzone çalıştırıldığında yakalanır; araç size sorunlu satır numarasını ve hatanın türünü söyler. Panel üzerinden çalışıyorsanız arayüz bu kuralların bir kısmını sizin için zorlar, ama ham dosya düzenlerken tüm sorumluluk sizdedir. Bu yüzden "düzenle, doğrula, yeniden yükle" ritmini istisnasız uygulamak, gece yarısı bozulan bir bölgeyle uğraşmaktan çok daha ucuza gelir.

Sıkça Sorulan Sorular#

Zone dosyası ile DNS kaydı arasındaki fark nedir?#

DNS kaydı, tek bir bilgi parçasıdır: örneğin www adının hangi IP'ye gittiğini söyleyen bir A kaydı. Zone dosyası ise bir alan adına ait bütün bu kayıtların toplandığı metin dosyasının tamamıdır. Yani zone dosyası bir kap, DNS kayıtları ise o kabın içindeki tek tek satırlardır. Bir panelde kayıt eklediğinizde aslında zone dosyasına yeni bir satır yazmış olursunuz; dosyanın kendisi SOA, NS ve tüm diğer kayıtları bir arada tutar.

Zone dosyasını elle düzenlemek zorunda mıyım?#

Hayır. Paylaşımlı hosting, cPanel ya da yönetilen DNS panelleri kullanıyorsanız, arayüzdeki kutucuklara veri girmeniz yeterlidir; panel zone dosyasını sizin adınıza günceller ve serial'i otomatik artırır. Ham dosyayı elle düzenlemek genellikle kendi BIND sunucunuzu yönettiğiniz, toplu değişiklik yaptığınız ya da bir zone'u başka sunucuya taşıdığınız durumlarda gerekir. Panel kullanan çoğu kullanıcı zone dosyasının varlığını bilmeden yıllarca DNS yönetir.

SOA serial numarasını neden her değişiklikte artırmam gerekiyor?#

Çünkü ikincil (slave) nameserver'lar, birincil sunucudaki zone'un değişip değişmediğini yalnızca serial numarasına bakarak anlar. Birincilin serial'i, ikincilin elindeki kopyadan büyükse "bölge güncellenmiş" diye zone transferi başlatılır. Serial'i artırmadan kayıt değiştirirseniz, birincil sunucu doğru cevabı verse bile ikincil sunucular eski kopyayı sunmaya devam eder ve değişikliğiniz bazı ziyaretçilere hiç ulaşmaz. Tarih tabanlı YYYYMMDDnn biçimi, hangi serial'in daha yeni olduğunu insan gözüyle de okunur kılar.

$ORIGIN ne işe yarar ve yazmazsam ne olur?#

$ORIGIN, dosyadaki tam nitelikli olmayan (sonu nokta ile bitmeyen) adların sonuna eklenecek alan adını belirler. $ORIGIN ornek.com. yazdığınızda dosyadaki www otomatik olarak www.ornek.com. olur; böylece her satırda uzun tam adı tekrar yazmaktan kurtulursunuz. Direktifi hiç yazmazsanız BIND, zone'un yapılandırmadaki adını origin olarak kullanır, dolayısıyla çoğu durumda dosya yine doğru çalışır. Yine de dosyanın nasıl yorumlandığını netleştirmek için başa $ORIGIN koymak iyi bir alışkanlıktır.

Zone dosyamı başka sunucuya nasıl taşırım?#

En kolay yol, mevcut zone dosyasını olduğu gibi kopyalamaktır; düz metin olduğu için scp ile taşımak ya da panelin "BIND zone file" export'unu alıp hedefte import etmek yeterlidir. Taşıdıktan sonra dosyadaki NS ve SOA satırlarının yeni sunucunuzu gösterdiğinden emin olun, named-checkzone ile doğrulayın ve BIND'i yeniden yükleyin. En kritik adım ise domain tarafındadır: alan adının nameserver'larını yeni sunucuya çevirmeden taşınan zone dosyası internette geçerli olmaz, çünkü dünya kayıtları hâlâ eski nameserver'lardan sorgular.

Zone dosyasında bir hata olursa ne olur?#

Zone dosyasında sözdizimi hatası varsa (eksik nokta, kapatılmamış tırnak, bozuk SOA gibi), BIND o bölgeyi yüklemeyi tümüyle reddeder ve alan adı çözümlenemez hale gelebilir. Bu yüzden dosyayı servise vermeden önce named-checkzone ile doğrulamak kritiktir; araç hatanın satır numarasını ve türünü söyler, böylece canlıya çıkmadan düzeltirsiniz. Panel üzerinden çalışıyorsanız arayüz çoğu hatalı girişi baştan engeller, ancak ham dosya düzenlerken doğrulama adımını asla atlamayın.

Kapanış#

Zone dosyası, ilk bakışta korkutucu görünen ama aslında son derece düzenli bir metin dosyasıdır: en üstte direktifler ($TTL, $ORIGIN), hemen ardından bölgenin kimliğini taşıyan SOA kaydı ve sonrasında aynı beş alanlı iskeleti izleyen kaynak kayıtları. Bu yapıyı bir kez kavradığınızda, hangi panelde çalışırsanız çalışın arkadaki mantığı görürsünüz; sondaki noktaya dikkat etmek, her düzenlemede SOA serial'ini artırmak ve dosyayı named-checkzone ile doğrulamak gibi birkaç alışkanlık, DNS ile ilgili sorunların büyük kısmını daha başlamadan önler.

Kendi zone dosyalarınızı ham düzeyde yönetmek, BIND kurmak ve tam DNS kontrolüne sahip olmak istiyorsanız VDS ve sanal sunucu çözümlerimizle sunucunuza kök erişim elde edebilirsiniz. Kurulum, güvenlik ve DNS yapılandırmasını uzman bir ekibe bırakmayı tercih ederseniz sunucu yönetimi hizmetimiz tüm bu ayrıntıları sizin adınıza doğru kurar. Yalnızca güvenilir bir DNS paneliyle sitenizi yayına almak istiyorsanız hosting paketlerimiz yönetimi kolay bir arayüzle gelir; alan adınızı da aynı yerden almak için domain sayfamıza göz atabilirsiniz.