DNS protokolünün doğal olarak yedek tutabilmesinin bir yolu var mı? Yedek ad sunucusu veya posta sunucusu kayıtları gibi bir kayıt sunucusu adresi? Bunu ararken sadece yedek ad sunucularında (NS kayıtları) sonuçlar gördüm.
DNS'nin yedek A kayıtlarını desteklemesinin bir yolu yoksa, sonuçları birincil olarak yanıtlamaması durumunda çalışan bir sunucuya yönlendirilecek şekilde sonuçları simüle etmenin en iyi yolu nedir?
Yanıtlar:
Evet ... biraz.
Burada yapabileceğiniz iki şey vardır: DNS sunucunuza belirli bir ad için birden fazla A kaydı koyarsanız, bunların tümü istemcilere sunulur ve bu istemciler bağlanmak için kümeden birini seçer, yani trafik tüm siteler arasında eşzamanlı olarak "adil" olarak eşit şekilde dağıtılmalıdır. Bu gerçekten tanımladığınız gibi değil, ancak yaygın bir durum (buna güvenmeme rağmen, çeşitli nedenlerle).
Diğer seçenek, DNS sunucunuza yalnızca bir A kaydı koymanız ve DNS sunucusunun (veya izleme komut dosyası gibi bir yardımcı programın) sitenizin ana adresini izlemesidir ve başarısız olursa DNS sunucusunun A kayıt diğer sitenize değiştirilir. Bu, aynı anda yalnızca bir sitenin trafik alacağı anlamına gelir.
Bu ikinci stratejinin dezavantajı DNS önbelleklemesidir. Eski site adresini alan herkes, eski adresi içeren DNS önbellek girişleri temizlenene kadar SOL olacaktır. Bu, TTL'lerinizi düşük tutmanız gerektiği anlamına gelir (nadiren pratik bir sorun olmasına rağmen DNS altyapınızdaki yükü arttırır), ancak yine de TTL'leri onurlandırmayan "haydut" DNS önbellekleri sorunu vardır. Bunlar herkes için büyük bir acı DNS girişlerini değiştirmek zorunda olan, ancak DNS girişlerini "sık sık" değiştirmek isteyen herkes için milyonlarca daha kötüdür (umarım siteniz günde birkaç kez aşağı inmez, ama yine de ...) Temel olarak, herkes bu hatalı davranan DNS önbelleklerinden birinin arkasında, sitenizi son derece uzun bir süre "kapalı" olarak görür ve onlara DNS önbelleğinin hatalı olduğunu açıklamaya çalışın ... Eugh.
Kısacası, bunu bir site için yapmazdım, çünkü düşündüğünüz riski azaltmanın daha iyi yolları vardır, ancak siteyi nasıl azaltacağınıza dair öneriler istiyorsanız bu riski açıklamanız gerekir.
Herkes açıkça yazmış olsanız bile WWW sunucularından bahsettiğinizi düşünüyor gibi görünüyor
Göz ardı edilen gerçek, HTTP servisinin istisna olduğu ve bu konuda norm değil olmasıdır. Normal durumda, evet, istemcilere DNS aracılığıyla bilgi yayımlamak için bir mekanizma vardır , böylece birincil sunuculardan yedekleme sunucularına doğru şekilde geri dönerler. Bu mekanizma, HTTP dışındakiyedek ad sunucusu veya posta sunucusu gibi
SRV diğer birçok protokol için hizmet istemcileri tarafından kullanılan kaynak kayıtlarıdır . Bkz. RFC 2782.
İle SRVkaynak kayıtları, müşteriler düşük ağırlıklı daha sık yüksek ağırlıklı sunucularını seçerek, ağırlığına göre eşit öncelikleri ile sunucuları arasında toplama, öncelikleri ve ağırlıkları, sunucularının listesini söylenir ve öncelik sırası sırayla sunucuları denemek için gereklidir olanlar. Bu nedenle SRVkaynak kayıtlarında, sunucu yöneticileri istemcilere yedek sunucuların ne olduğunu ve yüklerini eşit öncelikli sunucular kümesine nasıl dağıtacağını söyleyebilir.
Artık içerik DNS sunucuları, NSöncelik ve ağırlık bilgilerine sahip olmayan kendi kaynak kayıtlarının özel bir tür kaynak kaydı tarafından konumlandırılmıştır . Aynı şekilde, SMTP Aktarma sunucuları MX, öncelik bilgileri olan ancak ağırlıklandırma bilgisi olmayan kendi özel kaynak kaydı türlerine göre konumlandırılır . Dolayısıyla içerik DNS sunucuları için yedek ve yük dağıtım bilgilerini yayınlamak için herhangi bir hüküm yoktur; MXkaynak kayıtlar kullanılıyorsa , SMTP Geçiş sunucuları için yük dağıtım bilgilerini yayınlamak için herhangi bir hüküm yoktur.
Ancak, SRV-kaplanabilir MTS'ler artık mevcuttur. (Birincisi exim, SRV2005'ten beri kullanılabilen oldu.) Ve bagaj ve kaynak kayıtları ile birlikte numaralandırılmamış diğer hizmet protokolleri için, benimsenmesi çok daha kapsamlı ve yaygındır. Örneğin bir Microsoft Windows etki alanınız varsa, DNS'deki aramalar aracılığıyla bir dizi hizmet bulunur . Bu noktada, on yıldan fazla bir süredir durum böyleydi.MXNSSRVSRV
Sorun şu ki, HTTP bugüne kadar HTTP olduğunda, bugünlerde kural değil, herkes HTTP'yi düşünüyor.
SRVkayıtlar hizmetleri bulmanın tanımlanmış yoludur. Ayrıca sorunun mekanizmanın var olup olmadığı ve ne olduğu olduğuna dikkat edin. Mekanizma vardır ve bu mekanizmadır. On yıldır yaygın olarak kullanılmaktadır.
dinamik içerik sunuyorsanız ve aynı anda içerik veren iki sunucunuzun olması pratik değilse, diğer seçeneğiniz yine de DNS'inizde birden fazla kayıt olması ve yedekleme sunucusunu ICMP bağlantı noktasını erişmeye çalışan ve bağlanmaya çalışan istemcilere atayacak şekilde yapılandırmaktır ; herhangi bir noktada ana sunucu kapanırsa, yedekleme üzerindeki port 80 bloğunu kaldırmanız yeterlidir ve trafik gelmeye başlar.
Bunu yapmanın diğer tek (bütçe) yolu, isteklerde NAT gerçekleştirmek için ayrı bir makine (veya iki) kurmaktır, böylece bir web sunucusu ölürse, bunun için NAT kuralını kaldırabilirsiniz.
Yedek A kaydı yoktur, ancak rasgele sırada verilen birkaç A kaydı olabilir.
Çoğu tarayıcı, başarısız olursa başka bir sunucuyu deneyebilir. (Bakınız: Round Robin DNS ile Web Esnekliği )
VRRP veya CARP içeren birkaç sunucu tarafından desteklenen bir küme IP adresiniz olabilir . Birincil sunucu başarısız olduğunda yedekleme sunucusu adresi devralır.
Evet, ama bunu kendin yapmalısın ;-)
Neden "yedek A kaydı" istediğinizi ve yedeklemeye nasıl ve hangi koşullarda gitmek istediğiniz hakkında daha fazla bilgi verebilir misiniz?
Ayrıca, birincil ve yedek ana bilgisayarlar arasındaki ağ perspektifinden ilişkiyi bilmek de yararlı olacaktır.
Bu oldukça eski bir soru ama cevaplarda iki önemli teknoloji ortaya çıkmadı: Dinamik DNS ve CDN'ler.
Dinamik DNS, DNS kayıtlarının neredeyse gerçek zamanlı olarak değiştirilebileceği şekilde ayarlanır; böylece bir izleme istemcisi, hizmet kullanılabilirliğinin gerektirdiği şekilde genel DNS A kayıtlarındaki değişiklikleri tetikleyebilir. (Elbette, DNS barındırma hizmetinizin Dinamik DNS'yi desteklemesi gerekir.)
CDN'ler, örneğin Cloudflare (2010'da başlatılan, sanırım) gibi DNS dağıtımı için de kullanılabilir.