Po co wysyłać autorytatywny serwer nazw w DNS?

Z ciekawości sprawdzam pakiety DNS Wireshark. Widzę, że istnieje zapytanie DNS od hosta, a następnie odpowiedź DNS od serwera DNS. Wszystko jest zgodne z oczekiwaniami.

Jeśli jednak dokonasz dalszego sprawdzania w zapytaniu, zobaczysz, że serwer wysyła również NS (autorytatywny serwer nazw). Moje pytanie brzmi: dlaczego?

Jako gospodarz dbam tylko o adres IP. To jest główny punkt DNS , aby przekształcić nazwę w adres IP .

Dlaczego jako gospodarz miałbym potrzebować informacji NS?

— AhmedWas
źródło

@downvoter, proszę o komentarz. A jeśli uważasz, że moje pytanie jest takie łatwe, to przynajmniej odpowiedz na nie, a następnie głosuj.

— AhmedWas,

Zgodnie z filozofią i wzorcem głosowanie jest anonimowe i ani głosowanie w górę, ani głosowanie nie wymaga żadnego obowiązkowego wyjaśnienia . Etykietka pojawiająca się po najechaniu kursorem myszy nad dolny przycisk mówi: „to pytanie nie pokazuje żadnego wysiłku badawczego; jest niejasne lub nieprzydatne” . Również pytania mogą przyciągnąć głos negatywny, gdy nie są dobrze napisane , nie na temat lub brakuje szczegółów.

— HBruijn,

Odpowiedzi:

Tradycyjnie serwery nazw nie wysyłają krótkiej odpowiedzi na zapytanie, ale pełną odpowiedź zgodną z RFC 1034 - 1035, która zawiera sekcję uprawnień zawierającą rekordy zasobów wskazujące na autorytatywne serwery nazw.

Powodem jest prawdopodobnie to, że z rozproszonym i delegowanym charakterem DNS wydawało się wówczas dobrym pomysłem włączenie „źródła prawdy” do odpowiedzi.

Edycja: Nawiasem mówiąc: wysyłanie sekcji autorytetów jest zgodne z RFC, ale nie jest obowiązkowe dla wszystkich odpowiedzi na zapytania.

W BIND zachowanie to można dostroić za pomocą minimal-responses yes | no;dyrektywy, gdzie domyślną jest, noa sekcje Urząd i Dodatkowe odpowiedzi na zapytanie zawsze będą w pełni wypełnione.
Inne serwery nazw CloudFlare, AWS Route 53, Infoblocks i prawdopodobnie inne już domyślnie wysyłają tak minimalne odpowiedzi. Publiczne programy tłumaczące Google zwrócą sekcję Urząd, jeśli będzie dostępna, Cloudflare.

Myślę, że pochodzenie tej tradycji obejmuje zarówno sekcję dotyczącą autorytetów, jak i rzeczywistą odpowiedź na kwerendę, która ma swój rdzeń w (pseudo) kodzie z obecnie nieaktualnej wersji RFC882 strona 15-16

If the name server is not authoritative, the code copies 
the RRs for a closer name server into the response.  

The last section of the code copies all relevant RRs into the response.

— HBruijn
źródło

dzięki za edycję i dodatkowe informacje. Chciałbym móc dać ci więcej niż jeden głos W GÓRĘ :)

— AhmedWas,

To tak naprawdę nie odpowiada na pytanie. Wiemy już, że otrzymano pełną odpowiedź. Pytanie brzmiało: jaka jest z tego korzyść? Dlaczego standard jest zaprojektowany w ten sposób? Jaka jest wartość „dodatkowych” informacji w tej formie odpowiedzi?

— Wyścigi lekkości na orbicie

@LightnessRacesinOrbit do mnie, odpowiedź jest oczywista: serwer DNS nie tylko mówi mi, że example.com jest abcd; mówi mi, kto tak powiedział. Jest to rozsądne z punktu widzenia epistemologicznego, ponieważ nie mogę dokładnie powiedzieć, że wiem, że coś jest faktem, gdy w rzeczywistości wiem tylko, że jakaś strona trzecia twierdziła, że jest to fakt. Trudniej jest mi rozwiązywać problemy, gdy ludzie przedstawiają pogłoski, jakby to była obserwacja, lub ich wnioski jak pierwotne dowody itp. Różnica między stwierdzeniem, że X jest prawdą, a powiedzeniem mi, że Y jest prawdą, jest ogromna.

— Monty Harder

@MontyHarder Tak, to ma sens, ale mówię, że powinno być w odpowiedzi.

— Wyścigi lekkości na orbicie

@LightnessRacesinOrbit RFC nie zawsze zawierają motywacje projektowe. Aby wyjaśnić „w tamtym czasie wydawało się to dobrym pomysłem” - myślę, że powodem tego jest tradycyjne włączenie sekcji autorytetu oprócz rzeczywistej odpowiedzi na zapytanie, mimo że obecne RFC nie nakazują, aby wywodziły się z (pseudo ) kod z przestarzałej RFC882 strona 15-16 „... Jeśli serwer nazw nie jest autorytatywny, kod kopiuje RR dla bliższego serwera nazw do odpowiedzi. Ostatnia sekcja kodu kopiuje wszystkie odpowiednie RR do odpowiedzi ... ”

— HBruijn

Serwer nie wie, czy żądanie pochodzi od klienta końcowego, czy jest żądaniem rekurencyjnym z innego serwera nazw. Jeśli jest to inny serwer nazw, może buforować sekcję Urząd i wysyłać zapytania do tych serwerów nazw bezpośrednio w przyszłości.

Uważam, że było to pierwotne uzasadnienie protokołu, ale ma to wpływ na bezpieczeństwo. Odpowiedź może obejmować sekcję Autorytet, która zawiera fałszywe serwery nazw, co zostało wykorzystane w atakach zatruwania pamięci podręcznej. Tak więc serwery nazw zasadniczo nie buforują rekordów NS, chyba że są to rekordy delegowania dla poddomeny domeny, której dotyczy zapytanie.

— Barmar
źródło

Serwer może faktycznie odróżnić takie żądania. Flagi zawierają trochę prośby o rekursję.

— kasperd

Serwery mogą wysyłać zapytania rekurencyjne, np. Gdy forwardersfunkcja jest używana.

— Barmar

Ale jeśli to zrobisz, nie będzie to miało znaczenia dla autorytatywnych serwerów.

— kasperd