DNS Nerede Barınmalı? Registrar, Hosting Paneli ve Ayrı Sağlayıcı Karşılaştırması

Yeni bir alan adı aldınız ve sepette "DNS yönetimini bizim sunucularımızla yapın" kutucuğu zaten işaretli geldi. Ya da hostingi taşıyorsunuz, yeni firma size iki nameserver adresi verdi ve "bunları yazın, gerisi bizde" dedi. Her iki durumda da aslında bir mimari karar veriyorsunuz ama karar veriyormuş gibi hissetmiyorsunuz; sadece bir formu dolduruyorsunuz. O kutucuk işaretlendiğinde alan adınızın internetteki tek adres kaydı, bir hosting hesabının veya bir satış panelinin içine gömülmüş oluyor.

Bu kararın faturası genellikle aylar sonra geliyor. Bir gün fatura gecikiyor ve hesap askıya alınıyor; site kapanmıyor, alan adı komple çözümlenemez hâle geliyor — mail dahil. Ya da bir kampanya günü DNS sunucusu yüke dayanmıyor ve site "yok" oluyor. Ya da Let's Encrypt sertifikasını otomatikleştirmek istiyorsunuz, sağlayıcının API'si olmadığını öğreniyorsunuz.

Bu yazı üç seçeneği — alan adı firmanızın (registrar) DNS'i, hosting panelinizin DNS'i ve ayrı bir anycast DNS sağlayıcı — aynı kriter setiyle karşılaştırıyor. "Hangisi daha iyi" sorusuna tek bir cevap yok; ama "sizin durumunuzda hangisi" sorusunun net bir cevabı var ve aşağıdaki kriterler o cevabı çıkarmak için yeterli. Hangi panelin şu an yetkili olduğunu bilmiyorsanız önce DNS kayıtları hangi panelden değiştirilir yazısındaki teşhisi yapın; bu yazı "nerede olmalı" sorusuyla ilgileniyor.

Üç Seçenek Aslında Neyi Değiştiriyor#

Üçünde de sonuç aynı görünür: alan adınız bir IP'ye çözülür. Değişen şey, o cevabı veren makinelerin kime ait olduğu ve o makinelerin başka hangi işi yaptığıdır.

Registrar DNS. Alan adını aldığınız firmanın verdiği varsayılan nameserver'lar. Genellikle iki ya da üç sunucu, çoğunlukla tek bir veri merkezinde veya en fazla iki lokasyonda. Kayıt işinin yan hizmeti olduğu için ayrı bir ürün gibi geliştirilmez; panel arayüzü kayıt yenileme ekranının bir sekmesidir.

Hosting paneli DNS. cPanel/WHM, Plesk veya DirectAdmin kurulu sunucunun kendi BIND/PowerDNS servisi. Buradaki kritik ayrıntı şudur: DNS servisi, sitenizin de üzerinde çalıştığı makinede (ya da o firmanın aynı ağdaki iki makinesinde) çalışır. Yani web sunucusu ile DNS sunucusu aynı arıza alanını paylaşır. Avantajı, hesap açıldığında A/MX/SPF kayıtlarının otomatik oluşmasıdır; kimse elle bir şey yazmaz.

Ayrı DNS sağlayıcı. Cloudflare, Route 53, NS1, Google Cloud DNS, DNSimple, deSEC gibi yalnızca DNS işi yapan servisler. Onlarca lokasyondan anycast ile yayın yaparlar, API'leri birinci sınıf vatandaştır ve alan adınızın kaydından da hostinginden de bağımsızdırlar. Anycast'in ne yaptığını hiç okumadıysanız anycast DNS nedir yazısı bu farkın teknik temelini kurar.

Bir noktayı baştan netleştirelim: bu üç seçenek birbirinin alternatifidir, üst üste binmez. Nameserver kaydınız kimi gösteriyorsa yetkili odur; diğer iki panelde tuttuğunuz kayıtlar sessizce orada durur ve hiçbir çözücü onlara sormaz.

Karşılaştırma Kriterleri: Neye Bakmak Gerekiyor#

