Jaka jest rola rekordów NS na szczycie domeny DNS?

$ORIGIN example.com. ; not necessary, using this to self-document

$TTL 3600
@        IN     SOA   ns1.example.com. admin.example.com. (
                      1970010100 7200 1800 1209600 300)

@        IN     NS   ns1.example.com.
@        IN     NS   ns2.example.com.

@        IN     A    198.51.100.1
ns1      IN     A    198.51.100.2
ns2      IN     A    198.51.100.3

sub1     IN     NS   ns1.example.edu.

sub2     IN     NS   ns1.sub2
ns1.sub2 IN     A    203.0.113.1 ; inline glue record

Rola rekordu NS poniżej wierzchołka domeny jest dobrze zrozumiana; istnieją, aby przekazać uprawnienia do poddomeny innemu serwerowi nazw. Przykłady powyższego obejmują rekordy NS dla sub1i sub2. Umożliwiają one serwerowi nazw przekazywanie poleceń dla części domeny, dla których nie uważa się za autorytatywny.

Cel rekordów NS na szczycie domeny ns1iw ns2tym przypadku wydaje się mniej zrozumiały dla całego Internetu. Moje rozumienie (które może nie być holistyczne) jest następujące:

1. Nie są używane do buforowania serwerów DNS w celu ustalenia autorytatywnych serwerów dla domeny. Jest to obsługiwane przez klej serwera nazw , który jest zdefiniowany na poziomie rejestratora. Rejestrator nigdy nie wykorzystuje tych informacji do generowania zapisów kleju.
2. Nie są one używane do przekazywania uprawnień dla całej domeny innym serwerom nazw. Próba zrobienia tego za pomocą oprogramowania, takiego jak ISC BIND, nie spowoduje w ogóle „oczekiwanego” zachowania skierowania, ponieważ serwer nazw nadal będzie uważał się za autorytatywny dla strefy.
3. Nie są one używane przez serwer nazw w celu ustalenia, czy powinien on zwracać autorytatywne odpowiedzi (AA zestaw flag), czy nie; takie zachowanie jest określone przez to, czy oprogramowanie ma być master lub slave dla strefy. Większość oprogramowania serwera nazw całkiem chętnie obsłuży rekordy NS wierzchołka, które nie zgadzają się z informacjami zawartymi w wcześniejszych rekordach kleju, co z kolei spowoduje, że znane witryny sprawdzania poprawności DNS wygenerują ostrzeżenia dla domeny.

Skoro tak jest, to po co nam jest? Dlaczego definiujemy te informacje, jeśli nie wydają się być wykorzystywane przez buforowanie serwerów DNS w Internecie w ogóle?

Identyfikacja podrzędna

Rekordy NS na poziomie wierzchołka są używane przez serwer główny do identyfikacji jego podwładnych. Gdy dane na autorytatywnym serwerze nazw ulegną zmianie, reklamuje to za pośrednictwem DNS NOTIFYwiadomości ( RFC 1996 ) do wszystkich swoich rówieśników na tej liście. Serwery te z kolei oddzwonią z prośbą o SOAzapis (zawierający numer seryjny) i podejmą decyzję, czy usunąć nowszą kopię tej strefy.

• Możliwe jest wysyłanie tych wiadomości do serwerów niewymienionych w NSsekcji, ale wymaga to specyficznych dla danego serwera dyrektyw konfiguracyjnych (takich jak ISC BINDalso-notify dyrektywa ). Rekordy NS wierzchołka zawierają podstawową listę serwerów, które mają powiadamiać w domyślnej konfiguracji.
• Warto zauważyć, że serwery pomocnicze będą również wysyłać do siebie wiadomości NOTIFY na podstawie tych NSrekordów, zwykle skutkując zarejestrowanymi odmowami. Można to wyłączyć, instruując serwery, aby wysyłały powiadomienia tylko dla stref, dla których są wzorcami (BIND:) notify master;, lub pomijają NSpowiadomienia całkowicie na korzyść powiadomień wyraźnie zdefiniowanych w konfiguracji. (Wiąże: notify explicit;)

