DNS arama sırası nasıl belirlenir?


20

Örneğin: domain.com alan adını kaydettik ve kayıt sunucusu sunucusuna ad sunucusu kayıtlarını ekledik:
ns1.etkialanı.com.
ns2.domain.com.
ns3.domain.com.

Daha sonra domain.com'u ararız . 3 ad sunucusu adresinin hepsini alıyoruz.
1. Bu sunuculardan hangisinden daha fazlası istenecek ve neden?
2. Bölge dosyasındaki NS kayıtlarının sırası önemli mi?
3. Herhangi bir RFC'de belirlenmiş mi?

Yanıtlar:


20

Ne yazık ki, buradaki cevap "duruma bağlıdır". Bağlı olduğu faktörler etki alanına ve sahip olunan sunucuların nasıl kurulacağına ve kendi yerel DNS'inizin nasıl kurulduğuna bağlı olarak değişir.

İlk olarak, örneğin, iade edilen NS kayıtları ile ilgili olarak: bu kayıtların döndürüldüğü sırayı rasgele seçmenize izin verilir, bu nedenle sipariş her talep ettiğinizde farklılık gösterebilir. Öte yandan, bu tüm DNS uygulamaları tarafından yapılmaz, bu nedenle statik olarak sıralanmış bir liste alabilirsiniz. Mesele şu ki, emin olamıyorsunuz.

Daha sonra, bazı DNS uygulamaları her NS'yi paralel olarak sorgulayacak ve hangisini önce yanıtlarsa kullanacaktır. Diğerleri her birini vuracak, bazı taleplerde en hızlı olanı belirleyecek ve bunu kullanacaktır. Ya da sadece robin yapabilir.

DNS için birden fazla RFC vardır, bulduğumdan daha kullanışlı olan ikisi şunlardır:

http://www.faqs.org/rfcs/rfc1912.html

http://www.faqs.org/rfcs/rfc1033.html

Bunun cevabı olmayan bir şey olduğunun farkındayım, götürmeniz için kesin bir şey yok, ancak yukarıdakiler göz önüne alındığında, belirli bir alanın davranışını belirlemenin tek gerçek yolu test etmektir.


Cevabınızı onayladım. Ben de aynı şeyi söyleyecektim ama sen beni dövüyordun.
Tonny

Ayrıca getaddrinfo kullanan istemciler gethostbyname çağrıları rastgele görünüyorken sıralı sonuçlarla sonuçlanır. Bu davranışı beklemeyen müşteriler bu nedenle bazı açılardan Robin Robin'leri kıracaktır.
Matt

5