Aşağıdaki tablo altı kriterin üç seçenekte tipik olarak nasıl karşılandığını özetliyor. "Tipik" kelimesi önemli — her firma farklıdır, tablo bir eğilim haritasıdır, sözleşme yerine geçmez.

Tabloda kalın yazılan tek hücre kasıtlı: hosting paneli DNS'in gerçek maliyeti gecikme değil, arıza alanının çakışmasıdır. Buna ayrı bir bölüm ayırdım.

Sorgu Gecikmesi ve Coğrafi Dağılım Ne Kadar Önemli#

DNS gecikmesi, bir sayfa açılışında yalnızca ilk sorguda ödenir; sonrası TTL boyunca önbellekten gelir. Bu yüzden "DNS'i değiştirdim, sitem uçtu" iddiaları genellikle abartılıdır. Ama iki durumda gerçekten fark eder: ilk ziyaretteki soğuk açılışta (bounce oranını etkiler) ve sayfanız üçüncü taraf alan adlarına bağlanıyorsa her biri için ayrı bir çözümleme yapılır.

Kendi sağlayıcınızın gerçek gecikmesini ölçmek tahmin etmekten iyidir. dig çıktısındaki Query time satırı, önbelleği atlayıp doğrudan yetkili sunucuya sorduğunuzda anlamlı olur:

# Alan adının yetkili sunucularını bul
dig +short NS ornek.com

# Önbelleği atlayıp doğrudan yetkili sunucuya sor, süreyi oku
dig @ns1.saglayici.com ornek.com A +norecurse | grep "Query time"

# Aynı sunucuya on kez sorup ortalamayı gör
for i in $(seq 1 10); do
  dig @ns1.saglayici.com ornek.com A +norecurse +stats \
    | awk '/Query time/{print $4}'
done

Kendi bilgisayarınızdan aldığınız sonuç yalnızca sizin bulunduğunuz noktayı anlatır. Ziyaretçilerinizin ağırlıklı olarak Türkiye'de olduğu bir sitede, İstanbul'dan 15 ms alan bir sunucu fazlasıyla yeterlidir; hedef kitleniz Avrupa ve Orta Doğu'ya yayılmışsa tek lokasyonlu bir sunucu bazı bölgelerde 150 ms'nin üstüne çıkar. Anycast'in tek somut vaadi budur: her bölgede en yakın kopyaya düşmek.

Coğrafi dağılımı doğrulamanın kaba ama işe yarar bir yolu, sağlayıcının nameserver IP'lerinin kaç ayrı ağdan duyurulduğuna bakmaktır. İki nameserver'ın da aynı /24 bloğunda ve aynı AS numarasında olması, "yedekli" denen yapının aslında tek bir raf olduğunu gösterir:

dig +short NS ornek.com | while read ns; do
  ip=$(dig +short A "$ns" | head -1)
  echo "$ns -> $ip"
done

DDoS Dayanıklılığı: Asıl Kırılma Noktası#

DNS katmanına yapılan saldırılar web sunucusuna yapılanlardan farklı davranır. Sunucunuz ayakta kalsa bile yetkili DNS sunucunuz cevap veremiyorsa alan adınız yok olmuş sayılır; üstelik önbellekler dolduğunda kesinti kademeli olarak yayılır, bu yüzden ilk yarım saat "bazılarında açılıyor" gibi kafa karıştırıcı görünür.

Küçük ölçekli bir registrar veya paylaşımlı bir hosting sunucusu, birkaç Gbps'lik bir amplifikasyon saldırısını absorbe edemez. Daha kötüsü, hosting paneli DNS'inde saldırı DNS portuna gelse bile aynı hattı doldurduğu için web trafiğinizi de öldürür. Ayrı bir anycast sağlayıcıda ise saldırı trafiği onlarca PoP'a dağıldığı için tek bir noktada birikmez; sağlayıcının toplam kapasitesi sizin hattınızın kapasitesinden bağımsızdır.

Bu, "herkes DDoS yiyor" varsayımıyla değil, "yediğinizde ne olur" sorusuyla değerlendirilmelidir. Yılda bir kez 20 dakika kesinti kabul edilebilir bir blog için ayrı sağlayıcı lüks olabilir; ödeme akışı olan bir sitede aynı 20 dakika somut para kaybıdır.

