RFC 6762 | Многоадресный DNS

Аннотация

Поскольку сетевые устройства становятся меньше, более портативными и повсеместно распространенными, способность работать с менее настроенной инфраструктурой становится все более важной. В частности, полезна возможность поиска типов данных записей ресурсов DNS (включая, помимо прочего, имена хостов) в отсутствие обычного управляемого DNS-сервера.

Скачать оригинальный документ на английском языке RFC 6762 PDF

Многоадресный DNS (mDNS) предоставляет возможность выполнять DNS-подобные операции на локальном канале в отсутствие любого обычного Unicast DNS-сервера. Кроме того, Multicast DNS определяет часть пространства имен DNS как бесплатную для локального использования, без необходимости вносить ежегодную плату и без необходимости устанавливать делегирование или иным образом настраивать обычный DNS-сервер для ответа на эти имена.

Основные преимущества многоадресных DNS-имен состоят в том, что (i) для их настройки практически не требуется администрирование или настройка, (ii) они работают, когда нет инфраструктуры, и (iii) они работают во время сбоев инфраструктуры.

Статус этой заметки

Это документ по отслеживанию стандартов Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 5741.

Информацию о текущем статусе этого документа, любых ошибках и способах предоставления обратной связи по нему можно получить по адресу http://www.rfc-editor.org/info/rfc6762.

Уведомление об авторских правах

На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя текст упрощенной лицензии BSD, как описано в разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.

Этот документ может содержать материалы из Документов IETF или Вкладов IETF, опубликованных или обнародованных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из этих материалов, возможно, не предоставили Доверие IETF право разрешать модификации таких материалов. вне процесса стандартизации IETF. Без получения адекватной лицензии от лица (лиц), контролирующих авторские права на такие материалы, этот документ не может быть изменен вне процесса стандартизации IETF, и его производные работы не могут быть созданы вне процесса стандартизации IETF, кроме как для форматирования его для публикация в качестве RFC или перевод на другие языки, кроме английского.

1. Введение

Многоадресная DNS и ее сопутствующая технология DNS-based Service Discovery [RFC6763] были созданы для обеспечения IP-сети простотой использования и автоматической настройкой, для которой AppleTalk был хорошо известен [RFC6760]. При чтении этого документа полезно ознакомиться с концепциями сетевой конфигурации с нулевой конфигурацией [Zeroconf] и автоматической локальной локальной адресацией [RFC3927] [RFC4862].

Многоадресная DNS в значительной степени заимствует из существующего протокола DNS [RFC1034] [RFC1035] [RFC6195], используя существующую структуру сообщения DNS, синтаксис имени и типы записей ресурсов. В этом документе не указаны новые коды операций или коды ответов. Этот документ описывает, как клиенты отправляют DNS-подобные запросы через многоадресную IP-рассылку, и как совокупность узлов взаимодействует, чтобы коллективно отвечать на эти запросы полезным способом.

2. Условные обозначения и терминология, используемые в настоящем документе

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].

1. ОБЯЗАН — MUST. Это слово или термины «ТРЕБУЕТСЯ — REQUIRED» или «ДОЛЖЕН — SHALL» означают, что определение является абсолютным требованием спецификации.

2. НЕ ОБЯЗАН — MUST NOT. Эта фраза или фраза «НЕ ДОЛЖЕН — SHALL NOT» означают, что определение является абсолютным запретом спецификации.

3. СЛЕДУЕТ — SHOULD. Это слово или прилагательное «РЕКОМЕНДУЕТСЯ — RECOMMENDED» означают, что могут существовать веские причины в определенных обстоятельствах игнорировать конкретный элемент, но все последствия должны быть поняты и тщательно взвешены, прежде чем выбрать другой курс.

4. НЕ СЛЕДУЕТ — SHOULD NOT. Эта фраза или фраза «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED» означают, что могут существовать веские причины в определенных обстоятельствах, когда конкретное поведение является приемлемым или даже полезным, но все последствия должны быть поняты, а случай тщательно взвешен, прежде чем реализовывать какое-либо поведение. описано с этим ярлыком.

5. ВОЗМОЖЕН — MAY. Это слово, или прилагательное «ДОПОЛНИТЕЛЬНО — OPTIONAL», означает, что предмет действительно необязателен. Один продавец может включить товар, потому что этого требует конкретный рынок, или потому что продавец чувствует, что он улучшает продукт, в то время как другой продавец может опустить тот же товар. Реализация, которая не включает в себя конкретную опцию, «ОБЯЗАН — MUST» быть подготовлена к взаимодействию с другой реализацией, которая включает опцию, хотя, возможно, с уменьшенной функциональностью. В том же духе реализация, которая включает конкретную опцию, «ОБЯЗАН — MUST» быть подготовлена к взаимодействию с другой реализацией, которая не включает эту опцию (за исключением, конечно, функции, предоставляемой опцией).

Ключевое слово «УСТАРЕЛО» в этом документе относится к операции, атрибуту или значению, которые НЕ ДОЛЖНЫ использоваться или поддерживаться в новых реализациях.

Когда в этом документе используется термин «Multicast DNS», его следует понимать так: «Клиенты, выполняющие DNS-подобные запросы для DNS-подобных записей ресурсов, отправляют DNS-подобные UDP-запросы и ответные сообщения через IP Multicast на UDP-порт 5353». Обоснование выбора порта UDP 5353 обсуждается в Приложении А.

В этом документе термин «имя хоста» используется в строгом смысле для обозначения полного доменного имени, имеющего запись адреса IPv4 или IPv6. Он не использует термин «имя хоста» в общеупотребительном, но неверном смысле для обозначения только первой метки DNS полного доменного имени хоста.

Пакет DNS (или mDNS) содержит IP-адрес времени жизни (TTL) в заголовке IP, который фактически является пределом количества переходов для пакета, чтобы защититься от петель маршрутизации. Каждая запись ресурса также содержит TTL, который представляет собой количество секунд, в течение которых запись ресурса может быть кэширована. В этом документе термин «TTL IP» используется для обозначения TTL заголовка IP (предел перехода), а термин «TTL RR» или просто «TTL» означает ссылку на TTL записи ресурса (время жизни кэша).

Сообщения в формате DNS содержат заголовок, раздел вопросов, затем ответ, полномочия и дополнительные разделы записей. Разделы Ответ, Полномочия и Дополнительные записи содержат записи ресурсов в одном формате. В тех случаях, когда в этом документе описываются проблемы, которые в равной степени относятся ко всем трем разделам, он использует термин «разделы записей ресурсов» для общего обозначения этих трех разделов.

В этом документе используются термины «общий»(shared) и «уникальный»(unique) при обращении к наборам записей ресурсов [RFC1034]:

«Общий» набор записей ресурсов — это набор, в котором несколько респондентов многоадресной DNS могут иметь записи с одинаковыми именами, rrtype и rrclass, и несколько респондентов могут отвечать на определенный запрос.
«Уникальный» набор записей ресурсов — это тот, где все записи с этим именем, rrtype и rrclass концептуально находятся под контролем или владельцем одного респондента, и ожидается, что не более одного респондента должен ответить на запрос для этого имени , rrtype и rrclass. Прежде чем претендовать на владение уникальным набором записей ресурсов, ответчик ДОЛЖЕН проверить, что ни один другой респондент уже не претендует на владение этим набором, как описано в Разделе 8.1 «Проверка». (Из-за отказоустойчивости и других причин иногда допустимо, чтобы несколько респондентов отвечали за определенный «уникальный» набор записей ресурса, но такие взаимодействующие респонденты ДОЛЖНЫ давать ответы, содержащие идентичные rdata для этих записей. Если они не дают ответов содержащий идентичные rdata, тогда шаг зондирования отклонит данные как несовместимые с тем, что уже объявлено в сети для этих имен.)

Строго говоря, термины «общий» и «уникальный» применяются к наборам записей ресурсов, а не к отдельным записям ресурсов. Однако иногда удобно говорить о «записях общих ресурсов» и «записях уникальных ресурсов». При использовании этого способа следует понимать, что термины означают запись, которая является членом «общего» или «уникального» набора записей ресурсов, соответственно.

3. Многоадресные DNS Имена

Хосту, принадлежащему организации или частному лицу, которое контролирует некоторую часть пространства имен DNS, может быть присвоено глобально уникальное имя в этой части пространства имен DNS, например, «cheshire.example.com». Для тех из нас, у кого есть эта роскошь, это работает очень хорошо. Однако большинство пользователей домашних компьютеров не имеют простого доступа к какой-либо части глобального пространства имен DNS, в рамках которого они имеют полномочия для создания имен. Это оставляет большинство домашних компьютеров фактически анонимными для практических целей.

Чтобы устранить эту проблему, этот документ позволяет любому пользователю компьютера выбирать для своих компьютеров локальные ссылки на многоадресные DNS-имена в формате: «single-dns-label.local.». Например, ноутбук может ответить на имя «MyComputer.local». Любой пользователь компьютера получает право называть свой компьютер таким образом, при условии, что выбранное имя хоста еще не используется по этой ссылке. Назвав свой компьютер таким образом, пользователь имеет право продолжать использовать это имя до тех пор, пока в ссылке не возникнет конфликт имен, который не разрешен в пользу пользователя. Если это произойдет, компьютер (или его человек-пользователь) ДОЛЖЕН прекратить использование имени и ДОЛЖЕН попытаться присвоить новое уникальное имя для использования по этой ссылке. Ожидается, что эти конфликты будут относительно редкими для людей, которые выбирают разумные образные имена, но все же важно иметь механизм для их обработки, когда они случаются.

В этом документе указано, что DNS-домен верхнего уровня «.local». является специальным доменом со специальной семантикой, а именно, что любое полностью определенное имя заканчивается на «.local». является локальной ссылкой, а имена в этом домене имеют смысл только по той ссылке, откуда они происходят. Это аналогично адресам IPv4 в префиксе 169.254 / 16 или адресам IPv6 в префиксе FE80 :: / 10, которые являются локальными и имеют смысл только на той ссылке, откуда они происходят.

Любой DNS-запрос на имя, заканчивающееся на «.local». ДОЛЖЕН быть отправлен на локальный многоадресный адрес канала IPv4 mDNS 224.0.0.251 (или его эквивалент Fv02 :: FB в IPv6). Обоснование конструкции для использования фиксированного адреса многоадресной рассылки вместо выбора из диапазона адресов многоадресной рассылки с использованием хэш-функции обсуждается в Приложении B. Разработчики МОГУТ выбрать поиск таких имен одновременно с помощью других механизмов (например, Unicast DNS) и объединить результаты в некотором роде. Разработчики, решившие это сделать, должны знать о возможной путанице пользователя, когда данное имя может давать разные результаты в зависимости от условий внешней сети (например, какой механизм поиска имен реагирует быстрее).

Неважно, заканчивается ли имя на «.local». произошла из-за того, что пользователь явно ввел полное доменное имя, оканчивающееся на «.local.», или из-за того, что пользователь ввел неквалифицированное доменное имя, а программное обеспечение хоста добавило суффикс «.local». потому что этот суффикс появляется в списке поиска пользователя. Местный.» Суффикс может появиться в списке поиска, потому что пользователь настроил его вручную, или потому что он был получен через DHCP [RFC2132] или через любой другой механизм для настройки списка поиска DNS. В этом отношении «.local». Суффикс обрабатывается не иначе, как любой другой домен поиска, который может появиться в списке поиска DNS.

DNS-запросы для имен, которые не заканчиваются на «.local». МОЖЕТ быть отправлено на адрес многоадресной рассылки mDNS, если нет другого обычного DNS-сервера. Это может позволить узлам на одной и той же ссылке продолжать связь с использованием уникальных глобальных DNS-имен друг друга во время перебоев в сети, которые нарушают связь с большим Интернетом. При разрешении глобальных имен с помощью локальной многоадресной рассылки еще более важно использовать расширения безопасности DNS (DNSSEC) [RFC4033] или другие механизмы безопасности, чтобы гарантировать надежность ответа. Решение глобальных имен с помощью локальной многоадресной рассылки является спорным вопросом, и этот документ не обсуждает его дальше, вместо того, чтобы сосредоточиться на вопросе разрешения локальных имен с использованием сообщений DNS, отправленные на адрес многоадресной рассылки.

В этом документе рекомендуется использовать одно плоское пространство имен для локальных имен узлов (т. Е. Имен записей DNS «A» и «AAAA», которые сопоставляют имена с адресами IPv4 и IPv6), но других типов записей DNS (например, используемых). по обнаружению службы на основе DNS [RFC6763]) может содержать столько меток, сколько необходимо для желаемого использования, максимум до 255 байтов плюс нулевой завершающий байт в конце. Вопросы длины имени обсуждаются далее в Приложении C.

Обеспечение уникальности имен хостов, вероятно, желательно в общем случае, но этот документ не требует этого. Разрешено, чтобы набор согласованных хостов соглашался поддерживать несколько записей адресов DNS с одним и тем же именем, возможно, по причинам балансировки нагрузки или отказоустойчивости. В этом документе не говорится о том, является ли это разумным. Важно поддерживать оба режима работы. Протокол многоадресной DNS позволяет хостам проверять и поддерживать уникальные имена для записей ресурсов, где требуется такое поведение, а также позволяет хостам поддерживать несколько записей ресурсов с одним общим именем, где такое поведение желательно. Это соображение относится ко всем записям ресурсов, а не только к адресным записям (именам хостов). В итоге:

Требуется, чтобы протокол имел возможность обнаруживать и обрабатывать конфликты имен, но не обязательно, чтобы эта возможность использовалась для каждой записи.

4. Обратное сопоставление адресов

Как и «.local.», Домены обратного сопоставления IPv4 и IPv6 также определяются как локальные:

Любой DNS-запрос на имя, заканчивающееся на «254.169.in-addr.arpa.» НЕОБХОДИМО отправить на локальный многоадресный адрес 224.0.0.251 для локального канала IPv4 mDNS или на адрес многоадресной рассылки IPv6 mDNS FF02 :: FB. Поскольку имена в этом домене соответствуют локальным адресам IPv4-ссылок, логично, что локальная ссылка является лучшим местом для поиска информации, относящейся к этим именам.

Аналогично, любой DNS-запрос на имя в доменах обратного сопоставления для локальных адресов IPv6 («8.efip6.arpa.», «9.efip6.arpa.», «Aefip6.arpa.» И « befip6.arpa. «) ДОЛЖЕН быть отправлен на локальный многоадресный адрес канала IPv6 mDNS FF02 :: FB или локальный многоадресный адрес канала IPv4 mDNS 224.0.0.251.

5. Запросы

Существует два вида многоадресных DNS-запросов: однократные запросы, выполненные устаревшими преобразователями DNS, и непрерывные непрерывные многоадресные DNS-запросы, выполненные полностью совместимыми многоадресными DNS-запросами, которые поддерживают асинхронные операции, включая обнаружение службы на основе DNS [RFC6763].

За исключением редкого случая многоадресного DNS-ответчика, который объявляет только записи общих ресурсов и не имеет уникальных записей, многоадресный DNS-ответчик ДОЛЖЕН также реализовать многоадресный DNS-запрос, чтобы он мог сначала проверить уникальность этих записей, прежде чем он начнет отвечать на запросы для их.

5.1. Однократные многоадресные DNS-запросы

Самый базовый тип многоадресного DNS-клиента может просто слепо отправлять стандартные DNS-запросы на номер 224.0.0.251:5353, даже не зная, что такое многоадресный адрес. Это изменение обычно может быть реализовано с помощью нескольких строк кода в существующей библиотеке распознавателя DNS. Если запрашиваемое имя попадает в один из зарезервированных DNS-доменов многоадресной рассылки (см. Разделы 3 и 4), то вместо использования настроенного адреса DNS-сервера одноадресной рассылки запрос вместо этого отправляется на 224.0.0.251:5353 (или его эквивалент IPv6). [FF02 :: FB]: 5353). Как правило, время ожидания также сокращается до двух или трех секунд. Можно сделать минимальный многоадресный DNS-преобразователь только с этими простыми изменениями. Эти запросы обычно выполняются с использованием эфемерного исходного порта UDP с большим номером, но независимо от того, отправляются ли они с динамического порта или с фиксированного порта, эти запросы НЕ ДОЛЖНЫ отправляться с использованием исходного порта UDP 5353, поскольку с использованием исходного порта UDP 5353 сигнализирует о наличии полностью совместимого DNS-запроса Multicast, как описано ниже.

Простой распознаватель DNS, подобный этому, обычно просто получает первый полученный ответ. Он не будет прослушивать дополнительные ответы UDP, но во многих случаях это не может быть серьезной проблемой. Если пользователь вводит «http: //MyPrinter.local.» в свой веб-браузер, и их простой DNS-распознаватель просто берет первый полученный ответ, и пользователь видит веб-страницу состояния и конфигурации своего принтера, а затем протокол удовлетворяет потребности пользователя в этом случае.

Хотя базовый DNS-преобразователь, подобный этому, может быть достаточным для простого поиска имени хоста, он может не получить идеального поведения в других случаях. Дополнительные усовершенствования для создания полностью совместимого многоадресного DNS-запроса описаны ниже.

5.2. Непрерывный многоадресный DNS-запрос

В одноразовых запросах основное предположение состоит в том, что транзакция начинается, когда приложение выдает запрос, и заканчивается, когда первый ответ получен. Существует другой тип операции запроса, который является более асинхронным, в котором получение одного ответа не обязательно указывает на то, что больше не будет релевантных ответов, и операция запроса продолжается до тех пор, пока дальнейшие ответы не требуются. Определение того, когда дальнейшие ответы не требуются, зависит от типа выполняемой операции. Если операция ищет адреса IPv4 и IPv6 другого хоста, дальнейшие ответы не требуются после успешного подключения к одному из этих адресов IPv4 или IPv6. Если операция просматривает, чтобы предоставить пользователю список служб DNS-SD, найденных в сети [RFC6763], то дальнейшие ответы не требуются, когда пользователь указывает это программному обеспечению интерфейса пользователя, например, закрывая просмотр сети окно, которое отображало список обнаруженных сервисов.

Представьте себе гипотетическое программное обеспечение, которое позволяет пользователям обнаруживать сетевые принтеры. Пользователь хочет обнаружить все принтеры в локальной сети, а не только принтер, который быстрее всего реагирует. Когда пользователь активно ищет сетевой принтер для использования, он открывает окно просмотра сети, в котором отображается список обнаруженных принтеров. Для пользователя было бы удобно, если бы они могли полагаться на этот список сетевых принтеров, чтобы они оставались в актуальном состоянии по мере того, как сетевые принтеры приходят и уходят, вместо того, чтобы отображать устаревшую устаревшую информацию и требовать от пользователя явного нажатия «обновить» «Кнопка в любое время, когда они хотят видеть точную информацию (которая, с момента ее отображения, сама уже начинает устаревать и устаревать). Если мы хотим отображать постоянно обновляемый живой список, подобный этому, мы должны быть в состоянии сделать это эффективно, без наивного постоянного опроса, что было бы неоправданным бременем для сети. Не ожидается, что все пользователи будут постоянно просматривать новые принтеры, но когда пользователь просматривает экземпляры службы в течение длительного периода времени, мы хотим иметь возможность эффективно поддерживать эту операцию.

Следовательно, при повторной передаче многоадресных DNS-запросов для реализации такого рода непрерывного мониторинга интервал между первыми двумя запросами ДОЛЖЕН составлять не менее одной секунды, интервалы между последовательными запросами ДОЛЖНЫ увеличиваться как минимум в два раза, а запрашивающий объект ДОЛЖЕН реализовывать известный. Подавление ответа, как описано ниже в разделе 7.1. Механизм подавления известных ответов сообщает респондентам, какие ответы уже известны запрашивающему, тем самым позволяя респондентам избегать потери емкости сети при бессмысленной повторной передаче этих ответов. Запрашивающий повторно передает свой вопрос, потому что он хочет получить ответы, которые он, возможно, пропустил в первый раз, а не потому, что ему нужны дополнительные дубликаты ответов, которые он уже получил. Невозможность реализовать подавление известных ответов может привести к недопустимым уровням сетевого трафика. Когда интервал между запросами достигает или превышает 60 минут, запросчик МОЖЕТ ограничить интервал максимум до 60 минут и выполнять последующие запросы с постоянной скоростью один запрос в час. Чтобы избежать случайной синхронизации, когда по какой-то причине несколько клиентов начинают запрашивать в один и тот же момент (например, из-за некоторого общего внешнего события запуска), многоадресный DNS-запрос ДОЛЖЕН также задерживать первый запрос ряда на случайно выбранную величину в диапазон 20-120 мс.

