jak działa zapytanie dns [zamknięte]

7

kiedy piszę www.google.com, jak działa wyszukiwanie dns. Według mojej wiedzy najpierw trafia do serwera root i sprawdza, gdzie jest serwer .com dns. Następnie zwraca adres IP tego serwera. Następnie znajduje się informacja, gdzie znajduje się serwer Google. Teraz zwraca adres IP i byłoby to miejsce, w którym znajduje się www.google.com.

Aby rozwiązać ten problem, potrzebne są dwa wyszukiwania DNS. Popraw mnie, jeśli się mylę.

domain-name-system 
— użytkownik68350
źródło
Najpierw zostanie zapytany serwer DNS, który komputer skonfigurował statycznie lub otrzymał przez DHCP. Ten serwer może być w stanie bezpośrednio odpowiedzieć na twoje zapytanie, ponieważ jest autorytatywny dla nazwy, o którą prosiłeś lub ponieważ buforował odpowiedź. Tylko jeśli nie, używane są inne serwery DNS i serwer główny. Ale w zasadzie (bez buforowania) masz rację.
— Christoph
co masz na myśli mówiąc, że w końcu używany jest serwer root? Myślałem, że pierwsze wyszukiwanie dotyczy serwera root?
— user68350,
Administrator może zainstalować kopie stref, które są okresowo aktualizowane, na serwerze, aby zapewnić klientom szybsze odpowiedzi. Oczywiście nie można przechowywać całego Internetu, więc używane serwery zależą od tego, czy jest kopia, czy nie. Czy jesteś zainteresowany tym, co naprawdę się dzieje (co może być bardzo skomplikowane) lub co się dzieje w zasadzie?
— Christoph

Odpowiedzi:

6

Rozdzielczość DNS może stać się dość owłosiona, gdy zaczniesz rozważać takie rzeczy, jak buforowanie i anycast, ale na razie zachowajmy prostotę.

Oto fragmenty wykopów obok fragmentów tcpdump zapytania dla www.google.com do świeżo uruchomionego serwera nazw, więc nie jest używane buforowanie. Skróciłem niektóre znaczniki czasu dla czytelności.

Po pierwsze, lokalny serwer nazw (tutaj 192.168.10.10) zadaje jednemu z serwerów głównych (w tym przypadku h.root-servers.net, 128.63.2.53) pytanie „czym jest rekord A dla www.google.com?” h.root-servers.net nie jest autorytatywny dla www.google.com, ale ma delegację dla .com, więc zwraca to.

192.168.10.10.17203 > 128.63.2.53.53: 29969 [1au] A? www.google.com. (43)
128.63.2.53.53 > 192.168.10.10.17203: 29969- 0/15/16 (719)

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; AUTHORITY SECTION:
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.

Po drugie, lokalny serwer nazw wybiera następnie jeden z serwerów nazw z listy zwróconej przez h.root-servers.net i wysyła to samo zapytanie: „co to jest rekord A dla www.google.com?” W tym przypadku zapytano o serwer nazw f.gtld-servers.net (192.35.51.30). f.gtld-servers.net, która jest autorytatywna dla .com, odpowiedziała delegacjami serwera nazw dla strefy google.com

192.168.10.10.65182 > 192.35.51.30.53: 58632 [1au] A? www.google.com. (43)
192.35.51.30.53 > 192.168.10.10.65182: 58632- 0/4/5 (179)

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; AUTHORITY SECTION:
google.com.             172800  IN      NS      ns2.google.com.
google.com.             172800  IN      NS      ns1.google.com.
google.com.             172800  IN      NS      ns3.google.com.
google.com.             172800  IN      NS      ns4.google.com.

Zbliżać się! Teraz lokalny serwer nazw wybiera jeden z serwerów nazw w ostatniej odpowiedzi i zadaje to samo pytanie. W takim przypadku pyta ns2.google.com (216.239.34.10). ns2.google.com odpowiada, że ​​www.google.com jest w rzeczywistości rekordem CNAME (nazwa kanoniczna) dla www.l.google.com

192.168.10.10.4767 > 216.239.34.10.53: 15830 [1au] A? www.google.com. (43)
216.239.34.10.53 > 192.168.10.10.4767: 15830*- 6/0/0 CNAME[|domain]

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         604800  IN      CNAME   www.l.google.com.

Bardzo blisko! Teraz potrzebujemy tylko adresu www.l.google.com. Ponieważ znamy już serwery nazw dla google.com, po prostu pytamy jednego z nich. W takim przypadku pytamy ns3.google.com (216.239.36.10) „jaki jest rekord A dla www.l.google.com.” Odpowiada na adres, a my mamy naszą odpowiedź:

