Rozwalmy to trochę.
Rekordy NS w strefie TLD (na przykład example.com NS ...in com) są rekordami delegowania .
Rekordy A i AAAA w strefie TLD (na przykład ns1.example.com A ...in com) są zapisami kleju .
Rekordy NS w samej strefie (to znaczy example.com NS ...w example.com) są rekordami uprawnień .
Rekordy A i AAAA w samej strefie ( ns1.example.com A ...w example.com) są rekordami adresowymi , prostymi i prostymi.
Kiedy (rekurencyjne) rezolwer zaczyna się bez pamięci podręcznej danych własnej strefy i tylko cache strefy korzeniowej (który jest używany do bootstrap procesu rozwiązywania nazw), to najpierw przejść do ., następnie com.. Te comserwery będą reagować z odpowiedzią sekcji instytucję , która w zasadzie mówi „Nie wiem, ale wygląda tu dla kogoś, kto nie wie”, tak samo jak dla serwerów .zrobić com. Ta odpowiedź na zapytanie nie jest autorytatywna i nie zawiera wypełnionej sekcji odpowiedzi. To może również zawierać tzw dodatkowysekcja, która podaje odwzorowania adresów dla dowolnych nazw hostów, o których wie dany serwer (z zapisów kleju lub, w przypadku rekurencyjnych przeliczników, z wcześniej buforowanych danych). Program tłumaczący przyjmie tę odpowiedź na przekazanie, w razie potrzeby rozpozna nazwę hosta rekordu NS i przejdzie do zapytania do serwera DNS, na który delegowano uprawnienia. Proces ten może się powtarzać wiele razy, jeśli masz głęboką hierarchię delegowania, ale ostatecznie skutkuje odpowiedzią na zapytanie z ustawioną flagą „odpowiedź autorytatywna” .
Ważne jest, aby pamiętać, że resolver (ogólnie, mam nadzieję) nie będzie próbował rozbić nazwy hosta, która jest rozstrzygana, aby pytać o to kawałek po kawałku, ale po prostu wyśle go w całości na „najlepszy” serwer, o którym wie. Ponieważ przeciętny autorytatywny serwer nazw w Internecie jest nieautorytatywny dla większości prawidłowych nazw DNS, odpowiedzią będzie nieautorytatywna odpowiedź na delegację wskazująca na inny serwer DNS.
Teraz serwer nie musi być nigdzie nazwany w aktach delegowania ani uprawnień, aby był autorytatywny dla strefy. Rozważmy na przykład prywatny serwer główny; w takim przypadku istnieje autorytatywny serwer DNS, o którym wiedzą tylko administratorzy podrzędnych serwerów DNS strefy. Serwer DNS jest autorytatywny dla strefy, jeśli według jakiegoś mechanizmu, jego zdaniem, ma pełną i dokładną znajomość danej strefy. Zwykle autorytatywny serwer DNS może na przykład stać się nieautorytatywny, jeśli do skonfigurowanych serwerów głównych nie można dotrzeć w terminie określonym jako czas wygaśnięcia w rekordzie SOA.
Tylko wiarygodne odpowiedzi należy uznać za prawidłowe odpowiedzi na zapytania; wszystko inne jest albo delegacją, albo pewnego rodzaju błędem. Delegacja na serwer nieautorytatywny nazywana jest delegacją „lame”, co oznacza, że resolver musi cofnąć się o jeden krok i wypróbować inny serwer DNS o nazwie. Jeśli w delegacji nie istnieją wiarygodne osiągalne serwery nazw, wówczas rozpoznawanie nazw kończy się niepowodzeniem (w przeciwnym razie będzie tylko wolniejsze niż normalnie).
To wszystko jest ważne, ponieważ nieautorytatywne dane nie mogą być buforowane . Jak to możliwe, skoro nieautorytatywny serwer nie ma pełnego obrazu? Tak więc autorytatywny serwer musi, z własnej inicjatywy, być w stanie odpowiedzieć na pytanie „kto i na co ma być autorytatywny?”. To są informacje dostarczone przez rekordy NS w strefie.
Istnieje wiele przypadków skrajnych, w których może to naprawdę zrobić poważną różnicę, głównie skupionych wokół wielu etykiet nazw hostów w jednej strefie (prawdopodobnie dość powszechnych np. W strefach odwrotnego DNS, szczególnie w przypadku dużych dynamicznych zakresów adresów IP) lub gdy lista serwerów nazw różni się między strefa nadrzędna i strefa, o której mowa (co najprawdopodobniej jest błędem, ale można to zrobić również celowo).
Możesz zobaczyć, jak to działa bardziej szczegółowo, używając digjego +norec(nie żądaj rekurencji) i @funkcji specyfikatora serwera. Poniżej znajduje się ilustracja tego, jak działa rzeczywisty serwer DNS. Zapytanie o rekordy A w celu unix.stackexchange.comrozpoczęcia np . a.root-servers.net:
$ dig unix.stackexchange.com. A @a.root-servers.net. +norec
Przyjrzyj się uważnie liczeniom flagsposzczególnych sekcji. qrjest odpowiedzią na zapytanie i aajest autorytatywną odpowiedzią. Zauważ, że delegujesz się tylko na comserwery. Ręcznie postępuj zgodnie z tą delegacją (w rzeczywistości rekurencyjny przelicznik użyłby adresu IP z dodatkowej sekcji, jeśli został podany, lub zainicjowałby oddzielne rozpoznawanie nazw jednego z nazwanych serwerów nazw, jeśli nie podano adresów IP w odpowiedzi na delegację, ale my pomiń tę część i po prostu wróć do normalnego resolvera systemu operacyjnego dla zwięzłości przykładu):
$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec
Teraz widzisz, że stackexchange.comjest on delegowany (między innymi) ns1.serverfault.comi nadal nie otrzymujesz wiarygodnej odpowiedzi. Ponownie śledź delegację:
$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;unix.stackexchange.com. IN A
;; ANSWER SECTION:
unix.stackexchange.com. 300 IN A 198.252.206.16
Bingo! Otrzymaliśmy odpowiedź, ponieważ aaflaga jest ustawiona i zawiera adres IP dokładnie taki, jaki chcieliśmy znaleźć. Nawiasem mówiąc, warto zauważyć, że przynajmniej w momencie pisania tego postu listy serwerów nazw delegowanych i nazwanych z uprawnieniami wymienionymi różnią się, co wskazuje, że oba nie muszą być identyczne. To, co zilustrowałem powyżej, to w zasadzie praca wykonywana przez dowolny resolver, z wyjątkiem tego, że każdy praktyczny resolver będzie również buforował odpowiedzi po drodze, aby nie musiał za każdym razem uderzać w serwery root.
Jak widać z powyższego przykładu, zapisy dotyczące delegowania i kleju służą innym celom niż zapisy dotyczące uprawnień i adresów w samej strefie.
Buforujący, rozpoznający serwer nazw będzie również ogólnie sprawdzał poprawność zwracanych danych w celu ochrony przed zatruciem pamięci podręcznej. Na przykład może odmówić zapisania w pamięci podręcznej odpowiedzi zawierającej nazwy autorytatywnych serwerów comze źródła innego niż to, które zostało już nazwane przez strefę nadrzędną jako delegowane dla com. Szczegóły są zależne od serwera, ale ich celem jest jak najwięcej buforowania, bez otwierania drzwi stodoły, umożliwiając dowolnemu serwerowi nazw losowych w Internecie zastąpienie zapisów dotyczących delegacji w odniesieniu do wszystkiego, co nie jest oficjalnie pod jego „jurysdykcją”.