DNS Bölgeleri ve Bölge Transferleri Kılavuzu

DNS çoğu zaman tek bir küresel veritabanı gibi görünür, ama perde arkasında özenle bölümlenmiş bir sistemdir. Sorumluluk bölgelere ayrılır, her bölge birkaç yetkili sunucu tarafından sunulur ve bu sunucular bölge transferi adı verilen bir mekanizmayla eşitlenir. Bu parçaları anlamak; yayılma gecikmelerini teşhis etmenize, güvenilir bir DNS yapısı seçmenize ve internetteki en yaygın bilgi sızıntılarından biri olan kısıtlanmamış bölge transferinden kaçınmanıza yardımcı olur. Bu yazıda kavramları ele alıyor ve pratik yapılandırma ile test örnekleriyle bitiriyoruz.

Bölge ve alan adı: aynı şey değil

Alan adı (domain), DNS ağacındaki bir düğüm ve onun altındaki her şeydir. example.com bir alan adıdır, shop.example.com da öyle. Bölge (zone) ise idari bir sınırdır: ad alanının tek bir birim olarak yönetilen ve tek bir yetkili ad sunucusu kümesi tarafından yayımlanan kısmı.

Çoğu zaman bir alan adı ile bölgesi aynı görünür. Küçük bir işletme example.com için tüm kayıtlarını tek bir bölge dosyasında tutabilir. Ancak ağacın bir bölümü yetkilendirildiğinde (delegation) sınırlar ayrışır. eu.example.com kendi ad sunucuları olan başka bir ekibe devredilirse, üst bölge yalnızca onlara işaret eden NS kayıtlarını (ve gerekirse glue adreslerini) tutar ve eu.example.com ayrı bir bölge hâline gelir. example.com alan adı hâlâ eu.example.com’u kapsar, ama bölge kapsamaz.

Aynı mantık en üstte de geçerlidir: kök bölge .com’u yetkilendirir, .com bölgesi example.com’u sahibinin kaydettiği ad sunucularına yetkilendirir ve bu böyle devam eder. Bir alan adını TLDix WHOIS ve RDAP sorgulama aracıyla sorguladığınızda gördüğünüz ad sunucuları tam olarak kayıt otoritesindeki bu yetkilendirmedir.

Bir bölgenin içinde neler bulunur?

Bölge, kaynak kayıtlarından oluşan bir koleksiyondur. En yaygın olanlar aşağıda listelenmiştir.

Her bölgenin kökünde tam olarak bir SOA kaydı ve en az bir, genellikle iki ya da daha fazla NS kaydı bulunur.

SOA kaydı ve seri numarası

Start of Authority (yetki başlangıcı) kaydı, bölgenin nasıl yönetileceğini tanımlar. Bir bölge dosyasında tipik bir SOA şöyle görünür:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
              2026100701 ; serial
              7200       ; refresh
              900        ; retry
              1209600    ; expire
              300 )      ; negative caching TTL

• MNAME (ns1.example.com.) birincil sunucunun adını verir.
• RNAME (hostmaster.example.com.) yöneticinin posta kutusudur; ilk nokta @ işaretinin yerini tutar.
• Serial (seri) bölgenin sürüm numarasıdır. İkincil sunucular bunu kendi kopyalarıyla karşılaştırır; birincilin seri numarası daha yüksekse bölgeyi transfer ederler.
• Refresh (yenileme), ikincillerin seri numarasını ne sıklıkla kontrol edeceğidir.
• Retry (yeniden deneme), başarısız bir kontrolden sonra yeniden denemeden önce ne kadar bekleyecekleridir.
• Expire (sona erme), bir ikincilin birincile hiç ulaşamazsa yanıt vermeye ne kadar devam edeceğidir. Bu süreden sonra eski yanıtlar vermek yerine bölgeyi sunmayı bırakır.
• Minimum günümüzde NXDOMAIN gibi negatif yanıtların TTL’si olarak kullanılır (RFC 2308).

Yaygın bir gelenek, YYYYAAGGnn biçiminde tarihe dayalı bir seri numarası kullanmaktır; örneğin 7 Ekim 2026’daki ilk değişiklik için 2026100701. Elle düzenlenen bölgelerdeki en yaygın hata seri numarasını artırmayı unutmaktır: birincil yeni veriyi sunar, ama ikinciller onu hiç çekmez; böylece kullanıcılar hangi sunucuya ulaştıklarına göre farklı yanıtlar alır. Seri numaraları sıra uzayı aritmetiği (RFC 1982) kullanır; bu yüzden bir seri numarasını düşürmeniz gerekirse, daha küçük bir sayı yazmak yerine planlı adımlarla yapmalısınız.

Birincil ve ikincil sunucular

