Jak zasadniczo działa rozpoznawanie nazw DNS?

W tej chwili biorę kurs online dla systemu Linux i zadano mi pytanie, którego po prostu nie rozumiem. Wiem, jak wyszukać serwer nazw, jeśli mam rację, przynajmniej używa komendy dig, aby znaleźć adres w dodatkowym poleceniu sekcji, ale trochę się zagubiłem, gdy zadałem następujące pytanie.

Zakładając, że skonfigurowany serwer nazw nie ma do dyspozycji żadnych wyników w pamięci podręcznej, ile serwerów nazw musi zapytać serwer nazw w celu rozwiązania maps.google.com? Jakich poleceń użyłbyś do znalezienia wszystkich tych serwerów nazw? Wymień jeden z każdego poziomu i wyjaśnij, dlaczego ten poziom jest potrzebny.

Nie chcę odpowiedzi, chciałbym tylko wiedzieć, o co dokładnie jestem proszony.

Zakładając, że skonfigurowany serwer nazw nie ma do dyspozycji żadnych wyników w pamięci podręcznej, ile serwerów nazw musi zapytać serwer nazw w celu rozwiązania maps.google.com? Jakich poleceń użyłbyś do znalezienia wszystkich tych serwerów nazw? Wymień jeden z każdego poziomu i wyjaśnij, dlaczego ten poziom jest potrzebny.

Wybierzmy to osobno.

„Zakładając, że skonfigurowany serwer nazw nie ma do dyspozycji żadnych wyników w pamięci podręcznej” - po pierwsze, jeśli w ogóle nie ma danych w pamięci podręcznej, nie może niczego rozwiązać. Aby przygotować pamięć podręczną resolvera, musisz mieć rekord NS i adres (A, AAAA) dla strefy .(root). To główne serwery nazw, które znajdują się w root-servers.net.strefie. W tej strefie lub tych serwerach DNS nie ma nic magicznego. Jednak dane te są często dostarczane „poza pasmem” do resolvera DNS, właśnie w celu przygotowania pamięci podręcznej resolvera. Serwery nazw tylko do autorytetu nie potrzebują tych danych, ale serwery rozpoznające je potrzebują.

Również „rozwiązać” na co? Jakikolwiek typ RR o tej nazwie? ARR? Albo coś innego? Jaka klasa ( CH/ Chaosnet, IN/ Internet, ...)? Dokładny proces będzie inny, ale ogólna idea pozostanie taka sama.

Jeśli możemy założyć, że wiemy, jak znaleźć główne serwery nazw, ale nic więcej, a przez „rozwiązanie” rozumiemy uzyskanie zawartości wszystkich IN ARR powiązanych z nazwą, staje się to o wiele bardziej praktyczne.

Aby rozwiązać nazwę DNS, po prostu podziel nazwę na etykiety, a następnie przejdź od prawej do lewej. Nie zapomnij .na końcu; naprawdę byłbyś maps.google.com.bardziej zdecydowany niż maps.google.com. To pozostawia nam konieczność rozwiązania (wiemy o tym, ale prawdopodobnie implementacja usługi rozpoznawania nazw DNS nie zrobi tego):

• .
• com.
• google.com.
• maps.google.com.

Zacznij od zastanowienia się, gdzie poprosić o treść .. To łatwe; mamy już te informacje: nazwy głównych serwerów nazw i adresy IP . Mamy więc główny serwer nazw. Powiedzmy, że zdecydowaliśmy się użyć 198.41.0.4 ( a.root-servers.net, także 2001: 503: ba3e :: 2: 30), aby kontynuować rozpoznawanie nazw. W praktyce jedną z pierwszych rzeczy wykonanych przez resolver będzie prawdopodobnie użycie dostarczonych danych serwera głównego, aby poprosić jeden z serwerów strefy głównej o dokładną listę serwerów nazw dla strefy głównej, zapewniając w ten sposób, że którykolwiek nazwy i adresy IP są prawidłowe i dostępne, będzie miał pełny i kompletny zestaw danych dla strefy głównej po rozpoczęciu rozwiązywania.

maps.google.com. IN AWystrzel zapytanie DNS dla adresu 198.41.0.4. W odpowiedzi powie „nie, nie zrobię tego, ale oto ktoś, kto może wiedzieć”; to jest skierowanie. Zawiera NSrekordy najbliższej strefy, o której serwer wie, a także wszelkie rekordy kleju, które serwer ma do dyspozycji. Jeśli dane kleju nie są dostępne, najpierw musisz rozwiązać problem z hostem wymienionym w wybranym rekordzie NS, więc odtwórz osobne rozpoznawanie nazw, aby uzyskać adres IP; jeśli dane kleju są dostępne, będziesz mieć adres IP serwera nazw, który jest co najmniej „bliżej” odpowiedzi. W tym przypadku będzie to zestaw serwerów dla com.strefy, a także dane dotyczące kleju.