Dünya genelinde ISP'ler gibi müşteri düzeyinde gördüğüm en yaygın uygulama şöyledir:

  1. Birisi (geniş bantlı bir abone gibi), ISS'nin DNS sunucularından foo.example.com için A kaydını çözmesini ister.
  2. ISS kendi önbelleğini kontrol eder ve eğer bu kayıt önbelleğe alınırsa ve hala "taze" olarak kabul edilirse, derhal önbellek yoluyla geri gönderilir. ( Tüm DNS önbellekleri bu şekilde çalışır, böylece söz konusu sitenin DNS sunucularını gereksiz yere zorlamazlar. )
  3. Bu kaydı önbelleğe almadılarsa veya önbellek "eski / eski" olarak kabul edilirse, İSS en son kaydı yeniden çözmesi gerektiğini bilir.
  4. Şimdi ISS'nin en son kayıt hakkında hangi ad sunucularını sorgulayacağını bilmesi gerekiyor.
  5. ISS, etki alanı için yetkili ad sunucularının önbelleğe alınmış listesini kontrol ederek başlar (bunlar ns1.example.com, ns2.example.com vb. IP'leriyle birlikte). Bu kayıtlar hala yeni kabul edilirse, 8. adıma atlar.
  6. Önbelleğe alınan ad sunucusu kayıtlarının süresi dolduysa veya bu etki alanı için önbelleğe alınmış herhangi bir kaydı yoksa, ISS, TLD'nin kök ad sunucularını (bir .com etki alanı ise .com kayıt defteri gibi) sorgular. example.com için en güncel ad sunucusu adı / IP çiftleri. ( TLD'niz için kök ad sunucularının alan adınız hakkında ne bildiğini görmek için bunu "dig @ b.gtld-servers.net example.com" aracılığıyla kendiniz deneyebilirsiniz - alan adınız normal com / net / etc TLD'lere aitse. TLD'lerin ilgili kök sunucularını sorgulaması gerekir. )
  7. TLD'nin kök ad sunucuları , ad sunucularını her zaman sizin belirttiğiniz sırayla döndürür ; hiçbir randomizasyon devam etmez. Ayrıca her ad sunucusu için IP'leri döndürürler; Bu "TUTKAL" olarak bilinir ve internetin, bir alan adı hakkında hiçbir şey bilmeden önce bir ad sunucusu ana bilgisayar adının bir IP'ye nasıl çözüleceğine ilişkin "tavuk ve yumurta" sorununu çözmesine izin veren şeydir. Dahası, çoğu (en büyük olanlar olan com / net / etc kayıtları gibi) 2 günlük bir önbellek süresi kullanırlar, böylece "X alanı için ad sunucularının listesi nedir?" istekleri. Bu, yeni ad sunucularınızın dünya çapında tanındığını söyleyene kadar 2 gün beklemeniz GEREKEN ortak bilginin kaynağıdır.
  8. ISS, example.com'un ad sunucularını ve ns1.example.com, ns2.example.com, ns3.example.com gibi IP'lerini bildiğinde, ISS bu listeden rasgele bir sunucu seçer ve sorguyu gönderir. ( Bu güzel, söz konusu sitenin tüm DNS sunucularını gereksiz yere çekiçlemiyorlar ve her zaman listelenen ilk ad sunucusunu sorgulayarak yük dengelemeye daha fazla yardımcı oluyorlar. )
  9. İSS, belirli bir zaman aşımı süresi içinde bu ad sunucusundan yanıt alamazsa, listedeki başka bir sorguyu sorgular.
  10. Bir yanıtı olduğunda, ISS şimdi kendi yerel önbelleğinde saklar. Ne kadar süre önbellekli kalacağına gelince; herhangi bir DNS sunucusu tarafından döndürülen her kayıt aynı zamanda kendisiyle ilişkilendirilmiş bir "yumuşak süre sonu" süresine (saniye cinsinden) sahiptir. Bu, sorgulama istemcisinin (ISS'nin DNS sunucusu gibi) dikkate alınmadan önce bu kaydı önbelleğe almasına izin verilir " yine de kullanılabilir, ancak güncelliğini yitirmişse, yalnızca değiştirilmediğinden emin olmak için OLASI OLURSA yeni bir sorgu gerçekleştirilmelidir. " Ayrıca her bir ad sunucusunun "SOA" (Yetki Başlangıcı) kaydında belirtilen "zor sona erme" süresi de vardır (sizinkini "dig @ ns1.example.com example.com -t soa" aracılığıyla görebilirsiniz) söz konusu sunucu tarafından döndürülen tüm kayıtlar için genel bir "kesin sınır" belirtir, bundan sonra herhangi bir önbellek, isim sunucuları kapalıysa önbelleğe alınmış kaydını SİLMELİDİR ve kayıtları tekrar aramak imkansızdır. Genellikle yumuşak son kullanma süresi 30 dakika ila 5 saat arasındadır ve sert son kullanma süresi genellikle 1-3 hafta arasındadır.
  11. Bu kapsamlı işten sonra, ISP nihayet en son DNS kaydına sahiptir ve sahnenin arkasında ne kadar büyük bir işin gerçekleştiğini bilmeyen sorgulayıcı geniş bant abonesine geri gönderebilir!

Bu işlem HER kayıt araması için tekrarlanır. Ancak, yalnızca ilk sorgu tüm işi yapar; ad sunucusu IP'leri bundan sonra önbelleğe alınacak ve ISS'nin önbelleğe alınan DNS sunucusuna yapılan sonraki sorgular hızlı bir şekilde 8. adıma geçebilecektir.

Şimdi, 8. adımın randomizasyonuna gelince, kayıt düzeyinde çalışır. Diyelim ki ISS'nin geniş bant abonesi aşağıdaki kayıtları sordu:

  • Bir foo.example.com
  • Example.com
  • Bir www.example.com
  • MX example.com (bir İSS müşterisi bu kaydı istememelidir, ancak bu sadece bir örnektir)

Her kayıt bağımsız olarak önbelleğe alınmış ve aranan kendi ayrı "varlığı" olarak işlenecektir. Yani, diyelim ki abone ve İSS alan adına daha önce hiç rastlamadı ve her ikisinin de tamamen önbelleğe alınmış kayıtları yok. Aramalar aşağıdaki gibi olabilir:

  • Ns1.example.com aracılığıyla bir foo.example.com, daha sonra ISS önbelleğinde depolandı
  • Ns3.example.com aracılığıyla bir example.com, daha sonra ISS önbelleğinde depolanıyor
  • Ns2.example.com aracılığıyla bir www.example.com, daha sonra ISS önbelleğinde depolanıyor
  • Ns3.example.com aracılığıyla MX example.com, daha sonra ISS önbelleğinde depolandı

Önbelleğe alınan kayıtların süresi sona erdiğinde işlem tekrarlanır, böylece bu kayıt için sonraki isteklerin aynı sunucuyu tekrar kullanacağını bile bilmezsiniz.

Bu nedenle, tüm DNS sunucularınızın birbirleriyle tamamen senkronize olduğundan emin olmak ve her DNS kaydını her sunucuda mükemmel bir şekilde yansıtmak mutlak en büyük hedefinizdir . Bir DNS istemcisinin hangi sunucuya vuracağını asla bilemezsiniz ve herhangi bir siparişe güvenemezsiniz. Öyle bir şey yok.

Ayrıca, Adam C tarafından belirtildiği gibi, sunucu düzeyi (example.com) DNS sunucularının kendileri NS kayıtlarını döndürebilir ve bunların sırasını rasgele seçebilir. Normal DNS sunucularının NS kayıtlarını, kötü bir DNS uygulamasının her zaman ilk döndürülen ad sunucusunu seçmesi olasılığına karşı rasgele dağıtması çok yaygındır. Ancak, ROOT TLD ad sunucuları (daha önce bahsedilmişti) listeyi asla rastgele seçmeyecek ve etki alanını çözmek söz konusu olduğunda bunların listesi gerçekten önemlidir. Bu nedenle, çoğu uygulama her zaman aynı sunucuya çarpmamak ve aşırı yüklenmesini önlemek için ad sunucusu listelerinden rastgele bir sunucu seçer.

Pekala, DNS'in nasıl çalıştığı ve neleri hatırlamanız gerektiği konusunda sizin öncünüz.

  • Kısacası: Tüm DNS sunucularınıza sanki tek bir sunucu gibi davranın ve onlara atılabilecek herhangi bir sorguyu eşit şekilde yanıtlayabilmelerini sağlamak için hayattaki en yüksek hedefiniz olmasını sağlayın .

Feragatname: Hayatta DNS'yi yönetmekten daha yüksek hedefler mevcut olabilir, ancak ayrı olarak satılır, hayal gücünüzü kullanın. ;-)

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.