Когда многоадресный DNS-запрос получает ответ, ответ содержит значение TTL, указывающее, сколько секунд этот ответ является действительным. По истечении этого интервала ответ больше не будет действительным и ДОЛЖЕН быть удален из кэша. Прежде чем истечет время истечения записи, многоадресный DNS-запрос, имеющий локальные клиенты с активным интересом к состоянию этой записи (например, окно просмотра сети, отображающее список обнаруженных служб для пользователя), СЛЕДУЕТ повторить свой запрос, чтобы определить, запись все еще действительна.

Для выполнения этого обслуживания кеша многоадресный DNS-запрос должен запланировать повторную передачу своего запроса после того, как истечет как минимум 50% времени жизни записи. Этот документ рекомендует следующую конкретную стратегию.

Запрашивающий должен запланировать выдачу запроса на 80% времени жизни записи, а затем, если ответ не получен, на 85%, 90% и 95%. Если ответ получен, то оставшееся значение TTL сбрасывается до значения, указанного в ответе, и этот процесс повторяется до тех пор, пока многоадресный DNS-запрос постоянно интересуется записью. Если после четырех запросов ответ не получен, запись удаляется, когда она достигает 100% своего времени жизни. DNS-запрос многоадресной рассылки НЕ ДОЛЖЕН выполнять обслуживание этого кэша для записей, для которых у него нет локальных клиентов с активным интересом. Если истечение срока действия конкретной записи из кэша не приведет к сетевому эффекту для любого клиентского программного обеспечения, работающего на устройстве-запросчике, и не окажет видимого влияния на пользователя-пользователя, то для многоадресного DNS-запроса нет причины тратить проверку емкости сети. остается ли запись действительной.

Чтобы избежать случая, когда несколько многоадресных DNS-запросов в сети все выдают свои запросы одновременно, следует добавить случайное отклонение в 2% от записи TTL, чтобы запланированные запросы выполнялись на 80-82%, 85-87% 90-92%, а затем 95-97% от TTL.

ДОПОЛНИТЕЛЬНУЮ оптимизацию эффективности СЛЕДУЕТ выполнять, когда получен многоадресный DNS-ответ, содержащий уникальный ответ (как указано установленным битом очистки кэша, описанным в Разделе 10.2, «Объявления для очистки устаревших записей кэша»). В этом случае нет необходимости, чтобы запросчик продолжал выдавать поток запросов с экспоненциально увеличивающимися интервалами, поскольку получение уникального ответа является хорошим признаком того, что другие ответы не будут получены. В этом случае запрашивающему многоадресному DNS-серверу СЛЕДУЕТ планировать выполнить свой следующий запрос для этой записи на 80-82% от TTL записи, как описано выше.

Соответствующий многоадресный DNS-запрос, который реализует правила, указанные в этом документе, ДОЛЖЕН отправлять свои многоадресные DNS-запросы с исходного порта UDP 5353 (общеизвестный порт, назначенный для mDNS), и ДОЛЖЕН прослушивать многоадресные DNS-ответы, отправленные на порт назначения 5353 UDP. по многоадресному адресу локальной линии связи mDNS (224.0.0.251 и / или его эквивалент IPv6 FF02 :: FB).

5.3. Несколько вопросов на запрос

Многоадресный DNS позволяет запрашивающему разместить несколько вопросов в разделе вопросов одного сообщения запроса многоадресного DNS.

Семантика сообщения многоадресного запроса DNS, содержащего несколько вопросов, идентична серии отдельных сообщений запроса DNS, содержащих по одному вопросу. Объединение нескольких вопросов в одно сообщение является просто оптимизацией эффективности и не имеет другого семантического значения.

5.4. Вопросы, запрашивающие одноадресные ответы

Отправка многоадресных DNS-ответов через многоадресную рассылку дает то преимущество, что все остальные узлы в сети получают возможность видеть эти ответы, что позволяет им поддерживать свои кэши в актуальном состоянии и обнаруживать конфликтующие ответы.

Однако существуют ситуации, когда всем остальным узлам сети не нужно видеть каждый ответ. Примерами могут служить ноутбук, выходящий из спящего режима, кабель Ethernet, подключенный к работающей машине, или ранее неактивный интерфейс, активируемый через изменение конфигурации. В момент пробуждения или активации ссылки устройство становится новым участником в новой сети. Его многоадресный DNS-кэш для этого интерфейса пуст, и он не знает своих коллег по этой ссылке. Он может иметь значительное количество вопросов, на которые он хочет получить ответы сразу, чтобы найти информацию о его новом окружении и представить эту информацию пользователю. Будучи новым участником сети, он не знает, задавались ли те же самые вопросы и на что были даны ответы всего несколько секунд назад. В этом случае инициирование большого внезапного потока многоадресных ответов может привести к чрезмерной нагрузке на сеть.

Чтобы избежать большого количества потенциально ненужных ответов в этих случаях, Multicast DNS определяет верхний бит в поле класса вопроса DNS как бит одноадресного ответа. Когда этот бит установлен в вопросе, он указывает, что запрашивающий объект готов принимать одноадресные ответы в ответ на этот конкретный запрос, а также обычные многоадресные ответы. Эти вопросы, требующие одноадресных ответов, называются «QU», чтобы отличать их от более обычных вопросов, требующих многоадресных ответов (вопросы «QM»). DNS-запрос многоадресной рассылки, отправляющий свою первоначальную группу вопросов сразу после пробуждения из спящего режима или активации интерфейса, ДОЛЖЕН установить бит ответа одноадресной рассылки в этих вопросах.

Когда вопрос передается повторно (как описано в разделе 5.2), бит одноадресной передачи НЕ ДОЛЖЕН устанавливаться в последующих повторных передачах этого вопроса. Последующие повторные передачи ДОЛЖНЫ быть обычными вопросами «QM». После того, как на первый вопрос получены ответы, у запрашивающего должен быть большой список известных ответов (раздел 7.1), чтобы последующие запросы вызывали несколько, если таковые вообще имеются, дополнительных ответов. Возвращение к многоадресным ответам как можно скорее важно из-за преимуществ, предоставляемых многоадресными ответами (см. Приложение D). Кроме того, бит одноадресного ответа СЛЕДУЕТ устанавливать только для вопросов, которые активны и готовы к отправке в момент пробуждения из режима сна или активации интерфейса. Новые вопросы, созданные локальными клиентами впоследствии, должны рассматриваться как обычные вопросы «QM», и НЕ ДОЛЖЕН устанавливаться бит одноадресной передачи ответа на первый вопрос серии.

При получении вопроса с установленным битом одноадресного ответа ответчик СЛЕДУЕТ отвечать на него одноадресным пакетом, направленным обратно на запрос. Однако, если у ответчика не было многоадресной передачи этой записи в последнее время (в пределах одной четверти его TTL), то ответчик ДОЛЖЕН вместо этого многоадресно передать ответ, чтобы поддерживать все одноранговые кэши в актуальном состоянии и разрешать пассивное обнаружение конфликтов. В случае ответа на пробный вопрос (раздел 8.1) с установленным битом одноадресной передачи ответчик должен всегда генерировать запрошенный одноадресный ответ, но он также может отправлять многоадресное объявление, если время с момента последнего многоадресного объявления этой записи превышает четверть его TTL.

На ответы одноадресной рассылки распространяются все те же правила генерации пакетов, что и на ответы многоадресной рассылки, включая бит очистки кэша (раздел 10.2) и (за исключением случаев защиты уникального имени от проверки с другого хоста) случайные задержки для уменьшения сетевых коллизий (раздел 6).

5.5. Прямые одноадресные запросы к порту 5353

В специализированных приложениях могут быть редкие ситуации, когда имеет смысл для многоадресного DNS-запроса отправлять свой запрос через одноадресную передачу на конкретную машину. Когда многоадресный DNS-ответчик получает запрос через прямую одноадресную передачу, он ДОЛЖЕН отвечать так же, как и на вопросы «QU», как описано выше в разделе 5.4. Поскольку одноадресный запрос может быть получен с компьютера за пределами локальной ссылки, респонденты ДОЛЖНЫ проверить, что адрес источника в пакете запроса соответствует локальной подсети для этой ссылки (или, в случае IPv6, адрес источника имеет префикс on-link) и молча игнорировать пакет, если нет.

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

6. Ответы

Когда респондент многоадресной DNS создает и отправляет ответное сообщение многоадресной DNS, разделы записей ресурсов этого сообщения должны содержать только те записи, для которых этот респондент явно уполномочен. Эти ответы могут быть сгенерированы, потому что запись отвечает на вопрос, полученный в сообщении запроса многоадресной DNS, или в определенные другие моменты времени, которые респондент определяет, чем обоснованно нежелательное объявление. DNS-ответчик многоадресной рассылки НЕ ДОЛЖЕН помещать записи из своего кэша, которые были извлечены из других ответчиков в сети, в разделы записей ресурсов исходящих ответных сообщений. Только авторитетный источник для данной записи может выпускать ответы, содержащие эту запись.

Определение того, отвечает ли данная запись определенному вопросу, выполняется с использованием стандартных правил DNS: имя записи должно совпадать с именем вопроса, rrtype записи должен соответствовать qtype вопроса, если qtype не равен ANY (255) или rrtype не равен «CNAME» (5), и запись rrclass должна соответствовать вопросу qclass, если qclass не «ANY» (255). Как и в случае одноадресной DNS, обычно используется только класс DNS 1 («Интернет»), но если клиентское программное обеспечение использует классы, отличные от 1, ДОЛЖНЫ использоваться правила сопоставления, описанные выше.

DNS-ответчик многоадресной рассылки ДОЛЖЕН отвечать только в том случае, если у него есть положительный ненулевой ответ для отправки, или он достоверно знает, что конкретной записи не существует. Для уникальных записей, где хост уже установил единоличное владение именем, он ДОЛЖЕН возвращать отрицательные ответы на запросы записей, о которых он не знает, что они существуют. Например, хост без IPv6-адреса, который претендует на единоличное владение именем «host.local». для всех типов команд ДОЛЖЕН отвечать на запросы AAAA для «host.local». отправив отрицательный ответ, указывающий, что для этого имени не существует записей AAAA. См. Раздел 6.1 «Отрицательные ответы». Для общих записей, которые не принадлежат ни одному хосту, отсутствие данной записи подтверждается тем, что какой-либо компьютер не отвечает на многоадресный DNS-запрос, а не явным отрицательным ответом. Для общих записей NXDOMAIN и другие сообщения об ошибках НЕ ДОЛЖНЫ отправляться.

Многоадресные DNS-ответы НЕ ДОЛЖНЫ содержать вопросы в разделе «Вопросы». Любые вопросы в разделе «Вопросы» полученного ответа многоадресной DNS ДОЛЖНЫ игнорироваться. Многоадресные DNS-запросы, получающие многоадресные DNS-ответы, не волнует, какой вопрос вызвал ответ; они заботятся только о том, чтобы информация в ответе была достоверной и точной.

Ответчик многоадресной DNS в Ethernet [IEEE.802.3] и аналогичные совместно используемые сети множественного доступа ДОЛЖНЫ иметь возможность задерживать свои ответы до 500 мс, как описано ниже.

Если бы все большое количество многоадресных DNS-ответчиков сразу ответили на определенный запрос, коллизия была бы практически гарантирована. Путем наложения небольшой случайной задержки количество столкновений значительно уменьшается. В полноразмерном Ethernet, использующем максимально допустимую длину кабеля и максимально допустимое количество повторителей, кадр Ethernet уязвим для коллизий во время передачи его первых 256 битов. На 10 Мбит / с Ethernet это соответствует уязвимому временному окну в 25,6 микросекунд. В более высокоскоростных вариантах Ethernet уязвимое временное окно короче.

В случае, когда у многоадресного DNS-ответчика есть веские основания полагать, что он будет единственным ответчиком по ссылке, который отправит ответ (т. Е. Потому что он способен ответить на каждый вопрос в сообщении запроса и для всех этих ответов записи, которые он ранее проверил, что имя, rrtype и rrclass уникальны для ссылки), он НЕ ДОЛЖЕН устанавливать случайную задержку перед ответом и ДОЛЖЕН обычно генерировать свой ответ в течение не более 10 мс. В частности, это относится к ответам на тестовые запросы с установленным битом одноадресного ответа. Поскольку получение пробного запроса дает четкое указание на то, что какой-то другой респондент планирует начать использовать это имя в самом ближайшем будущем, ответы на такие пробные запросы для защиты уникальной записи являются высоким приоритетом и должны быть выполнены без задержки. Пробный запрос можно отличить от обычного запроса тем, что пробный запрос содержит предложенную запись в разделе полномочий, которая отвечает на вопрос в разделе вопросов (более подробную информацию см. В разделе 8.2, «Одновременное прерывание связи зонда»).

Безотлагательный ответ подходит для таких записей, как запись адреса для конкретного имени хоста, когда имя хоста ранее было проверено уникальным. Безотлагательный ответ * не * подходит для таких вещей, как поиск записей PTR, используемых для обнаружения службы на основе DNS [RFC6763], где можно ожидать большое количество ответов.

В любом случае, когда может быть несколько ответов, например, запросы, в которых ответ является членом набора записей общего ресурса, каждому ответчику СЛЕДУЕТ задерживать свой ответ на случайное количество времени, выбранное с равномерным случайным распределением в диапазоне 20-120 мс , Причина, по которой требуется, чтобы задержка составляла не менее 20 мс, заключается в том, чтобы приспособиться к ситуации, когда два или более пакета запроса передаются последовательно, потому что в этом случае мы хотим, чтобы респондент с ответами на более чем один из этих запросов имел возможность объединить все свои ответы в одно ответное сообщение.

В случае, когда в запросе установлен бит TC (усеченный), указывающий, что последующие последующие пакеты с известным ответом будут следовать, ответчики ДОЛЖНЫ задерживать свои ответы на случайное количество времени, выбранное с равномерным случайным распределением в диапазоне 400-500 мс, чтобы подождать достаточно времени для получения всех пакетов с известным ответом, как описано в разделе 7.2 «Подавление многопакетного известного ответа».

Порт UDP источника во всех многоадресных DNS-ответах ДОЛЖЕН быть 5353 (общеизвестный порт, назначенный для mDNS). Реализации многоадресной DNS ДОЛЖНЫ молча игнорировать любые ответы многоадресной DNS, которые они получают, если исходный порт UDP не 5353.

UDP-порт назначения во всех многоадресных DNS-ответах ДОЛЖЕН быть 5353, а адрес назначения ДОЛЖЕН быть локальным многоадресным адресом канала IPv4 mDNS 224.0.0.251 или его эквивалентным Fv02 :: FB IPv6, за исключением случаев генерации ответа на запрос, который явно запрашивается. одноадресный ответ:

через бит одноадресного ответа,
в силу устаревшего запроса (Раздел 6.7),
в силу того, что является прямым одноадресным запросом.

За исключением этих трех конкретных случаев, ответы НЕ ДОЛЖНЫ отправляться через одноадресную передачу, поскольку тогда механизмы «пассивного наблюдения за отказами», описанные в разделе 10.5, не будут работать правильно. Другие преимущества отправки ответов через многоадресную рассылку обсуждаются в Приложении D. Многоадресный DNS-запрос ДОЛЖЕН принимать только одноадресные ответы, если они отвечают на недавно отправленный запрос (например, отправленный в течение последних двух секунд), который явно запрашивал одноадресные ответы. DNS-запрос многоадресной рассылки ДОЛЖЕН молча игнорировать все другие одноадресные ответы.
Чтобы защитить сеть от чрезмерного переполнения пакетов из-за программных ошибок или злонамеренных атак, многоадресный DNS-ответчик НЕ ДОЛЖЕН (за исключением одного особого случая ответа на зондирующие запросы) выполнять многоадресную передачу записи на заданном интерфейсе до тех пор, пока не истечет хотя бы одна секунда с момента последний раз эта запись была многоадресной на этом интерфейсе. Законный запросчик в сети должен был увидеть предыдущую передачу и кэшировать ее.

Запрашивающий, который не получил и не кешировал предыдущую передачу, повторяет свой запрос и получает последующий ответ. В особом случае ответа на зондирующие запросы из-за ограниченного времени, в течение которого зондирующий хост примет решение о том, использовать имя или нет, ответчик многоадресной DNS ДОЛЖЕН ответить быстро. Только в этом особом случае, когда при многоадресном ответе на зонд, многоадресному DNS-ответчику требуется только отложить передачу, если это необходимо, чтобы обеспечить интервал не менее 250 мс с момента последней многоадресной записи на этом интерфейсе.

6.1. Отрицательные ответы

В ранней разработке Multicast DNS предполагалось, что явные отрицательные ответы никогда не понадобятся. Хост может утверждать о существовании набора записей, который, как он утверждает, существует, и объединение всех таких наборов в ссылке — это набор многоадресных DNS-записей, которые существуют в этой ссылке. Утверждение об отсутствии каждой записи в дополнении к этому набору — то есть всех возможных многоадресных DNS-записей, которые могут существовать по этой ссылке, но не существуют в данный момент, — было сочтено нецелесообразным и ненужным. Отсутствие записи будет подтверждено запросом, запрашивающим ее и не получающим ответ от любого из хостов, в настоящее время подключенных к ссылке.

Однако опыт эксплуатации показал, что явные отрицательные ответы иногда могут быть полезны. Одним из таких примеров является случай, когда запрос запрашивает запись AAAA, а у рассматриваемого имени хоста нет связанных адресов IPv6. В этом случае отвечающий узел знает, что в настоящее время он обладает исключительным владением этим именем, и он знает, что в настоящее время у него нет адресов IPv6, поэтому явный отрицательный ответ предпочтительнее, чем запрашивающему, который должен повторно передать свой запрос несколько раз, и в конечном итоге отказаться от тайм-аута, прежде чем он может прийти к выводу, что данная запись AAAA не существует.

Каждый раз, когда респондент получает запрос на имя, для которого он подтвердил исключительное владение, для типа, для которого у этого имени нет записей, ответчик ДОЛЖЕН (за исключением случаев, разрешенных в (а) ниже) отвечать, утверждая несуществование этой записи, используя запись DNS NSEC [RFC4034]. В случае многоадресной DNS запись NSEC используется не для своих обычных свойств безопасности DNSSEC [RFC4033], а просто как способ выражения того, какие записи существуют или не существуют с данным именем.

После получения вопроса для определенного имени, rrtype и rrclass, для которого ответчик имеет один или несколько уникальных ответов, ответчик МОЖЕТ также включить запись NSEC в раздел дополнительных записей, указывающий на отсутствие других rrtypes для этого имени, и rrclass.

Разработчики, работающие с устройствами с достаточным объемом памяти и ресурсов ЦП, МОГУТ выбрать реализацию кода для обработки всей общности записи DNS NSEC [RFC4034], включая растровые изображения длиной до 65 536 бит. Чтобы облегчить использование устройствами с ограниченными памятью и ресурсами ЦП, многоадресные DNS-запросы ТРЕБУЮТСЯ только для возможности анализа ограниченной формы записи DNS NSEC. Все совместимые реализации многоадресной DNS ДОЛЖНЫ, по крайней мере, правильно генерировать и анализировать ограниченный формат записи DNS NSEC, описанный ниже:

Поле «Имя следующего домена» содержит собственное имя записи. При использовании со сжатием имени это означает, что поле «Имя следующего домена» всегда занимает ровно два байта в сообщении.
Номер блока типовой битовой карты равен 0.
Байт длины блока битовой карты типа является значением в диапазоне 1-32.
Данные битовой карты типа составляют 1-32 байта, как указано длиной байта.

Поскольку эта ограниченная форма записи DNS NSEC ограничена нулевым номером блока битовой карты типов, она не может выражать существование rrtypes выше 255. Следовательно, если у многоадресного DNS-ответчика должны быть записи с rrtypes выше 255, он НЕ ДОЛЖЕН генерировать их записи NSEC в ограниченной форме для этих имен, поскольку это будет означать, что в имени нет записей с rrtypes выше 255, что будет ложным. В таких случаях многоадресный DNS-ответчик ДОЛЖЕН либо (а) не выдавать запись NSEC для этого имени, либо (б) выдавать полную запись NSEC, содержащую соответствующий блок (блоки) битовой карты типов с правильными битами, установленными для всех типов записей, которые существовать. На практике это не является существенным ограничением, поскольку rrtypes выше 255 в настоящее время не используются широко.