Powtórz ten proces, zadając jednemu z com.serwerów nazw to samo pytanie. Oni też nie wiedzą, ale przekierują cię na wiarygodne serwery nazw Google. W tym momencie w ogólnym przypadku zostanie trafione lub pominięte, czy dane dotyczące kleju są dostarczane, czy nie; nic nie stoi na przeszkodzie, comaby domena miała tylko serwery nazw nl, na przykład w takim przypadku mało prawdopodobne jest, aby dane kleju były dostępne z serwerów gTLD. Podane dane kleju mogą być również niekompletne, a jeśli naprawdę masz pecha, może być nawet niepoprawne! Trzeba zawsze być przygotowanym na tarło poza tym odrębna uchwała nazwa wspomniałem powyżej.

Zasadniczo kontynuujesz, dopóki nie otrzymasz odpowiedzi z aaustawioną flagą (odpowiedź autorytatywna). Że odpowiedź powie Ci co prosisz, albo że RR prosiłeś nie istnieje (albo NXDOMAIN, albo NOERRORzero rekordów danych odpowiedzi). Wypatruj odpowiedzi takich jak SERVFAIL(i wycofaj się o jeden krok i wypróbuj inny serwer, jeśli go otrzymasz; jeśli wszystkie wymienione serwery powrócą SERVFAIL, zakończ proces rozpoznawania nazw i wróć SERVFAILdo klienta).

Alternatywą do prosząc o pełnej RRname z każdego serwera (co może być uznane za złą praktyką) jest użycie listy split-up etykiet, które ustaliliśmy wcześniej, zapytać serwery nazwa nadana przez serwer dalej w kierunku korzenia do IN NSi IN A/ IN AAAARR dla tej etykiety i użyj jej do dalszego rozpoznawania nazw. W praktyce jest to tylko nieznacznie inne i nadal obowiązuje ten sam proces.

Możesz symulować cały ten proces, korzystając z +traceopcji dignarzędzia, która jest częścią BIND lub set debugw nslookup.

To też warto pamiętać, że niektóre RRtypes (zwłaszcza NS, MXoraz kilka innych, również, A6po przystępnej dobrze wykorzystane na chwilę, ale została wycofana) i można zrobić referencyjnych inne RR. W takim przypadku konieczne może być odrodzenie jeszcze jednego procesu rozpoznawania nazw, aby udzielić pełnej i przydatnej odpowiedzi klientowi.

Istnieje dnstracerpolecenie (może być konieczne jego zainstalowanie, przynajmniej na Debianie, to także nazwa pakietu), które będzie śledzić rozpoznawanie nazw. Możesz także (jak Koveras wskazuje w komentarzu) użyć dig.

Oto z dnstracer. -s .oznacza zacząć od roota; -4oznacza użycie IPv4 (tutaj jest uszkodzona wersja 6 ...); -ooznacza wyświetlanie adresów IP na końcu (pominąłem tę część danych wyjściowych, jest ich dużo).

anthony@Zia:~$ dnstracer -s . -4 -o maps.google.com
Tracing to maps.google.com[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4) 
 |\___ m.gtld-servers.net [com] (192.55.83.30) 
 |     |\___ ns4.google.com [google.com] (216.239.38.10) Got authoritative answer 
 |     |\___ ns3.google.com [google.com] (216.239.36.10) Got authoritative answer 
 |     |\___ ns1.google.com [google.com] (216.239.32.10) Got authoritative answer 
 |      \___ ns2.google.com [google.com] (216.239.34.10) Got authoritative answer 
⋮

To wyjście jest kontynuowane, ponieważ dnstracer śledzi wszystkie ścieżki (abyś mógł zobaczyć, czy np. Niektóre serwery nazw mają przestarzałą strefę).

Widzisz więc, że jedno zapytanie kierowane jest do głównego serwera nazw, następnie do serwerów gtld (serwer strefy .com), a wreszcie do serwera nazw Google.

Z dig, wyjście jest znacznie bardziej szczegółowe (więc zrobię dużo cięcia):

dig -4 maps.google.com. +norecurse +trace
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> maps.google.com. +norecurse +trace
;; global options: +cmd
.                       425379  IN      NS      b.root-servers.net.
⋮
com.                    172800  IN      NS      f.gtld-servers.net.
⋮
google.com.             172800  IN      NS      ns2.google.com.
⋮
maps.google.com.        300     IN      A       74.125.228.70
⋮

digdodatkowo pokazuje, że wykonał zapytanie w celu uzyskania bieżącej listy głównych serwerów nazw. Jest to coś, co zwykle robi serwer DNS bardzo rzadko. Nie jestem więc pewien, czy policzysz to w skrzynce na zimno.

Oczywiście możesz również oglądać aktualne zapytania za pomocą np wireshark..