SOA Kaydı Nedir ve Alanları

Bir alan adının DNS ayarlarını ilk kez açtığınızda karşınıza A, CNAME, MX gibi tanıdık kayıtların yanında pek de dikkat çekmeyen bir satır çıkar: SOA. Çoğu kullanıcı bu satırı görmezden gelir çünkü panel onu genellikle otomatik oluşturur ve elle düzenlemek gerekmez. Oysa SOA kaydı, o bölgenin kimlik kartıdır. Hangi sunucunun bu bölge üzerinde yetkili olduğunu, kime haber verileceğini ve bölgenin ne sıklıkla senkronize edileceğini tek başına bu kayıt belirler. Yani görünürde sessiz duran bu satır, aslında tüm bölgenin yönetim kurallarını taşır.

Bu rehberde SOA kaydının ne olduğunu, hangi alanlardan oluştuğunu ve her alanın pratikte neyi kontrol ettiğini adım adım açıklayacağız. Serial numarasının neden her değişiklikte artırılması gerektiğini, refresh ve retry değerlerinin ikincil sunucuları nasıl etkilediğini ve yanlış ayarların hangi somut sorunlara yol açtığını gerçek örneklerle göstereceğiz. Kıdemli bir sistem yöneticisinin masasına oturup ekranı birlikte incelediğinizi düşünün; amacımız tam olarak bu netlikte bir anlayış kazandırmak.

SOA Kaydı Nedir ve Neden Her Bölgede Bulunur#

SOA, "Start of Authority" yani "Yetki Başlangıcı" ifadesinin kısaltmasıdır. Bir DNS bölgesi (zone) oluşturulduğunda, o bölgenin ilk ve zorunlu kaydı SOA'dır. RFC 1035'ten bu yana geçerli olan DNS standartları, geçerli bir bölgenin en az bir SOA ve bir NS kaydına sahip olmasını şart koşar. SOA kaydı olmayan bir bölge teknik olarak geçersizdir ve pek çok DNS sunucusu böyle bir bölgeyi hiç yüklemez.

Bu kaydın "yetki başlangıcı" olarak adlandırılmasının sebebi, o alan adı için otoritenin nereden başladığını ilan etmesidir. Bir çözümleyici (resolver) alan-adiniz.com için soru sorduğunda, hangi sunucunun bu bölge hakkında kesin bilgiye sahip olduğunu SOA kaydından öğrenir. Kaydın içindeki bilgiler hem birincil (primary/master) sunucu ile ikincil (secondary/slave) sunucular arasındaki senkronizasyonu düzenler hem de negatif yanıtların (var olmayan bir kaydın) ne kadar süre önbellekte tutulacağını belirler.

DNS'in genel çalışma mantığını hatırlamak isterseniz DNS nedir yazımız iyi bir başlangıç noktasıdır. SOA kaydı bu büyük sistemin, tek bir bölge ölçeğindeki yönetim çekirdeğidir. Aşağıda tipik bir SOA kaydının BIND söz dizimindeki görünümünü inceleyelim:

$TTL 3600
@   IN  SOA  ns1.clou.tr. hostmaster.clou.tr. (
                2026071001  ; Serial
                7200        ; Refresh
                1800        ; Retry
                1209600     ; Expire
                3600 )      ; Minimum TTL

Parantez içindeki beş sayı SOA kaydının kalbidir. Bu satırların her biri, bölgenin nasıl yönetileceğini belirleyen bir kuralı temsil eder ve rehberin geri kalanında bunları tek tek açacağız.

SOA Kaydının İki Başlangıç Alanı MNAME ve RNAME#

Serial ve zamanlama değerlerine geçmeden önce, kaydın ilk iki alanına bakmak gerekir çünkü onlar sayısal değil metinseldir ve sık sık karıştırılır.

MNAME (Primary Name Server) alanı, bu bölge için yetkili birincil ad sunucusunun tam adıdır. Yukarıdaki örnekte ns1.clou.tr. bu görevi üstlenir. Bu alan, bölge üzerinde değişiklik yapma yetkisine sahip ana sunucuyu işaret eder. Dinamik DNS güncellemeleri veya bazı senkronizasyon mekanizmaları bu alanı referans alır, bu yüzden yanlış bir MNAME değeri sessizce arka planda sorunlara yol açabilir.