DNSSEC Desteği: Kim İmzalıyor, Zinciri Kim Kuruyor#

DNSSEC'te iki ayrı iş vardır ve çoğu karışıklık bu ikisinin karıştırılmasından çıkar: bölgeyi imzalamak (DNS sağlayıcısının işi) ve DS kaydını üst bölgeye yazmak (registrar'ın işi). İkisi aynı firmadaysa süreç tek tıktır. Farklı firmalardaysa sağlayıcıdan DS değerlerini alıp registrar paneline elle girmeniz gerekir ve registrar bu alanı sunmuyorsa DNSSEC'i teknik olarak açamazsınız.

Karar aşamasında sorulacak soru şudur: alan adı firmanız DS kaydı girişi sunuyor mu? Sunmuyorsa ayrı bir DNS sağlayıcıya geçseniz bile güven zinciri kurulamaz. Mevcut durumu tek komutla görebilirsiniz:

# Üst bölgede DS kaydı var mı (zincir kurulmuş mu)
dig +short DS ornek.com

# Bölge imzalı mı, doğrulama başarılı mı
dig +dnssec +multi ornek.com SOA | grep -E "RRSIG|flags"

# Doğrulamayı uçtan uca sına
delv @1.1.1.1 ornek.com A

delv çıktısında fully validated görüyorsanız zincir sağlamdır; unsigned answer görüyorsanız imzalama ya hiç açılmamıştır ya da DS kaydı eksiktir. Kavramın kendisi ve anahtar rollerini DNSSEC nedir yazısında ayrıntılı ele aldık.

API, Otomasyon ve Altyapı-Kod Entegrasyonu#

DNS'i elle yönettiğiniz sürece bu kriter önemsiz görünür. İki durumda birdenbire zorunluluğa dönüşür:

Wildcard sertifika yenileme. Let's Encrypt'te *.ornek.com sertifikası yalnızca DNS-01 doğrulamasıyla alınır; bu da yenileme anında otomatik olarak bir _acme-challenge TXT kaydı yazılıp silinmesi demektir. Sağlayıcınızın API'si yoksa her 60 günde bir elle kayıt eklemek zorunda kalırsınız — ve bir kez unuttuğunuzda sertifika düşer.

# Cloudflare API token ile wildcard sertifika (acme.sh)
export CF_Token="CF_API_TOKEN_DEGERI"
acme.sh --issue --dns dns_cf -d ornek.com -d '*.ornek.com'

# Route 53 kullanıyorsanız
acme.sh --issue --dns dns_aws -d ornek.com -d '*.ornek.com'

Altyapının versiyonlanması. Birden fazla alan adı yönetiyorsanız kayıtları kod olarak tutmak, "kim ne zaman neyi sildi" sorusunu çözer. Ayrı sağlayıcılar bunu doğrudan destekler:

# Basitleştirilmiş bir kayıt tanımı örneği (kod olarak DNS)
zone: ornek.com
records:
  - name: "@"
    type: A
    ttl: 300
    value: 203.0.113.10
  - name: www
    type: CNAME
    ttl: 300
    value: ornek.com.
  - name: "@"
    type: MX
    ttl: 3600
    value: "10 mail.ornek.com."
  - name: "@"
    type: TXT
    ttl: 3600
    value: "v=spf1 mx include:_spf.saglayici.com -all"

Hosting panelleri bu ihtiyacı kısmen karşılar: WHM ve Plesk'in API'leri vardır ama DNS'e özel değildir, dokümantasyonları zayıftır ve hesap taşındığında endpoint değişir. Registrar DNS'lerinin çoğunda ise API hiç yoktur.

Apex CNAME Sorunu ve Kayıt Tipi Desteği#

