W jaki sposób Root Name Server może obsłużyć wszystkie żądania DNS?

18

Czytałem o DNS kilka dni temu i dowiedziałem się, jak przetwarzane są żądania. Jeśli przejdziesz na stronę www.example.com, żądanie przejdzie do głównego serwera nazw, aby dowiedzieć się, kto jest właścicielem tego adresu .com, a następnie kolejne żądanie przejdzie na inny, bardziej lokalny serwer DNS, aby zobaczyć, kto jest właścicielem example.com adres i tak dalej.

W jaki sposób jest technicznie możliwe, że 13 głównych serwerów nazw może obsłużyć wszystkie żądania złożone przez miliardy użytkowników Internetu jednocześnie, bez konieczności wykonywania ddos: ed?

domain-name-system nameserver ddos Rox
źródło
11
Nawiasem mówiąc, twoje podsumowanie działania DNS jest nieprawidłowe. Pytanie skierowane do głównego serwera nazw nie brzmi „kto jest właścicielem .com?” ale „jaki jest adres IP www.example.com?” (główny serwer nazw odpowiada przez odwołanie do właściciela .com). Główny serwer nazw widzi całe zapytanie (przydatne w statystyce, eksploracji danych itp.).
bortzmeyer
@bortzmeyer Głównym powodem, dla którego cała nazwa jest wysyłana do serwerów głównych, jest to, że nie każda kropka w nazwie niekoniecznie stanowi granicę władzy. W praktyce uważam, że zawsze granica władzy znajduje się tuż pod TLD, ale w zasadzie nie jest to gwarantowane. Dlatego w pewnym momencie w przyszłości może zostać podjęta decyzja o wprowadzeniu specjalnej TLD, w której druga warstwa jest obsługiwana przez serwery root, aby po zapytaniu o serwery root a.b.c.examplepowiedziano ci, kto jest odpowiedzialny, c.examplea nie kto jest odpowiedzialny example.
kasperd

Odpowiedzi:

51

Są 13 wysoce dostępnymi klastrami serwerów, a nie tylko 13 serwerami.

Między innymi operatorzy serwerów nazw root muszą mieć wystarczającą pojemność, aby obsłużyć trzykrotnie swoje normalne obciążenie ruchem ( RFC 2870 ). Prowadzi to do dość dużych klastrów.

Jednak serwery nazw korzeniowe służą jedynie odpowiedzi dla najpopularniejszych domen najwyższego poziomu, czyli siebie com., net., uk., ae., itd, a serwery nazw, które kwerendy root może buforować tę informację do 48 godzin , co znacznie zmniejsza obciążenie na serwery nazw root. Prowadzi to do mniejszych klastrów.

Główne serwery nazw znajdują się w ponad 130 fizycznych lokalizacjach w 53 krajach; z tylko 13 nazwami serwerów, odbywa się to za pomocą magii anycast IPv4.

Główne serwery nazw mają również własną stronę internetową , która może być interesująca do przeczytania.

Michael Hampton
źródło
48 h to TTL rekordów NS w katalogu głównym. Ale można to zastąpić serwerami nazw samej TLD. Na przykład dla .jp jest to tylko 24 godziny.
bortzmeyer
Cóż, są rozmowy na temat serwerów nazw korzeniowych tutaj. :)
Michael Hampton
RFC 2870 jest dziś dość przestarzały. Z powodu ataków dDoS główny serwer nazw musi być gotowy na ponad trzykrotny normalny ruch.
bortzmeyer
8
53 kraje? czy to przypadek, czy wybrali go tak jak port zapytania DNS? : D
amyassin
10

Oni nie. Główne serwery nazw muszą tylko powiedzieć, jakie serwery nazw obsługują com. Odtąd nie musisz się do nich udawać, aby obsłużyć jakąkolwiek domenę com. Główne serwery nazw nie mają pojęcia, kto jest właścicielem example.com. Są to główne serwery nazw, a nie serwery nazw com .

To, co powiedział slimsuperhero, jest również prawdą. Wiele serwerów nazw o dużej objętości korzysta z anycast, aby jeden adres IP był obsługiwany przez wiele serwerów na całym świecie.