192.168.10.10.63657 > 216.239.36.10.53: 62511 [1au] A? www.l.google.com. (45)
216.239.36.10.53 > 192.168.10.10.63657: 62511*- 5/0/0 A[|domain]

;; QUESTION SECTION:
;www.l.google.com.              IN      A

;; ANSWER SECTION:
www.l.google.com.       300     IN      A       74.125.232.116
www.l.google.com.       300     IN      A       74.125.232.112
www.l.google.com.       300     IN      A       74.125.232.115
www.l.google.com.       300     IN      A       74.125.232.113
www.l.google.com.       300     IN      A       74.125.232.114

Huzzah!

W każdym razie mam nadzieję, że to wystarczy, aby zacząć. Istnieje wiele świetnych zasobów. Książka O'Reilly „DNS and BIND” jest bardzo przydatna.

Bardzo gorąco polecam zainstalowanie programu dig w celu sprawdzenia, jak przebiegają zapytania DNS. Na przykład możesz użyć dig + trace, aby łatwo zobaczyć ścieżkę delegowania do hosta:

; <<>> DiG 9.7.0-P1 <<>> +trace www.google.com
;; global options: +cmd
.                       516930  IN      NS      k.root-servers.net.
.                       516930  IN      NS      g.root-servers.net.
.                       516930  IN      NS      h.root-servers.net.
.                       516930  IN      NS      j.root-servers.net.
.                       516930  IN      NS      a.root-servers.net.
.                       516930  IN      NS      m.root-servers.net.
.                       516930  IN      NS      b.root-servers.net.
.                       516930  IN      NS      f.root-servers.net.
.                       516930  IN      NS      d.root-servers.net.
.                       516930  IN      NS      c.root-servers.net.
.                       516930  IN      NS      l.root-servers.net.
.                       516930  IN      NS      i.root-servers.net.
.                       516930  IN      NS      e.root-servers.net.
;; Received 244 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms

com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
;; Received 492 bytes from 202.12.27.33#53(m.root-servers.net) in 45 ms

google.com.             172800  IN      NS      ns2.google.com.
google.com.             172800  IN      NS      ns1.google.com.
google.com.             172800  IN      NS      ns3.google.com.
google.com.             172800  IN      NS      ns4.google.com.
;; Received 168 bytes from 192.33.14.30#53(b.gtld-servers.net) in 42 ms

www.google.com.         604800  IN      CNAME   www.l.google.com.
www.l.google.com.       300     IN      A       74.125.232.115
www.l.google.com.       300     IN      A       74.125.232.113
www.l.google.com.       300     IN      A       74.125.232.116
www.l.google.com.       300     IN      A       74.125.232.114
www.l.google.com.       300     IN      A       74.125.232.112
;; Received 132 bytes from 216.239.34.10#53(ns2.google.com) in 131 ms

Zauważ, jak podobny jest do śladu zapytania wcześniej? Mam nadzieję, że to pomaga.

— Cakemox
źródło
Myślę, że warto wspomnieć, że rekursywny serwer nazw zna adresy IP serwerów nazw dla strefy głównej - nazywane są root serwerami nazw - z jego konfiguracji (plik root.hints) lub są one kompilowane w jego źródle.
— ZaphodB
4

Jest to nieco bardziej skomplikowane, ponieważ DNS jest dość mocno buforowany. Komputer lokalny może nawet buforować dane, a wyszukiwanie nie idzie dalej.

Maszyna zapyta o swoją własną pamięć podręczną, a jeśli to się nie powiedzie, zapyta o podstawowy serwer DNS, o którym została poinformowana. Może to być buforujący serwer DNS, a mój wynik powoduje pamięć podręczną, w którym to przypadku rekord jest zwracany i wyszukiwanie kończy się. Jest to również najprawdopodobniej rekursywny serwer DNS i teraz wykona legalną pracę dla twojego komputera.

Jeśli podstawowy serwer DNS nie ma informacji, zapyta o główne serwery nazw, na które odpowiedzą (w twoim przykładzie) na serwery nazw TLD dla .com

Zapytanie zostanie wysłane na serwery .com TLD, które odpowiedzą na adres wiarygodnego serwera nazw dla google.com

Zapytanie zostanie wysłane do autorytatywnego serwera nazw dla google.com z prośbą o rekord www.google.com. Zostanie to znalezione i zwrócone do podstawowego serwera DNS, który będzie buforował go i zwróci rekord.

— użytkownik619714
źródło
3

DNS jest hierarchiczny i, jak powiedział Lain, mocno buforowany. Być może bardziej skomplikowany przykład może ci pomóc.