DNS standardı, bir ismin CNAME kaydı varsa aynı isimde başka kayıt bulunmasını yasaklar. Alan adının kökü (apex, yani ornek.com) zorunlu olarak SOA ve NS kayıtları taşıdığı için apex'e CNAME yazılamaz. Bu soyut bir kural değil, çok somut bir engeldir: yükünüzü bir CDN'in ya da yük dengeleyicinin xyz.cloudfront.net gibi bir adına yönlendirmek istediğinizde www.ornek.com için sorun yoktur ama ornek.com için yolunuz kapanır.

Ayrı DNS sağlayıcılarının çözümü ALIAS/ANAME (Cloudflare'de "CNAME flattening") adı verilen sağlayıcıya özgü bir kayıt tipidir: sağlayıcı hedefi kendi tarafında çözer ve dışarıya normal bir A kaydı gibi sunar. Registrar ve hosting paneli DNS'lerinde bu neredeyse hiç bulunmaz; oradaki tek seçenek hedefin IP'sini elle yazmaktır ve o IP değiştiğinde siteniz sessizce ölür.

Kayıt tipi desteğini seçim öncesi kontrol edin. Pratikte eksik çıkan tipler şunlardır:

Son satır özellikle can sıkıcıdır: 2048 bit bir DKIM anahtarı tek bir TXT dizesine sığmaz, parçalara bölünüp tırnak içinde birleştirilmesi gerekir. Bunu desteklemeyen bir panelde DKIM kurulumu yarıda kalır.

En Çok Atlanan Risk: DNS'i Hosting Hesabının İçinde Tutmak#

Buraya kadar sayılan her kriter derece meselesidir. Bu bölümdeki risk ise ikili bir anahtardır: ya ayaktasınız ya da alan adınız internetten tamamen silinmiş gibidir.

DNS'iniz hosting hesabınızın içindeyse ve o hesap askıya alınırsa (ödeme gecikmesi, kaynak aşımı, kötüye kullanım şüphesi, hesabın yanlışlıkla kapatılması), yalnızca web siteniz kapanmaz. Nameserver'lar da o hesabın parçası olduğu için ornek.com hiçbir sorguya cevap veremez hâle gelir. Sonuçları şunlardır:

• Site kapanır — beklenen sonuç budur.
• MX kaydı çözülemediği için mail akışı durur. Size mail gönderen sunucular alıcı sunucuyu bulamaz; bir süre kuyrukta bekletir, sonra bounce eder. Yani hosting hesabı askıdayken gelen kurumsal yazışmalar kalıcı olarak kaybolur.
• Alan adını başka bir sunucuya taşımak için yapacağınız DNS değişikliğini, o DNS panelinde yapamazsınız — çünkü panel askıda.
• SPF/DKIM/DMARC kayıtları da gittiği için, başka bir sağlayıcıdan mail göndermeye çalışsanız bile doğrulamalar başarısız olur.
• Sunucunun tamamı düşerse (donanım arızası, veri merkezi kesintisi) aynı senaryo yaşanır; üstelik bu kez DNS failover kuramazsınız, çünkü failover'ı yapacak DNS de aynı makinededir.

Bu, teorik bir felaket senaryosu değil, hosting destek kuyruklarındaki en yaygın acil taleplerden biridir. Kaçınmanın yolu basittir: DNS, web sunucusuyla aynı arıza alanında olmasın. Alan adınız bir firmada, hostinginiz bir başkasında, DNS'iniz üçüncü bir yerde olabilir ve bu dağınıklık değil, dayanıklılıktır. İki hizmeti ayırmanın operasyonel sonuçlarını domain ve hosting ayrı mı alınır yazısında ayrıca tartıştık.

Geçiş Maliyeti: Zone Aktarımı ve TTL Planı#

DNS sağlayıcısı değiştirmek, doğru sırayla yapıldığında kesintisizdir. Yanlış sırayla yapıldığında ise klasik "bazı kullanıcılarda eski site açılıyor" tablosuna yol açar. Doğru sıra şudur:

1. Mevcut kayıtların tam listesini çıkarın. Panel ekranına bakarak değil, sorgulayarak. Gözden en çok kaçan kayıtlar doğrulama TXT'leri, _dmarc, _domainkey altındaki DKIM ve alt alan adlarıdır.
2. TTL'leri düşürün ve eski TTL kadar bekleyin. Kayıtlarınız 86400 (24 saat) TTL ile yayılıyorsa, TTL'i 300'e indirdikten sonra dünyadaki önbelleklerin boşalması için 24 saat beklemelisiniz. Bu adım atlandığında geçiş bir gün boyunca ikili davranır. Mekanizma DNS propagasyon süresi yazısında ayrıntılı.
3. Yeni sağlayıcıda bölgeyi eksiksiz oluşturun ve yeni nameserver'lara doğrudan sorarak doğrulayın.
4. Ancak bundan sonra registrar panelinden NS kayıtlarını değiştirin. Adımın kendisi için nameserver değiştirme yazısına bakabilirsiniz.
5. Eski bölgeyi en az bir hafta silmeyin. Geri dönmeniz gerekirse hazır dursun.

Kayıtları toplamak için panel ekran görüntüsü almak yerine sorgulayın:

# Bilinen kayıt tiplerini eski yetkili sunucudan tek tek çek
OLD=ns1.eskisaglayici.com
for t in SOA NS A AAAA MX TXT CAA; do
  echo "--- $t"
  dig @$OLD ornek.com $t +noall +answer
done

# Sık kullanılan alt adları ve doğrulama kayıtlarını da unutmayın
for n in www mail ftp cpanel autodiscover _dmarc default._domainkey; do
  dig @$OLD "$n.ornek.com" ANY +noall +answer
done

# TTL'i düşürdükten sonra gerçekten düştü mü kontrol edin
dig ornek.com A | awk '/^ornek\.com\./{print "TTL:", $2}'

Kendi sunucunuzda BIND çalıştırıyorsanız bölgeyi doğrudan dışa aktarabilirsiniz; bu, elle kopyalarken kayıt atlama riskini tamamen ortadan kaldırır:

# Çalışan bölgeyi diske yaz ve oku
rndc sync -clean ornek.com
named-checkzone ornek.com /var/named/ornek.com.db

# cPanel sunucusunda bölge dosyalarının yeri
ls -l /var/named/ornek.com.db

Bir uyarı: dig AXFR ile bölge transferi denemek çoğu sağlayıcıda Transfer failed döner, çünkü AXFR yetkisiz istemcilere kapalıdır. Bu bir hata değil, doğru yapılandırmadır; kayıtları tip tip çekmek zorundasınız.

Kim İçin Hangisi: Üç Profil#

Küçük site, kişisel blog, tanıtım sayfası. Hosting panelinin DNS'i işinizi görür; kurulum sıfır efor ister, A ve MX kayıtları otomatik gelir. Tek şartla: alan adınızın kaydı hostingle aynı hesapta değilse ve düzenli ödeme yapıyorsanız. Ayrı bir sağlayıcıya geçmek de zarar vermez; ücretsiz planlar bu ölçek için fazlasıyla yeterlidir ve ileride taşınmayı kolaylaştırır.

E-ticaret ve ödeme alan siteler. Ayrı bir anycast sağlayıcı pratikte zorunludur. Gerekçe hız değil, üç ayrı risk: hosting hesabı askıya alındığında mail akışının da durması, DDoS anında DNS'in web ile aynı hattı paylaşması ve kampanya günlerinde tek lokasyonlu bir sunucunun yük altında yanıt gecikmesini büyütmesi. Apex'i bir CDN'e bağlamak isteyeceğiniz için ALIAS/ANAME desteği de burada gerçek bir gereksinime dönüşür.

Çok alan adlı kurumsal yapı. Onlarca alan adı, birden çok ortam (prod/staging), otomatik sertifika yenileme ve birden çok kişinin yetkisi söz konusuysa karar kriteri tamamen API ve yetkilendirmeye kayar: alan adı bazında rol tanımlanabiliyor mu, değişiklikler denetim kaydına düşüyor mu, kayıtlar kod olarak versiyonlanabiliyor mu, SLA sözleşmede yazılı mı. Registrar ve hosting panelleri bu dört soruda da yetersiz kalır. Ayrıca alan adı kaydını (registrar) DNS sağlayıcısından da ayrı tutmak, tek bir hesabın ele geçirilmesinin hem alan adını hem DNS'i aynı anda kaybettirmesini engeller.

Son bir pratik not: hangi seçeneği seçerseniz seçin, kayıtlarınızın bir metin kopyasını sağlayıcı dışında bir yerde saklayın. Bölgenizin dig çıktısıyla alınmış bir dökümü, panel erişiminizi kaybettiğiniz gün elinizdeki tek envanter olur.

Sıkça Sorulan Sorular#

Hosting firmamın verdiği nameserver'ları kullanmak zorunda mıyım?#

Hayır. Nameserver kaydı alan adı kaydınıza aittir ve alan adı firmanızın panelinden serbestçe değiştirilir. Hosting firmanız yalnızca sunucunun IP'sini vermek zorundadır; siz o IP'yi istediğiniz DNS sağlayıcısında A kaydı olarak tanımlarsınız. Bazı paylaşımlı paketlerde otomatik kurulum kolaylık sağlasın diye varsayılan nameserver'lar önerilir, ama bu bir zorunluluk değildir.

Ücretsiz DNS sağlayıcılar gerçekten yeterli mi?#

Çoğu senaryo için evet. Ücretsiz planlar genellikle sınırsız sorgu, anycast ağın tamamı ve tam kayıt tipi desteği sunar. Ücretli plana geçmenin gerçek gerekçeleri farklıdır: yazılı SLA ve kesinti kredisi, gelişmiş trafik yönlendirme (ağırlıklı, coğrafi, failover), daha ayrıntılı rol yetkilendirme ve öncelikli destek. Küçük ve orta ölçekli bir sitede bu dördü de zorunlu değildir.

DNS sağlayıcısı değiştirirken sitem kapanır mı?#

Doğru sırayla yapılırsa kapanmaz. Kritik nokta, yeni sağlayıcıda tüm kayıtları eksiksiz oluşturup doğruladıktan sonra nameserver değişikliğini yapmaktır. Geçiş sırasında iki bölge birbirinin aynısı olduğu için, hangi sunucuya sorulursa sorulsun aynı cevap döner. Eski bölgeyi hemen silmek ise geri dönüş imkânınızı yok eder; en az bir hafta bekletin.

DNS'i Cloudflare'e taşırsam hostingimi de değiştirmem gerekir mi?#

Hayır, ikisi bağımsızdır. Cloudflare yalnızca DNS cevaplarını verir; dosyalarınız ve veritabanınız mevcut sunucunuzda kalır. Yapmanız gereken tek şey A kaydının doğru IP'yi göstermesidir. Proxy (turuncu bulut) modunu açarsanız trafik Cloudflare üzerinden geçmeye başlar; kapalı bırakırsanız Cloudflare sadece DNS sağlayıcısı olarak çalışır ve hosting davranışınız hiç değişmez.

Alan adı firmam ile DNS sağlayıcım farklı olursa DNSSEC çalışır mı?#

Çalışır ama iki adımlıdır. DNS sağlayıcısı bölgeyi imzalar ve size DS kayıt değerlerini verir; siz bu değerleri alan adı firmanızın panelindeki DNSSEC/DS bölümüne girersiniz. Alan adı firmanız DS girişi sunmuyorsa güven zinciri kurulamaz ve DNSSEC etkin olmaz. Bu yüzden DNSSEC planlıyorsanız, registrar seçiminde DS kaydı desteğini önceden kontrol edin.

Nameserver'larımın kaç lokasyondan yayın yaptığını nasıl anlarım?#

Kesin liste sağlayıcının belgelerinde olur, ama kaba bir kontrol yapabilirsiniz: nameserver adlarının IP'lerini çözüp aynı /24 bloğunda ve aynı otonom sistemde olup olmadıklarına bakın. İkisi de tek bir blokta çıkıyorsa muhtemelen tek lokasyon söz konusudur. Gerçek anycast kullanan sağlayıcılarda aynı IP'ye farklı ülkelerden sorduğunuzda gecikme belirgin biçimde farklılaşır; bu farkı çevrimiçi çok noktalı sorgu araçlarıyla ölçebilirsiniz.