Если реализация многоадресного DNS получает запись NSEC, где поле «Next Domain Name» не является собственным именем записи, то реализация ДОЛЖНА игнорировать поле «Next Domain Name» и обрабатывать оставшуюся часть записи NSEC как обычно. В многоадресной DNS поле «Имя следующего домена» в настоящее время не используется, но его можно использовать в будущей версии этого протокола, поэтому реализация многоадресной DNS НЕ ДОЛЖНА отклонять или игнорировать запись NSEC, которую она получает только потому, что находит неожиданное значение в поле «Next Domain Name».

Если реализация DNS многоадресной рассылки получает запись NSEC, содержащую более одной карты битов типа, или если номер блока карты битов типа не равен нулю, или когда длина блока не находится в диапазоне 1-32, то реализация DNS многоадресной передачи МОЖЕТ молча игнорировать всю запись NSEC. Реализация многоадресной DNS НЕ ДОЛЖНА игнорировать все сообщение только потому, что это сообщение содержит одну или несколько записей NSEC, которые реализация многоадресной DNS не может проанализировать. Это условие должно позволить будущим усовершенствованиям протокола вводиться обратно совместимым способом, который не нарушает совместимость со старыми реализациями Multicast DNS.

Чтобы помочь дифференцировать эти синтезированные записи NSEC (сгенерированные программно на лету) от обычных записей NSEC одноадресной DNS (которые фактически существуют в подписанной зоне DNS), синтезированные записи NSEC многоадресной DNS НЕ ДОЛЖНЫ иметь бит NSEC, установленный в бите типа. Карта, в то время как в обычных одноадресных DNS-записях NSEC установлен бит NSEC.

TTL записи NSEC указывает предполагаемое время жизни отрицательной записи в кэше. В общем, TTL, указанный для записи NSEC, ДОЛЖЕН быть таким же, как TTL, который имел бы этот документ, если бы он существовал. Например, TTL для записей адресов в многоадресной DNS обычно составляет 120 секунд (см. Раздел 10), поэтому отрицательное время жизни кэша для несуществующей записи адреса также должно составлять 120 секунд.

Отвечающий ДОЛЖЕН генерировать только отрицательные ответы на запросы, для которых у него есть законное право собственности на рассматриваемое имя, rrtype и rrclass, и он может обоснованно утверждать, что не существует записей с такими именами, rrtype и rrclass. Ответчик может утверждать, что указанный rrtype не существует для одного из его имен, если он априори знает, что у него есть исключительное владение этим именем (например, имена записей PTR с обратным сопоставлением адресов, которые получены из IP-адресов, которые должны быть уникальна для локальной ссылки) или если ранее она заявляла об уникальном владении этим именем, используя тестовые запросы для rrtype «ANY». (Если бы он использовал тестовые запросы для определенного rrtype, он имел бы только имя для этого rrtype и не мог утверждать, что другие rrtypes не существуют.)

Конструктивное обоснование этого механизма для кодирования отрицательных ответов обсуждается далее в Приложении E.

6.2. Ответ на адресные запросы

Когда многоадресный DNS-ответчик отправляет многоадресное ответное DNS-сообщение, содержащее его собственные записи адресов, он ДОЛЖЕН включать все адреса, действительные на интерфейсе, на котором он отправляет сообщение, и НЕ ДОЛЖЕН включать адреса, которые недопустимы на этом интерфейсе (например, как адреса, которые могут быть настроены на других интерфейсах хоста). Например, если интерфейс имеет как локальный локальный канал IPv6, так и маршрутизируемый адрес IPv6, оба должны быть включены в ответное сообщение, чтобы запросчики получали оба и могли сами выбирать, какой из них использовать. Это позволяет запрашивающему, имеющему только локальный адрес канала IPv6, подключаться к локальному адресу канала, а другому запрашивающему, имеющему маршрутизируемый адрес IPv6, подключаться вместо этого к маршрутизируемому адресу IPv6.

Когда многоадресный DNS-ответчик помещает запись адреса IPv4 или IPv6 (rrtype «A» или «AAAA») в ответное сообщение, он ДОЛЖЕН также помещать любые записи другого типа адреса с тем же именем в дополнительный раздел, если есть пробел в сообщении. Это должно обеспечить совместное использование судьбы, чтобы все адреса устройства доставлялись атомарно в одном сообщении, чтобы снизить риск того, что потеря пакетов может привести к тому, что запросчик получит только адреса IPv4, а не адреса IPv6, или наоборот.

В случае, если устройство имеет только адреса IPv4, но не имеет адресов IPv6, или наоборот, соответствующая запись NSEC ДОЛЖНА быть помещена в дополнительный раздел, чтобы запросчики могли с уверенностью знать, что устройство не имеет адресов такого рода.

Некоторые многоадресные DNS-ответчики рассматривают физический интерфейс с адресами IPv4 и IPv6 как единый интерфейс с двумя адресами. Другие многоадресные DNS-ответчики могут рассматривать этот случай как логически два интерфейса (один с одним или несколькими IPv4-адресами, а другой — с одним или несколькими IPv6-адресами), но отвечающие, которые работают таким образом, НЕ ДОЛЖНЫ помещать соответствующие автоматические записи NSEC в отправляемые ими ответы. (т. е. отрицательное утверждение IPv4 в их ответах IPv6 и отрицательное утверждение IPv6 в их ответах IPv4), поскольку это может привести к неправильной работе в ответчиках в сети, которые работают прежним способом.

6.3. Ответы на запросы с несколькими вопросами

DNS-ответчики на многоадресную рассылку ДОЛЖНЫ правильно обрабатывать сообщения DNS-запросов, содержащие более одного вопроса, отвечая на любой или все вопросы, на которые у них есть ответы. В отличие от запросов на один вопрос, где ответ без задержки допускается в соответствующих случаях, для сообщений запроса, содержащих более одного вопроса, все (не оборонительные) ответы ДОЛЖНЫ быть произвольно задержаны в диапазоне 20-120 мс или 400-500 мс, если бит TC (усеченный) установлен. Это связано с тем, что, когда сообщение запроса содержит более одного вопроса, респондент многоадресной DNS обычно не может быть уверен, что другие респонденты не будут одновременно генерировать ответы на другие вопросы в этом сообщении запроса. (Ответы, защищающие имя, в ответ на проверку этого имени не подпадают под действие этого правила задержки и по-прежнему отправляются немедленно.)

6.4. Агрегация ответов

Когда это возможно, респондент ДОЛЖЕН ради эффективности сети объединять как можно больше ответов в одно многоадресное ответное сообщение DNS. Например, когда у респондента есть несколько ответов, которые он планирует отправить, каждый из которых задерживается на другой интервал, тогда более ранние ответы ДОЛЖНЫ быть задержаны на дополнительные 500 мс, если это позволит объединить их с другими ответами, запланированными для немного позже.

6.5. Запросы с подстановочными знаками (qtype «ANY» и qclass «ANY»)

Отвечая на запросы, используя qtype «ANY» (255) и / или qclass «ANY» (255), многоадресный DNS-респондент ДОЛЖЕН ответить * ALL * своими записями, которые соответствуют запросу. Это несколько отличается от того, как qtype «ANY» и qclass «ANY» работают в Unicast DNS.

Распространенным заблуждением является то, что Unicast DNS-запрос для qtype «ANY» вызовет ответ, содержащий все соответствующие записи. Это неверно Если есть какие-либо записи, соответствующие запросу, ответ должен содержать только одну из них, не обязательно все из них.

Такое несколько удивительное поведение обычно наблюдается при кэшировании (то есть, «рекурсивных») серверов имен. Если сервер кэширования получает «ЛЮБОЙ» запрос qtype, для которого у него есть хотя бы один действительный ответ, ему разрешается возвращать только те совпадающие ответы, которые, как он случается, уже есть в его кэше, и не требуется повторная консультация авторитетного сервера имен. проверить, есть ли еще записи, которые также соответствуют запросу qtype «ANY».

Например, можно представить, что запрос qtype «ANY» для имени «host.example.com» вернет записи адресов IPv4 (A) и IPv6 (AAAA) для этого хоста. На самом деле происходит то, что это зависит от истории того, какие запросы были ранее получены промежуточными серверами кэширования. Если на сервере кэширования нет записей для «host.example.com», он будет обращаться к другому серверу (обычно к уполномоченному серверу имен для рассматриваемого имени) и в этом случае обычно возвращает все адреса IPv4 и IPv6. записей. Однако, если какой-то другой хост недавно выполнил запрос для qtype «A» для имени «host.example.com», так что сервер кэширования уже имеет записи адреса IPv4 для «host.example.com» в своем кэше, но не IPv6 записи адресов, тогда он вернет только те записи адресов IPv4, которые уже кэшированы, и никаких записей адресов IPv6.

Многоадресный DNS не разделяет это свойство, так что запросы qtype «ANY» и qclass «ANY» возвращают некоторое неопределенное подмножество совпадающих записей. Отвечая на запросы, используя qtype «ANY» (255) и / или qclass «ANY» (255), многоадресный DNS-респондент ДОЛЖЕН ответить * ALL * своими записями, которые соответствуют запросу.

6.6. Сотрудничающие многоадресные DNS-ответчики

Если многоадресный DNS-ответчик («A») наблюдает за каким-либо другим многоадресным DNS-ответчиком («B»), отправьте многоадресный DNS-ответ, содержащий запись ресурса с тем же именем, rrtype и rrclass, что и у одной из записей ресурсов A, но * отличается * rdata, тогда:

Если запись ресурса А предназначена для записи общего ресурса, то это не конфликт, и никаких действий не требуется.
Если запись ресурса А предназначена для того, чтобы быть членом уникального набора записей ресурса, принадлежащего исключительно этому респонденту, то это конфликт, и он ДОЛЖЕН быть обработан, как описано в Разделе 9 «Разрешение конфликтов».

Если TTL записи ресурса B, приведенной в сообщении, составляет по крайней мере половину истинного TTL с точки зрения A, то никаких действий не требуется.
Если TTL записи ресурса B, приведенной в сообщении, составляет менее половины истинного TTL с точки зрения A, то A ДОЛЖЕН пометить свою запись, которая будет объявлена посредством многоадресной рассылки. Запрашивающие, получающие запись от B, будут использовать TTL, заданный B, и, следовательно, могут удалить запись раньше, чем ожидает A. Посылая свой собственный многоадресный ответ, исправляющий TTL, A гарантирует, что запись будет сохранена в течение желаемого времени.

Эти правила позволяют нескольким многоадресным DNS-ответчикам предлагать одни и те же данные в сети (возможно, из-за отказоустойчивости), не конфликтуя друг с другом.

6.7. Унаследованные одноадресные ответы

Если исходный UDP-порт в полученном многоадресном DNS-запросе не является портом 5353, это указывает на то, что инициатором запроса является простой распознаватель, такой как описанный в разделе 5.1, «Одноразовые многоадресные DNS-запросы», который не полностью реализует все многоадресной DNS. В этом случае многоадресный DNS-ответчик ДОЛЖЕН отправить UDP-ответ непосредственно обратно на запрос, через одноадресную передачу, на исходный IP-адрес и порт пакета запроса. Этот одноадресный ответ ДОЛЖЕН быть обычным одноадресным ответом, который генерируется обычным одноадресным DNS-сервером; например, он ДОЛЖЕН повторять идентификатор запроса и вопрос, заданный в сообщении запроса. Кроме того, бит очистки кэша, описанный в Разделе 10.2, «Объявления для очистки устаревших записей кэша», НЕ ДОЛЖЕН быть установлен в устаревших одноадресных ответах.

TTL записи ресурса, заданный в устаревшем одноадресном ответе, НЕ ДОЛЖЕН быть больше десяти секунд, даже если истинный TTL записи ресурса DNS многоадресной рассылки выше. Это связано с тем, что многоадресные DNS-ответчики, которые полностью участвуют в протоколе, используют механизмы когерентности кэша, описанные в разделе 10 «Значения TTL записи ресурса и когерентность кэша», для обновления и аннулирования устаревших данных. Если бы одноадресные ответы, отправленные устаревшим распознавателям, чтобы использовать те же самые высокие TTL, эти устаревшие преобразователи, которые не реализуют эти механизмы когерентности кэша, могли бы сохранять устаревшие данные записей кэшированных ресурсов еще долго после того, как они больше не действительны.

7. Сокращение трафика

Различные методы используются для уменьшения объема трафика в сети.

7.1. Подавление известных ответов

Когда многоадресный DNS-запрос отправляет запрос, на который он уже знает некоторые ответы, он заполняет раздел «Ответ» в сообщении DNS-запроса этими ответами.

Как правило, это относится только к общим записям, а не к уникальным записям, поскольку, если многоадресный DNS-запрос уже имеет хотя бы одну уникальную запись в своем кэше, он не должен ожидать дальнейших различных ответов на этот вопрос, поскольку уникальные записи его уже содержит полный ответ, поэтому у него нет причин отправлять запрос вообще. Напротив, наличие нескольких общих записей в своем кеше не обязательно означает, что многоадресный DNS-запрос не будет получать дальнейшие ответы на этот запрос, и именно в этом случае целесообразно использовать список известных ответов для подавления повторной отправки избыточные ответы, которые уже знает запрашивающий.

DNS-ответчик многоадресной рассылки НЕ ДОЛЖЕН отвечать на запрос многоадресной DNS, если ответ, который он даст, уже включен в раздел ответов с TTL RR, по меньшей мере, наполовину правильного значения. Если TTL RR ответа, как указано в разделе «Ответ», составляет менее половины истинного TTL RR, известного как многоадресный DNS-ответчик, то ответчик ДОЛЖЕН отправить ответ, чтобы обновить кэш запрашивающего до того, как запись подвергнется опасности. истечения срока действия.

Поскольку многоадресный DNS-респондент будет отвечать, если оставшийся TTL, указанный в списке Known-Answer, меньше половины истинного TTL, для запрашивающего лица излишне включать такие записи в список Known-Answer. Таким образом, многоадресный DNS-запрос НЕ ДОЛЖЕН включать записи в список известных ответов, у которых оставшийся TTL составляет менее половины их исходного TTL. Это просто заняло бы место в сообщении без достижения цели подавления ответов и, следовательно, было бы бессмысленной тратой емкости сети.

DNS-запрос многоадресной рассылки НЕ ДОЛЖЕН кэшировать записи ресурсов, обнаруженные в разделе «Известные ответы» других многоадресных DNS-запросов. Раздел ответов многоадресных DNS-запросов не является официальным. Помещая информацию в раздел ответа многоадресного DNS-запроса, запрашивающий заявляет, что он * считает * информацию достоверной. Это не утверждение, что информация * является * верной. Некоторые из этих записей могли быть получены с других хостов, которых больше нет в сети. Распространение этой устаревшей информации на другие многоадресные DNS-запросы в сети не поможет.

7.2. Мультипакет подавления известных ответов

Иногда многоадресный DNS-запрос уже имеет слишком много ответов, чтобы поместиться в разделе «Известные ответы» своих пакетов запросов. В этом случае он должен выполнить многоадресный DNS-запрос, содержащий вопрос и столько записей известного ответа, сколько уместится. Затем он ДОЛЖЕН установить бит TC (усеченный) в заголовке перед отправкой запроса. Он ДОЛЖЕН немедленно следовать за пакетом с другим пакетом запроса, не содержащим вопросов, и таким количеством записей об известных ответах, которое подходит. Если по-прежнему остается слишком много записей для размещения в пакете, он снова устанавливает бит TC и продолжается до тех пор, пока не будут отправлены все записи известного ответа.

Ответчик Multicast DNS, увидевший запрос Multicast DNS с установленным битом TC, откладывает свой ответ на период времени, случайно выбранный в интервале 400-500 мс. Это дает многоадресному DNS-запросу время для отправки дополнительных пакетов с известным ответом до того, как ответчик ответит. Если респондент видит какой-либо из своих ответов, перечисленных в списках известных ответов последующих пакетов от запрашивающего хоста, он ДОЛЖЕН удалить этот ответ из списка ответов, которые он планирует дать (при условии, что ни один другой хост в сети также не выдал запрос для этой записи и ожидает получения ответа).

Если ответчик получает дополнительные пакеты известного ответа с установленным битом TC, он ДОЛЖЕН увеличить задержку по мере необходимости, чтобы обеспечить паузу в 400-500 мс после последнего такого пакета, прежде чем он отправит свой ответ. Это открывает потенциальный риск того, что непрерывный поток пакетов с известным ответом теоретически может помешать ответчику ответить бесконечно. На практике ответы никогда не задерживаются значительно, и в случае возникновения ситуации, когда действительно произошли значительные задержки, это может быть сценарий, когда сеть перегружена настолько, что было бы желательно допустить ошибку из-за осторожности. Следствием задержки ответа может быть то, что пользователю требуется больше времени, чем обычно, чтобы обнаружить все услуги в локальной сети; напротив, следствием неправильного ответа до того, как все пакеты «Известный ответ» будут получены, будет потраченная впустую емкость, посылая ненужные ответы в уже перегруженной сети. В этой (редкой) ситуации жертвой скорости для сохранения надежной работы сети является правильный компромисс.

7.3. Подавление дубликатов вопросов

Если хост планирует передать (или повторно передать) запрос, и он видит, что другой хост в сети отправляет запрос, содержащий тот же вопрос «QM», и раздел «Известный ответ» этого запроса не содержит записей о том, что этот хост не будет также помещать в свой собственный раздел «Известные ответы», тогда этот хост ДОЛЖЕН обрабатывать свой собственный запрос как отправленный. Когда несколько запросов в сети запрашивают одни и те же записи ресурсов, им не нужно многократно задавать один и тот же вопрос.

7.4. Подавление дубликата ответа

Если хост планирует отправить ответ, и он видит, что другой хост в сети отправляет ответное сообщение, содержащее ту же самую запись ответа, и TTL в этой записи не меньше, чем TTL, который этот хост дал бы, то этому хосту СЛЕДУЕТ обрабатывать свой ответ как отправленный, а не отправлять идентичный ответ сам. Когда несколько респондентов в сети имеют одинаковые данные, нет необходимости всем им отвечать.

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

Эта функция особенно полезна, когда используются многоадресные DNS-прокси-серверы, когда в сети может быть несколько прокси-серверов, дающих многоадресные DNS-ответы от имени другого хоста (например, потому что этот другой хост в данный момент спит и сам не отвечает). на запросы).

8. Проверка и объявление при запуске

Обычно многоадресный DNS-ответчик должен иметь, как минимум, адресные записи для всех своих активных интерфейсов. Создание и реклама записи HINFO на каждом интерфейсе также могут быть полезны для сетевых администраторов.

Каждый раз, когда многоадресный DNS-ответчик запускается, просыпается из спящего режима, получает указание о событии «Изменение соединения» сетевого интерфейса или имеет любую другую причину полагать, что его сетевое подключение могло измениться каким-либо соответствующим способом, он ДОЛЖЕН выполнить два шаги запуска ниже: Зондирование (Раздел 8.1) и Объявление (Раздел 8.3).

8.1. Прощупывание — Probing

Первый шаг запуска заключается в том, что для всех тех записей ресурсов, которые респондент многоадресной DNS желает быть уникальными в локальной ссылке, он ДОЛЖЕН отправить DNS-запрос многоадресной рассылки с запросом на эти записи ресурса, чтобы проверить, используются ли какие-либо из них. Основным примером этого являются записи адресов узла, которые сопоставляют его уникальное имя с уникальными адресами IPv4 и / или IPv6. Все зондирующие запросы ДОЛЖНЫ выполняться с использованием нужного имени и класса записи ресурса (обычно это класс 1, «Интернет») и типа запроса «ЛЮБОЙ» (255), чтобы получить ответы для всех типов записей с этим именем. Это позволяет использовать один вопрос вместо нескольких, что более эффективно в сети. Это также позволяет хосту проверять исключительное владение именем для всех rrtypes, что желательно в большинстве случаев. Например, было бы странно, если бы одному хосту принадлежала запись «A» для «myhost.local.», Но другому хосту принадлежала запись «AAAA» для этого имени.