Çoğu bölge, dayanıklılık ve performans için birkaç yetkili sunucu tarafından yayımlanır. Bunlardan biri, bölgenin düzenlendiği ya da örneğin bir veritabanından veya sağlayıcı API’sinden üretildiği birincil sunucudur (eskiden master deniyordu). Diğerleri birincilden alınan salt okunur kopyaları tutan ikincil sunuculardır (eskiden slave deniyordu).

Bir çözümleyicinin bakış açısından NS kayıtlarında listelenen tüm yetkili sunucular eşittir; herhangi birine sorabilir. Tutarlılığın önemli olmasının nedeni budur: bir ikincil geride kalırsa trafiğinizin bir kısmı eski kayıtları görür. Birçok kuruluş gizli birincil (hidden primary) kullanır; bu, genel NS kayıtlarında listelenmeyen ve yalnızca ikincilleri besleyen bir sunucudur ve saldırılara maruz kalmasını azaltır.

Farklı bir sağlayıcıdan ya da ağdan ikincil sunucular kullanmak da kesintileri atlatmanın klasik bir yoludur, çünkü bir sağlayıcıdaki arıza artık tüm bölgeyi çevrim dışı bırakmaz.

Tam transfer (AXFR) ve artımlı transfer (IXFR)

Bir ikincilin veriye ihtiyacı olduğunda TCP üzerinden bölge transferi ister.

AXFR: bölgenin tamamı

RFC 5936’da standartlaştırılan AXFR, SOA kaydıyla başlayıp yine SOA kaydıyla biterek bölgedeki her kaydı gönderir. Basit ve sağlamdır; bir ikincilin henüz kopyası yoksa her zaman kullanılır. Ancak büyük bölgelerde her küçük değişiklikten sonra tam kopyayı tekrarlamak bant genişliği ve zaman israfıdır.

IXFR: yalnızca değişenler

RFC 1995’te tanımlanan IXFR, ikincilin mevcut seri numarasını göndermesine ve yalnızca farkları, yani sürümler arasında silinen ve eklenen kayıtları almasına olanak tanır. Bunu yapabilmek için birincilin son değişikliklerin bir günlüğünü (journal) tutması gerekir. Farkları üretemezse, örneğin günlük temizlendiyse, tam bölge göndermeye geri döner.

NOTIFY: yenileme zamanlayıcısını beklemeye son

Yalnızca yenileme aralığına güvenmek, değişikliklerin ikincillere ulaşmasının saatler sürebileceği anlamına gelirdi. RFC 1996’da tanımlanan DNS NOTIFY mekanizması bu sorunu çözer. Bölge değiştiğinde birincil, ikincillerine bir NOTIFY mesajı gönderir. Her ikincil bunun üzerine SOA’yı sorgular, daha yüksek seri numarasını görür ve hemen bir IXFR ya da AXFR başlatır. Pratikte bu, ikincil güncellemelerini saniyelere indirir. Bir NOTIFY kaybolursa diye yenileme aralığı yine de bir güvenlik ağı olarak çalışır.

Bunun, insanların yayılma dediği şeyden farklı olduğunu unutmayın. Tüm yetkili sunucular eşitlendikten sonra kalan gecikme, dünya genelindeki çözümleyicilerin eski kayıtları TTL süreleri dolana kadar önbellekte tutmasından kaynaklanır.

Açık bölge transferleri neden sorundur?

Bir sunucu herkese AXFR izni veriyorsa, herkes bölgenin tüm içeriğini indirebilir. Bu; iç ana makine adlarını, test sistemlerini, VPN uç noktalarını, posta altyapısını ve adlandırma kalıplarını açığa çıkarabilir; keşif aşamasını çocuk oyuncağına çeviren bilgilerdir bunlar. Bu yanlış yapılandırma, çoğu zaman varsayılan ayarlardan ya da eski kurulumlardan kalma olarak internette hâlâ görülüyor. Kural basittir: bölgeyi yalnızca kendi ikincil sunucularınız transfer edebilmelidir.

IP tabanlı kısıtlamalar iyi bir ilk adımdır, ancak IP adresleri değişebilir ya da paylaşılabilir. TSIG bunun üzerine kimlik doğrulama ekler.

Transferleri ACL ve TSIG ile güvenceye almak

TSIG (Transaction Signature, RFC 8945), DNS mesajlarını imzalamak için paylaşılan gizli bir anahtar ve HMAC-SHA256 gibi bir HMAC algoritması kullanır. Birincil yalnızca doğru anahtarla imzalanmış transfer isteklerine yanıt verir; ikincil de verinin gerçekten birincilden geldiğini ve yolda değiştirilmediğini doğrulayabilir. TSIG bölgeyi şifrelemez; gizlilik için, desteklendiği yerlerde XoT (TLS üzerinden bölge transferi, RFC 9103) gibi daha yeni standartlar kullanılabilir.

