Eğitimler

Name server: Hosting, kayıt sağlayıcı veya bulut arasında seçim

Siteniz kayıt sağlayıcının name server'ında sallanıyorsa, bu kılavuz hosting, kayıt sağlayıcı ve bulut DNS arasındaki seçim kriterlerini sayı ve komutla gösterir.

Eğitimler

Site açılıyor, ancak birkaç saatte bir on dakika boyunca "DNS_PROBE_FINISHED_NXDOMAIN" alıyorsunuz. Ya da daha kötüsü: müşteri başka bir şehirden arayıp siteyi göremediğini söylüyor, siz ise kendi ofisinizden her şeyi sağlıklı görüyorsunuz. Bu belirtiler neredeyse her zaman tek bir kökene sahiptir: name server'ınız, onun için inşa edilmediği bir yerdedir. Gerçek karar da "hangisi daha iyi" değildir; karar, hangi seçeneğin sizin trafik deseniniz ve erişim seviyeniz için doğru olduğudur.

Name server tam olarak neyi kontrol eder

Name server (Authoritative Nameserver), DNS sorgularına son yanıtı verir. Biri sitenizin adresini yazdığında, resolver kökten başlar, TLD'ye ulaşır ve son olarak sizin name server'ınıza "Alan adının A kaydı nedir?" diye sorar. Bu döngü ne kadar yavaş veya kararsız olursa, kullanıcı sitenizden tek bir bayt bile görmeden önce bekler.

Bu rolü üç yere emanet edebilirsiniz: alan adı kayıt sağlayıcısının paneli, hosting kontrol paneli veya bağımsız bir bulut DNS servisi. Bu üçünün farkı yanıt hızında, kayıt kontrolünde ve sunucunuz çöktüğünde ne olduğunda kendini gösterir.

Üç seçenek, krizde üç farklı davranış

KriterKayıt sağlayıcı name server'ıHosting name server'ıBulut DNS
Kayıt değişikliği yayılma hızıYavaş, bazen 2 saatten fazlaOrta, genellikle 30 dakikanın altındaHızlı, çoğu zaman 5 dakikanın altında
Kayıt kontrolüSınırlı, eski arayüzKontrol panelinize bağlıTam, API ve şablon
Otomatik failoverYokNadirenVar
MaliyetÜcretsizÜcretsizÜcretsizden profesyonel planlara kadar

Yukarıdaki tablo kararı vermiyor. Kararı veren şey şudur: birincil sunucunuz erişilemez hale gelirse, name server'ınız ne yapabilir? Kayıt sağlayıcı name server'ı hiçbir şey yapmaz. Hosting name server'ı da genellikle biri kaydı manuel olarak değiştirene kadar aynı IP'yi döndürür. Sadece üçüncü seçenek kendi başına karar verebilir.

TTFB'niz neden yükseliyor ve bunun name server ile ilgisi ne

Yaygın bir hata, her şeyi sunucunun üzerine yıkmaktır. Sitenizin TTFB'si 800 milisaniyeyse, önce dig ile name server yanıt süresinin ne kadar olduğuna bakın:

dig @1.1.1.1 example.com A +stats
dig +trace example.com

Çıktıda Query time alanına bakın. 50 milisaniyenin altı normaldir. 300 ila 600 milisaniye arasında dönüyorsa, sorun web sunucunuzdan öncedir ve her PHP optimizasyonu işe yaramaz. Yavaşlığın hangi noktadan geldiğini anlamak için, ücretsiz araçlar ServerNet'in DNS ve TTFB testini birkaç coğrafi noktada yapar ve farkı gösterir.

Daha az söylenen bir nokta: kayıtların TTL'si. TTL'yi 300 saniyeye ayarladıysanız ve sonra sunucuyu değiştirmek istiyorsanız, geçişiniz 5 dakikaya kadar tutarsız olur. 86400'e ayarladıysanız, bir güne kadar. Her geçişten önce TTL'yi 300'e düşürün, bir gün bekleyin, geçişi yapın, sonra geri alın.

Gerçekte nerede hata yapıyorlar

Şurada hata yapıyorlar: name server'ı hosting üzerine koyuyorlar ve sonra hostingi değiştiriyorlar, name server'ın da onunla gideceğini düşünmeden. Sonuç, sitenin sadece eski IP'yi önbelleğe alanlar için değil, herkes için erişilemez hale gelmesidir. Belirtisi de tam olarak şudur: dig kendi sunucunuzdan yanıt verir, ancak dışarıdan SERVFAIL alırsınız. Name server hosting üzerindeyse, her taşımadan önce NS kayıtlarını bağımsız bir servise taşıyın.

İkinci hata: her iki NS'yi de aynı sağlayıcıya koymak. O sağlayıcı sorun yaşarsa, her iki name server'ınız birlikte çöker ve hiç yedekliliğiniz olmaz. En az iki name server, iki farklı ağda gereklidir.

Her senaryo için seçim kriteri

Kişisel site veya düşük trafikli blog

Hosting name server'ı yeterlidir. Basittir, tek paneliniz vardır ve ekstra karmaşıklık size bir şey katmaz. Sadece kontrol panelinin MX ve TXT kayıtlarını düzenleme imkânı verdiğinden emin olun; bazı ucuz paneller bunu gizler.