В этом случае полезна возможность размещения более одного вопроса в многоадресном DNS-запросе, поскольку он может позволить хосту использовать одно сообщение для проверки всех своих записей ресурсов вместо необходимости отдельного сообщения для каждого. Например, хост может одновременно проверять уникальность своей записи «A» и всех своих записей SRV [RFC6763] в одном и том же сообщении запроса.

Когда все готово для отправки своих тестовых пакетов DNS многоадресной рассылки, хост должен сначала дождаться короткого случайного времени задержки, равномерно распределенного в диапазоне 0-250 мс. Эта случайная задержка предназначена для защиты от случая, когда несколько устройств включаются одновременно, или несколько устройств подключаются к концентратору Ethernet, который затем включается, или происходит какое-то другое внешнее событие, которое может привести к тому, что группа хостов отправит все синхронизированные зонды.

Через 250 мс после первого запроса хост должен отправить второй; затем, через 250 мс, третий. Если через 250 мс после третьего теста не было получено конфликтующих ответов многоадресной DNS, хост может перейти к следующему шагу, объявив. (Обратите внимание, что зондирование — это единственное исключение из обычного правила, что между повторениями одного и того же вопроса должна быть не менее одной секунды, а интервал между последующими повторениями должен быть как минимум удвоен.)

При отправке тестовых запросов хост НЕ ДОЛЖЕН проверять свой кэш на наличие возможных ответов. Только конфликтующие многоадресные DNS-ответы, полученные «живым» из сети, считаются действительными для определения того, было ли зондирование успешным или неудачным.

Чтобы позволить службам объявлять о своем присутствии без необоснованной задержки, временное окно для проверки намеренно установлено достаточно коротким. В результате этого с момента отправки первого тестового пакета другое устройство в сети, использующее это имя, имеет всего 750 мс для ответа на защиту своего имени. В медленных или загруженных сетях, или в обоих случаях, задержка прохождения сигнала туда и обратно может составлять несколько сотен миллисекунд, а задержки программного обеспечения в медленных устройствах могут добавить дополнительную задержку. Следовательно, важно, чтобы, когда устройство получило пробный запрос на имя, которое оно использует в настоящее время, оно ДОЛЖНО сгенерировать свой ответ, чтобы немедленно защитить это имя и отправить его как можно быстрее. Обычные правила о случайных задержках перед ответом, чтобы избежать внезапных пакетов одновременных ответов от разных хостов, здесь не применяются, так как обычно максимум один хост должен когда-либо отвечать на заданный пробный вопрос. Даже если одно сообщение с запросом DNS содержит несколько тестовых вопросов, для этого сообщения было бы необычно вызывать защитный ответ более чем с одного другого хоста. Из-за правил ограничения скорости многоадресной передачи mDNS зонды СЛЕДУЕТ отправлять в виде вопросов «QU» с установленным битом одноадресной рассылки, чтобы разрешить защищающемуся хосту отвечать немедленно через одноадресную рассылку, вместо того, чтобы потенциально ждать, прежде чем ответить через многоадресную рассылку.

Во время зондирования с момента отправки первого пробного пакета до 250 мс после третьего зондирования, если получен какой-либо конфликтующий ответ многоадресной DNS, тогда зондирующий хост ДОЛЖЕН отложить существующий хост и ДОЛЖЕН выбрать новые имена для некоторых или всех его ресурсные записи по мере необходимости. Очевидно, что конфликтующие многоадресные DNS-ответы, полученные * перед * отправкой первого тестового пакета, ДОЛЖНЫ игнорироваться (см. Обсуждение устаревших тестовых пакетов в Разделе 8.2, «Одновременное прерывание связи зонда» ниже). В случае проверки хоста с использованием типа запроса «ЛЮБОЙ», как рекомендовано выше, любой ответ, содержащий запись с таким именем любого типа, ДОЛЖЕН рассматриваться как конфликтующий ответ и обрабатываться соответствующим образом.

Если в течение любого десятисекундного периода возникает пятнадцать конфликтов, то хост ДОЛЖЕН подождать не менее пяти секунд перед каждой последующей попыткой дополнительной проверки. Это должно помочь гарантировать, что в случае программных ошибок или других непредвиденных проблем, ошибочные хосты не будут заполнять сеть непрерывным потоком многоадресного трафика. Для очень простых устройств действительный способ выполнить это требование — всегда ждать пять секунд после любой неудачной попытки проверки, прежде чем пытаться снова.

Если респондент другим способом знает, что его уникальное имя набора записей ресурсов, rrtype и rrclass уже не может использоваться любым другим респондентом в сети, то он ДОЛЖЕН пропустить этап проверки для этого набора записей ресурсов. Например, при создании записей PTR с обратным сопоставлением адресов хост может разумно предположить, что никакой другой хост не будет пытаться создать те же записи PTR, поскольку это будет означать, что два хоста пытаются использовать один и тот же IP-адрес, и если в этом случае два хоста будут страдать от проблем со связью, выходящих за рамки возможностей Multicast DNS. Точно так же, если респондент действует как прокси-сервер, перенимая у другого многоадресного DNS-респондента, который уже проверил уникальность записи, то прокси-сервер НЕ ДОЛЖЕН повторять этап проверки для этих записей.

8.2. Синхронный разрыв пробника

Проницательный читатель заметит, что в предыдущем описании есть условие гонки. Если два хоста одновременно проверяют одно и то же имя, ни один из них не получит никакого ответа на запрос, и хосты могут ошибочно прийти к выводу, что оба могут перейти к использованию имени. Чтобы нарушить эту симметрию, каждый узел заполняет секцию авторизации сообщения запроса записью или записями с помощью rdata, которые он будет предлагать использовать, если его проверка будет успешной. Раздел полномочий используется здесь способом, аналогичным тому, как он используется в качестве «раздела обновления» в сообщении об обновлении DNS [RFC2136] [RFC3007].

Когда хост выполняет поиск группы связанных записей с одним и тем же именем (например, запись SRV и TXT, описывающая службу DNS-SD), в разделе вопросов необходимо разместить только один вопрос, поскольку тип запроса «ЛЮБОЙ» ( 255), который будет вызывать ответы для всех записей с этим именем. Однако для правильной работы тай-брейка во всех случаях Секция полномочий должна содержать * все * записи и предлагаемые данные, проверяемые на предмет уникальности.

Когда узел, который проверяет запись, видит, что другой узел отправляет запрос на эту же запись, он обращается к разделу полномочий этого запроса. Если он находит какую-либо запись (записи) ресурса там, которая отвечает на запрос, то он сравнивает данные этой (этих) записи (записей) ресурса со своими собственными предварительными данными. Сначала мы рассмотрим простой случай, когда хост проверяет одну запись, одновременно получая запрос от другого хоста, который также проверяет одну запись. Две записи сравниваются и лексикографически более поздние данные выигрывают. Это означает, что если хост обнаружит, что его собственные данные лексикографически позже, он просто игнорирует зонд другого хоста. Если хост обнаруживает, что его собственные данные лексикографически раньше, то он переносится на хост-победитель, ожидая одну секунду, а затем снова начинает поиск этой записи. Логика ожидания одной секунды, а затем повторной попытки заключается в защите от устаревших тестовых пакетов в сети (возможно, даже от устаревших тестовых пакетов, отправленных несколько минут назад самим этим хостом, до некоторого изменения конфигурации, которое может быть возвращено после небольшой задержки некоторыми Ethernet-коммутаторы и некоторые базовые станции 802.11). Если победивший одновременный зонд был от другого реального хоста в сети, то через одну секунду он завершит свое зондирование и ответит на последующие зондирования. Если явно выигравший одновременный зонд на самом деле был просто старым устаревшим пакетом в сети (возможно, от самого хоста), то, когда он повторяет свое зондирование в одну секунду, его зондирование остается без ответа, и он успешно запрашивает имя.

Определение «лексикографически позже» выполняется сначала путем сравнения класса записи (за исключением бита очистки кеша, описанного в разделе 10.2), затем типа записи, затем необработанного сравнения двоичного содержимого rdata без учета значения или структуры. Если классы записей различаются, то численно больший класс считается «лексикографически позже». В противном случае, если типы записей различаются, то численно больший тип считается «лексикографически позже». Если оба rrtype и rrclass совпадают, тогда сравниваются rdata.

В случае записей ресурсов, содержащих rdata, которая подвергается сжатию имен [RFC1035], имена ДОЛЖНЫ быть несжатыми перед сравнением. (Сведения о том, как конкретное имя сжимается, являются артефактом того, как и где запись записывается в сообщение DNS; это не внутреннее свойство самой записи ресурса.)

Байты необработанных несжатых rdata сравниваются по очереди, интерпретируя байты как восьмибитовые значения UNSIGNED, пока не будет найден байт, значение которого больше значения его аналога (в этом случае rdata, байт которого имеет большее значение, равен считается лексикографически более поздним) или одна из записей ресурсов исчерпывает rdata (в этом случае запись ресурса, в которой все еще остаются оставшиеся данные вначале, считается лексикографически позднее). Ниже приведен пример конфликта:

MyPrinter.local. A 169.254.99.200
MyPrinter.local. A 169.254.200.50

В этом случае 169.254.200.50 лексикографически позже (третий байт со значением 200 больше, чем его аналог со значением 99), поэтому он считается победителем.

Обратите внимание, что очень важно, чтобы байты интерпретировались как значения UNSIGNED в диапазоне 0-255, иначе это может привести к неверному результату. В приведенном выше примере, если байт со значением 200 был неправильно интерпретирован как восьмибитное значение со знаком, то он будет интерпретирован как значение -56, и неправильная запись адреса будет считаться победителем.

8.2.1. Одновременное прерывание пробника для нескольких записей

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

Записи сортируются в том же лексикографическом порядке, как описано выше, то есть, если классы записей различаются, запись с меньшим номером класса идет первой. Если классы одинаковы, но rrtypes различаются, запись с меньшим номером rrtype идет первой. Если класс и rrtype совпадают, тогда rdata сравнивается побайтно, пока не будет найдено различие. Например, в общем случае объявления служб DNS-SD с помощью записи TXT и записи SRV запись TXT идет первой (значение rrtype для TXT равно 16), а запись SRV идет второй (значение rrtype для SRV составляет 33).

При сравнении записей, если первые записи идеально совпадают, то сравниваются вторые записи и так далее. Если в каком-либо списке записей заканчиваются записи до того, как обнаруживается какая-либо разница, то считается, что список с оставшимися записями выиграл тай-брейк. Если в обоих списках одновременно заканчиваются записи без каких-либо различий, это означает, что два устройства объявляют идентичные наборы записей, как это иногда делается для обеспечения отказоустойчивости, и фактически никакого конфликта нет.

8.3. Объявление

Вторым этапом запуска является то, что респондент многоадресной DNS ДОЛЖЕН послать незапрошенный ответ многоадресной DNS, содержащий в разделе ответов все свои новые зарегистрированные записи ресурсов (как общие записи, так и уникальные записи, которые завершили этап проверки). Если имеется слишком много записей ресурсов для одного пакета, следует использовать несколько пакетов.

В случае общих записей (например, записей PTR, используемых обнаружением службы на основе DNS [RFC6763]), записи просто помещаются как есть в раздел ответа ответа DNS.

В случае записей, которые были проверены как уникальные на предыдущем шаге, они помещаются в раздел ответа ответа DNS с наиболее значимым битом rrclass, установленным в единицу. Наиболее значимым битом rrclass для записи в разделе «Ответ» ответного сообщения является бит очистки кэша многоадресной DNS, который более подробно обсуждается ниже в разделе 10.2 «Объявления для очистки устаревших записей кэша».

DNS-ответчик многоадресной рассылки ДОЛЖЕН отправить не менее двух нежелательных ответов с интервалом в одну секунду. Чтобы обеспечить повышенную устойчивость к потере пакетов, ответчик МОЖЕТ отправить до восьми незапрошенных ответов, при условии, что интервал между незапрошенными ответами увеличивается по крайней мере в два раза с каждым отправленным ответом.

DNS-ответчик многоадресной рассылки НЕ ДОЛЖЕН отправлять объявления в отсутствие информации о том, что его сетевое подключение могло измениться каким-либо соответствующим образом. В частности, многоадресный DNS-ответчик НЕ ДОЛЖЕН отправлять регулярные периодические объявления как само собой разумеющееся.

Всякий раз, когда респондент многоадресной DNS получает любой ответ многоадресной DNS (запрошенный или иным образом), содержащий конфликтующую запись ресурса, конфликт ДОЛЖЕН быть разрешен, как описано в Разделе 9 «Разрешение конфликтов — Conflict Resolution».

8.4. Обновление

В любое время, если rdata какой-либо из записей DNS многоадресной рассылки хоста изменяется, хост ДОЛЖЕН повторить шаг Announcing, описанный выше, чтобы обновить соседние кэши. Например, если какой-либо из IP-адресов хоста изменяется, он ДОЛЖЕН повторно объявить эти записи адресов. Хосту не нужно повторять шаг зондирования, поскольку он уже установил уникальное право собственности на это имя.

В случае общих записей, хост ДОЛЖЕН послать объявление «до свидания» с нулевым TTL RR (см. Раздел 10.1, «Пакеты прощания») для старых rdata, чтобы его можно было удалить из одноранговых кэшей, прежде чем объявить новые rdata , В случае уникальных записей хосту СЛЕДУЕТ пропустить объявление «до свидания», поскольку бит очистки кэша во вновь объявленных записях в любом случае приведет к сбросу старых rdata из одноранговых кэшей.

Хост может обновлять содержимое любой из своих записей в любое время, хотя хост НЕ ДОЛЖЕН обновлять записи чаще, чем десять раз в минуту. Частые быстрые обновления создают нагрузку на сеть. Если у хоста есть информация для распространения, которая меняется чаще, чем десять раз в минуту, тогда может быть более целесообразно разработать протокол для этой конкретной цели.

9. Разрешение конфликтов

Конфликт возникает, когда респондент многоадресной DNS имеет уникальную запись, для которой он в настоящий момент является доверенным, и он получает ответное сообщение многоадресной DNS, содержащее запись с тем же именем, rrtype и rrclass, но несовместимыми rdata. То, что может считаться несовместимым, является контекстно-зависимым, за исключением того, что записи ресурсов с одинаковыми rdata никогда не считаются несовместимыми, даже если они происходят от разных хостов. Это делается для того, чтобы разрешить использование прокси-серверов и других отказоустойчивых механизмов, которые могут привести к тому, что более одного ответчика будут способны выдавать идентичные ответы в сети.

Типичным примером типа записи ресурса, который должен быть уникальным и не разделяемым между хостами, является запись адреса, которая отображает имя хоста на его IP-адрес. Если узел является свидетелем того, как другой хост объявит адресную запись с тем же именем, но с другим IP-адресом, это считается несоответствующим, и эта адресная запись считается конфликтующей.

Всякий раз, когда респондент многоадресной DNS получает любой ответ многоадресной DNS (запрошенный или иным образом), содержащий конфликтующую запись ресурса в любом из разделов записи ресурса, респондент многоадресной DNS ДОЛЖЕН немедленно переустанавливает свою конфликтующую уникальную запись в состояние проверки и выполняет описанные шаги запуска. выше в Разделе 8 «Проверка и оповещение при запуске». Протокол, используемый на этапе проверки, определит победителя и проигравшего, а проигравший ДОЛЖЕН прекратить использовать имя и перенастроить.

Очень важно, чтобы любой хост, получающий запись ресурса, которая конфликтует с одной из его собственных, ДОЛЖЕН предпринимать действия, как описано выше. В случае двух хостов, использующих одно и то же имя хоста, когда один из них был настроен для запроса уникального имени хоста, а другой — нет, тот, который не был настроен для запроса уникального имени хоста, не воспримет никакого конфликта и будет не предпринимать никаких действий. Вернувшись в состояние «Зондирование», хост, которому требуется уникальное имя хоста, выполнит необходимые шаги, чтобы обеспечить получение уникального имени хоста.

Рекомендуемый порядок действий после проб и ошибок следующий:

1. Программно измените имя записи ресурса, чтобы найти новое уникальное имя. Это можно сделать, добавив некоторую дополнительную идентификационную информацию (например, название модели оборудования), если она еще не присутствует в имени, или добавив цифру «2» к имени, или увеличив число в конце Назовите, если один уже присутствует.

2. Снова проверьте и повторяйте при необходимости, пока не будет найдено уникальное имя.

3. Как только доступное уникальное имя было определено путем исследования без получения какого-либо противоречивого ответа, запишите это вновь выбранное имя в постоянное хранилище, чтобы устройство использовало то же имя в следующий раз, когда оно будет выключено.

4. Отобразите сообщение для пользователя или оператора, информирующее их об изменении имени.

Например: Имя «Музыка Боба» используется другим музыкальным сервером в сети. Ваша музыкальная коллекция была переименована в «Bob’s Music (2)». Если вы хотите изменить это имя, используйте [опишите соответствующий пункт меню или диалог предпочтений здесь].

Сведения о том, как пользователь или оператор получают информацию о новом имени, зависят от контекста. Настольный компьютер с экраном может открыть диалоговое окно. Безголовый сервер в шкафу может записать сообщение в файл журнала или использовать любой механизм (электронная почта, SNMP-ловушка и т. Д.), Который он использует, чтобы сообщить администратору об ошибках. С другой стороны, автономный сервер в шкафу может вообще не информировать пользователя — если пользователь захочет, он заметит, что имя изменилось, и подключится к серверу обычным способом (например, через веб-браузер), чтобы настроить новое имя.

5. После одной минуты проверки, если многоадресному DNS-ответчику не удалось найти какое-либо неиспользуемое имя, он должен записать сообщение об ошибке, чтобы проинформировать пользователя или оператора об этом факте. Такая ситуация никогда не должна возникать при нормальной работе. Единственными ситуациями, которые могут вызвать это, может быть либо преднамеренная атака типа «отказ в обслуживании», либо какая-то очень неясная аппаратная или программная ошибка, которая действует как преднамеренная атака типа «отказ в обслуживании».

Эти соображения применимы к адресным записям (то есть к именам хостов) и ко всем ресурсным записям, где требуется уникальность (или поддержание некоторого другого определенного ограничения).

10. Значения TTL записи ресурса и когерентность кэша

Как правило, рекомендуемое значение TTL для многоадресных записей ресурсов DNS с именем хоста в качестве имени записи ресурса (например, A, AAAA, HINFO) или именем хоста, содержащимся в rdata записи ресурса (например, SRV, PTR с обратным отображением) запись) ДОЛЖНО быть 120 секунд.

Рекомендуемое значение TTL для других записей ресурсов многоадресной DNS составляет 75 минут.

Запрашивающий с активным невыполненным запросом выдаст сообщение с запросом, когда одна или несколько записей ресурсов в его кэше имеют 80% срока действия. Если TTL для этих записей составляет 75 минут, этот текущий процесс обслуживания кэша дает устойчивую частоту запросов одного запроса каждые 60 минут.

Любой распределенный кеш нуждается в протоколе когерентности кеша. Если записи ресурсов многоадресного DNS следуют рекомендациям и имеют TTL 75 минут, это означает, что устаревшие данные могут сохраняться в системе в течение чуть более часа. Значительно меньшее значение RR TTL по умолчанию сократит время жизни устаревших данных, но создаст слишком большой дополнительный трафик в сети. Для минимизации влияния таких устаревших данных доступны различные методы, описанные в пяти подразделах ниже.

10.1. Прощальные пакеты

В случае, когда хост знает, что определенные данные записи ресурса вот-вот станут недействительными (например, когда хост подвергается чистому завершению), хост ДОЛЖЕН отправить незапрошенный ответный пакет многоадресной DNS, предоставив то же имя записи ресурса, rrtype. , rrclass и rdata, но RR TTL равно нулю. Это приводит к обновлению значения TTL, хранящегося в записях кэша соседних хостов, до нуля, в результате чего эта запись кэша будет быстро удалена.

Запрашивающим, получающим многоадресный DNS-ответ с нулевым TTL, НЕ СЛЕДУЕТ немедленно удалять запись из кэша, а вместо этого записывать TTL, равный 1, а затем удалять запись через секунду. В случае нескольких многоадресных DNS-ответчиков в сети, описанных в Разделе 6.6 выше, если один из ответчиков завершает работу и неправильно отправляет прощальные пакеты для своих записей, он дает другим взаимодействующим ответчикам одну секунду, чтобы отправить свой собственный ответ для «спасения — rescue». msgstr «записи до истечения срока их действия и удалены.

