jak działa zapytanie dns [zamknięte]

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ę.

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.

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.

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”.

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

Nie mylisz się Oto świetna ilustracja działania zapytania DNS.

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