Autorytatywna definicja

Powyższe pytanie zawierało błąd:

Nie są używane do buforowania serwerów DNS w celu ustalenia autorytatywnych serwerów dla domeny. Jest to obsługiwane przez klej serwera nazw, który jest zdefiniowany na poziomie rejestratora. Rejestrator nigdy nie wykorzystuje tych informacji do generowania zapisów kleju.

Jest to łatwy wniosek, ale nie jest dokładny. Dane NSi dane rekordu kleju (takie jak zdefiniowane na koncie rejestracyjnym) nie są wiarygodne. Jest oczywiste, że nie można ich uznać za „bardziej autorytatywne” niż dane znajdujące się na serwerach, na które delegowane są uprawnienia. Podkreśla to fakt, że odesłania nie mają aaustawionej flagi (Odpowiedź autorytatywna).

Ilustrować:

$ dig @a.gtld-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14021
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; AUTHORITY SECTION:
example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net.     172800  IN      A       199.43.135.53
a.iana-servers.net.     172800  IN      AAAA    2001:500:8f::53
b.iana-servers.net.     172800  IN      A       199.43.133.53
b.iana-servers.net.     172800  IN      AAAA    2001:500:8d::53

Zwróć uwagę na brak aaflag dla powyższej odpowiedzi. Samo skierowanie nie jest wiarygodne. Z drugiej strony dane na serwerze, o którym mowa, są wiarygodne.

$ dig @a.iana-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2349
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; ANSWER SECTION:
example.com.            86400   IN      NS      a.iana-servers.net.
example.com.            86400   IN      NS      b.iana-servers.net.

To powiedziawszy, relacja ta może być bardzo myląca, ponieważ nie można dowiedzieć się o autorytatywnych wersjach tych NSrekordów bez rekordów nieautorytatywnych NSzdefiniowanych po stronie nadrzędnej odwołania. Co się stanie, jeśli się nie zgodzą?

• Krótka odpowiedź brzmi „niespójne zachowanie”.
• Długa odpowiedź jest taka, że serwery nazw będą początkowo stub wszystko off skierowania (i klej) na pustym cache, ale ci NS, AorazAAAA zapisy mogą ostatecznie zostać zastąpione, gdy są odświeżane. Odświeżenia następują po wygaśnięciu TTL tych tymczasowych rekordów lub gdy ktoś wyraźnie poprosi o odpowiedź na te rekordy.
  • Ai AAAArekordy dla danych spoza strefy (tj. comserwery nazw definiujące klej dla danych poza comstrefą, jak example.net) na pewno zostaną odświeżone, ponieważ jest dobrze zrozumiałym pojęciem, że serwer nazw nie powinien być uważany za wiarygodne źródło takich informacji . (RFC 2181)
  • Gdy wartości NSrekordów różnią się między stroną nadrzędną i podrzędną odwołania (np. Serwery nazw wprowadzone do panelu sterowania rejestratora różnią się od NSrekordów znajdujących się na tych samych serwerach), występujące zachowania będą niespójne, aż do dziecka włącznie NSrekordy są całkowicie ignorowane. Wynika to z faktu, że zachowanie nie jest dobrze zdefiniowane przez standardy, a implementacja różni się w zależności od implementacji serwera rekurencyjnego. Innymi słowy, spójnego zachowania w Internecie można oczekiwać tylko wtedy, gdy definicje serwera nazw dla domeny są spójne między stroną nadrzędną i podrzędną odwołania .

Krótko mówiąc, rekurencyjne serwery DNS w Internecie będą odbijały się między miejscami docelowymi, jeśli rekordy zdefiniowane po stronie nadrzędnej odwołania nie będą zgodne z wiarygodnymi wersjami tych rekordów. Początkowo preferowane będą dane obecne w skierowaniu, które zostaną zastąpione autorytatywnymi definicjami. Ponieważ pamięci podręczne są nieustannie odbudowywane od zera w Internecie, nie jest możliwe, aby Internet mógł osiąść na jednej wersji rzeczywistości w tej konfiguracji. Jeśli wiarygodne zapisy robią coś nielegalnego zgodnie ze standardami, np. Wskazywanie , staje się to jeszcze trudniejsze do rozwiązania; domena będzie naprzemiennie działała i nie działała w przypadku oprogramowania, które odrzuca naruszenie. (tj. ISC BIND / nazwany)NS rekordy na aliasy zdefiniowane przez aCNAME