10.2. Объявления для очистки устаревших записей кэша

Всякий раз, когда у узла есть запись ресурса с новыми данными или с тем, что потенциально может быть новыми данными (например, после перезагрузки, пробуждения из спящего режима, подключения к новой сетевой ссылке или изменения IP-адреса), хост должен сообщать об этом партнерам. новые данные. В тех случаях, когда хост не был постоянно подключен и участвует в сетевом соединении, он ДОЛЖЕН сначала проверить уникальность своих уникальных записей, как описано выше в Разделе 8.1, «Зондирование».

После завершения шага проверки, при необходимости, хост ДОЛЖЕН послать серию незапрошенных объявлений для обновления записей кэша на соседних хостах. В этих незапрошенных объявлениях, если запись является проверенной уникальностью, хост устанавливает старший значащий бит поля rrclass записи ресурса. Этот бит, бит очистки кэша, сообщает соседним хостам, что это не общий тип записи. Вместо того, чтобы объединять эту новую запись аддитивно в кеш в дополнение к любым предыдущим записям с тем же именем, rrtype и rrclass, все старые записи с этим именем, rrtype и rrclass, которые были получены более одной секунды назад, объявляются недействительными, и отмечен как истекающий из кэша в одну секунду.

Семантика бита очистки кеша следующая: обычно, когда запись ресурса появляется в разделе записи ресурса в ответе DNS, это означает: «Это утверждение, что эта информация истинна». Когда запись ресурса появляется в разделе «Запись ресурса» ответа DNS с установленным битом очистки кэша, это означает: «Это утверждение, что эта информация является правдой и всей правдой, и все, что вы, возможно, слышали больше, чем Второй назад относительно записей с этим именем / rrtype / rrclass больше не соответствует действительности «.

Чтобы учесть случай, когда набор записей с одного хоста, составляющих один уникальный RRSet, слишком велик для размещения в одном пакете, сбрасываются только записи кэша, возраст которых превышает одну секунду. Это позволяет хосту, который объявляет, генерировать быстрый пакет пакетов «спина к спине» по сети, содержащий все члены RRSet. При получении записей с установленным битом очистки кеша все записи старше одной секунды помечаются для удаления на одну секунду в будущем. Через одну секунду после окончания небольшого пакета пакетов все записи, не представленные в этом пакете, будут истекать из всех одноранговых кэшей.

Каждый раз, когда хост отправляет пакет ответа, содержащий некоторые элементы уникального RRSet, он ДОЛЖЕН отправить весь RRSet, предпочтительно в одном пакете, или если весь RRSet не уместится в одном пакете, в быстром пакете пакетов, отправленных как близко друг к другу, насколько это возможно. Хост ДОЛЖЕН установить бит очистки кэша для всех членов уникального RRSet.

Другой причиной ожидания одной секунды перед удалением устаревших записей из кэша является размещение мостовых сетей. Например, объявление записи адреса хоста по беспроводному интерфейсу может быть соединено с проводным Ethernet и может привести к тому, что записи адреса Ethernet того же хоста будут сброшены из одноранговых кэшей. Задержка в одну секунду дает хосту возможность увидеть, как его собственное объявление поступило в проводной Ethernet, и немедленно повторно объявить записи адресов своего интерфейса Ethernet, чтобы оба набора оставались действительными и находились в одноранговых кешах.

Эти правила, касающиеся того, когда устанавливать бит очистки кеша и отправлять весь rrset, применяются независимо от того, * почему * генерируется ответное сообщение. Они применяются к объявлениям при запуске, как описано в Разделе 8.3, «Объявление», и к ответам, генерируемым в результате получения сообщений с запросами.

Бит очистки кэша устанавливается только в записях в разделах записей ресурсов DNS-ответов многоадресной рассылки, отправляемых на UDP-порт 5353.

Бит очистки кэша НЕ ДОЛЖЕН устанавливаться ни в одной записи ресурса в ответном сообщении, отправляемом в устаревших одноадресных ответах на порты UDP, отличные от 5353.

Бит очистки кеша НЕ ДОЛЖЕН устанавливаться ни в одной записи ресурса в списке Known-Answer любого сообщения запроса.

Бит очистки кеша НЕ ДОЛЖЕН устанавливаться ни в одной записи общего ресурса. Это может привести к немедленному удалению всех других общих версий этой записи ресурса с разными rdata от разных респондентов из всех кешей в сети.

Бит очистки кеша * не * применяется к вопросам, перечисленным в разделе вопросов многоадресного DNS-сообщения. Верхний бит поля rrclass в вопросах используется для совершенно другой цели (см. Раздел 5.4, «Вопросы, запрашивающие одноадресные ответы»).

Обратите внимание, что бит очистки кэша НЕ является частью класса записи ресурса. Бит очистки кеша является наиболее значимым битом второго 16-битного слова записи ресурса в разделе записи ресурса в многоадресном DNS-сообщении (поле, обычно называемое полем rrclass), а фактический класс записи ресурса равен наименее значимые пятнадцать битов этого поля. Не существует класса записи ресурса многоадресной DNS 0x8001. Значение 0x8001 в поле rrclass записи ресурса в ответном сообщении DNS многоадресной рассылки указывает на запись ресурса с классом 1 с установленным битом очистки кэша. При получении записи ресурса с установленным битом очистки кеша реализации должны позаботиться о том, чтобы замаскировать этот бит перед сохранением записи ресурса в памяти или иным образом обеспечить правильную семантическую интерпретацию.

Повторное использование верхнего бита поля rrclass применяется только к обычным типам записей ресурсов, которые подлежат кэшированию, а не к псевдо-RR, таким как OPT [RFC2671], TSIG [RFC2845], TKEY [RFC2930], SIG0 [RFC2931] и т. Д. ., которые относятся только к конкретному сообщению транспортного уровня, а не к каким-либо фактическим данным DNS. Поскольку псевдо-RR никогда не должны входить в кэш многоадресной DNS, концепция бита очистки кэша для этих типов неприменима. В частности, поле rrclass записи OPT кодирует размер полезной нагрузки UDP отправителя и должно интерпретироваться как значение длины в шестнадцать бит в диапазоне 0-65535, а не флаг в один бит и длина в пятнадцать бит.

10.3. Очистка кэша при изменении топологии

Если оборудование на данном хосте может указывать на физические изменения подключения, тогда, когда оборудование указывает на такое изменение, хост должен учитывать эту информацию в своей стратегии управления кешем многоадресной DNS. Например, хост может выбрать немедленную очистку всех записей кэша, полученных на определенном интерфейсе, когда этот кабель отключен. В качестве альтернативы, хост может настроить оставшийся TTL на всех этих записях на несколько секунд, чтобы, если кабель не будет повторно подключен быстро, эти записи истекут из кэша.

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

10.4. Очистка кэша при индикации сбоя

Иногда можно определить, что запись в кэше устарела, когда клиент пытается использовать содержащиеся в ней данные, и клиент считает эти данные неверными.

Например, rdata в записи адреса может быть определен как неправильный, если попытки связаться с этим хостом не удаются, либо потому, что (для адреса IPv4 в локальной подсети) запросы ARP для этого адреса остаются без ответа, потому что (для адреса IPv6 с префикс on-link) ND-запросы для этого адреса остаются без ответа, или потому что (для адреса в удаленной сети) маршрутизатор возвращает ошибку ICMP «Host Unreachable».

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

Данные в записи PTR DNS-SD могут быть определены как неправильные, если попытки поиска записи SRV, на которую они ссылаются, не увенчались успехом.

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

Когда кэш получает эту подсказку о том, что он должен подтвердить какую-либо запись, он ДОЛЖЕН выполнить два или более запросов для записи ресурса в споре. Если в течение десяти секунд ответ не получен, то, хотя его TTL может указывать, что срок его действия еще не истек, эта запись ДОЛЖНА быть незамедлительно удалена из кэша.

Конечным результатом этого является то, что если принтер испытывает внезапное отключение питания или другое внезапное отключение от сети, его имя может продолжать появляться в списках обозревателей DNS-SD, отображаемых на экранах пользователей. В конце концов, эта запись истекает из кеша естественным образом, но если пользователь попытается получить доступ к принтеру до того, как это произойдет, неудачная попытка связаться с принтером вызовет более поспешное завершение его записей в кеш. Это разумный компромисс между хорошим пользовательским опытом и хорошей эффективностью сети. Если бы мы настаивали на том, чтобы принтеры исчезали из списка принтеров в течение 30 секунд после того, как они стали недоступными, для всех режимов сбоев единственный способ добиться этого состоял бы в том, чтобы клиент опрашивал принтер по крайней мере каждые 30 секунд, или для принтера объявлять о своем присутствии, по крайней мере, каждые 30 секунд, что будет неоправданным бременем для большинства сетей.

10.5. Пассивное Наблюдение Отказов — Passive Observation Of Failures (POOF)

Хост наблюдает за многоадресными запросами, выданными другими хостами в сети. Одним из основных преимуществ отправки ответов с использованием многоадресной рассылки является то, что она позволяет всем хостам видеть ответы (или их отсутствие) на эти запросы.

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

После просмотра двух или более из этих запросов и отсутствия ответа многоадресной рассылки, содержащего ожидаемый ответ, в течение десяти секунд, даже если его TTL может указывать, что срок его действия еще не истек, эта запись ДОЛЖНА быть удалена из кэша. Хосту НЕ СЛЕДУЕТ выполнять собственные запросы, чтобы подтвердить, что запись действительно пропала. Если бы каждый хост в большой сети делал это, это вызвало бы много ненужного многоадресного трафика. Если узел A отправляет многоадресные запросы, которые остаются без ответа, то нет никаких оснований полагать, что узел B или любой другой узел, вероятно, будет более успешным.

В предыдущем разделе «Очистка кэша при индикации сбоя» описывается ситуация, когда пользователь, пытающийся распечатать, обнаруживает, что принтер больше не доступен. Благодаря реализации пассивного наблюдения, описанного здесь, когда один пользователь не может связаться с принтером, все хосты в сети обнаруживают этот сбой и соответственно обновляют свои кэши.

11. Проверка адреса источника

Все ответы на Multicast DNS (включая ответы, отправленные с помощью одноадресной передачи) СЛЕДУЕТ отправлять с IP TTL, установленным в 255. Рекомендуется обеспечить обратную совместимость со старыми запросами DNS для Multicast (реализует черновую версию этого документа, опубликованную в феврале 2004 года), которые проверяют IP TTL на приеме, чтобы определить, возник ли пакет на локальной линии связи. Эти старые запросы отменяют все пакеты с TTL, отличными от 255.

Узел, отправляющий многоадресные DNS-запросы на локальный адрес ссылки (включая 224.0.0.251 и локальные многоадресные адреса FF02 :: FB link), ДОЛЖЕН принимать только те ответы на этот запрос, которые исходят от локальной ссылки, и молча отбрасывать любые другие ответы. пакеты. Без этой проверки удаленные мошеннические хосты могли бы отправлять поддельные ответные пакеты (возможно, одноадресные на хост-жертву), которые принимающая машина могла неверно истолковать как исходящие из локальной линии.

Проверка того, был ли получен ответ по локальной ссылке, выполняется двумя способами:

Все ответы, полученные с адресом назначения в заголовке IP, который является локальным многоадресным адресом канала IPv4 mDNS 224.0.0.251 или локальным адресом многоадресной передачи канала IPv6 mDNS FF02 :: FB, обязательно считаются отправленными по локальной ссылке, независимо от исходного IP-адреса. Это важно для обеспечения правильной и надежной работы устройств в необычных конфигурациях, таких как несколько логических подсетей IP, наложенных на один канал, или в случаях серьезной неправильной конфигурации, когда устройства физически подключены к одному каналу, но в настоящее время неправильно настроены на полностью несвязанные IP-адреса и маски подсети.
Для ответов, полученных с адресом одноадресной рассылки в заголовке IP, проверяется IP-адрес источника в пакете, чтобы определить, является ли он адресом в локальной подсети. Адрес источника IPv4 определяется как находящийся в локальной подсети, если для (одного из) адресов, настроенных на интерфейсе, принимающем пакет, (I & M) == (P & M), где I и M адрес интерфейса и маска подсети соответственно, P — IP-адрес источника из пакета, ‘&’ представляет побитовую логическую ‘и’ операцию, а ‘==’ представляет битовый тест на равенство. Исходный адрес IPv6 определяется на локальной линии, если для любого из префиксов IPv6 на линии на интерфейсе, получающем пакет (полученным через объявления маршрутизатора IPv6 или настроенным иным образом на хосте), первые n битов адрес источника IPv6 совпадает с первыми «n» битами адреса префикса, где «n» — длина рассматриваемого префикса.

Поскольку запросчики будут игнорировать ответы, по-видимому, происходящие за пределами локальной подсети, ответчик ДОЛЖЕН избегать генерирования ответов, которые он может разумно предсказать, будут игнорироваться. Это особенно относится к наложенным подсетям. Если ответчик получает запрос, адресованный многоадресному локальному адресу канала IPv4 mDNS 224.0.0.251, с адреса источника, который явно не находится в той же подсети, что и ответчик (или, в случае IPv6, с адреса источника IPv6, для которого у ответчика нет никакого адреса с тем же префиксом на этом интерфейсе), тогда, даже если запрос указывает, что предпочтителен одноадресный ответ (см. Раздел 5.4, «Вопросы, запрашивающие одноадресные ответы»), ответчик ДОЛЖЕН выбрать ответ в любом случае многоадресной рассылкой, поскольку он может разумно предсказать, что одноадресный ответ с явно нелокальным адресом источника, вероятно, будет игнорироваться.

12. Особые характеристики многоадресных DNS-доменов

В отличие от обычных DNS-имен, имена, заканчивающиеся на «.local». имеют только локальное значение. То же самое относится и к именам в локальном домене обратного сопоставления IPv4 «254.169.in-addr.arpa». и локальные обратные сопоставления IPv6-доменов «8.e.f.ip6.arpa.», «9.e.f.ip6.arpa.», «a.e.f.ip6.arpa.» и «b.e.f.ip6.arpa.».

Эти имена функционируют главным образом как идентификаторы протокола, а не как видимые для пользователя идентификаторы. Даже если они иногда могут быть видны конечным пользователям, это не является их основной целью. Как таковые, эти имена должны рассматриваться как непрозрачные идентификаторы. В частности, строка «local» не должна переводиться или локализоваться на разные языки, так же как имя «localhost» не переводится и не локализуется на разных языках.

Обычный одноадресный DNS стремится предоставить единое единое пространство имен, где данный DNS-запрос дает один и тот же ответ независимо от того, где на планете он выполняется или на какой рекурсивный DNS-сервер отправляется запрос. Напротив, каждая IP-ссылка имеет свой собственный «.local.», «254.169.in-addr.arpa.» и пространства имен обратного сопоставления IPv6 link-local, и ответ на любой запрос имени в этих доменах зависит от того, где этот запрос запрашивается. (Эта характеристика не уникальна для многоадресной DNS. Хотя первоначальная концепция DNS представляла собой единое глобальное пространство имен, в последние годы разделенные представления, брандмауэры, интрасети, геолокация DNS и т. П. Все чаще означали, что ответ на данный запрос DNS стала зависеть от местоположения запрашивающего.)

Адрес сервера имен IPv4 для домена многоадресной DNS — 224.0.0.251. Адрес сервера имен IPv6 для многоадресного DNS-домена — FF02 :: FB. Это многоадресные адреса; поэтому они идентифицируют не один хост, а совокупность хостов, работая совместно для поддержания некоторого разумного факсимильного сообщения в грамотно управляемой зоне DNS. Концептуально, многоадресный DNS-домен — это единая DNS-зона; однако его сервер реализован как распределенный процесс, работающий на кластере свободно взаимодействующих процессоров, а не как отдельный процесс, работающий на одном процессоре.

Домены многоадресной DNS не делегируются от своего родительского домена с помощью записей NS (сервера имен), и также отсутствует концепция делегирования поддоменов в домене многоадресной DNS. Просто потому, что конкретный хост в сети может отвечать на запросы для определенного типа записи с именем «example.local». ничего не говорит о том, будет ли этот хост отвечать за имя «child.example.local.» или за другие типы записей с именем «example.local.».

В доменах многоадресной DNS нет записей NS. Вместо этого домены многоадресной DNS зарезервированы IANA, и фактически существует неявное делегирование всех доменов многоадресной DNS 224.0.0.251:5353 и [FF02 :: FB]: 5353 групп многоадресной рассылки благодаря клиентскому программному обеспечению, реализующему протокол. правила, указанные в этом документе.

DNS-зоны многоадресной рассылки не имеют записи SOA (Start of Authority). Запись SOA обычной зоны DNS содержит такую информацию, как адрес электронной почты администратора зоны и монотонно увеличивающийся серийный номер последней модификации зоны. Для каждой заданной зоны многоадресной DNS не существует ни одного администратора, поэтому адрес электронной почты отсутствует. Поскольку узлы, управляющие любой заданной зоной многоадресной DNS, координируются слабо, нет доступного монотонно увеличивающегося серийного номера, чтобы определить, изменилось ли содержимое зоны. Хост, содержащий часть общей зоны, может в любой момент выйти из строя или отключиться от сети без уведомления других хостов. Не существует надежного способа предоставить серийный номер зоны, который бы при каждом сбое или отключении немедленно изменялся, указывая на то, что содержимое общей зоны изменилось.

Передача зон невозможна для любой многоадресной DNS-зоны.

13. Включение и отключение многоадресной DNS

Возможность переключения на многоадресный DNS для имен, не заканчивающихся на «.local». ДОЛЖЕН быть пользовательский параметр и ДОЛЖЕН быть отключен по умолчанию из-за возможных проблем безопасности, связанных с непреднамеренным локальным разрешением явно глобальных имен. Включение многоадресной DNS для имен, не заканчивающихся на «.local». может быть целесообразным в защищенной изолированной сети или в какой-либо будущей сети, где машины будут использовать DNSSEC исключительно для всех запросов DNS и могут иметь многоадресные DNS-ответчики, способные генерировать соответствующие криптографические подписи DNSSEC, тем самым обеспечивая защиту от подделки.

Возможность искать неквалифицированные (относительные) имена, добавляя «.local». (или нет) контролируется ли «.local.» появляется (или нет) в списке поиска DNS клиента.

Не требуется никакого специального элемента управления для включения и отключения многоадресной DNS для имен, явно заканчивающихся на «.local». как введено пользователем. Пользователю не нужен способ отключить Multicast DNS для имен, заканчивающихся на «.local.», Потому что, если пользователь не хочет использовать Multicast DNS, он может добиться этого, просто не используя эти имена. Если пользователь * вводит * имя, оканчивающееся на «.local.», То мы можем с уверенностью предположить, что пользователь, вероятно, хотел, чтобы оно работало. Наличие параметров конфигурации пользователя, которые можно (преднамеренно или непреднамеренно) устанавливать таким образом, чтобы локальные имена не работали, — это еще один способ расстроить способность пользователя выполнять нужные ему задачи, увековечив мнение, что «IP-сеть слишком сложна, чтобы настроить и слишком сложно использовать «.

14. Соображения для нескольких интерфейсов

Хост ДОЛЖЕН защищать свое локальное имя узла на всех активных интерфейсах, на которых он отвечает на многоадресные DNS-запросы.

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

Хост может использовать одно и то же имя (или набор имен) для всех своих адресных записей на всех интерфейсах или может управлять своими многоадресными DNS-интерфейсами независимо, потенциально отвечая на другое имя (или набор имен) в разные интерфейсы.

За исключением случаев прокси и других подобных специализированных применений, адреса в записях адресов IPv4 или IPv6 в многоадресных ответах DNS ДОЛЖНЫ быть действительными для использования на интерфейсе, на котором отправляется ответ.

Так же, как один и тот же локальный IP-адрес канала может действительно использоваться одновременно на разных каналах разными хостами, так и одно и то же имя локального хоста канала может действительно использоваться одновременно на разных каналах, и это не является ошибкой. Многосетевой узел с подключениями к двум разным каналам может иметь возможность обмениваться данными с двумя разными узлами, которые действительно используют одно и то же имя. Хотя такой тип дублирования имен должен быть редким, это означает, что хосту, который хочет полностью поддерживать этот случай, нужны API-интерфейсы сетевого программирования, которые позволяют приложениям указывать, на каком интерфейсе выполнять многоадресный DNS-запрос локальной ссылки, и определять, на каком интерфейсе получен многоадресный ответ DNS.