RNAME (Responsible Name) alanı ise bölgeden sorumlu kişinin e-posta adresidir, ancak DNS formatında yazılır. Burada önemli bir ayrıntı vardır: e-posta adresindeki @ işareti bir nokta ile değiştirilir. Yani [email protected] adresi SOA kaydında hostmaster.clou.tr. biçiminde görünür. Eğer kullanıcı adı bölümünde nokta varsa (örneğin [email protected]), o nokta ters eğik çizgi ile kaçış karakterine alınır ve ad\.soyad.clou.tr. şeklinde yazılır. Bu ayrıntıyı bilmeyen yöneticiler zaman zaman geçersiz bir e-posta biçimi yüzünden bölge dosyasının yüklenmemesiyle karşılaşır.

Aşağıdaki tablo bu iki alanı özetler:

Bu iki alan doğruysa, kaydın geri kalanı tamamen sayısal zamanlama değerlerinden oluşur.

Serial Numarası ve Neden Her Değişiklikte Artırılmalı#

Serial, SOA kaydının en kritik ve en çok hata yapılan alanıdır. Bir bölgenin sürüm numarası gibi düşünebilirsiniz. İkincil sunucular, birincil sunucudaki bölgenin güncellenip güncellenmediğini yalnızca bu numaraya bakarak anlar. Mantık son derece basittir: ikincil sunucu birincil sunucudaki serial numarasını kendi sakladığı numarayla karşılaştırır. Birincil sunucudaki numara daha büyükse, bölge değişmiş demektir ve ikincil sunucu güncel kopyayı ister. Numara aynı veya daha küçükse, ikincil sunucu hiçbir şey yapmaz.

İşte tam bu yüzden bölgede her değişiklik yaptığınızda serial numarasını artırmanız gerekir. Yeni bir A kaydı eklediniz ama serial'i artırmayı unuttunuz diyelim; ikincil sunucular numarayı değişmemiş görür ve eski, hatalı kayıtları sunmaya devam eder. Sonuç olarak bazı ziyaretçiler yeni sunucunuza, bazıları eski adrese yönlenir ve saatlerce süren, tespiti zor bir tutarsızlık yaşarsınız.

Endüstride en yaygın yöntem tarih tabanlı serial biçimidir: YYYYMMDDNN. Burada yıl, ay, gün ve o gün içindeki değişiklik sayacı yer alır. Örneğin 10 Temmuz 2026 tarihindeki ilk değişiklik 2026071001, aynı günkü ikinci değişiklik 2026071002 olur.

# Bölge değişikliğinden sonra serial'i artırmayı unutmayın
# Dün:      2026070903
# Bugün ilk değişiklik:
2026071001
# Bugün ikinci değişiklik:
2026071002

Serial ile ilgili kritik bir kural daha vardır: numara asla küçültülmemelidir. DNS serial değeri 32 bitlik işaretsiz bir tam sayıdır ve sarma (wrap-around) aritmetiği kullanır. Yanlışlıkla çok büyük bir sayı girip sonra geri düşürmeye çalışırsanız, ikincil sunucular yeni değeri "daha eski" sayabilir ve bölgeyi hiç güncellemez. Böyle bir durumdan çıkmanın standart yolu, RFC 1982'de tanımlanan yöntemle numarayı önce maksimuma yakın bir değere taşıyıp senkronizasyonu bekledikten sonra istediğiniz düşük değere geçmektir. Bu yüzden en güvenli yaklaşım, her zaman monoton biçimde artan bir serial kullanmaktır.

Refresh ve Retry İkincil Sunucuları Nasıl Yönetir#

SOA kaydındaki refresh ve retry değerleri, ikincil sunucuların birincil sunucuyu ne sıklıkla kontrol edeceğini belirler. Her iki değer de saniye cinsindendir.

Refresh, ikincil sunucunun birincil sunucudaki serial numarasını ne kadar sürede bir sorgulayacağını söyler. Örnekteki 7200 değeri iki saat demektir; yani ikincil sunucu her iki saatte bir "bölge güncellendi mi?" diye sorar. Bu değer çok yüksekse, yaptığınız değişiklikler ikincil sunuculara yavaş yansır. Çok düşükse birincil sunucu gereksiz sorgu trafiğiyle yorulur. Modern kurulumların çoğu, birincil sunucu değişiklik anında ikincil sunuculara NOTIFY mesajı gönderdiği için refresh değerine daha az bağımlıdır; ancak NOTIFY kaybolursa refresh yine de güvenlik ağı olarak devreye girer.