Mağaza veya gelir getiren site

Burada bulut DNS'i seçerim. Nedeni hız değil, failover yeteneğidir. Birincil sunucu erişilemez hale gelirse, kayıt yedek sunucuya gider ve müşteriniz fark etmez. Bedeli, ekstra bir karmaşıklık katmanı eklenmesi ve kayıtları API'den yönetmeyi öğrenmeniz gerektiğidir. Bunu sadece bir kişinin anladığı bir ekip için, bu karmaşıklık kendisi bir risk olabilir.

Yerel kullanıcıları olan servis

Kullanıcılarınızın tümü İran'daysa, yabancı bulut name server'ı her zaman en iyi seçenek değildir. Ağ yolu ve yaptırımlar, DNS yanıtının içeriden yerel bir name server'dan daha yavaş olmasına neden olabilir. Burada varsayım yapmayın, test edin. İran içinden iki noktadan bir dig yeterlidir ki karar değişsin.

Kesintisiz name server geçişi

  1. Mevcut kayıtları tamamen çıkarın: dig example.com ANY +noall +answer ve ayrıca dig example.com MX ve dig example.com TXT.
  2. Yeni serviste tüm kayıtları önceden oluşturun, e-posta doğrulama ve SPF kayıtları dahil.
  3. TTL'yi 300'e düşürün ve en az bir tam döngü bekleyin.
  4. NS kayıtlarını kayıt sağlayıcı panelinde değiştirin. Bu, geri döndürülemez tek adımdır, bu yüzden öncesinde her şeyin hazır olduğundan emin olun.
  5. dig +trace ile birkaç noktadan yayılımın tamamlandığını doğrulayın.

WordPress üzerinde çalışıyorsanız, geçişten sonra muhtemelen cron'un çalışmaması veya veritabanındaki eski adresler gibi sorunlarla karşılaşırsınız. Eklentisiz WordPress taşıma kılavuzu tam olarak DNS değişikliğinden sonraki bu adımı kapsar.

Name server doğru olduğunda ama site yavaş kaldığında

Query time 50 milisaniyenin altındaysa ve site hâlâ yavaşsa, sorun başka bir yerdedir. WordPress'te dahili cron her zaman şüphelilerden biridir; WordPress wp-cron'u gerçek sistem cron'u ile değiştirin. Eklenti sayısı 30'u geçtiyse, başka herhangi bir şeyden önce eklenti denetimi yapın. Ve paylaşımlı hostingdeyseniz, giriş/çıkış sınırlaması veya işlemci sınırlaması olup olmadığını kontrol edin.

Orta düzey trafiğe sahip WordPress siteleri için, cron ve kaynaklar üzerinde tam kontrole sahip bir Linux hosting, genellikle ucuz paylaşımlı hostingden daha ucuza gelir, çünkü tekrarlayan sorun gidermeler için zamanınızı serbest bırakır. WordPress siteniz varsa ve sunucu ayarlarıyla uğraşmadan yola koyulmak istiyorsanız, WordPress hosting ServerNet bu katmanı omuzlarınızdan alır.

Sık sorulan sorular

Name server değişikliği site kesintisine neden olur mu?

Doğru yapılırsa hayır. Kesinti, kayıtları yeni serviste oluşturmadığınızda veya geçişten önce TTL'yi düşürmediğinizde ortaya çıkar. TTL 300 saniyedeyken, tutarsızlık penceresi en fazla birkaç dakikadır.

Kaç name server gereklidir?

En az iki name server ve tercihen iki farklı ağda olmalıdır. İkisi de aynı sağlayıcıdaysa, o sağlayıcının arızası ikisini birlikte devre dışı bırakır ve gerçek yedekliliğiniz olmaz.

Bulut DNS site hızını artırır mı?

Yükleme süresinin yalnızca küçük bir kısmı DNS ile ilgilidir. TTFB'niz 800 milisaniye ve DNS yanıt süreniz 40 milisaniyeyse, name server değişikliği neredeyse hiç fark yaratmaz. Önce dig ile ölçün, sonra karar verin.

Mevcut name server'ımın hangisi olduğunu nasıl anlarım?

dig NS example.com +short komutunu çalıştırın. Çıktı, kayıt sağlayıcının veya hostingin sunucu adlarını gösteriyorsa, oradadır. Bir bulut servisinin adını görüyorsanız, zaten geçiş yapmışsınızdır.

Herhangi bir karardan önce, bir kez dig +trace çalıştırın ve her adımın süresine bakın. Gördüğünüz sayı, herhangi bir karşılaştırmadan daha fazla kararınızı değiştirir.

ServerNet Destek

ServerNet mühendislik ve yayın ekibi — altyapı, ağ ve web barındırma uzmanları.

WordPress Hosting
Paylaş:

Yorumlar 0

Henüz yorum yok — ilk siz olun!

Yorum bırakın

İlgili hizmet

WordPress Hosting

LiteSpeed Enterprise ve NVMe üzerinde WordPress'e özel altyapı — otomatik kurulum, güvenli güncelleme, staging ve sizi Google'da üstte tutan önbellek.