Существует еще одна особая мера предосторожности, которую должны принять многосетевые хосты. На современных портативных компьютерах обычно используется соединение Ethernet и беспроводное соединение 802.11 [IEEE.802.11] одновременно. То, что программное обеспечение на портативном компьютере не может легко сказать, является ли беспроводное соединение фактически подключено к тому же сегменту сети, что и его соединение Ethernet. Если две сети соединены вместе, то пакеты, которые хост отправляет на одном интерфейсе, поступят на другой интерфейс спустя несколько миллисекунд, и необходимо позаботиться о том, чтобы это соединение не вызывало проблем:

Когда хост объявляет имя своего хоста (то есть записи адресов) на своем беспроводном интерфейсе, эти записи анонсов отправляются с установленным битом очистки кэша, поэтому, когда они поступают в сегмент Ethernet, они вызывают все равноправные узлы в Ethernet. очистить записи адресов Ethernet хоста из их кешей. Протокол многоадресной DNS имеет защиту для защиты от этой ситуации: когда записи принимаются с установленным битом очистки кэша, другие записи не удаляются сразу из одноранговых кэшей, но помечаются для удаления в течение одной секунды. Когда хост видит, что его собственные записи беспроводного адреса поступают на его интерфейс Ethernet с установленным битом очистки кэша, этот односекундный льготный период дает хосту время для ответа и повторного объявления своих записей адреса Ethernet, чтобы восстановить эти записи в одноранговых кэшах до того, как они удалены.
Как описано, это решает одну проблему, но создает другую, потому что, когда эти записи объявлений Ethernet возвращаются на беспроводной интерфейс, хост снова будет защищаться, чтобы восстановить свои беспроводные записи, и этот процесс будет продолжаться вечно, непрерывно наводняя сеть трафиком. , Для решения этой проблемы в протоколе многоадресной DNS имеется вторая защита: бит очистки кэша не применяется к записям, полученным совсем недавно, в течение последней секунды. Это означает, что когда хост видит, что его собственные записи адресов Ethernet поступают на его беспроводной интерфейс с установленным битом очистки кэша, он знает, что нет необходимости повторно объявлять свои записи беспроводных адресов снова, поскольку он уже отправил их менее секунды назад, и это делает их невосприимчивыми к удалению из одноранговых кэшей. (См. Раздел 10.2.)

15. Замечания о множественных ответчиках на одной машине

Можно иметь более одного многоадресного DNS-ответчика и / или реализацию запроса на одной машине, но есть некоторые известные проблемы.

15.1. Получение одноадресных ответов

В большинстве операционных систем входящие * многоадресные * пакеты могут быть доставлены на * все * открытые сокеты, привязанные к нужному номеру порта, при условии, что клиенты предпримут соответствующие шаги, чтобы разрешить это. По этой причине все реализации многоадресной DNS ДОЛЖНЫ использовать параметры SO_REUSEPORT и / или SO_REUSEADDR (или эквивалентные в зависимости от конкретной операционной системы), поэтому все они смогут связываться с UDP-портом 5353 и получать входящие многоадресные пакеты, адресованные этому порту. , Однако, в отличие от многоадресных пакетов, входящие одноадресные UDP-пакеты обычно доставляются только в первый сокет для привязки к этому порту. Это означает, что ответы «QU» и другие пакеты, отправленные по одноадресной передаче, будут приниматься только первым многоадресным DNS-ответчиком и / или запросчиком в системе. Это ограничение может быть частично смягчено, если реализации многоадресной DNS обнаруживают, что они не первыми связываются с портом 5353, и в этом случае они не запрашивают ответы «QU». Один из способов определить, запущена ли уже другая реализация многоадресного DNS, — это попытка привязки к порту 5353 без использования SO_REUSEPORT и / или SO_REUSEADDR, и если это не удается, это указывает, что какой-то другой сокет уже связан с этим портом.

15.2. Многопакетные списки известных ответов

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

15.3. Эффективность

Если бы у каждого клиента на машине была своя независимая реализация многоадресной DNS, они потеряли бы определенные преимущества в эффективности. Помимо ненужного дублирования кода, использования памяти и загрузки ЦП, клиенты не получат преимущества общего кеша всей системы и не смогут объединять отдельные запросы в отдельные пакеты для уменьшения сетевого трафика.

15.4. Рекомендация

Из-за этих проблем этот документ рекомендует разработчикам разрабатывать системы с единой реализацией многоадресной DNS, которая предоставляет многоадресные DNS-сервисы, совместно используемые всеми клиентами на этом компьютере, так как большинство современных операционных систем имеют одну реализацию TCP, которая совместно используется всеми клиентами на эта машина. Из-за технических ограничений могут возникнуть ситуации, когда внедрение многоадресной DNS-реализации «пользовательского уровня» в клиентское прикладное программное обеспечение является наиболее целесообразным решением, и, хотя это обычно работает на практике, разработчики должны знать о проблемах, изложенных в этом разделе.

16. Многоадресный набор символов DNS

Исторически, Unicast DNS использовался с очень ограниченным набором символов. Действительно, обычный DNS обычно ограничен только двадцатью шестью буквами, десятью цифрами и дефисом, даже не допуская пробелов или других знаков препинания. Попытки исправить это для одноадресной DNS были сильно ограничены из-за предполагаемой необходимости приспособления старых ошибочных реализаций DNS. На самом деле, сама спецификация DNS не накладывает никаких ограничений на то, какие символы могут использоваться в именах, и хорошие реализации DNS обрабатывают любые произвольные восьмибитные данные без проблем. «Разъяснения к спецификации DNS» [RFC2181] непосредственно обсуждает тему допустимого набора символов в разделе 11 («Синтаксис имени») и прямо заявляет, что имена DNS могут содержать произвольные восьмибитные данные. Однако старые правила для имен хостов ARPANET еще в 1980-х годах требовали, чтобы имена хостов были просто буквами, цифрами и дефисами [RFC1034], и, поскольку преимущественное использование DNS заключается в хранении записей адресов хостов, многие предполагали, что протокол DNS сам страдает от того же ограничения. Можно было бы с уверенностью сказать, что могут быть гипотетические неверные реализации, которые неправильно обрабатывают восьмибитные данные, но было бы неверно утверждать, что протокол не допускает имен, содержащих восьмибитные данные.

Многоадресная DNS является новым протоколом и не имеет (пока) старых ошибочных устаревших реализаций, чтобы ограничить выбор дизайна. Соответственно, он принимает простое очевидное элегантное решение: все имена в многоадресной DNS ДОЛЖНЫ быть закодированы как предварительно составленный текст UTF-8 [RFC3629] «Net-Unicode» [RFC5198].

Некоторые пользователи 16-битного Unicode начали вставлять символ «неразрывный пробел нулевой ширины» (U + FEFF) в начале каждого файла UTF-16 в качестве подсказки, чтобы определить, являются ли данные старшим или младшим порядковым числом, и называя это «Меткой порядка байтов» (BOM). Поскольку существует только один возможный порядок байтов для данных UTF-8, спецификация не является ни необходимой, ни разрешенной. DNS-имена многоадресной рассылки НЕ ДОЛЖНЫ содержать «Порядок следования байтов». Любое вхождение символа Unicode U + FEFF в начале или в любом другом месте в имени DNS многоадресной рассылки ДОЛЖНО интерпретироваться как фактическая предполагаемая часть имени, представляющая (как и для любого другого допустимого значения Юникода) фактический буквальный экземпляр этого символ (в данном случае символ пробела нулевой ширины).

Для имен, которые ограничены буквами, цифрами и дефисами US-ASCII [RFC0020], кодировка UTF-8 идентична кодировке US-ASCII, поэтому она полностью совместима с существующими именами хостов. Для символов вне диапазона US-ASCII используется кодировка UTF-8.

Реализации многоадресной DNS НЕ ДОЛЖНЫ использовать любые другие кодировки, кроме предварительно составленного UTF-8 (US-ASCII считается совместимым подмножеством UTF-8). Причины выбора UTF-8 вместо Punycode [RFC3492] обсуждаются далее в Приложении F.

Простые правила нечувствительности к регистру в одноадресной DNS [RFC1034] [RFC1035] также применяются в многоадресной DNS; то есть при сравнении имен строчные буквы «a» — «z» (от 0x61 до 0x7A) соответствуют их прописным эквивалентам от «A» до «Z» (от 0x41 до 0x5A). Следовательно, если запросчик отправляет запрос на запись адреса с именем «myprinter.local.», То ответчик, имеющий запись адреса с именем «MyPrinter.local». должен выдать ответ. Других автоматических эквивалентностей не должно быть. В частности, все многобайтовые символы UTF-8 (коды 0x80 и выше) сравниваются путем простого двоичного сравнения необработанных значений байтов. Акцентированные символы * не * определены как автоматически эквивалентные их акцентированным аналогам. Если требуется автоматическая эквивалентность, это может быть достигнуто за счет использования программно сгенерированных записей CNAME. Например, если у респондента есть запись адреса для акцентированного имени Y, а запросчик выдает запрос для имени X, где X совпадает с Y со всеми удаленными акцентами, тогда респондент может выдать ответ, содержащий два ресурса записи: запись CNAME «X CNAME Y», утверждающая, что запрошенное имя X (без акцента) является псевдонимом для истинного (акцентированного) имени Y, за которым следует запись адреса для Y.

17. Размер многоадресного DNS-сообщения

Спецификация DNS 1987 года [RFC1035] ограничивает количество сообщений DNS, передаваемых по протоколу UDP, не более 512 байтов (не считая заголовков IP или UDP). Для пакетов UDP, передаваемых через глобальный Интернет в 1987 году, это было уместно. Для многоадресных локальных пакетов в современных сетях нет причин сохранять это ограничение. Учитывая, что пакеты по определению являются локальными, нет проблем с MTU пути, которые следует учитывать.

Многоадресные DNS-сообщения, передаваемые по UDP, могут достигать IP MTU физического интерфейса за вычетом места, необходимого для заголовка IP (20 байтов для IPv4; 40 байтов для IPv6) и заголовка UDP (8 байтов).

В случае одной записи ресурса многоадресной DNS, которая слишком велика для того, чтобы поместиться в один пакет многоадресного ответа размером с MTU, респондент многоадресной DNS ДОЛЖЕН отправить одну запись ресурса в одной дейтаграмме IP с использованием нескольких фрагментов IP. Ресурсные записи этого большого СЛЕДУЕТ избегать, за исключением очень редких случаев, когда они действительно являются подходящим решением для рассматриваемой проблемы. Разработчики должны знать, что многие простые устройства не собирают фрагментированные дейтаграммы IP, поэтому большие записи ресурсов НЕ ДОЛЖНЫ использоваться, за исключением случаев, когда разработчик знает, что все получатели осуществляют повторную сборку, или когда большая запись ресурса содержит дополнительные данные, которые не являются необходимыми. для правильной работы клиента.

Многоадресный DNS-пакет, больший, чем MTU интерфейса, который отправляется с использованием фрагментов, НЕ ДОЛЖЕН содержать более одной записи ресурса.

Даже при использовании фрагментации многоадресный DNS-пакет, включая заголовки IP и UDP, НЕ ДОЛЖЕН превышать 9000 байт.

Обратите внимание, что 9000 байт также является максимальным размером полезной нагрузки пакета Ethernet «Jumbo» [Jumbo]. Однако на практике пакеты Ethernet «Jumbo» не используются широко, поэтому желательно, чтобы пакеты всегда были размером менее 1500 байт. Даже на хостах, которые обычно обрабатывают пакеты «Jumbo» Ethernet и повторную сборку фрагментов IP, для этих хостов становится все более распространенным реализовывать режимы энергосбережения, когда основной ЦП переходит в спящий режим и передает задачи приема пакетов более ограниченному процессору в аппаратное обеспечение сетевого интерфейса, которое может не поддерживать пакеты Ethernet «Jumbo» или повторную сборку фрагмента IP.

18. Формат многоадресного сообщения DNS

В этом разделе описываются конкретные правила, относящиеся к допустимым значениям для полей заголовка многоадресного DNS-сообщения, и другие аспекты формата сообщения.

18.1. ID (идентификатор запроса)

Реализации многоадресной DNS ДОЛЖНЫ прослушивать незапрошенные ответы, выдаваемые хостами, загружающимися (или выходящими из спящего режима или иным образом присоединяющимися к сети). Поскольку эти незапрошенные ответы могут содержать полезный ответ на вопрос, на который в данный момент ожидает ответ, реализации DNS многоадресной рассылки СЛЕДУЕТ проверять все полученные сообщения ответа DNS многоадресной рассылки на наличие полезных ответов, независимо от содержимого поля ID или раздела вопросов. , В многоадресной DNS знание того, какое конкретное сообщение запроса (если оно есть) отвечает за получение конкретного ответного сообщения, менее интересно, чем знание, содержит ли ответное сообщение полезную информацию.

Реализации многоадресной DNS МОГУТ кэшировать данные из любого или всех ответных сообщений многоадресной DNS, которые они получают, для возможного будущего использования, при условии, конечно, что для этих кэшированных записей ресурсов выполняется нормальное устаревание TTL.

В сообщениях многоадресного запроса идентификатор запроса ДОЛЖЕН быть установлен равным нулю при передаче.

В многоадресных ответах, включая незапрошенные многоадресные ответы, идентификатор запроса ДОЛЖЕН быть установлен равным нулю при передаче и ДОЛЖЕН игнорироваться при приеме.

В устаревших одноадресных ответных сообщениях, генерируемых конкретно в ответ на конкретный (одноадресный или многоадресный) запрос, идентификатор запроса ДОЛЖЕН совпадать с идентификатором из сообщения запроса.

18.2. QR (запрос / ответ) бит

В сообщениях запроса бит QR ДОЛЖЕН быть нулевым.

В ответных сообщениях бит QR ДОЛЖЕН быть одним.

18.3. OPCODE

Как в запросах многоадресной рассылки, так и в ответах многоадресной рассылки OPCODE ДОЛЖЕН быть нулевым при передаче (в настоящее время для многоадресной передачи поддерживаются только стандартные запросы). Многоадресные DNS-сообщения, полученные с OPCODE, отличным от нуля, ДОЛЖНЫ игнорироваться.

18.4. AA (Авторитетный ответ) бит

В сообщениях запроса бит достоверного ответа ДОЛЖЕН быть нулевым при передаче и ДОЛЖЕН игнорироваться при приеме.

В ответных сообщениях для многоадресных доменов бит достоверного ответа ДОЛЖЕН быть установлен на единицу (если этот бит не установлен, это будет означать, что есть какое-то другое место, где может быть найдена «лучшая» информация), и ДОЛЖЕН игнорироваться при приеме.

18.5. TC (усеченный) бит

В сообщениях запроса, если бит TC установлен, это означает, что вскоре могут появиться дополнительные записи об известных ответах. Ответчик ДОЛЖЕН записать этот факт и дождаться этих дополнительных записей известного ответа, прежде чем решать, отвечать ли. Если бит TC сброшен, это означает, что у запрашивающего хоста нет дополнительных известных ответов.

В многоадресных ответных сообщениях бит TC ДОЛЖЕН быть нулевым при передаче и ДОЛЖЕН игнорироваться при приеме.

В устаревших одноадресных ответных сообщениях бит TC имеет то же значение, что и в обычном одноадресном DNS: это означает, что ответ слишком велик для размещения в одном пакете, поэтому запрашивающему СЛЕДУЕТ повторить свой запрос с использованием TCP, чтобы получить больший ответ.

18.6. RD (требуемая рекурсия) бит

Как в многоадресном запросе, так и в многоадресном ответном сообщении бит «Рекурсия» ДОЛЖЕН быть нулевым при передаче и ДОЛЖЕН игнорироваться при приеме.

18.7. RA (Доступна рекурсия) бит

Как в запросах многоадресной рассылки, так и в ответах многоадресной рассылки бит «Рекурсия» ДОЛЖЕН быть нулевым при передаче и ДОЛЖЕН игнорироваться при приеме.

18.8. Z (ноль) бит

Как в запросе, так и в ответном сообщении нулевой бит ДОЛЖЕН быть нулевым при передаче и ДОЛЖЕН игнорироваться при приеме.

18.9. AD (бит аутентичных данных)

Как в запросах на многоадресную рассылку, так и в ответах на многоадресную рассылку бит аутентичных данных [RFC2535] ДОЛЖЕН быть нулевым при передаче и ДОЛЖЕН игнорироваться при приеме.

18.10. CD (проверка отключена) бит

Как в многоадресном запросе, так и в ответном сообщении многоадресной рассылки бит проверки отключения [RFC2535] ДОЛЖЕН быть нулевым при передаче и ДОЛЖЕН игнорироваться при приеме.

18.11. RCODE (код ответа)

Как в запросах многоадресной рассылки, так и в ответных сообщениях многоадресной рассылки код ответа ДОЛЖЕН быть нулевым при передаче. Многоадресные DNS-сообщения, полученные с ненулевыми кодами ответа, ДОЛЖНЫ игнорироваться.

18.12. Переназначение старшего бита класса q в разделе вопросов

В разделе вопросов многоадресного DNS-запроса верхний бит поля qclass используется для указания того, что одноадресные ответы предпочтительнее для этого конкретного вопроса. (См. Раздел 5.4.)

18.13. Повторное использование верхнего бита rrclass в разделах записи ресурса

В разделах записи ресурса DNS-ответа многоадресной рассылки верхний бит поля rrclass используется для указания того, что запись является членом уникального RRSet, и весь RRSet был отправлен вместе (в одном пакете или последовательно пакеты, если слишком много записей, чтобы поместиться в один пакет). (См. Раздел 10.2.)

18.14. Сжатие имени

При создании многоадресных DNS-сообщений реализациям СЛЕДУЕТ использовать сжатие имен везде, где это возможно, чтобы сжимать имена записей ресурсов, заменяя некоторые или все имена записей ресурсов компактной двухбайтовой ссылкой на появление этих данных где-то ранее в сообщении [ RFC1035].

Это относится не только к многоадресным DNS-ответам, но и к запросам. Когда запрос содержит более одного вопроса, последовательные вопросы в одном и том же сообщении часто содержат сходные имена, и, следовательно, для сохранения байтов СЛЕДУЕТ использовать сжатие имен. Кроме того, запросы могут также содержать «Известные ответы» в разделе «Ответы» или проверять разрыв данных в разделе «Полномочия», и эти имена ДОЛЖНЫ быть аналогичным образом сжаты для обеспечения эффективности сети.

Помимо сжатия * имен * записей ресурсов, имена, которые отображаются в * rdata * следующих rrtypes, ДОЛЖНЫ также быть сжаты во всех многоадресных DNS-сообщениях:

NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC

До будущего действия Стандартов IETF [RFC5226], определяющего, что имена в rdata других типов должны быть сжаты, имена, которые появляются в rdata любого типа, не перечисленного выше, НЕ ДОЛЖНЫ быть сжаты.

Реализации, принимающие многоадресные DNS-сообщения, ДОЛЖНЫ правильно декодировать сжатые имена, появляющиеся в разделе вопросов, и сжатые имена записей ресурсов, появляющиеся в других разделах.

Кроме того, реализации ДОЛЖНЫ правильно декодировать сжатые имена, появляющиеся в * rdata * перечисленных выше rrtypes. Там, где это возможно, реализации СЛЕДУЕТ также правильно декодировать сжатые имена, появляющиеся в * rdata * других rrtypes, известных разработчикам во время реализации, потому что такое заблаговременное планирование помогает облегчить развертывание будущих реализаций, у которых может быть причина для сжатия этих rrtypes. Возможно, что в будущем не будет создано Действие по стандартам IETF [RFC5226], которое предписывает или разрешает сжатие rdata в новых типах, но реализация, разработанная таким образом, что они способны распаковывать все известные типы, помогает держать будущие опции открытыми.

Одно конкретное различие между одноадресной DNS и многоадресной DNS заключается в том, что одноадресная DNS не разрешает сжатие имен для целевого хоста в записи SRV, поскольку реализации одноадресной DNS до появления первой спецификации SRV в 1996 году [RFC2052] могут неправильно декодировать эти сжатые записи. Поскольку все реализации многоадресного DNS были созданы после 1996 года, все реализации многоадресного DNS ТРЕБУЮТСЯ для правильного декодирования сжатых записей SRV.