Retry, ikincil sunucu birincil sunucuya ulaşamadığında ne kadar bekleyip yeniden deneyeceğini belirtir. Örnekteki 1800 değeri otuz dakikadır. Refresh zamanı geldi ama birincil sunucu yanıt vermedi diyelim; ikincil sunucu bir sonraki refresh süresini beklemez, bunun yerine retry süresi kadar bekleyip tekrar dener. Bu yüzden retry değeri neredeyse her zaman refresh değerinden küçük olmalıdır. Aksi halde geçici bir kesinti sonrası senkronizasyon gereksiz yere gecikir.

Aşağıdaki tablo bu iki değeri karşılaştırır:

Pratikte bu ikilinin dengesini kurmak, hem senkronizasyon gecikmesini hem de sunucu yükünü optimize etmenin anahtarıdır. Küçük ve orta ölçekli bölgeler için 3600 saniye refresh ile 900 saniye retry oldukça makul bir başlangıçtır.

Expire ve Minimum TTL Değerlerinin Rolü#

SOA kaydının son iki sayısal alanı, uç durumları ve önbellek davranışını yönetir.

Expire, ikincil sunucunun birincil sunucuyla hiç iletişim kuramaması durumunda bölge verisini ne kadar süre "geçerli" sayacağını belirler. Örnekteki 1209600 değeri on dört gündür. Diyelim ki birincil sunucunuz çöktü ve iki hafta boyunca hiç ulaşılamadı; bu süre dolduğunda ikincil sunucu elindeki verinin artık güvenilmez olduğuna karar verir ve o bölge için yanıt vermeyi bırakır. Bu, eski ve muhtemelen yanlış verinin sonsuza kadar sunulmasını engelleyen bir güvenlik mekanizmasıdır. Expire değeri her zaman refresh ve retry değerlerinden çok daha büyük olmalıdır; genellikle bir ila dört hafta arası tercih edilir.

Minimum TTL, tarihsel olarak bölge kayıtları için varsayılan yaşam süresi anlamına geliyordu. Ancak RFC 2308'den bu yana bu alanın anlamı değişmiştir ve artık esas olarak "negatif önbellekleme süresi" olarak kullanılır. Yani bir çözümleyici var olmayan bir kayıt sorguladığında (NXDOMAIN yanıtı aldığında), bu olumsuz sonucu ne kadar süre önbellekte tutacağını bu değer belirler. Örnekteki 3600 değeri, sorgulanan bir alt alan adı yoksa bu "yok" bilgisinin bir saat boyunca önbelleklenmesi demektir.

Bu ayrımın pratik bir sonucu vardır. Minimum TTL değerini çok yüksek ayarlarsanız ve yeni bir alt alan adı (örneğin blog.alan-adiniz.com) eklerseniz, daha önce o adı sorgulamış ve "yok" yanıtı almış çözümleyiciler yeni kaydı fark etmeden önce uzun süre beklemek zorunda kalır. Yeni kayıtları sık ekleyen ortamlarda bu değeri makul tutmak faydalıdır.

; Negatif önbellekleme etkisini gösteren senaryo
; Minimum TTL = 3600 iken:
; 1) kullanici blog.alan-adiniz.com sorguladi -> NXDOMAIN
; 2) bu "yok" yaniti 1 saat onbellekte tutulur
; 3) siz 5 dakika sonra blog kaydini eklediniz
; 4) ayni cozumleyici 1 saat boyunca kaydi goremez

Farklı Ortamlarda SOA Kaydını Görüntüleme ve Doğrulama#

Bir bölgenin SOA kaydını incelemek, DNS sorunlarını teşhis etmenin en hızlı yollarından biridir. En yaygın araç dig komutudur ve neredeyse her Linux dağıtımında bulunur.

# Belirli bir alan adının SOA kaydını sorgula
dig alan-adiniz.com SOA +short

# Ornek cikti:
# ns1.clou.tr. hostmaster.clou.tr. 2026071001 7200 1800 1209600 3600

# Otoritatif sunucudan dogrudan sorgula (onbellegi atla)
dig @ns1.clou.tr alan-adiniz.com SOA

Windows tarafında ise nslookup benzer bir işi görür:

nslookup -type=soa alan-adiniz.com

Serial numarasının birincil ve ikincil sunucularda aynı olup olmadığını karşılaştırmak, senkronizasyon sorunlarını tespit etmenin en pratik yöntemidir. İki sunucudan farklı serial değerleri dönüyorsa, ikincil sunucu henüz güncellenmemiş demektir. Böyle bir durumda önce birincil sunucudaki serial'in gerçekten artırılıp artırılmadığını, ardından NOTIFY ve zone transfer izinlerini kontrol etmek gerekir.

