Aynı TLD / sağlayıcıya ait olmayan birden fazla ad sunucusu olabilir mi?


15

GoDaddy kesintisi ışığında, alan adımız için ad sunucusu listemizi ek bir ad sunucusu sağlayıcısı içerecek şekilde güncelledik. Liste şöyle görünür:

  1. ns61.domaincontrol.com
  2. ns54.domaincontrol.com
  3. ns1.dreamhost.com
  4. ns2.dreamhost.com

Hem Godaddy hem de Dreamhost, A ve MX kayıtlarını işlemek için bölge girişlerine sahiptir. Fikir şu ki, bir sağlayıcı dışarı çıkarsa diğeri geri dönüş olacak.

Ancak, yapılandırmamı http://www.intodns.com/ ile test ettiğimde, SOA serilerinin kabul edilmediğine dair bir uyarı alıyorum.

Ad sunucusu yapılandırmasındaki bazı temel bilgileri yanlış anladım mı? Gelecekteki sorunları önlemek için ne yapabilirim?


İntodns.com gibi hizmetler, seri uyumsuzluğu gibi sorunları vurgular, çünkü yapılandırmanızdaki DNS sunucularının senkronize olmaması gibi hatalar hakkında bilgi verebilir. Ancak bu, bunun, arama yapan istemciler için mutlaka bir sorun olacağı anlamına gelmez. Hile, neyi göz ardı edebileceğinizi ve belirli koşullar altında öğrenmektir.
John Gardeniers

Yanıtlar:


14

SOA seri numaralarının eşleşmemesi, farklı DNS sağlayıcıları kullanmanız nedeniyle mükemmel bir anlam ifade ediyor. Sağlayıcılar arasındaki SOA seri numaraları, bir sağlayıcı diğerine bölge aktarımlarını desteklemedikçe eşleşmeyecektir, bu büyük olasılıkla ... ancak sorun değil. Seri numaralarının alan adınız için ad çözümlemesi üzerinde herhangi bir etkisi yoktur, yalnızca aynı sağlayıcıda veya bölge aktarımlarına herkese izin verilirse bölgeyi barındıran tüm ad sunucuları arasında yalnızca bölgeyi barındıran ad sunucuları için bir anlamı vardır. onları. Emin olmanız gereken şey, bir sağlayıcıya kayıt eklediğinizde, değiştirdiğinizde veya sildiğinizde diğer sağlayıcıda da aynısını yaptığınızdır. Bir sağlayıcıda DNS kayıtlarını senkronize tutan ana / bağımlı mekanizma, diğer sağlayıcıda kayıtlarınızı senkronize tutmayacak, '


1
Görüyorum ki, temel olarak her bir sağlayıcıda bölge kayıtlarımızı manuel olarak yönettiğimiz göz önüne alındığında beklenen davranış. Sanırım bir sonraki adım, senkronizasyonu otomatikleştirmeye bakmak, ancak bölge kayıtlarını çok sık değiştirmeyi planlamıyoruz.
Simon

Evet, sağlayıcılar arasındaki seri numaralarının eşleşmemesini beklerim. DNS kayıtlarını sağlayıcılar arasında manuel olarak yönetmek zorunda kalmamak için her iki sağlayıcının üçüncü taraf bölge aktarımlarını destekleyip desteklemediğini görmeniz gerekir ... ancak destekleyenlere güvenmem.
joeqwerty

7

Emin olabilirsin.

Örneğin, çalıştığım yerde 4 ad sunucumuz var, bunlardan 2 tanesi bir DNS ana bilgisayarında barındırılıyor, biri bizim tarafımızdan barındırılıyor, diğeri ise ikinci bir harici DNS ana bilgisayarı tarafından barındırılıyor.

Kabul edilmeyen SOA (yetki başlangıcı) dizileri DNS'nizle [büyük olasılıkla] bir senkronizasyon sorunu olduğunu gösterir - tüm ad sunucuları DNS kayıtlarınızın aynı sürümünü sunmuyor. Bu gerçek bir sorun olabilir veya DNS'nin yetkili ad sunucularınızdan geri kalanına tam olarak yayılmadığını gösterebilir.

İşte MS'den bir SOA kaydının yapısı hakkında bulduğum hızlı bir KB. Umarım bu sizin için neler olduğunu açıklığa kavuşturacaktır.

Seri numarası - Bu bölge dosyasının düzeltme numarası. Bölge dosyası her değiştirildiğinde bu sayıyı artırın. Her değişiklik yapıldığında bu değerin artırılması önemlidir, böylece değişiklikler herhangi bir ikincil DNS sunucusuna dağıtılır.


Bazı kayıtlarda küçük bir fark olduğunu düşünüyorum, ismin çözülmesini etkileyecek hiçbir şey yok. Bütünlük için onları özdeş hale getireceğim.
Simon

2
@Simon Eh, joeqwerty'nin de belirttiği gibi, bu mümkün olmayabilir. DNS ana makinelerimiz bölge aktarımlarına izin veriyor ve sizinkilerin olmayabilir. Sizinki yoksa, "seri" / düzeltme, DNS ana bilgisayarları (bu beklenen ve endişelenecek bir şey) arasında eşleşmez ve yalnızca kayıtların tüm ad sunucularınızda aynı olduğundan emin olmanız gerekir.
HopelessN00b
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.