Kök Adı Sunucularının tüm DNS isteklerini işlemesi nasıl mümkün olabilir?


18

Birkaç gün önce DNS hakkında okuyordum ve isteklerin nasıl işlendiğini öğrendim. Www.example.com adresine giderseniz, bu .com adresine kimin sahip olduğunu görmek için Kök Adı Sunucularına bir istek gönderilir, o zaman başka bir istek example.com'a kimin sahip olduğunu görmek için başka, daha yerel bir DNS sunucusuna gider. adresi vb.

13 Kök Adı Sunucusunun, dünyadaki milyarlarca İnternet kullanıcısı tarafından yapılan tüm talepleri aynı anda ddos: ed olmadan eşzamanlı olarak ele alması teknik olarak nasıl mümkün olabilir?


11
Bu arada, DNS'in çalışma şekli özetiniz yanlış. Kök adı sunucusuna sorulan soru ".com'un sahibi kim?" Değil. ancak "www.example.com'un IP adresi nedir?" (kök adı sunucusu, .com sahibine yapılan bir başvuru ile yanıt verir). Kök adı sunucusu tüm sorguyu görür (istatistik, veri madenciliği vb. İçin yararlıdır).
bortzmeyer

@bortzmeyer Tüm adın kök sunuculara gönderilmesinin ana nedeni, addaki her noktanın zorunlu olarak bir yetki sınırı olmamasıdır. Uygulamada, TLD'nin hemen altında her zaman bir yetki sınırı olduğuna inanıyorum, ancak prensip olarak garanti edilmiyor. Bu nedenle, gelecekte bir noktada, ikinci katmanın kök sunucular tarafından işlendiği özel bir TLD uygulamaya karar verilebilir, böylece kök sunucuları sorguladığınızda, a.b.c.examplekimin sorumlu olduğu c.exampleyerine kimin sorumlu olduğu size söylenecektir example.
kasperd

Yanıtlar:


51

Bunlar 13 konum derece müsait kümeleri sunucularının değil sadece 13 sunucularını.

Diğer şeylerin yanı sıra, kök ad sunucusu operatörlerinin normal trafik yüklerinin üç katını işlemek için yeterli kapasiteye sahip olmaları gerekir ( RFC 2870 ). Bu oldukça büyük kümelere yol açar.

Ancak, kök ad sunucularının yalnızca üst düzey alan adları için tepkilerini kendilerini, yani hizmet com., net., uk., ae., vb ve kök bu bilgileri önbelleğe alabilir sorgulamak nameserverlar 48 saate kadar dramatik kök ad sunucularını de yükü azaltır. Bu, daha küçük kümelere yol açar.

Kök ad sunucuları 53 ülkede 130'un üzerinde fiziksel konumda bulunmaktadır; sadece 13 sunucu adıyla, bu IPv4 anycast büyüsü ile yapılır.

Kök ad sunucularının da ilginç bir okuma bulabileceğiniz kendi web sitesi vardır.


48 sa, kökteki NS kayıtlarının TTL'sidir. Ancak TLD'nin ad sunucuları tarafından geçersiz kılınabilir. Örneğin, .jp için sadece 24 saattir.
bortzmeyer

Eh, olan burada kök ad sunucularını bahsediyor. :)
Michael Hampton

RFC 2870 bugün oldukça eski. DDoS saldırıları nedeniyle, bir kök ad sunucusunun normal trafiğinin üç katından daha fazlasını yanıtlamaya hazır olması gerekir.
bortzmeyer

8
53 ülke? bir tesadüf mü yoksa sadece DNS sorgu portu gibi mi seçtiler ?? : D
amyassin

10

Yapmazlar. Kök ad sunucuları size hangi ad sunucularının işlediğini söylemelidir com. Bundan sonra, içindeki herhangi bir alan adını işlemek için onlara gitmenize gerek yoktur com. Kök ad sunucularının kim olduğu hakkında hiçbir fikri yoktur example.com. Bunlar kök ad sunucularıdır, com ad sunucuları değildir .

