Dlaczego DNS działa tak, jak działa?

To jest pytanie kanoniczne dotyczące usługi DNS (Domain Name Service).

Jeśli moje rozumienie systemu DNS jest prawidłowe, rejestr .com zawiera tabelę mapującą domeny (www.example.com) na serwery DNS.

1. Jaka jest zaleta? Dlaczego nie zmapować bezpośrednio na adres IP?

2. Jeśli jedyny rekord, który musi się zmienić, gdy konfiguruję serwer DNS tak, aby wskazywał inny adres IP, znajduje się na serwerze DNS, dlaczego proces nie jest natychmiastowy?

3. Jeśli jedynym powodem opóźnienia są pamięci podręczne DNS, czy można je ominąć, aby zobaczyć, co dzieje się w czasie rzeczywistym?

W rzeczywistości jest to bardziej skomplikowane - zamiast jednego „centralnego rejestru (który) zawiera tabelę mapującą domeny (www.mysite.com) na serwery DNS”, istnieje kilka warstw hierarchii

Jest to centralny rejestr (serwery root), które zawierają tylko niewielki zestaw wpisów: NS (nameserver) zapisy dla wszystkich domen najwyższego poziomu - .com, .net, .org, .uk, .us, .au, i tak dalej.

Te serwery zawierają tylko rekordy NS dla następnego poziomu niższego. Aby wybrać jeden przykład serwery nazw dla .ukdomeny ma tylko wpisy dotyczące .co.uk, .ac.ukoraz inne strefy drugiego poziomu używane w Wielkiej Brytanii.

Serwery te zawierają tylko rekordy NS na następny poziom niżej - aby kontynuować przykład, podają, gdzie znaleźć rekordy NS google.co.uk. Na tych serwerach w końcu znajdziesz mapowanie między nazwą hosta www.google.co.uki adresem IP.

Jako dodatkowe zmarszczki każda warstwa będzie również służyć do zapisywania „kleju”. Każdy rekord NS mapuje domenę na nazwę hosta - na przykład rekordy NS dla .uklisty nsa.nic.ukjako jeden z serwerów. Aby przejść do następnego poziomu, musimy dowiedzieć się, że rekordy NS nic.uksą, i okazuje się, że zawierają nsa.nic.ukrównież. Więc teraz musimy znać adres IP nsa.nic.uk, ale aby się tego dowiedzieć, musimy wykonać zapytanie nsa.nic.uk, ale nie możemy wykonać tego zapytania, dopóki nie poznamy adresu IP dla nsa.nic.uk...

Aby rozwiązać ten dylemat, serwery dla .ukdodać rekord A dla nsa.nic.ukInto the ADDITIONAL SECTIONodpowiedzi (odpowiedź poniżej przycięte dla zwięzłość):

jamezpolley@li101-70:~$dig nic.uk ns

; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14

;; QUESTION SECTION:
;nic.uk.                IN  NS

;; ANSWER SECTION:
nic.uk.         172800  IN  NS  nsb.nic.uk.
nic.uk.         172800  IN  NS  nsa.nic.uk.

;; ADDITIONAL SECTION:
nsa.nic.uk.     172800  IN  A   156.154.100.3
nsb.nic.uk.     172800  IN  A   156.154.101.3

Bez tych dodatkowych rekordów klejów nigdy nie bylibyśmy w stanie znaleźć serwerów nazw, nic.uk.a więc nigdy nie bylibyśmy w stanie wyszukać żadnych hostowanych tam domen.

Aby wrócić do swoich pytań ...

a) Jaka jest zaleta? Dlaczego nie zmapować bezpośrednio na adres IP?

Po pierwsze, umożliwia dystrybucję zmian do poszczególnych stref. Jeśli chcesz zaktualizować wpis www.mydomain.co.uk, po prostu musisz edytować informacje na serwerze mydomain.co.uknazw. Nie ma potrzeby powiadamiania centralnych .co.ukserwerów, .ukserwerów ani głównych serwerów nazw. Gdyby istniał tylko jeden centralny rejestr, który odwzorował wszystkie poziomy w dół hierarchii, który musiał być powiadamiany o każdej zmianie wpisu DNS w całym łańcuchu, byłby całkowicie zalany ruchem.

Przed 1982 r. Tak właśnie miało miejsce rozpoznawanie nazw. Jeden centralny rejestr został powiadomiony o wszystkich aktualizacjach i rozpowszechnili plik o nazwie, hosts.txtktóry zawierał nazwę hosta i adres IP każdej maszyny w Internecie. Nowa wersja tego pliku była publikowana co kilka tygodni i każda maszyna w Internecie musiałaby pobrać nową kopię. Na długo przed 1982 rokiem zaczęło to być problematyczne, dlatego wymyślono DNS, aby zapewnić bardziej rozproszony system.