RFC 2181 §5.4.1 zawiera tabelę rankingową wiarygodności tych danych i wyraźnie stwierdza, że ​​dane w pamięci podręcznej związane z poleceniami i klejem nie mogą zostać zwrócone jako odpowiedź na wyraźne żądanie rekordów, do których się odnoszą.

5.4.1. Ranking data

   When considering whether to accept an RRSet in a reply, or retain an
   RRSet already in its cache instead, a server should consider the
   relative likely trustworthiness of the various data.  An
   authoritative answer from a reply should replace cached data that had
   been obtained from additional information in an earlier reply.
   However additional information from a reply will be ignored if the
   cache contains data from an authoritative answer or a zone file.

   The accuracy of data available is assumed from its source.
   Trustworthiness shall be, in order from most to least:

     + Data from a primary zone file, other than glue data,
     + Data from a zone transfer, other than glue,
     + The authoritative data included in the answer section of an
       authoritative reply.
     + Data from the authority section of an authoritative answer,
     + Glue from a primary zone, or glue from a zone transfer,
     + Data from the answer section of a non-authoritative answer, and
       non-authoritative data from the answer section of authoritative
       answers,
     + Additional information from an authoritative answer,
       Data from the authority section of a non-authoritative answer,
       Additional information from non-authoritative answers.

   <snip>

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.

Rekordy NS delegowanej strefy zapewniają kompletność definicji domeny. Same serwery NS będą polegać na pliku strefy. Nie oczekuje się, że spróbują znaleźć się, wykonując rekurencyjne zapytanie z serwerów głównych. Rekordy NS w pliku strefy zapewniają szereg innych funkcji.

Serwery buforujące mogą odświeżyć listę serwerów nazw, odpytując serwer nazw z jego pamięci podręcznej. Tak długo, jak serwer buforujący zna adres serwera nazw, będzie go używał, zamiast rekurencyjnie wyszukiwać odpowiedni rekord NS.

Podczas przenoszenia serwerów nazw ważne jest aktualizowanie starych serwerów nazw, a także nowych serwerów nazw. Zapobiegnie to awariom lub niespójnościom, które wystąpią, gdy dwie definicje stref nie zsynchronizują się. Zaktualizowane rekordy zostaną ostatecznie odświeżone przez wszystkie serwery, które buforowały rekordy NS. Spowoduje to zastąpienie buforowanej listy serwerów nazw.

Rekordy NS pomagają również w potwierdzaniu poprawności konfiguracji DNS. Oprogramowanie do sprawdzania poprawności często sprawdza, czy definicje serwera nazw strefy delegującej są zgodne z definicjami dostarczonymi przez strefę. To sprawdzenie można wykonać na wszystkich serwerach nazw. Wszelkie niedopasowania mogą wskazywać na błędną konfigurację.

Posiadanie rekordów NS pozwala na rozłączone (lokalne) strefy. Mogą to być subdomeny zarejestrowanej domeny lub zupełnie nowa domena (niezalecane z powodu zmian TLD). Hosty, które używają serwerów nazw jako serwerów nazw, będą mogły znaleźć strefy, do których nie można uzyskać dostępu przez rekurencję z serwerów głównych. Inne serwery nazw mogą być skonfigurowane do wyszukiwania serwerów nazw dla stref lokalnych.

W przypadku podzielonego DNS (wewnętrznego / zewnętrznego) może być pożądany inny zestaw serwerów DNS. W takim przypadku lista NS (i prawdopodobnie inne dane) będzie inna, a rekordy NS w plikach strefy będą zawierały listę odpowiednich serwerów nazw.