Зачем отправлять авторитетный сервер имен в DNS?

Из любопытства я проверяю DNS-пакеты Wireshark. Я вижу, что есть DNS-запрос от хоста, а затем DNS-ответ от DNS-сервера. Все так, как и ожидалось.

Однако, если вы еще раз подтвердите запрос, вы увидите, что сервер также отправляет NS (полномочный сервер имен). Мой вопрос: почему?

Как хозяин, я забочусь только об IP. Это главный пункт DNS , чтобы разрешить имя в IP - адрес .

Зачем мне как хозяину информация о NS?

— AhmedWas
источник

@ downvoter, пожалуйста, прокомментируйте. И если вы думаете, что мой вопрос настолько прост, то хотя бы ответьте на него, а затем понизьте.

— AhmedWas

По философии и замыслу голоса являются анонимными, и ни голосование за, ни голосование не требуют обязательного объяснения . Всплывающая подсказка, которая появляется, когда указатель мыши наводит курсор на кнопку «вниз», гласит: «этот вопрос не требует каких-либо исследований; он неясен или бесполезен» . Кроме того, вопросы могут привлечь к себе отрицательное голосование, если они не очень хорошо написаны , не совсем по теме или отсутствующим деталям.

— HBruijn

Ответы:

Традиционно серверы имен отправляют не короткий ответ на запрос, а полный ответ в соответствии с RFC 1034 - 1035, который включает в себя раздел полномочий, содержащий записи ресурсов, которые указывают на авторитетный сервер (ы) имен.

Вероятно, причина в том, что с распределенным и делегированным характером DNS в то время казалось хорошей идеей включить «источник правды» в ответы.

Изменить: Кстати: отправка раздела полномочий является RFC-совместимым, но не обязательным для всех ответов на запросы.

В BIND это поведение можно настроить с помощью minimal-responses yes | no;директивы, где по умолчанию noзадано значение, а разделы Authority и Additional ответа на запрос всегда будут заполнены полностью.
Другие серверы имен CloudFlare, AWS Route 53, Infoblocks и, возможно, другие уже будут отправлять такие минимальные ответы по умолчанию. Публичные распознаватели Google вернут раздел Authority, когда он будет доступен, Cloudflare.

Я думаю, что происхождение этой традиции, включающей как раздел полномочий, так и фактический ответ на запрос, коренится в (псевдо) коде из устаревшего RFC882, стр. 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
источник

спасибо за редактирование и дополнительную информацию. Я хотел бы дать вам больше, чем один голос ВВЕРХ :)

— AhmedWas

Это на самом деле не отвечает на вопрос. Мы уже знаем, полный ответ получен. Вопрос был в том, в чем выгода? Почему стандарт разработан таким образом? Какова ценность «дополнительной» информации в этой форме ответа?

— Гонки

@LightnessRacesinOrbit для меня, ответ очевиден: DNS-сервер не просто говорит мне, что example.com является abcd; это говорит мне, кто так сказал. Это эпистемологически правильно, потому что я не могу точно сказать вам, что я знаю, что что-то является фактом, когда я на самом деле знаю только, что какая-то третья сторона утверждала, что это факт. Я нахожу более трудным устранять проблемы, когда люди представляют слухи, как будто это наблюдение, или их выводы, как если бы они были первичным доказательством и т. Д. Разница между утверждением X, что это правда, и тем, что Y сказал, что это правда, огромна.

— Монти Хардер

@MontyHarder Да, это имеет смысл, но я хочу сказать, что это должно быть в ответе.

— Гонки

@LightnessRacesinOrbit RFC не всегда включают мотивы дизайна. Чтобы прояснить «это казалось хорошей идеей в то время», я думаю, что причина, по которой традиционно добавляется раздел полномочий в дополнение к фактическому ответу на запрос, даже при том, что текущий RFC не предписывает, что происходит из (псевдо ) код из устаревшего RFC882 стр. 15-16 "... Если сервер имен не является полномочным, код копирует RR для более близкого сервера имен в ответ. В последнем разделе кода копируются все соответствующие RR в ответ ... "

— HBruijn

Сервер не знает, поступает ли запрос от конечного клиента или это рекурсивный запрос от другого сервера имен. Если это другой сервер имен, он может кешировать секцию полномочий и запрашивать эти серверы имен непосредственно в будущем.

Я считаю, что это было первоначальное обоснование в протоколе, но это имеет последствия для безопасности. Ответ может включать в себя раздел авторизации, в котором перечислены поддельные серверы имен, и это использовалось при атаках отравления кэша. Поэтому серверы имен, как правило, не будут кэшировать записи NS, если они не являются записями делегирования для субдомена запрашиваемого домена.

— Barmar
источник

Сервер действительно может определить разницу между такими запросами. Во флагах есть немного, чтобы попросить рекурсию.

— Касперд

Серверы могут отправлять рекурсивные запросы, например, когда эта forwardersфункция используется.

— Бармар

Но если вы сделаете это, то все равно не будут заботиться об авторитетных серверах.

— Касперд