David Schwartz
źródło
Ale gdyby miliard użytkowników przeglądało różne adresy .com w tym samym momencie, czy serwery nazw root obsługiwałyby wszystkie żądania?
Rox
3
Nie. Z jednej strony użytkownicy rozmawiają tylko z rekurencyjnymi serwerami nazw (tymi, którzy łączą się z innymi serwerami nazw, aby uzyskać odpowiedzi), a główne serwery nazw nie są rekurencyjne (służą tylko lokalnym informacjom, które już znają). Użytkownicy rozmawiają ze swoimi własnymi serwerami nazw (zwykle dostarczanymi przez ich usługodawcę internetowego), którzy muszą tylko raz zapytać główne serwery nazw dla serwerów, które obsługują com.
David Schwartz
1
@DavidSchwartz ma rację - więc zamiast miliarda żądań od miliarda użytkowników otrzymaliby tylko około miliona żądań od miliona dostawców usług internetowych, z których każdy obsługuje tysiąc użytkowników.
Shadur
@Shadur: Teraz serwery nazw dla comz drugiej strony muszą być znacznie bardziej masywne.
David Schwartz
1
I jestem całkiem pewien, że są odpowiednio skalowane i grupowane.
Shadur
6

Każdy serwer root nie jest tak naprawdę serwerem, są to ogromne klastry serwerów. Oprócz tego odpowiedzi DNS są buforowane, więc nie każde żądanie dociera do serwera root.

Gevial
źródło
3

Pamiętaj, że nie korzystasz z serwerów głównych. Zwykle używasz serwera DNS dostarczonego przez dostawcę usług internetowych, który zazwyczaj może natychmiast zareagować, jeśli potrzebne informacje znajdują się w lokalnej pamięci podręcznej. Tylko jeśli nie jest w pamięci podręcznej, pytany jest ich serwer DNS, a dopiero potem serwer główny (i ta odpowiedź jest następnie buforowana)

Thorbjørn Ravn Andersen
źródło
0

W rzeczywistości jest to 13 Anycastowy adres IP, który można znaleźć na wielu serwerach na całym świecie. Możesz spojrzeć na link, aby znaleźć te serwery w razie potrzeby. Wszystkimi tymi serwerami zarządza zainteresowany organ.

Fakt, że nadal używamy tylko 13 adresów IP (i klastra serwerów posiadających ten sam adres IP) polega na tym, że rozmiar pakietu nie przekroczy 512 bajtów. To dlaczego? mamy TCP, który może przekroczyć ten rozmiar pakietu, dlaczego nie możemy go użyć ?. Chodzi o to, że TCP wiąże się z bardzo dużym obciążeniem, ponieważ obejmuje wiele kroków i procedur w celu ustanowienia połączenia TCP. Z tego powodu cały proces zapytania DNS będzie przebiegał powoli.

Rzeczy takie jak DNS nigdy nie mogą być wolne i dlatego wciąż używamy tego samego starego systemu.

Jaison
źródło
Odpowiedź na zapytanie .nie mieści się już w 512 bajtach. Ponieważ IPv6 jest teraz koniecznością, odpowiedź wzrosła do 811 bajtów. Z EDNS, które można zwrócić w jednej odpowiedzi. Jednak zapytania .nie są potrzebne tak często, że kilka podróży w obie strony jest wizytówką. Jest to przede wszystkim potrzebne, aby rekursory poznały najnowsze zmiany adresów IP rdzeni, które rzadko się zmieniają.
kasperd
@kasperd Nie jestem pewien. Sprawdziłem dig + trace dla normalnego rekordu A lub rekordu AAAA i wszystkie odpowiedzi (z serwerów poziomu root, serwerów najwyższego poziomu lub serwerów nazw) mają mniej niż 508 do 509 bajtów. Czy możesz wyjaśnić trochę więcej na ten temat.
Jaison
Aby uzyskać pełną odpowiedź, musisz użyć EDNS lub TCP. Żądania UDP bez EDNS nigdy nie mogą uzyskać odpowiedzi dłuższej niż 512 bajtów.
kasperd