В устаревших одноадресных ответах, генерируемых для ответа на устаревшие запросы, сжатие имен НЕ ДОЛЖНО выполняться для записей SRV.

19. Краткое изложение различий между многоадресным DNS и одноадресным DNS

DNS многоадресной рассылки в максимально возможной степени разделяет знакомые API, синтаксис именования, типы записей ресурсов и т. Д. Одноадресной DNS. Конечно, существуют необходимые различия в силу того, что он использует многоадресную передачу и действует в сообществе взаимодействующих партнеров, а не в четко определенной иерархии, контролируемой строгой цепочкой официальных делегаций от корня. Эти различия приведены ниже:

Многоадресный DNS …
* использует многоадресную рассылку
* использует порт UDP 5353 вместо порта 53
* работает в четко определенных частях пространства имен DNS
* не имеет записей SOA (начало работы)
* использует UTF-8 и только UTF-8 для кодирования имен записей ресурсов
* допускает имена до 255 байтов плюс завершающий нулевой байт
* позволяет сжатие имен в rdata для SRV и других типов записей
* позволяет большие пакеты UDP
* позволяет более одного вопроса в сообщении запроса
* определяет согласованные результаты для запросов qtype «ANY» и qclass «ANY»
* использует раздел ответа на запрос для перечисления известных ответов
* использует бит TC в запросе для указания дополнительных известных ответов
* использует раздел авторизации запроса для пробного разрешения конфликтов
* игнорирует поле Query ID (кроме генерации устаревших ответов)
* не требует повторения вопроса в ответном сообщении
* использует незапрошенные ответы для объявления новых записей
* использует записи NSEC, чтобы сигнализировать об отсутствии записей
* определяет бит одноадресного ответа в rrclass вопросов запроса
* определяет бит очистки кэша в rrclass записей ответов
* использует DNS RR TTL 0, чтобы указать, что запись была удалена
* рекомендует AAAA записи в дополнительном разделе при ответе
для выполнения запросов типа «А» и наоборот
* отслеживает запросы для выполнения дублирования вопросов
* отслеживает ответы для выполнения дублирования подавления ответов …
* … и постоянное обнаружение конфликтов
* … и оппортунистическое кеширование

20. Соображения IPv6

Хост только для IPv4 и хост только для IPv6 ведут себя как «корабли, которые проходят ночью». Даже если они находятся в одном и том же Ethernet, ни один из них не знает о трафике другого. По этой причине каждая физическая ссылка может иметь * два * не связанных «.local». зоны, одна для IPv4 и одна для IPv6. Поскольку для практических целей группа хостов только для IPv4 и группа хостов только для IPv6 в одном и том же Ethernet действуют так, как если бы они находились в двух совершенно отдельных сегментах Ethernet, неудивительно, что они используют «.local». зона должна появляться точно так же, как если бы они действительно находились в двух совершенно отдельных сегментах Ethernet.

Хост с двумя стеками (v4 / v6) может участвовать как в «.local». зоны, и должны зарегистрировать свое имя (имена) и выполнить поиск как с использованием IPv4, так и IPv6. Это позволяет ему достигать и получать доступ как к хостам, использующим только IPv4, так и только к IPv6. По сути, это действует как многосетевой хост с одним подключением к логическому «сегменту Ethernet IPv4» и подключением к логическому «сегменту Ethernet IPv6». Когда такой хост генерирует записи NSEC, если он использует одно и то же имя хоста для своих адресов IPv4 и своих адресов IPv6 на этом сетевом интерфейсе, его записи NSEC должны указывать, что имя хоста имеет записи A и AAAA.

21. Вопросы безопасности

Алгоритм обнаружения и разрешения конфликтов имен по своей природе является алгоритмом, предполагающим взаимодействие участников. Его цель состоит в том, чтобы позволить группе хостов прийти к взаимно непересекающемуся набору имен хостов и других имен записей ресурсов DNS, в отсутствие какого-либо центрального органа для координации этого или посредника в спорах. В отсутствие каких-либо более высоких полномочий для разрешения споров единственная альтернатива заключается в том, что участники должны работать вместе, чтобы прийти к решению.

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

В среде, где есть группа взаимодействующих участников, но клиенты не могут быть уверены, что на том же физическом канале нет антагонистических хостов, взаимодействующие участники должны использовать сигнатуры IPsec и / или DNSSEC [RFC4033], чтобы они могли различать Многоадресные DNS-сообщения от доверенных участников (которые они обрабатывают как обычно) от многоадресных DNS-сообщений от ненадежных участников (которые они молча отбрасывают).

Если DNS-запросы для * глобальных * DNS-имен отправляются на многоадресный адрес mDNS (во время перебоев в сети, которые нарушают связь с большим Интернетом), * особенно * важно использовать DNSSEC, потому что у пользователя может сложиться впечатление, что он или она общение с каким-то подлинным хостом, когда на самом деле он или она действительно общается с каким-то локальным хостом, который просто маскируется под это имя. Это менее критично для имен, заканчивающихся на «.local.», Потому что пользователь должен знать, что эти имена имеют только локальное значение и никаких глобальных полномочий не подразумевается.

Большинство пользователей компьютеров пренебрегают вводить конечную точку в конце полного доменного имени, что делает его относительным доменным именем (например, «www.example.com»). В случае сбоя в сети попытки положительно разрешить введенное имя не удастся, что приведет к применению списка поиска, включая «.local.», Если он присутствует. Вредоносный хост может маскироваться под «www.example.com». ответив на полученный многоадресный DNS-запрос на «www.example.com.local.». Чтобы избежать этого, хост НЕ ДОЛЖЕН добавлять суффикс поиска «.local.», Если он присутствует, к любому относительному (частично квалифицированному) имени хоста, содержащему две или более меток. Добавление «.local.» к относительным именам хостов с одной меткой допустимо, так как пользователь не должен ожидать, что имя хоста с одной меткой будет разрешено как есть. Однако пользователи, у которых есть и «example.com», и «local» в своих списках поиска, должны знать, что, если они введут «www» в свой веб-браузер, им может быть не сразу понятно, является ли отображаемая страница «www». .example.com «или» www.local «.

Многоадресная DNS использует порт UDP 5353. В операционных системах, где только привилегированным процессам разрешено использовать порты ниже 1024, такая привилегия не требуется для использования порта 5353.

22. Соображения IANA

IANA выделил порт UDP 5353 для протокола многоадресной DNS, описанного в этом документе [SN].

IANA выделил локальный многоадресный адрес IPv4 224.0.0.251 для использования, описанного в этом документе [MC4].

IANA выделил набор многоадресных адресов IPv6 FF0X :: FB (где «X» обозначает любую шестнадцатеричную цифру от «1» до «F») для использования, описанного в этом документе [MC6]. Только адрес FF02 :: FB (локальная область ссылки) в настоящее время используется развернутым программным обеспечением, но возможно, что в будущем разработчики могут поэкспериментировать с многоадресной DNS, используя адреса более широкой области, например FF05 :: FB (site-local объем) [RFC4291].

IANA внедрила следующие записи DNS:

MDNS.MCAST.NET. IN A 224.0.0.251
251.0.0.224.IN-ADDR.ARPA. IN PTR MDNS.MCAST.NET.

Записи для AAAA и соответствующих записей PTR не были сделаны, поскольку еще нет RFC, обеспечивающего руководство для управления доменом IP6.ARPA, относящимся к адресному пространству многоадресной рассылки IPv6.

Повторное использование верхнего бита поля rrclass в разделах записей вопросов и ресурсов означает, что многоадресная DNS может переносить записи DNS только с классами в диапазоне 0-32767. Классы в диапазоне от 32768 до 65535 несовместимы с многоадресной DNS. IANA отметила этот факт, и, если IANA получит запрос на выделение значения класса DNS выше 32767, IANA перед выполнением запроса удостоверится, что запрашивающая сторона знает об этом значении. Это не означает, что в распределении значений класса DNS выше 32767 должно быть отказано, только то, что они не должны быть разрешены, пока запрашивающая сторона не указала, что они знают о том, как это распределение будет взаимодействовать с многоадресной DNS. Однако на сегодняшний день IANA назначило только три класса DNS (1, 3 и 4), и только один (1, «Интернет») фактически широко используется, поэтому этот вопрос, вероятно, останется чисто теоретическим.

IANA записала список доменов ниже как доменные имена специального назначения [RFC6761]:

.local.
.254.169.in-addr.arpa.
.8.e.f.ip6.arpa.
.9.e.f.ip6.arpa.
.a.e.f.ip6.arpa.
.b.e.f.ip6.arpa.

22.1. Вопросы резервирования доменных имен

Шесть доменов, перечисленных выше, и любые имена, попадающие в эти домены (например, «MyPrinter.local.», «34.12.254.169.in-addr.arpa.», «Ink-Jet._pdl-datastream._tcp.local.» ) являются специальными [RFC6761] следующими способами:

1. Пользователи могут использовать эти имена так же, как и другие DNS-имена, вводя их везде, где они могли бы ввести обычное DNS-имя или десятичный IPv4-адрес с точками или буквальный IPv6-адрес.

Поскольку нет централизованного органа, ответственного за назначение локальных точечных имен, и все устройства в локальной сети имеют равные права требовать любое локальное точечное имя, пользователи ДОЛЖНЫ знать об этом и ДОЛЖНЫ проявлять соответствующую осторожность. В ненадежной или незнакомой сетевой среде пользователям СЛЕДУЕТ осознавать, что использование имени, такого как «www.local», может на самом деле не соединять их с ожидаемым веб-сайтом, и они могут легко подключить их к другой веб-странице или даже к фальшивому или пародия их предполагаемого веб-сайта, предназначенного для обмана их в раскрытии конфиденциальной информации. Как и в случае с сетью, сквозная криптографическая безопасность может быть полезным инструментом. Например, при соединении с ssh процесс проверки ключа хоста ssh проинформирует пользователя, если он обнаружит, что идентичность объекта, с которым он связывается, изменилась с момента последнего подключения к этому имени.

2. Прикладное программное обеспечение может использовать эти имена так же, как и другие аналогичные имена DNS, и не требуется распознавать имена и обращаться с ними особым образом. Из-за относительной легкости подмены точечных локальных имен сквозная криптографическая безопасность остается важной при общении через локальную сеть, так же, как и при общении через глобальный Интернет.

3. API и библиотеки разрешения имен ДОЛЖНЫ распознавать эти имена как специальные и НЕ ДОЛЖНЫ отправлять запросы на эти имена на их настроенные (одноадресные) кэширующие DNS-серверы. Это делается для того, чтобы избежать ненужной нагрузки на корневые серверы имен и другие серверы имен, вызванной запросами, для которых эти серверы имен не могут дать полезные неотрицательные ответы и никогда не получат полезных неотрицательных ответов.

4. Кеширующие DNS-серверы ДОЛЖНЫ распознавать эти имена как особые и НЕ ДОЛЖНЫ пытаться найти для них записи NS или иным образом запрашивать у доверенных DNS-серверов попытку их разрешения. Вместо этого, кэширующие DNS-серверы ДОЛЖНЫ генерировать немедленные ответы NXDOMAIN на все такие запросы, которые они могут получать (из неправильно работающих библиотек распознавателя имен). Это сделано для того, чтобы избежать ненужной нагрузки на корневые серверы имен и другие серверы имен.

5. Официальные DNS-серверы НЕ ДОЛЖНЫ по умолчанию настраиваться для ответа на запросы для этих имен, и, подобно кеширующим DNS-серверам, СЛЕДУЕТ генерировать немедленные ответы NXDOMAIN для всех таких запросов, которые они могут получить. Программное обеспечение DNS-сервера МОЖЕТ предоставлять возможность конфигурации для переопределения этого значения по умолчанию, для целей тестирования или других специализированных целей.

6. Операторам DNS-серверов НЕ СЛЕДУЕТ пытаться настроить доверенные DNS-серверы, чтобы они действовали как доверенные для любого из этих имен. Настройка уполномоченного DNS-сервера для использования в качестве доверенного для любого из этих имен во многих случаях может не дать ожидаемого результата. Поскольку библиотеки распознавателя имен и кэширующие DNS-серверы НЕ ДОЛЖНЫ отправлять запросы на эти имена (см. 3 и 4 выше), такие запросы СЛЕДУЕТ подавлять до того, как они даже достигнут рассматриваемого авторитетного DNS-сервера, и, следовательно, он даже не получит возможность ответить их.

7. Регистраторы DNS НЕ ДОЛЖНЫ позволять каким-либо физическим или юридическим лицам регистрировать какие-либо из этих имен обычным способом. Эти имена являются зарезервированными идентификаторами протоколов со специальным значением и выходят за пределы набора имен, доступных для распределения регистраторами. Попытка выделить одно из этих имен, как если бы оно было обычным доменным именем, вероятно, не будет работать должным образом по причинам 3, 4 и 6 выше.

23. Благодарности

Концепции, описанные в этом документе, были изучены, разработаны и реализованы с помощью Рана Аткинсона, Ричарда Брауна, Фрика Дейкстры, Эрика Гутмана, Кайла Маккея, Паси Саролахти, Пекки Саволы, Робби Симпсона, Марка Таунсли, Пола Викси, Билла Вудкока, и другие. Особая благодарность выражается Бобу Брэдли, Джошу Грессли, Скотту Гершеру, Рори МакГуайру, Роджеру Пантосу и Кирену Секару за их значительный вклад. Выражаем особую благодарность также Керри Линн за преобразование документа в форму xml2rfc в мае 2010 года и региональному директору Ральфу Дромсу за то, что он обработал документ на последних этапах.

24. Ссылки

24.1. Нормативные ссылки

[MC4] IANA, «IPv4 Multicast Address Space Registry», <http://www.iana.org/assignments/multicast-addresses/>.

[MC6] IANA, «IPv6 Multicast Address Space Registry», <http://www.iana.org/assignments/ipv6-multicast-addresses/>.

[RFC0020] Cerf, V., «ASCII format for network interchange», RFC 20, October 1969.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, November 2003.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for the DNS Security Extensions», RFC 4034, March 2005.

[RFC5198] Klensin, J. and M. Padlipsky, «Unicode Format for Network Interchange», RFC 5198, March 2008.

[RFC6195] Eastlake 3rd, D., «Domain Name System (DNS) IANA Considerations», BCP 42, RFC 6195, March 2011.

[RFC6761] Cheshire, S. and M. Krochmal, «Special-Use Domain Names», RFC 6761, February 2013.

[SN] IANA, «Service Name and Transport Protocol Port Number Registry», <http://www.iana.org/assignments/service-names-port-numbers/>.

24.2. Информационные ссылки

[B4W] «Bonjour for Windows»,
<http://en.wikipedia.org/wiki/Bonjour_(software)>.

[BJ] Apple Bonjour Open Source Software,
<http://developer.apple.com/bonjour/>.

[IEEE.802.3]
«Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier Sense Multiple Access with Collision Detection (CMSA/CD) Access Method and Physical Layer Specifications», IEEE Std 802.3-2008, December 2008,
<http://standards.ieee.org/getieee802/802.3.html>.

[IEEE.802.11]
«Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications», IEEE Std 802.11-2007, June
2007, <http://standards.ieee.org/getieee802/802.11.html>.

[Jumbo] «Ethernet Jumbo Frames», November 2009,
<http://www.ethernetalliance.org/library/whitepaper/ethernet-jumbo-frames/>.

[NIAS] Cheshire, S. «Discovering Named Instances of Abstract Services using DNS», Work in Progress, July 2001.

[NSD] «NsdManager | Android Developer», June 2012, <http://developer.android.com/reference/android/net/nsd/NsdManager.html>.

[RFC2052] Gulbrandsen, A. and P. Vixie, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2052, October 1996.

[RFC2132] Alexander, S. and R. Droms, «DHCP Options and BOOTP Vendor Extensions», RFC 2132, March 1997.