Załóżmy, że masz komputer należący do firmy z kilkoma jednostkami biznesowymi odzwierciedlonymi w strukturze domeny. Twój komputer ma nazwę machine.businessunit1.company.com, tzn. Należy do businessunit1.company.com, który jest twoim głównym sufiksem DNS.

Jednostka biznesowa jest bardzo duża i obsługuje kilka serwerów DNS (dns1.businessunit1.company.com, dns2.businessunit1.company.com), a także np. Serwer internetowy o nazwie www.businessunit1.company.com.

Jeśli twój komputer chce teraz rozwiązać www.businessunit1.company.com, najpierw przeszuka lokalną pamięć podręczną DNS. I. e. Twoje urządzenie pamięta ostatnio wprowadzone przez Ciebie wpisy DNS, ponieważ jest bardzo prawdopodobne, że będziesz potrzebować wyników ponownie, np. po kliknięciu łącza na stronie internetowej. Nie wiem, czy możesz zobaczyć, co twój komputer zapisał w pamięci podręcznej, ale istnieje polecenie usunięcia wszystkiego, co zapamiętał twój komputer (w systemie Windows):ipconfig /flushdns

Jeśli twoje urządzenie nie pamięta odpowiedzi, zapyta - jak już wcześniej skomentowałem - serwery DNS skonfigurowane dla twojej karty sieciowej. Najprawdopodobniej Twoi administratorzy skonfigurują dns1.businessunit1.company.com i dns2.businessunit.company.com. Powodem tego jest to, że chcesz szybko odpowiedzieć na zapytanie DNS bez dużego ruchu. Jeśli dns1.businessunit1.company.com otrzyma zapytanie dotyczące www, odpowie na nie, ponieważ jest autorytatywne dla strefy * .businessunit1.company.com. Autorytatywny oznacza, że ​​ten serwer zna jedyną prawidłową odpowiedź dla wszystkich nazw DNS kończących się na „businessunit1.company.com”.

Załóżmy teraz, że masz zapytania www.businessunit2.company.com. Twój komputer, jeśli nie pamięta samej odpowiedzi, ponownie zapyta dns1.businessunit1.company.com. Teraz jest wiele możliwości: po pierwsze, twoi administratorzy mogą być sprytni i przewidzieli, że jest bardzo prawdopodobne, że ludzie z businessunit1 również będą chcieli często uzyskiwać dostęp do maszyn w businessunit2. Dlatego skonfigurowali dns1.businessunit1.firma.com do przechowywania kopii danych z dns1.businessunit2.firma.com. dns1.businessunit1.company.com może użyć tej kopii, aby odpowiedzieć na twoje pytanie. Po drugie, administratorzy z pewnością powiedzą dns1.businessunit1.company.com, co mają robić, gdy nie znają odpowiedzi na twoje pytanie: pyta inny serwer DNS. Prawdopodobnie jest to dns1.company.com, ale może to być również dowolny inny serwer DNS, w tym serwery root.

Jak powiedział Lain, dns1.businessunit1.company.com może zapamiętać każdą odpowiedź otrzymaną od innych serwerów DNS. I. e. jeśli poprosisz o www.google.com, być może będziesz musiał poprosić o inny serwer, ale jeśli poprosisz po raz drugi, zapamięta odpowiedź i powie ci bezpośrednio.

Zasadniczo możesz zobaczyć, skąd pochodzi twoja odpowiedź DNS, pisząc np nslookup www.google.com. Dane wyjściowe powiedzą serwerowi i czy jest to wiarygodna odpowiedź, czy nie. Najprawdopodobniej będzie to nieautorytatywne, ponieważ nie odpowiada na to serwer DNS Google, który jest odpowiedzialny za wszystkie nazwy DNS kończące się na „google.com”.

— Christoph
źródło
Możesz wyświetlić lokalną pamięć podręczną DNS, używającipconfig /displaydns
— Christoph,
1

W rzeczywistości wszystko jest bardzo skomplikowane i zależy od serwera DNS. Bez ograniczeń, zrób 66 zapytań .

— alvosu
źródło
0

To jest poprawne. I może jeszcze 1 szuka subdomeny „www”.

— Jonathan Rioux
źródło
mogą istnieć miliony adresów URL z częścią www. Jak zdobyć unikalny adres IP, jeśli wyszukujesz www?
— user68350,
Hierarchia DNS przebiega od początku do końca. Jeśli wpiszesz www, lista wyszukiwania DNS twojego urządzenia zostanie użyta do uzupełnienia nazwy.
— Christoph
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.