Slimsuperhero'nun söyledikleri de doğrudur. Birçok yüksek hacimli ad sunucusu , dünya çapında bir dizi sunucu tarafından sunulan tek bir IP adresine sahip olmak için anycast kullanır .


Ancak aynı milyarda 1 milyar kullanıcı farklı .com adreslerine sörf yapsaydı, kök adı sunucuları tüm istekleri ele alır mı?
Rox

3
Hayır. Bir kere, kullanıcılar yalnızca özyinelemeli ad sunucularıyla (yanıt almak için diğer ad sunucularına bağlananlar) konuşur ve kök ad sunucuları özyinelemez (yalnızca zaten bildikleri yerel bilgileri sunar). Kullanıcılar , işleyen sunucular için kök ad sunucularından yalnızca bir kez sormaları gereken kendi ad sunucularıyla (genellikle ISP'leri tarafından sağlanır) konuşur com.
David Schwartz

1
@DavidSchwartz doğrudur - bu nedenle bir milyar kullanıcıdan bir milyar talep yerine, her biri bin kullanıcıya hizmet veren bir milyon ISP'den kabaca bir milyon istek alırlar.
Shadur

@Shadur: Şimdi, isim sunucularının comçok daha büyük bir dayak alması gerekiyor.
David Schwartz

1
Ve uygun şekilde ölçeklendiklerinden ve kümelendiklerinden eminim.
Shadur

6

Her kök sunucu aslında bir sunucu değildir, büyük sunucu kümeleridir. Buna ek olarak, DNS yanıtları önbelleğe alınır, böylece her istek kök sunucuya ulaşmaz.


3

Not Eğer kök sunucularını kullanmayın. Genellikle İnternet Servis Sağlayıcınız tarafından sağlanan ve ihtiyacınız olan bilgiler yerel önbelleklerinde ise hemen yanıt verebilen DNS sunucusunu kullanırsınız. Yalnızca önbelleğe alınmazsa, akış yukarı DNS sunucuları sorulur ve yalnızca sonunda kök sunucu sorulur (ve bu yanıt daha sonra önbelleğe alınır)


0

Aslında dünyadaki birçok sunucuya çözümlenen 13 Anycast IP adresi. Gerekirse bu sunucuları bulmak için Link'e bakabilirsiniz . Tüm bu sunucular ilgili makam tarafından yönetilir.

Hala sadece 13 IP adresi (Ve aynı IP adresine sahip sunucular kümesi) kullanmamız, paket boyutunun 512 baytın ötesine geçmemesini sağlamaktır. O zaman neden? Bu paket boyutunun ötesine geçebilecek TCP'miz neden kullanamıyoruz ?. Mesele şu ki, TCP bir TCP bağlantısı kurmak için birden fazla adım ve prosedür içerdiğinden çok yüksek bir ek yük içerir. Bu nedenle, bir DNS sorgusunun tüm işlemi yavaşlar.

DNS gibi şeyler asla yavaş olamaz ve bu yüzden hala aynı eski sistemi kullanıyoruz.


Bir sorgunun cevabı .artık 512 bayta sığmıyor. IPv6 artık bir zorunluluk olduğu için cevap 811 bayta çıktı. EDNS ile tek bir yanıtla iade edilebilir. Ancak sorgular için .sık sık birkaç gidiş-dönüş bir showtopper gerekli değildir. Özyinelemelerin, köklerin IP adreslerinde nadiren değişen en son değişiklikleri öğrenmesi gerekir.
17'de kasperd

@kasperd Emin değilim. Dig + trace'i normal A kaydı veya AAAA kaydı için kontrol ettim ve tüm yanıtlar (Kök düzey sunucularından, üst düzey sunuculardan veya ad sunucularından) 508 ila 509 baytın altında. Bu konuda biraz daha açıklayabilir misiniz?
Jaison

Tam yanıtı almak için EDNS veya TCP kullanmanız gerekir. EDNS'siz UDP istekleri hiçbir zaman 512 bayttan daha uzun yanıt alamaz.
kasperd
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.