BIND kullanıyorsanız, bölge dosyasının söz dizimini yüklemeden önce doğrulamak da iyi bir alışkanlıktır:

# Bolge dosyasinin sozdizimini kontrol et
named-checkzone alan-adiniz.com /etc/bind/zones/db.alan-adiniz.com

# Ciktida "OK" ve yuklenen serial numarasi gorunur:
# zone alan-adiniz.com/IN: loaded serial 2026071001
# OK

Çoğu paylaşımlı hosting ve yönetilen DNS panelinde SOA değerlerini elle düzenlemeniz gerekmez; panel makul varsayılanları kendisi uygular ve serial'i her kayıt değişikliğinde otomatik artırır. Yine de değerlerin ne anlama geldiğini bilmek, bir sorun çıktığında panelin nerede yanlış davrandığını anlamanızı sağlar. Ad sunucularını değiştirdiğinizde SOA kaydının da yeni birincil sunucuya işaret etmesi gerektiğini unutmayın; bu konuda nameserver değiştirme rehberimiz sürecin tamamını adım adım anlatır.

SOA Ayarlarında Sık Yapılan Hatalar ve Öneriler#

Yılların deneyiminden süzülmüş birkaç yaygın hata, SOA kaynaklı sorunların neredeyse tamamını oluşturur. Bunları bilmek, çoğu problemi daha ortaya çıkmadan önlemenizi sağlar.

İlk ve en sık hata, serial numarasını artırmayı unutmaktır. Bölgeyi elle düzenleyen yöneticiler kayıtları güncelleyip serial'e dokunmadan dosyayı kaydeder ve neden değişikliklerin yayılmadığını anlamaya çalışır. Otomatik serial artırımı olan panellerde bu sorun yaşanmaz, ancak elle yönetilen BIND ortamlarında bir kontrol listesi tutmak faydalıdır.

İkinci sık hata, mantıksız zamanlama değerleridir. Retry değerinin refresh değerinden büyük olması, expire değerinin refresh'ten küçük olması gibi durumlar teknik olarak bölgeyi çalıştırır ama beklenmedik senkronizasyon davranışlarına yol açar. Aşağıdaki hızlı referans, sağlıklı bir değer hiyerarşisini özetler:

Üçüncü hata ise RNAME alanındaki e-posta biçimidir. @ işaretini nokta yapmayı unutmak veya kullanıcı adındaki noktayı kaçış karakterine almamak, bölge dosyasının hiç yüklenmemesine neden olabilir. Bu yüzden bir bölge dosyasını düzenledikten sonra mutlaka named-checkzone ile doğrulama yapmak, üretim ortamına hatalı bir kayıt göndermenin önüne geçer.

Son olarak, ad sunucusu değişikliği yaptığınızda SOA'daki MNAME değerini güncellemeyi ihmal etmeyin. Eski sağlayıcıdan yeni bir DNS altyapısına geçerken bölge doğru taşınsa bile MNAME hâlâ eski sunucuyu gösteriyorsa, dinamik güncellemeler ve bazı denetim araçları yanlış hedefe yönelir. Bu tür geçişleri sorunsuz yapmak için site taşıma hizmetimiz veya profesyonel sunucu yönetimi desteğimiz süreci sizin yerinize yürütebilir.

Sıkça Sorulan Sorular#

SOA kaydını elle düzenlemem gerekir mi?#

Çoğu kullanıcının SOA kaydına elle dokunmasına gerek yoktur. Paylaşımlı hosting panelleri ve yönetilen DNS servisleri bu kaydı otomatik oluşturur, makul zamanlama değerleri atar ve her kayıt değişikliğinde serial numarasını kendisi artırır. Yalnızca kendi BIND veya benzeri bir DNS sunucunuzu elle yönettiğinizde SOA alanlarını doğrudan düzenlemeniz gerekir. Yine de değerlerin anlamını bilmek, bir sorun çıktığında teşhis koymanızı kolaylaştırır.

Serial numarasını yanlışlıkla çok büyük girdim, nasıl düzeltirim?#

DNS serial değeri asla küçültülmemesi gereken monoton artan bir sayı olduğundan, yanlışlıkla çok büyük bir değer girdiyseniz basitçe eski küçük değere dönemezsiniz; ikincil sunucular bunu daha eski sayar ve güncellemeyi reddeder. Standart çözüm, RFC 1982'de tanımlanan yöntemle numarayı önce maksimuma yakın bir ara değere taşımak, tüm ikincil sunucuların senkronize olmasını beklemek ve ardından istediğiniz düşük değere geçmektir. Bu iki aşamalı yaklaşım sarma aritmetiği sayesinde çalışır.