[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, «Dynamic Updates in the Domain Name System (DNS UPDATE)», RFC 2136, April 1997.

[RFC2181] Elz, R. and R. Bush, «Clarifications to the DNS Specification», RFC 2181, July 1997.

[RFC2535] Eastlake 3rd, D., «Domain Name System Security Extensions», RFC 2535, March 1999.

[RFC2671] Vixie, P., «Extension Mechanisms for DNS (EDNS0)», RFC 2671, August 1999.

[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, «Secret Key Transaction Authentication for DNS (TSIG)», RFC 2845, May 2000.

[RFC2930] Eastlake 3rd, D., «Secret Key Establishment for DNS (TKEY RR)», RFC 2930, September 2000.

[RFC2931] Eastlake 3rd, D., «DNS Request and Transaction Signatures ( SIG(0)s )», RFC 2931, September 2000.

[RFC3007] Wellington, B., «Secure Domain Name System (DNS) Dynamic Update», RFC 3007, November 2000.

[RFC3492] Costello, A., «Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)», RFC 3492, March 2003.

[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, «Dynamic Configuration of IPv4 Link-Local Addresses», RFC 3927, May 2005.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, March 2005.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

[RFC4795] Aboba, B., Thaler, D., and L. Esibov, «Link-local Multicast Name Resolution (LLMNR)», RFC 4795, January 2007.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, «Neighbor Discovery for IP version 6 (IPv6)», RFC 4861, September 2007.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, «IPv6 Stateless Address Autoconfiguration», RFC 4862, September 2007.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5890] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework», RFC 5890, August 2010.

[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, «Understanding Apple’s Back to My Mac (BTMM) Service», RFC 6281, June 2011.

[RFC6760] Cheshire, S. and M. Krochmal, «Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)», RFC 6760, February 2013.

[RFC6763] Cheshire, S. and M. Krochmal, «DNS-Based Service Discovery», RFC 6763, February 2013.

[Zeroconf] Cheshire, S. and D. Steinberg, «Zero Configuration Networking: The Definitive Guide», O’Reilly Media, Inc., ISBN 0-596-10100-7, December 2005.

Приложение А. Обоснование конструкции для выбора номера порта UDP

Аргументы были сделаны за и против использования UDP-порта 53, стандартного Unicast DNS-порта. Некоторые из аргументов приведены ниже. Аргументы для использования другого порта были более многочисленными и более убедительными, поэтому этот вариант был в конечном итоге выбран. Порт UDP «5353» был выбран из-за мнемонического сходства с «53».

Аргументы для использования UDP-порта 53:

Это «просто DNS», поэтому это должен быть тот же порт.
Требуется меньше усилий для обновления старых библиотек распознавателя для выполнения простых многоадресных DNS-запросов. Нужно изменить только адрес получателя. В некоторых случаях это может быть достигнуто без каких-либо изменений кода, просто добавив адрес 224.0.0.251 в файл конфигурации.

Аргументы для использования другого порта (UDP-порт 5353):

Это не просто DNS. Это DNS-подобный протокол, но другой.
Изменение кода библиотеки распознавателя для использования другого номера порта не сложно. В некоторых случаях этого можно достичь без каких-либо изменений кода, просто добавив адрес 224.0.0.251:5353 в файл конфигурации.
Использование одного и того же номера порта затрудняет запуск многоадресного DNS-ответчика и обычного одноадресного DNS-сервера на одном компьютере. Если обычный DNS-сервер Unicast также желает реализовать многоадресную DNS, он может сделать это, открыв два сокета. Наличие двух разных номеров портов обеспечивает такую гибкость.
Некоторые программы VPN перенаправляют весь исходящий трафик на порт 53 и перенаправляют его на специальный DNS-сервер, настроенный для обслуживания этих клиентов VPN, когда они подключены к корпоративной сети. Сомнительно, что это правильно, но это распространено, и перенаправление локальных многоадресных DNS-пакетов на удаленный сервер редко приводит к каким-либо полезным результатам. Это означает, например, что пользователь такого программного обеспечения VPN становится неспособным получить доступ к своему локальному сетевому принтеру, сидящему на их столе прямо рядом с его компьютером. Использование другого порта UDP помогает избежать этой конкретной проблемы.
Во многих операционных системах непривилегированное программное обеспечение не может отправлять или получать пакеты через порты с низким номером. Это означает, что любое программное обеспечение, отправляющее или получающее многоадресные DNS-пакеты через порт 53, должно работать как «root», что является нежелательным риском для безопасности. Использование UDP-порта с большим номером позволяет обойти это ограничение.

Приложение B. Обоснование дизайна для отказа от использования хэшированных многоадресных адресов

Некоторые протоколы обнаружения используют диапазон адресов многоадресной рассылки и определяют адрес, который будет использоваться хеш-функцией искомого имени. Запросы отправляются через многоадресную рассылку на адрес, указанный в хэш-функции, а ответы возвращаются запрашивающему через одноадресную рассылку. В частности, в IPv6, где многоадресные адреса чрезвычайно распространены, этот подход часто отстаивается. Например, обнаружение соседей IPv6 [RFC4861] отправляет сообщения запроса соседей на «адрес многоадресной рассылки запрашиваемого узла», который вычисляется как функция запрашиваемого адреса IPv6.

У использования хешированных многоадресных адресов, подобных этому, в протоколе обнаружения служб есть некоторые недостатки:

Когда у хоста есть большое количество записей с разными именами, хосту, возможно, придется присоединиться к большому количеству групп многоадресной рассылки. Каждый раз, когда узел присоединяется к группе многоадресной рассылки или покидает ее, это приводит к трафику протокола управления группами Интернета (IGMP) или многоадресному прослушивателю (MLD) в сети, объявляющему этот факт. Присоединение к большому количеству групп многоадресной рассылки может создать чрезмерную нагрузку на оборудование Ethernet, которое обычно эффективно поддерживает ограниченное количество адресов многоадресной рассылки. Когда это число превышено, аппаратному обеспечению Ethernet, возможно, придется прибегнуть к получению всех многоадресных рассылок и передаче их к сетевому коду хоста для фильтрации в программном обеспечении, что, в первую очередь, лишает смысла использование диапазона адресов многоадресной рассылки. Наконец, многие стеки IPv6 имеют фиксированный предел IPV6_MAX_MEMBERSHIPS, и код просто завершается с ошибкой, если клиент пытается превысить этот предел. Общие значения для IPV6_MAX_MEMBERSHIPS — 20 или 31.
Несколько вопросов не могут быть помещены в один пакет, если они не все хешируют на один и тот же адрес многоадресной рассылки.
Подавление дубликатов вопросов не работает, если запросчики не видят запросы друг друга.
Подавление дубликатов ответов не работает, если респонденты не видят ответы друг друга.
Оппортунистическое кэширование не работает.
Непрерывное обнаружение конфликтов не работает.

Приложение C. Обоснование дизайна для максимальной длины DNS-имени многоадресной рассылки

DNS-имена многоадресной рассылки могут иметь длину до 255 байтов (в формате сообщения на проводе), не считая завершающий нулевой байт в конце.

«Доменные имена — реализация и спецификация» [RFC1035] гласит:

Различные объекты и параметры в DNS имеют ограничения по размеру. Они перечислены ниже. Некоторые могут быть легко изменены, другие являются более фундаментальными.
метки 63 октета или меньше
имена 255 октетов или меньше
…
общая длина доменного имени (то есть октетов меток и октетов длины меток) ограничена 255 октетами или менее.

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

Несколько факторов заставляют нас заключить, что ограничение в 255 байт * не * включает в себя завершающий ноль:

При разработке программного обеспечения для ограничения эффективности характерно ограничение по размеру, равное степени двух или кратному степени двух. Например, целое число в современном процессоре обычно составляет 2, 4 или 8 байтов, а не 3 или 5 байтов. Число 255 не является степенью двойки и не является для большинства людей особенно примечательным числом. Он заслуживает внимания ученых-компьютерщиков только по одной причине — потому что он ровно на один * меньше *, чем степень двух. Когда ограничение размера ровно на единицу меньше степени двойки, это убедительно свидетельствует о том, что один дополнительный байт зарезервирован по какой-то конкретной причине — в этом случае, возможно, зарезервировано, чтобы оставить место для конечного нуля в конце.
В случае длин меток DNS указанный предел составляет 63 байта. Как и в случае общей длины имени, этот предел ровно на единицу меньше, чем степень двух. Этот предел длины метки также исключает байт длины метки в начале каждой метки. Включая этот дополнительный байт, 63-байтовая метка занимает 64 байта пространства в памяти или в сообщении DNS.
В программной инженерии обычно семантическая «длина» объекта на единицу меньше количества байтов, которое требуется для хранения этого объекта. Например, в C strlen («foo») равен 3, а sizeof («foo») (который включает в себя завершающий нулевой байт в конце) равен 4.
В тексте, описывающем общую длину доменного имени, явно упоминается, что длина метки и октеты данных включены, но не упоминается конечный ноль в конце. Нулевой байт в конце доменного имени не является длиной метки. Действительно, нулевое значение выбрано в качестве завершающего маркера именно потому, что оно не является допустимым байтовым значением длины — DNS запрещает пустые метки. Например, имя типа «плохое имя». не является допустимым доменным именем, поскольку оно содержит метку нулевой длины в середине, которая не может быть выражена в сообщении DNS, поскольку программное обеспечение, выполняющее синтаксический анализ сообщения, неверно интерпретирует байт нулевой длины метки как нулевой маркер «конца имени» вместо.

Наконец, «Разъяснения к спецификации DNS» [RFC2181] предлагают дополнительное подтверждение того, что в контексте спецификаций DNS указанная «длина» имени домена не включает в себя завершающий нулевой байт в конце. Этот документ ссылается на корневое имя, которое обычно пишется как «.» и представлен в сообщении DNS одним одиночным нулевым байтом (то есть нулевыми байтами данных плюс завершающий ноль) как «полное имя нулевой длины»:

Полное имя нулевой длины определяется как представляющий корень дерева DNS, и обычно записывается и отображается как «.».

Эта формулировка поддерживает интерпретацию того, что в контексте DNS, когда речь идет о длинах имен, завершающий нулевой байт в конце не учитывается. Если корневое имя («.») Считается нулевой длиной, то для согласованности длина (например) «org» должна быть 4, а длина «ietf.org» должна быть 9, так как показано ниже:

Завершающий нулевой байт в конце не учитывается

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

Однако многие разработчики Unicast DNS по-разному читают эти RFC и утверждают, что ограничение в 255 байт включает в себя конечный ноль и что в «Разъяснениях к спецификации DNS» [RFC2181] указано, что «.» это «полное имя нулевой длины» было просто ошибкой.

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

Совместимые реализации многоадресной DNS ДОЛЖНЫ поддерживать имена длиной до 255 байтов плюс конечный ноль, то есть всего 256 байтов.

Приложение D. Преимущества многоадресных ответов

Некоторые люди утверждают, что отправка ответов через многоадресную рассылку неэффективна в сети. Фактически, использование многоадресных ответов может привести к общему снижению общего многоадресного трафика по ряду причин, а также предоставляет и другие преимущества:

Оппортунистическое кеширование. Один многоадресный ответ может обновить кэши на всех машинах в сети. Если другая машина позже захочет выполнить тот же запрос, и у нее уже есть ответ в кеше, ей может даже не понадобиться передавать этот многоадресный запрос по сети.
Подавление дубликатов запросов. Когда более чем один компьютер выполняет один и тот же текущий долгоживущий запрос, каждый компьютер не должен передавать свой собственный независимый запрос. Когда одна машина передает запрос, все другие узлы видят ответы, поэтому они могут подавлять свои собственные запросы.
Пассивное наблюдение за неудачами (POOF). Когда хост видит многоадресный запрос, но не видит соответствующий многоадресный ответ, он может использовать эту информацию для быстрого удаления устаревших данных из своего кэша. Для достижения того же уровня качества пользовательского интерфейса и скорости отклика без многоадресных ответов потребуется меньшее время жизни кэша и более частый опрос сети, что приводит к более высокой скорости передачи пакетов.
Пассивное обнаружение конфликтов. Тот факт, что имя было ранее подтверждено как уникальное, не гарантирует, что оно останется таким до бесконечности. Позволяя всем многоадресным DNS-респондентам постоянно отслеживать ответы своих коллег, конфликты, возникающие из-за изменений топологии сети, могут быть быстро обнаружены и разрешены. Если ответы не отправлялись через многоадресную рассылку, потребовался бы какой-то другой механизм обнаружения конфликтов, который налагал бы на себя дополнительную нагрузку на сеть.
Использование на устройствах с ограниченными ресурсами памяти: при использовании отложенных ответов для уменьшения сетевых коллизий респондентам необходимо вести запись списка, на которую следует отправлять каждый ответ. Опция многоадресных ответов позволяет респондентам с ограниченным хранилищем, которые не могут хранить произвольно длинный список адресов ответов, выбирать, при необходимости, переключаться на один многоадресный ответ вместо нескольких одноадресных ответов.
Наложение подсетей. В случае наложенных подсетей многоадресные ответы позволяют получателю с уверенностью знать, что ответ возник по локальной ссылке, даже если его исходный адрес может явно указывать на иное.
Надежность перед лицом неправильной конфигурации: многоадресная рассылка на локальном канале выходит за рамки практически всех возможных неправильных настроек сети. Даже если у вас есть набор устройств, в которых IP-адрес, маска подсети, шлюз по умолчанию и адрес DNS-сервера каждого устройства неверны, пакеты, отправленные любым из этих устройств, адресованные локальному адресу назначения многоадресной рассылки, все равно будут доставлены всем сверстники по локальной ссылке. Это может быть чрезвычайно полезно при диагностике и устранении сетевых проблем, поскольку облегчает прямой канал связи между клиентом и сервером, который работает без использования ARP, таблиц IP-маршрутизации и т. Д. Возможность выяснить, какой IP-адрес имеет устройство (или считает, что это так). имеет) часто является очень ценным первым шагом в диагностике, почему он не может общаться в локальной сети.

Приложение E. Обоснование дизайна для кодирования отрицательных ответов

Были рассмотрены альтернативные методы утверждения несуществования, такие как использование ответа NXDOMAIN или создание записи ресурса с rdata нулевой длины.

Использование ответа NXDOMAIN плохо работает с многоадресной DNS. Одноадресный ответ DNS NXDOMAIN применяется ко всему сообщению, но для эффективности многоадресный DNS позволяет (и поощряет) множественные ответы в одном сообщении. Если бы код ошибки в заголовке был NXDOMAIN, было бы непонятно, к какому имени (ям) применяется этот код ошибки.

Утверждение небытия путем отправки записи ресурса с rdata нулевой длины будет означать, что не будет никакого способа провести различие между несуществующей записью и записью, которая существует с rdata нулевой длины. По аналогии, большинство файловых систем сегодня допускают пустые файлы, поэтому файл, который существует с нулевыми байтами данных, не считается эквивалентным имени файла, который не существует.

Преимущество утверждения несуществования с помощью записей NSEC вместо ответов NXDOMAIN заключается в том, что записи NSEC могут быть добавлены в дополнительный раздел ответа DNS для предоставления дополнительной информации, выходящей за рамки явно запрашиваемого запросчиком. Например, в ответ на запрос SRV респондент должен включить запись (записи) A, дающую свои IPv4-адреса в дополнительном разделе, и запись NSEC, указывающую, какие другие типы он имеет или не имеет для этого имени. Если респондент работает на хосте, который не поддерживает IPv6 (или поддерживает IPv6, но в настоящее время не имеет адреса IPv6 на этом интерфейсе), то эта запись NSEC в дополнительном разделе будет указывать на отсутствие записей AAAA. По сути, респондент говорит: «Вот моя запись SRV, а вот мои адреса IPv4, и нет, у меня нет адресов IPv6, поэтому не тратьте свое время на расспросы». Без этой информации в дополнительном разделе запрашивающему потребовался бы дополнительный обход, чтобы выполнить дополнительный запрос, чтобы убедиться, что целевой хост не имеет записей AAAA. (Возможно, Unicast DNS также может извлечь выгоду из этой способности выражать несуществование в дополнительном разделе, но это выходит за рамки этого документа.)

Приложение F. Использование UTF-8

После многих лет дебатов, в результате осознанной необходимости учесть определенные реализации DNS, которые, очевидно, не могли обрабатывать символы, не являющиеся буквой, цифрой или дефисом (и, по-видимому, никогда не будут обновлены для устранения этого ограничения), Unicast Сообщество DNS остановилось на чрезвычайно барочной кодировке под названием «Punycode» [RFC3492]. Punycode — это поразительно оригинальное решение для кодирования, но оно сложное, трудное для понимания и сложное для реализации с использованием сложных методов, включая вставное несортированное кодирование, обобщенные целые числа переменной длины и адаптацию смещения.

Результирующая кодировка является удивительно компактной, учитывая ограничения, но она все же не так хороша, как простая прямая UTF-8, и трудно даже предсказать, будет ли данная входная строка кодироваться в строку Punycode, которая соответствует 63-байтовому пределу DNS, кроме просто попробовав кодирование и посмотрев, подходит ли оно. Действительно, кодированный размер зависит не только от входных символов, но и от порядка их появления, поэтому один и тот же набор символов может кодировать или не кодировать допустимую строку Punycode, которая соответствует 63-байтовому пределу DNS, в зависимости от порядка появляются символы Это чрезвычайно трудно представить в пользовательском интерфейсе, который объясняет пользователям, почему одно имя разрешено, а другое, содержащее точно такие же символы, — нет. Ни Punycode, ни какие-либо другие «ASCIIC-совместимые кодировки» [RFC5890], предлагаемые для одноадресной DNS, не могут использоваться в многоадресных DNS-сообщениях. Любой текст, представленный внутри другого представления, должен быть преобразован в канонический предварительно составленный UTF-8, прежде чем помещаться в любое многоадресное DNS-сообщение.

Приложение G. Частные пространства имен DNS

Специальная обработка имен, заканчивающихся на «.local». был реализован на компьютерах Macintosh со времен Mac OS 9 и продолжается сегодня в Mac OS X и iOS. Существуют также реализации для Microsoft Windows [B4W], Linux и других платформ.

Некоторые операторы сетей, настраивающие частные внутренние сети («интрасети»), использовали незарегистрированные домены верхнего уровня, а некоторые, возможно, использовали домен верхнего уровня «.local». Использование «.local» в качестве частного домена верхнего уровня конфликтует с Multicast DNS и может вызвать проблемы у пользователей. Клиенты могут быть настроены на параллельную отправку DNS-запросов как многоадресной, так и одноадресной передачи для этих имен, и это позволяет искать имена в обоих направлениях, но это приводит к дополнительному сетевому трафику и дополнительным задержкам в разрешении имен, а также к потенциальному созданию пользователя. путаница, когда неясно, был ли какой-либо данный результат получен через многоадресную локальную связь от однорангового узла в той же ссылке или от настроенного сервера имен одноадресной рассылки. Из-за этого мы не рекомендуем использовать «.local» в качестве частного домена Unicast DNS верхнего уровня. Мы вообще не рекомендуем использовать незарегистрированные домены верхнего уровня, но если сетевые операторы решат сделать это, следующие домены верхнего уровня использовались в частных внутренних сетях без проблем, вызванных попыткой повторного использования «.local». для этого:

.intranet.
.internal.
.private.
.corp.
.home.
.lan.

Приложение H. История развертывания

В июле 1997 года в электронном письме в список рассылки net-thinkers@thumper.vmeng.com Стюарт Чешир впервые предложил идею использования протокола привязки имен AppleTalk [RFC6760] по IP. В результате этого и связанных с ним обсуждений IETF рабочая группа IETF Zeroconf была учреждена в сентябре 1999 года. После различных обсуждений в рабочих группах и других неофициальных обсуждений IETF было написано несколько интернет-проектов, которые были слабо связаны с общими темами DNS и многоадресной рассылки, но не рассматривал аспект обнаружения услуг NBP.

В апреле 2000 года Стюарт Чешир зарегистрировал многоадресный адрес IPv4 224.0.0.251 в IANA [MC4] и начал писать код для проверки и разработки идеи выполнения обнаружения, подобного NBP, с использованием многоадресной DNS, которая была задокументирована в группе из трех интернет-проектов. :

«Требования к протоколу для замены протокола привязки имен AppleTalk (NBP)» [RFC6760] представляет собой обзор, объясняющий протокол привязки имен AppleTalk, поскольку многие в сообществе IETF имели небольшой опыт непосредственного использования AppleTalk и путаницу в IETF. Сообщество по поводу того, что сделал AppleTalk NBP, вызывало путаницу относительно того, что потребуется для замены на основе IP.
«Обнаружение именованных экземпляров абстрактных сервисов с использованием DNS» [NIAS] предложил способ выполнения обнаружения, подобного NBP, с использованием DNS-совместимых имен и типов записей.
«Многоадресный DNS» (этот документ) указывает способ транспортировки этих DNS-совместимых запросов и ответов с использованием IP-многоадресной передачи для сред с нулевой конфигурацией, где не было доступного обычного сервера Unicast DNS.

В 2001 году в обновление для Mac OS 9 добавлена поддержка библиотеки распознавателя для поиска имени хоста с использованием Multicast DNS. Если пользователь ввел имя, например «MyPrinter.local». в любом сетевом программном обеспечении, использующем стандартные API поиска имен Mac OS 9, эти API поиска имен распознают имя как локальное имя точки и запрашивают его, отправляя простые однократные многоадресные DNS-запросы на 224.0.0.251: 5353. Это позволило пользователю, например, ввести имя «MyPrinter.local». в их веб-браузере для просмотра веб-страницы состояния и конфигурации принтера или введите имя «MyPrinter.local». в утилиту настройки принтера, чтобы создать очередь печати для печати документов на этом принтере.

Программное обеспечение многоадресного DNS-ответчика, с полным обнаружением услуг, впервые начало поставляться конечным пользователям в объеме с запуском Mac OS X 10.2 «Jaguar» в августе 2002 года и производителями сетевых принтеров (которые исторически поддерживали AppleTalk в своих сетевых принтерах и были восприимчивыми к технологиям на основе IP, которые могли бы предложить им аналогичную простоту использования), вскоре после этого начали внедрять Multicast DNS.

В сентябре 2002 года Apple выпустила исходный код для демона mDNSResponder в качестве открытого источника под стандартной Apple Public License License (APSL) Apple.
ПО для многоадресного DNS-ответчика стало доступно пользователям Microsoft Windows в июне 2004 года с запуском Apple Rendezvous для Windows (теперь Bonjour для Windows), как в исполняемом виде (загружаемый установщик для конечных пользователей), так и в виде Open Source (один поддерживаемых платформ в теле кроссплатформенного кода Apple в общедоступном хранилище исходного кода CVS mDNSResponder) [BJ].

В августе 2006 года Apple повторно лицензировала кроссплатформенный исходный код mDNSResponder под лицензией Apache, версия 2.0.

В дополнение к настольным и портативным компьютерам, работающим под управлением Mac OS X и Microsoft Windows, Multicast DNS теперь реализован в широком спектре аппаратных устройств, таких как беспроводные базовые станции Apple AirPort, iPhone и iPad, а также в домашних шлюзах других производителей. сетевые принтеры, сетевые камеры, видеорегистраторы TiVo и др.

Сообщество Open Source выпустило много независимых реализаций Multicast DNS, некоторые из которых на C похожи на демон mDNSResponder от Apple, а другие на различных языках, включая Java, Python, Perl и C # / Mono.

В январе 2007 года IETF опубликовала Информационный RFC «Разрешение многоадресных имен локальной сети (LLMNR)» [RFC4795], который в значительной степени похож на многоадресную DNS, но несовместим в некоторых небольших, но важных отношениях. В частности, проект LLMNR явно исключал поддержку обнаружения служб, что делало его неподходящим кандидатом на использование протокола для замены AppleTalk NBP [RFC6760].

В то время как первоначальный фокус поиска многоадресной DNS и обнаружения служб на основе DNS был для сред с нулевой конфигурацией без обычного DNS-сервера одноадресной передачи, обнаружение службы на основе DNS также работает с использованием одноадресных DNS-серверов, используя обновление DNS [RFC2136] [RFC3007] для создания службы. записи обнаружения и стандартные DNS-запросы для их запроса. Служба Apple Back to My Mac, запущенная с Mac OS X 10.5 «Leopard» в октябре 2007 года, использует обнаружение службы на основе DNS через одноадресную DNS [RFC6281].

В июне 2012 года операционная система Google Android добавила встроенную поддержку DNS-SD и многоадресной DNS с классом android.net.nsd.NsdManager в Android 4.1 «Jelly Bean» (уровень API 16) [NSD].

Адрес автора

Stuart Cheshire
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA

Phone: +1 408 974 3207

EMail: cheshire@apple.com

Marc Krochmal
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA

Phone: +1 408 974 4368

EMail: marc@apple.com