Po drugie, byłby to pojedynczy punkt awarii - gdyby upadł pojedynczy centralny rejestr, cały Internet byłby offline. Posiadanie systemu rozproszonego oznacza, że ​​awarie wpływają tylko na małe części Internetu, a nie na całość.

(Aby zapewnić dodatkową redundancję, w rzeczywistości istnieje 13 oddzielnych klastrów serwerów obsługujących strefę główną. Wszelkie zmiany w rekordach domeny najwyższego poziomu muszą zostać wprowadzone do wszystkich 13; wyobraź sobie, że musisz koordynować aktualizację wszystkich 13 z nich dla każdej zmiany na dowolną nazwę hosta w dowolnym miejscu na świecie ...)

b) Jeśli jedyny rekord, który musi się zmienić, gdy konfiguruję serwer DNS, aby wskazywał inny adres IP, znajduje się na serwerze DNS, dlaczego proces nie jest natychmiastowy?

Ponieważ DNS wykorzystuje dużo pamięci podręcznej, aby zarówno przyspieszyć, jak i zmniejszyć obciążenie NS. Bez buforowania, za każdym razem odwiedził google.co.ukkomputer musiałby wychodzić do sieci patrzeć na serwery .uk, a potem .co.uk, potem .google.co.uk, potem www.google.co.uk. Te odpowiedzi niewiele się zmieniają, więc wyszukiwanie ich za każdym razem jest stratą czasu i ruchu w sieci. Zamiast tego, gdy NS zwróci rekordy do twojego komputera, będzie zawierać wartość TTL, która każe Twojemu komputerowi buforować wyniki przez kilka sekund.

Na przykład rekordy NS .ukmają TTL 172800 sekund - 2 dni. Google jest jeszcze bardziej konserwatywny - rekordy NS google.co.ukmają TTL wynoszącą 4 dni. Usługi, które polegają na możliwości szybkiej aktualizacji, mogą wybrać znacznie niższy czas wygaśnięcia - na przykład telegraph.co.ukczas wygaśnięcia ich rekordów NS wynosi zaledwie 600 sekund.

Jeśli chcesz, aby aktualizacje Twojej strefy były niemal natychmiastowe, możesz obniżyć TTL tak daleko, jak chcesz. Im niższy jest ustawiony, tym większy ruch zobaczą twoje serwery, ponieważ klienci częściej odświeżają swoje rekordy. Za każdym razem, gdy klient musi skontaktować się z Twoimi serwerami w celu wykonania zapytania, spowoduje to pewne opóźnienie, ponieważ jest to wolniejsze niż wyszukiwanie odpowiedzi w lokalnej pamięci podręcznej, więc będziesz również chciał rozważyć kompromis między szybkimi aktualizacjami a szybką usługą.

c) Jeśli jedynym powodem opóźnienia są pamięci podręczne DNS, czy można je ominąć, aby zobaczyć, co dzieje się w czasie rzeczywistym?

Tak, jest to łatwe, jeśli testujesz ręcznie za pomocą diglub podobnych narzędzi - po prostu powiedz, z którym serwerem się skontaktować.

Oto przykład buforowanej odpowiedzi:

jamezpolley@host:~$dig telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    319 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    319 IN  NS  eur3.akam.net.
telegraph.co.uk.    319 IN  NS  use2.akam.net.
telegraph.co.uk.    319 IN  NS  usw2.akam.net.
telegraph.co.uk.    319 IN  NS  use4.akam.net.
telegraph.co.uk.    319 IN  NS  use1.akam.net.
telegraph.co.uk.    319 IN  NS  usc4.akam.net.
telegraph.co.uk.    319 IN  NS  ns1-224.akam.net.

;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb  2 05:46:02 2012
;; MSG SIZE  rcvd: 198

Sekcja flagi tutaj nie zawiera aaflagi, więc możemy zobaczyć, że ten wynik pochodzi z pamięci podręcznej, a nie bezpośrednio z wiarygodnego źródła. W rzeczywistości możemy zobaczyć, że pochodzi z 97.107.133.4, który jest akurat jednym z lokalnych translatorów DNS Linode. Fakt, że odpowiedź została podana z pamięci podręcznej bardzo blisko mnie, oznacza, że ​​uzyskanie odpowiedzi zajęło mi 0 ms; ale jak zobaczymy za chwilę, cena, którą płacę za tę prędkość, jest taka, że ​​odpowiedź jest prawie 5 minut nieaktualna.

Aby ominąć resolver Linode i przejść bezpośrednio do źródła, po prostu wybierz jedną z NS i powiedz digowi, aby skontaktowała się z nim bezpośrednio:

jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    600 IN  NS  use2.akam.net.
telegraph.co.uk.    600 IN  NS  eur3.akam.net.
telegraph.co.uk.    600 IN  NS  use1.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    600 IN  NS  usc4.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-224.akam.net.
telegraph.co.uk.    600 IN  NS  usw2.akam.net.
telegraph.co.uk.    600 IN  NS  use4.akam.net.

;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb  2 05:48:47 2012
;; MSG SIZE  rcvd: 198

Widać, że tym razem wyniki zostały podane bezpośrednio ze źródła - zwróć uwagę na aaflagę, która wskazuje, że wyniki pochodzą z wiarygodnego źródła. W moim wcześniejszym przykładzie wyniki pochodzą z mojej lokalnej pamięci podręcznej, więc nie mają aaflagi. Widzę, że wiarygodne źródło dla tej domeny ustawia TTL na 600 sekund. Wyniki, które uzyskałem wcześniej z lokalnej pamięci podręcznej, miały TTL wynoszące zaledwie 319 sekund, co mówi mi, że siedzieli w pamięci podręcznej przez (600-319) sekund - prawie 5 minut - zanim je zobaczyłem.

Chociaż TTL wynosi tutaj tylko 600 sekund, niektórzy dostawcy usług internetowych będą próbowali jeszcze bardziej ograniczyć swój ruch, zmuszając swoje resolwery DNS do buforowania wyników na dłużej - w niektórych przypadkach na 24 godziny lub dłużej. Tradycyjnie (w sposób, w jaki nie wiemy, czy to jest naprawdę konieczne, ale bądźmy bezpieczni), zakładamy, że każda wprowadzona zmiana DNS nie będzie widoczna wszędzie na internet przez 24-48 godzin.

a) Liczba mapowań nazw hostów na świecie jest NAPRAWDĘ duża. Ten system przekazuje odpowiedzialność za hosting wszystkich rekordów subdomeny i MX oraz każdego innego rekordu DNS właścicielowi domeny. To był właściwie cel nazwy domeny. .comjest przechowywany przez jeden rejestr, w którym .ukinny może być przechowywany. Podobnie example.comi otherexample.commoże być hostowany osobno, aby można było dystrybuować zasoby.

b) Jest buforowany, co zmniejsza liczbę trafień na twoim serwerze DNS do niewielkiej części tego, co byłoby inaczej. Domyślnie zapisy są przechowywane w pamięci podręcznej przez 2 dni, zanim zostaną usunięte. Można to zmienić, zmieniając czas wygaśnięcia rekordu.

c) Możesz skutecznie zatrzymać buforowanie rekordów, ustawiając naprawdę krótki TTL. NIE jest to zalecane, chyba że używasz go do dynamicznego DNS. Buforowanie znacznie obniża liczbę trafień na serwerze DNS. Aby wybrać odgadnięty numer z powietrza, mówimy o odrzuceniu 95% żądań.

Jeśli korzystasz z systemu * nix, pobierz kopię djbdns Dana Bernsteina ze strony http://cr.yp.to/djbdns.html i uruchom jego program dnstrace, aby zobaczyć, jak działa system zapytań rekurencyjnych. To bardzo pouczające.

a) Liczba możliwych nazw domen jest o wiele za duża, aby obsługiwać je jeden serwer. I nie tylko .com; jest .net, .org, .se, .info i wiele innych. Dodaj do tego, że możesz delegować odpowiedzialność za subdomenę (co faktycznie comdziała). Mniej scentralizowany system DNS ułatwia zarządzanie.

b) Maszyny po drodze od użytkownika do ciebie mają pamięć podręczną DNS, aby zminimalizować liczbę potrzebnych żądań. Zapobiega, na przykład, spamowaniu sieci z prośbami o adres „serverfault.com” za każdym razem, gdy dostajesz stronę od SF. Te serwery potrafią nawet buforować wyniki „domena nie istnieje”, dlatego nawet pojawienie się zupełnie nowej domeny może trochę potrwać.

c) Mimo że możesz wyłączyć pamięć podręczną, między twoim komputerem a serwerem DNS twojadomena.com często znajdują się inne serwery DNS. Na przykład serwer DNS Twojego usługodawcy internetowego będzie próbował buforować tyle pamięci, ile może. Jedyne rekordy, które są relatywnie szybko aktualizowane w sieci, to te z krótkim TTL (co w zasadzie mówi „jestem ważny tylko przez kilka sekund; potem zapytaj mnie ponownie o aktualne informacje”). Przyczyny TTL są jednak tak wysokie, że serwer odpowiedzialny za domenę może przenieść część pracy na inne serwery. Gdyby cała sieć kontaktowała się z jednym lub dwoma serwerami DNS typu rinky-dink za każde trafienie na twoją stronę, byłyby one praktycznie bezużyteczne, gdyby ktoś zobaczył twoją stronę na /., Digg itp.