Refresh ve retry değerleri değişikliklerimin yayılma hızını etkiler mi?#

Doğrudan etkiler ancak modern kurulumlarda etkisi eskisi kadar belirleyici değildir. Günümüzde birincil sunucular bölge değiştiğinde ikincil sunuculara anında NOTIFY mesajı gönderir, bu yüzden değişiklikler refresh süresini beklemeden yayılır. Refresh ve retry değerleri, NOTIFY mesajının kaybolduğu veya birincil sunucuya geçici olarak ulaşılamadığı durumlarda güvenlik ağı olarak devreye girer. Yani düşük bir refresh değeri hız garantisi değil, olası bir kayıp durumunda telafi süresidir.

Minimum TTL ile kayıtların TTL değeri aynı şey midir?#

Hayır, bunlar farklı kavramlardır ve karıştırılması yaygın bir yanılgıdır. SOA kaydındaki minimum TTL, RFC 2308'den bu yana esas olarak negatif önbellekleme süresini yani var olmayan bir kayda verilen NXDOMAIN yanıtının ne kadar önbelleklenceğini belirler. Bireysel kayıtların kendi TTL değerleri ise doğrudan o kayıt satırında tanımlanır ve olumlu yanıtların ne kadar süre önbellekte tutulacağını kontrol eder. İki değer farklı amaçlara hizmet eder ve ayrı ayrı ayarlanabilir.

SOA kaydımı nasıl görüntüleyebilirim?#

En pratik yöntem dig alan-adiniz.com SOA komutunu kullanmaktır; bu komut MNAME, RNAME, serial ve tüm zamanlama değerlerini tek satırda gösterir. Windows kullanıyorsanız nslookup -type=soa alan-adiniz.com aynı bilgiyi verir. Otoritatif sunucudan doğrudan sorgu yapmak isterseniz dig @ns1.sunucu-adi alan-adiniz.com SOA biçiminde ilgili ad sunucusunu belirtebilirsiniz. Birincil ve ikincil sunuculardan dönen serial değerlerini karşılaştırmak, senkronizasyon sorunlarını tespit etmenin en hızlı yoludur.

İki ad sunucumun serial numaraları farklı görünüyor, sorun ne olabilir?#

Farklı serial değerleri, ikincil sunucunun henüz birincil sunucuyla senkronize olamadığını gösterir. En yaygın nedenler şunlardır: birincil sunucuda serial artırılmamış olabilir, NOTIFY mesajı ikincil sunucuya ulaşmamış olabilir veya zone transfer izinleri yanlış yapılandırılmış olabilir. Önce birincil sunucudaki serial'in gerçekten arttığını doğrulayın, ardından güvenlik duvarı ve allow-transfer ayarlarının ikincil sunucuya izin verdiğinden emin olun. Kısa bir süre içinde serial değerleri eşitlenmiyorsa, ikincil sunucunun günlük kayıtlarında transfer hatası aramak sorunu netleştirir.

Kapanış#

SOA kaydı, ilk bakışta göz ardı edilen ama bir DNS bölgesinin tüm yönetim mantığını taşıyan temel bileşendir. MNAME ve RNAME alanları yetkiyi ve sorumluyu tanımlarken, serial numarası senkronizasyonun kalbini oluşturur; refresh, retry, expire ve minimum TTL değerleri ise ikincil sunucuların davranışını ve önbellek sürelerini ince ayarla düzenler. Bu beş sayı ile iki metin alanını doğru anladığınızda, DNS senkronizasyonuyla ilgili sorunların büyük kısmını dakikalar içinde teşhis edebilirsiniz.

Clou.TR olarak sunduğumuz hosting ve alan adı paketlerinde DNS bölgeleriniz doğru varsayılan SOA değerleriyle otomatik yapılandırılır; serial numarası her değişiklikte kendiliğinden artar ve senkronizasyon sizin için yönetilir. Daha ileri seviye ihtiyaçlar için VDS sunucu çözümlerimizle kendi DNS altyapınızı kurabilir, dilerseniz sunucu yönetimi hizmetimizle tüm zone yapılandırmasını ekibimize bırakabilirsiniz. DNS ve alan adı yönetiminde takıldığınız her noktada uzman destek ekibimiz yanınızda.