Anahtar genellikle BIND’da tsig-keygen ile üretilir. Birincildeki yapılandırma şöyle görünebilir:

key "xfer-key" {
    algorithm hmac-sha256;
    secret "REPLACE-WITH-GENERATED-SECRET";
};

zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com.db";
    allow-transfer { key "xfer-key"; };
    also-notify { 198.51.100.20; };
    notify yes;
};

İkincilde ise:

key "xfer-key" {
    algorithm hmac-sha256;
    secret "REPLACE-WITH-GENERATED-SECRET";
};

server 192.0.2.10 { keys { "xfer-key"; }; };

zone "example.com" {
    type secondary;
    primaries { 192.0.2.10; };
    file "/var/cache/bind/example.com.db";
};

Gizli anahtarı güvenli biçimde saklayın, personel ya da sağlayıcı değiştiğinde yenileyin ve mümkün olduğunda her ikincil ilişkisi için ayrı bir anahtar kullanın. Eski BIND sürümleri primary ve secondary yerine master ve slave anahtar sözcüklerini kullanır; güncel sürümler her ikisini de kabul eder.

Bölge transferlerini dig ile test etmek

Kısıtlamaları yapılandırdıktan sonra, erişimi olmaması gereken bir makineden doğrulayın:

dig @ns1.example.com example.com AXFR

Doğru kilitlenmiş bir sunucu Transfer failed ya da REFUSED durumuyla yanıt verir. Yetkili bir ikincilden anahtarla test edin:

dig @192.0.2.10 example.com AXFR -y hmac-sha256:xfer-key:REPLACE-WITH-SECRET
dig @192.0.2.10 example.com IXFR=2026100701

Tüm yetkili sunucuların eşit olduğunu doğrulamak için seri numaralarını karşılaştırın:

dig +nssearch example.com
dig @ns2.example.com example.com SOA +short

Bir sunucu daha eski bir seri numarası bildiriyorsa NOTIFY teslimatını, TCP 53 numaralı port için güvenlik duvarı kurallarını ve her iki taraftaki günlükleri kontrol edin. Transfer testlerini yalnızca işlettiğiniz ya da test izniniz olan sunucularda yapın.

Pratik senaryo: İkinci bir DNS sağlayıcısını devreye almak

Diyelim ki bölgeniz şu anda tek bir yönetilen DNS sağlayıcısında duruyor ve kesintilere karşı ikinci bir sağlayıcıyı ikincil olarak eklemek istiyorsunuz. İlk adım, mevcut sağlayıcınızın giden bölge transferini (outbound AXFR/IXFR) ve NOTIFY’ı destekleyip desteklemediğini öğrenmektir. Destekliyorsa yeni sağlayıcıdan transfer isteklerinin geleceği IP adreslerini alın ve bunları izin listesine ekleyin; mümkünse bir TSIG anahtarı da tanımlayın. Ardından yeni sağlayıcıda bölgeyi ikincil olarak oluşturun ve ilk AXFR’nin tamamlanmasını bekleyin.

Kayıt firmanızdaki NS kayıtlarını değiştirmeden önce yeni sunucuları doğrudan sorgulayın ve seri numarasının birincille aynı olduğunu doğrulayın. Birkaç rastgele kaydı her iki tarafta karşılaştırın. Ancak her şey eşleştiğinde yeni ad sunucularını kayıt firmasındaki listeye ekleyin. DNSSEC kullanıyorsanız ikincil sağlayıcının imzalı bölgeyi olduğu gibi sunabildiğinden emin olun; aksi hâlde doğrulama yapan çözümleyiciler hata alır. Son olarak, bir değişiklik yapıp birkaç saniye içinde iki sağlayıcıda da göründüğünü kontrol ederek NOTIFY’ın çalıştığını test edin.

Bütün resmi sağlıklı tutmak

Bölgeler ve transferler, bir alan adını erişilebilir tutmanın yalnızca bir parçasıdır. Kayıt otoritesindeki yetkilendirme doğru ad sunucularına işaret etmeli, DNSSEC imzaları geçerli kalmalı (ikinciller imzalı bölgeleri sunabilir, ancak anahtarlar ve DS kaydı eşleşmelidir; bunu DNSSEC’in alan adı güvenliği için neden vazgeçilmez olduğu yazımızda açıklıyoruz) ve alan adının kendisinin süresi dolmamalıdır. Alan adlarınızı ve yenileme tarihlerini TLDix alan adı panelinde tutmak, sorunları kullanıcılardan önce fark etmenizi kolaylaştırır. Net bir SOA stratejisi, etkin NOTIFY, TSIG ile kısıtlanmış transferler ve dig ile düzenli kontrollerle DNS’iniz hem tutarlı hem de dışarıdan haritalanması çok daha zor hâle gelir.