RFC 6763 | Обнаружение службы на основе DNS

Аннотация

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

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

Оглавление

 

1. Введение
2. Условные обозначения и терминология, используемые в настоящем документе
3. Цели дизайна
4. Перечисление экземпляров службы (просмотр)
4.1. Имена экземпляров структурированных сервисов
4.1.1. Имена экземпляров
4.1.2. Сервисные имена
4.1.3. Доменные имена
4.2. Презентация интерфейса пользователя
4.3. Внутренняя обработка имен
5. Разрешение экземпляра службы
6. Синтаксис данных для записей DNS-SD TXT
6.1. Общие правила форматирования записей DNS TXT
6.2. Размер записи DNS-SD TXT 
6.3. Правила формата записи DNS TXT для использования в DNS-SD
6.4. Правила для ключей в парах ключ-значение DNS-SD
6.5. Правила для значений в парах ключ / значение DNS-SD
6.6. Пример записи TXT
6.7. Версия тега
6.8. Экземпляры обслуживания с несколькими записями TXT
7. Сервисные имена
7.1. Выборочное перечисление экземпляров (подтипы)
7.2. Ограничения длины имени службы
8. Флагманское Наименование
9. Перечисление типов услуг
10. Заполнение DNS информацией
11. Обнаружение просмотра и регистрации доменов (перечисление доменов)
12. Генерация дополнительных записей DNS
12.1. PTR Records
12.2. SRV Records
12.3. TXT Records
12.4. Другие типы записей
13. Рабочие примеры
13.1. Какие веб-страницы рекламируются на dns-sd.org?
13.2. Какие веб-страницы конфигурации принтера существуют?
13.3. Как получить доступ к веб-странице под названием «Обнаружение служб»?
14. Соображения по IPv6
15. Вопросы безопасности
16. Соображения IANA
17. Благодарности
18. Ссылки
18.1. Нормативные ссылки
18.2. Информационные ссылки
Приложение А. Обоснование использования DNS в качестве основы для обнаружения служб
Приложение B. Заказ компонентов имени экземпляра сервиса
B.1. Семантическая структура
B.2. Эффективность сети
В.3. Операционная гибкость
Приложение C. То, что вы видите, это то, что вы получаете
Приложение D. Выбор заводских имен по умолчанию
Приложение E. Кодировки имен в системе доменных имен
Приложение F. Модель просмотра «Непрерывное прямое обновление»
Приложение G. История развертывания
Адрес автора

 

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

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

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 5741.
Информацию о текущем статусе этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc6763.

 

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

Copyright (c) 2013 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

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

 

1. Введение

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

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

В этом документе указывается, что конкретный экземпляр службы может быть описан с использованием записи DNS SRV [RFC2782] и DNS TXT [RFC1035]. Запись SRV имеет имя в форме «<Экземпляр>. <Служба>. <Домен>» и содержит целевой хост и порт, к которому может быть подключен экземпляр службы. DNS-запись TXT с тем же именем предоставляет дополнительную информацию об этом экземпляре в структурированной форме с использованием пар ключ / значение, описанных в разделе 6. Клиент обнаруживает список доступных экземпляров данного типа службы, используя запрос для DNS PTR Запись [RFC1035] с именем в форме «<Service>. <Domain>», которая возвращает набор из нуля или более имен, которые являются именами вышеупомянутых пар записей DNS SRV / TXT.

Эта спецификация совместима как с Multicast DNS [RFC6762], так и с существующим на сегодняшний день Unicast DNS-сервером и клиентским программным обеспечением.

При использовании с многоадресной DNS DNS-SD может обеспечить работу без конфигурации — просто подключите устройство DNS-SD / mDNS, и его услуги будут объявлены на локальной линии без дальнейшего взаимодействия с пользователем [ZC].

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

Обратите внимание, что при использовании DNS-SD с одноадресным DNS служба Unicast DNS-SD НЕ ДОЛЖНА предоставляться тем же оборудованием DNS-сервера, которое в настоящее время предоставляет стандартную для организации службу поиска имени хоста. В то время как многие люди думают о «DNS» исключительно в контексте сопоставления имен хостов с IP-адресами, на самом деле «DNS является общей (хотя и несколько ограниченной) иерархической базой данных и может хранить практически любые данные практически для любых целей. «[RFC2181]. Передавая субдомены «_tcp» и «_udp», вся рабочая нагрузка, связанная с DNS-SD, может быть выгружена на другой компьютер. Такая гибкость, позволяющая обрабатывать DNS-SD на главном DNS-сервере или нет, по усмотрению администратора сети, является одним из преимуществ использования DNS.

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

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

 

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» быть подготовлена ​​к взаимодействию с другой реализацией, которая не включает эту опцию (за исключением, конечно, функции, предоставляемой опцией).

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

 

3. Цели дизайна

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

1. Возможность запрашивать услуги определенного типа в определенном логическом домене и получать в ответ список именованных экземпляров (просмотр сети или «Перечисление экземпляров служб»).
2. Учитывая конкретный именованный экземпляр, способность эффективно преобразовывать это имя экземпляра в требуемую информацию, необходимую клиенту для фактического использования службы, то есть IP-адреса и номера порта, как минимум (разрешение экземпляра службы).
3. Имена экземпляров должны быть относительно постоянными. Если пользователь выбирает свой принтер по умолчанию из списка доступных вариантов сегодня, то завтра он все равно сможет печатать на этом принтере — даже если IP-адрес и / или номер порта, где находится служба, изменились — без пользователя (или их программное обеспечение), повторяя шаг (i) (начальный просмотр сети) во второй раз.

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

Эти цели обсуждаются более подробно в оставшейся части этого документа. Более подробное рассмотрение требований к обнаружению служб можно найти в «Требованиях к протоколу для замены протокола привязки имен AppleTalk (NBP)» [RFC6760]. Этот документ опирается на примеры из двух десятилетий опыта работы с AppleTalk для разработки списка универсальных требований, которые широко применимы к любому протоколу обнаружения потенциальных услуг.

 

4. Перечисление экземпляров службы (просмотр)

Традиционные записи DNS SRV [RFC2782] полезны для определения местоположения экземпляров службы определенного типа, когда все экземпляры практически неразличимы и предоставляют клиенту одну и ту же услугу.

Например, записи SRV с (гипотетическим) именем «_http._tcp.example.com». позволит клиенту обнаруживать серверы, реализующие службу «_http._tcp» (то есть веб-серверы) для «example.com». домен. Неустановленное предположение состоит в том, что все эти серверы предлагают идентичный набор веб-страниц, и для клиента не имеет значения, какой из серверов он использует, если он выбирает один случайным образом в соответствии с правилами веса и приоритетов, изложенными в спецификация DNS SRV [RFC2782].

Экземпляры других видов услуг менее легко взаимозаменяемы. Если приложение для обработки текстов ищет (гипотетическую) запись SRV «_ipp._tcp.example.com». найти список принтеров Internet Printing Protocol (IPP) [RFC2910] в Example Co., затем выбрать один из них наугад и напечатать на нем, вероятно, не то, что хочет пользователь.

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

 

4.1. Имена экземпляров структурированных сервисов

Этот документ заимствует логический синтаксис и семантику именования сервисов из записей DNS SRV, но добавляет один уровень косвенности. Вместо того, чтобы запрашивать записи типа «SRV» с именем «_ipp._tcp.example.com.», Клиент запрашивает записи типа «PTR» (указатель от одного имени к другому в пространстве имен DNS) [RFC1035].

По сути, если кто-то думает о доменном имени «_ipp._tcp.example.com». как аналог абсолютного пути к каталогу в файловой системе, тогда поиск PTR DNS-SD сродни выполнению листинга этого каталога, чтобы найти все записи, которые он содержит. (Помните, что доменные имена выражаются в обратном порядке по сравнению с путевыми именами — абсолютный путь начинается с корня слева и читается слева направо, тогда как полное доменное имя начинается с корня справа и читать справа налево. Если полное доменное имя «_ipp._tcp.example.com.» было выражено как путь к файловой системе, это будет «/ com / example / _tcp / _ipp».)

Результатом этого поиска PTR для имени «<Service>. <Domain>» является набор из нуля или более записей PTR, дающих имена экземпляров службы в форме:

Service Instance Name = <Instance> . <Service> . <Domain>

Для объяснения того, почему компоненты находятся в этом порядке, см. Приложение B, «Порядок упорядочения компонентов имени экземпляра службы».

 

4.1.1. Имена экземпляров

Часть <Instance> имени экземпляра службы — это удобное для пользователя имя, состоящее из произвольного текста Net-Unicode [RFC5198]. Он НЕ ДОЛЖЕН содержать управляющие символы ASCII (байтовые значения 0x00-0x1F и 0x7F) [RFC20], но в других случаях разрешается содержать любые символы без ограничений, включая пробелы, верхний регистр, нижний регистр, знаки пунктуации, включая точки, символы с акцентом, не Римский текст и все остальное, что может быть представлено с использованием Net-Unicode. Для обсуждения того, почему имя <Instance> должно быть видимым для пользователя, удобным для пользователя именем, а не невидимым сгенерированным машиной непрозрачным идентификатором, см. Приложение C «Что вы видите, то и получаете».

Часть <Instance> имени службы, предлагаемой в сети, ДОЛЖНА настраиваться пользователем, настраивающим службу, чтобы он или она могли дать ей информативное имя. Однако устройству или услуге НЕ СЛЕДУЕТ требовать, чтобы пользователь настраивал имя, прежде чем его можно будет использовать. Разумный выбор имени по умолчанию может во многих случаях обеспечить доступ к устройству или услуге без какой-либо ручной настройки. Имя по умолчанию должно быть коротким и описательным, и НЕ ДОЛЖНО включать в себя адрес устройства управления доступом к среде (MAC), серийный номер или любую аналогичную непонятную шестнадцатеричную строку в попытке сделать имя глобально уникальным. Для обсуждения того, почему имена <Instance> не нужно (и НЕ ДОЛЖНО) делать уникальными на заводе, см. Приложение D, «Выбор имен по умолчанию».

Эта часть <Instance> имени экземпляра службы хранится непосредственно в DNS как единая метка DNS для канонического предварительно составленного текста UTF-8 [RFC3629] «Net-Unicode» (форма нормализации Unicode C) [RFC5198]. Дальнейшее обсуждение кодировок текста см. В Приложении E «Кодировки имен в системе доменных имен».

Длина меток DNS в настоящее время ограничена 63 октетами. Для кодировки UTF-8 может потребоваться до четырех октетов на символ Unicode, что означает, что в худшем случае часть имени <Instance> может быть ограничена пятнадцатью символами Unicode. Однако Unicode-символы с большей длиной октета в кодировке UTF-8, как правило, используются реже, и, как правило, имеют большее значение для каждого символа.

Обратите внимание, что любой символ в обычно используемой 16-разрядной базовой многоязычной плоскости Unicode [Unicode6] может быть закодирован не более чем тремя октетами кодировки UTF-8. Это означает, что имя экземпляра может содержать до 21 символа кандзи, что является достаточно выразительным именем для большинства целей.

 

4.1.2. Сервисные имена

Часть <Service> в имени экземпляра службы состоит из пары меток DNS в соответствии с соглашением, уже установленным для записей SRV [RFC2782]. Первая метка пары — это символ подчеркивания, за которым следует имя службы [RFC6335]. Имя службы определяет, что служба делает и какой протокол приложения она использует для этого. Вторая метка — это либо «_tcp» (для протоколов приложений, работающих по протоколу TCP), либо «_udp» (для всех остальных). Для получения более подробной информации см. Раздел 7 «Имена сервисов».

4.1.3. Доменные имена

Часть <Domain> имени экземпляра службы указывает поддомен DNS, в котором эти имена зарегистрированы. Это может быть «local.», Что означает «link-local Multicast DNS» [RFC6762], или это может быть обычное доменное имя DNS Unicast, такое как «ietf.org.», «Cs.stanford.edu.» Или «eng.us.ibm.com.» Поскольку имена экземпляров службы не являются именами хостов, они не ограничены обычными правилами для имен хостов [RFC1033] [RFC1034] [RFC1035], и субдоменам сервисов расширенного текста разрешено и рекомендуется, например:

Building 2, 1st Floor . example . com .
Building 2, 2nd Floor . example . com .
Building 2, 3rd Floor . example . com .
Building 2, 4th Floor . example . com .

Кроме того, поскольку имена экземпляров служб не ограничены ограничениями имен хостов, в этом документе рекомендуется, чтобы они сохранялись в DNS и передавались по проводам, закодированные в виде простого канонического предварительно составленного UTF-8 [RFC3629] «Net-Unicode» (Форма нормализации Unicode C) [RFC5198] текст. В тех случаях, когда DNS-сервер возвращает отрицательный ответ для рассматриваемого имени, клиентское программное обеспечение МОЖЕТ выбрать повторную попытку запроса, используя алгоритм «Punycode» [RFC3492], чтобы преобразовать имя UTF-8 в IDNA «A-метка» [RFC5890 ], начиная с метки верхнего уровня, затем повторно отправляя запрос, с каждым разом все больше меток, транслируемых в метки А IDNA, и отказываясь, если он преобразовал все метки в метки А IDNA и запрос все еще не выполнен.

 

4.2. Презентация интерфейса пользователя

Имена, полученные в результате поиска PTR перечисления экземпляров службы, представляются пользователю в списке, чтобы пользователь мог выбрать одно (или более). Как правило, отображается только первая метка (удобная для пользователя часть <Instance> имени).

В общем случае <Service> и <Domain> уже известны клиентскому программному обеспечению, они были изначально неявно предоставлены пользователем, посредством указания на запрашиваемую услугу и домен, в котором следует искать для этого. Обратите внимание, что программное обеспечение, обрабатывающее ответ, должно быть осторожным, чтобы не делать недопустимых предположений, поскольку * возможно * хотя и редко * при перечислении служб в одном домене возвращать имена служб в другом домене. Аналогично, при использовании подтипов (см. Раздел 7.1, «Выборочное перечисление экземпляров») <Service> обнаруженного экземпляра может не совпадать с <Service>, который был запрошен.

Дальнейшее обсуждение особенностей пользовательского интерфейса перечисления экземпляров служб (просмотр) см. В Приложении F, «Модель просмотра в режиме постоянного обновления».

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

 

4.3. Внутренняя обработка имен

Если клиентское программное обеспечение берет части <Instance>, <Service> и <Domain> Имени экземпляра службы и внутренне объединяет их вместе в одну строку, то, поскольку часть <Instance> может содержать любые символы, включая точки, ДОЛЖНЫ быть приняты соответствующие меры предосторожности для обеспечения надлежащего сохранения границ меток DNS. Клиентское программное обеспечение может делать это различными способами, например, экранированием персонажа.

В этом документе РЕКОМЕНДУЕТСЯ, чтобы при объединении трех частей имени экземпляра службы любые точки в части <Instance> были экранированы в соответствии с обычным соглашением DNS для текстовых файлов: путем предшествующей литеральной точки с обратной косой чертой (т. Е. «.» Становится «\. «). Аналогично, любые обратные косые черты в части <Instance> также должны быть экранированы, если им предшествует обратная косая черта (поэтому «\» становится «\\»).

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

 

5. Разрешение экземпляра службы

Когда клиенту необходимо связаться с конкретной службой, идентифицируемой по имени экземпляра службы, ранее обнаруженному с помощью перечисления экземпляра службы (просмотра), он запрашивает записи SRV и TXT с этим именем. Запись SRV для службы дает номер порта и имя целевого хоста, где может быть найдена служба. Запись TXT предоставляет дополнительную информацию об услуге, как описано в разделе 6 «Синтаксис данных для записей TXT DNS-SD».

Записи SRV чрезвычайно полезны, поскольку они устраняют необходимость в предварительно назначенных номерах портов. Доступно только 65535 номеров портов TCP. Эти номера портов традиционно выделяются по одному на протокол приложения [RFC6335]. Некоторые протоколы, такие как X Window System, имеют выделенный блок из 64 портов TCP (6000-6063). Использование отдельного порта TCP для каждого отдельного экземпляра данной службы на данном компьютере вполне разумно, но выделение каждому приложению собственного большого статического диапазона, как это было сделано для системы X Window, не является практическим способом сделать это. На любом данном хосте большинство TCP-портов зарезервировано для служб, которые никогда не будут работать на этом конкретном хосте в течение срока его службы. Это очень плохое использование ограниченного пространства порта. Использование записей SRV позволяет каждому хосту динамически выделять свои доступные номера портов тем службам, которые на самом деле работают на том хосте, которые в них нуждаются, а затем объявлять назначенные номера портов через записи SRV. Распределение доступных номеров портов прослушивания локально для каждого хоста по мере необходимости позволяет гораздо лучше использовать доступное пространство порта, чем сегодняшнее централизованное глобальное распределение.

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

 

6. Синтаксис данных для записей DNS-SD TXT

Некоторым службам, обнаруженным с помощью перечисления экземпляров службы, может потребоваться нечто большее, чем просто IP-адрес и номер порта, чтобы полностью идентифицировать экземпляр службы. Например, при печати по старому протоколу Unix LPR (порт 515) [RFC1179] часто указывается имя очереди [BJP]. Это имя очереди обычно короткое и загадочное, и его не нужно показывать пользователю. Его следует рассматривать так же, как IP-адрес и номер порта: это еще один компонент информации адресации, необходимый для идентификации конкретного экземпляра услуги, предлагаемой некоторым компонентом оборудования. Аналогично, файловый сервер может иметь несколько томов, каждый из которых идентифицируется своим именем тома. Веб-сервер обычно имеет несколько страниц, каждая из которых идентифицируется своим собственным URL-адресом. В этих случаях необходимые дополнительные данные сохраняются в записи TXT с тем же именем, что и запись SRV. Конкретный характер этих дополнительных данных и то, как их следует использовать, зависит от службы, но общий синтаксис данных в записи TXT стандартизирован, как описано ниже.

Каждая служба DNS-SD ДОЛЖНА иметь запись TXT в дополнение к своей записи SRV с тем же именем, даже если у службы нет дополнительных данных для хранения, и запись TXT содержит не более одного нулевого байта. Это позволяет службе явно контролировать время жизни (TTL) своей (пустой) записи TXT, вместо использования отрицательного кэширования TTL по умолчанию, которое в противном случае использовалось бы для ответа DNS «нет ошибки — нет ответа».

Обратите внимание, что это требование для обязательной записи TXT применяется исключительно к рекламе службы DNS-SD, то есть к услугам, рекламируемым с использованием соглашения PTR + SRV + TXT, указанного в этом документе. Это не требование записей SRV в целом. Тип данных записи SRV DNS [RFC2782] все еще может использоваться в других контекстах без каких-либо требований для сопровождения записей PTR и TXT.

 

6.1. Общие правила форматирования записей DNS TXT

DNS-запись TXT может иметь длину до 65535 (0xFFFF) байтов. Общая длина указывается длиной, указанной в заголовке записи ресурса в сообщении DNS. Невозможно напрямую определить, исходя из данных, как долго это происходит (например, отсчет длины в начале отсутствует или завершающий байт NULL в конце).

Обратите внимание, что при использовании многоадресной DNS [RFC6762] максимальный размер пакета составляет 9000 байтов, включая заголовок IP, заголовок UDP и заголовок сообщения DNS, что накладывает верхний предел на размер записей TXT, составляющий около 8900 байтов. На практике максимальный разумный размер записи TXT DNS-SD даже меньше этого, обычно не более нескольких сотен байтов, как описано ниже в разделе 6.2.

Формат данных в записи TXT DNS — это одна или несколько строк, упакованных вместе в памяти без каких-либо промежуточных пробелов или байтов заполнения для выравнивания слов.

Формат каждой составляющей строки в записи TXT DNS — это один байт длины, за которым следуют 0-255 байтов текстовых данных.

Эти правила формата для записей TXT определены в разделе 3.3.14 спецификации DNS [RFC1035] и не относятся к DNS-SD. DNS-SD определяет дополнительные правила для того, какие данные должны храниться в этих составляющих строках, когда они используются для рекламы услуг DNS-SD, то есть когда они используются для описания услуг, рекламируемых с использованием соглашения PTR + SRV + TXT, указанного в этом документе.

Пустая TXT-запись, содержащая нулевые строки, не допускается [RFC1035]. Реализации DNS-SD НЕ ДОЛЖНЫ выдавать пустые записи TXT. Клиенты DNS-SD ДОЛЖНЫ трактовать следующее как эквивалентное:

• TXT-запись, содержащая один нулевой байт. (то есть одна пустая строка.)
• Пустая (нулевая длина) TXT-запись. (Это не является строго законным, но если он получен, его следует интерпретировать так же, как одну пустую строку.)
• Нет записи TXT. (т. е. ответ NXDOMAIN или ответ без ошибок.)

 

6.2. DNS-SD TXT Размер записи

Общий размер типичной записи DNS-SD TXT должен быть небольшим — 200 байтов или меньше.

В тех случаях, когда оправдано больше данных (например, печать LPR [BJP]), сохранение общего размера менее 400 байт должно позволять помещаться в одном 512-байтовом сообщении DNS [RFC1035].

В крайних случаях, когда даже этого недостаточно, сохранение размера записи TXT ниже 1300 байт должно позволить ей поместиться в одном 1500-байтовом пакете Ethernet.

Использование записей TXT размером более 1300 байт в настоящее время НЕ РЕКОМЕНДУЕТСЯ.

Обратите внимание, что некоторые поставщики оборудования Ethernet предлагают наборы микросхем с многоадресной рассылкой DNS [RFC6762], так что компьютеры могут находиться в спящем режиме и быть обнаруживаемыми в сети. Ранние версии таких наборов микросхем иногда были весьма ограничены: например, некоторые были (неразумно) ограничены обработкой записей TXT размером не более 256 байт (что означало, что службы принтера LPR с большими записями TXT не работали). Разработчики должны знать об этом действительном ограничении и должны понимать, что даже аппаратное обеспечение, которое в противном случае идеально способно, может иметь более низкое энергопотребление и режимы сна, которые являются более ограниченными.

 

6.3. Правила формата записи DNS TXT для использования в DNS-SD

DNS-SD использует записи DNS TXT для хранения произвольных пар ключ / значение, передающих дополнительную информацию об именованном сервисе. Каждая пара ключ / значение кодируется как собственная составляющая строка в записи TXT DNS в форме «ключ = значение» (без кавычек). Все до первого символа ’=’ является ключом (раздел 6.4). Все, что находится после первого символа «=» до конца строки (включая последующие символы «=», если есть), является значением (раздел 6.5). Вокруг значения не требуются кавычки, даже если оно содержит пробелы, символы «=» или другие знаки пунктуации. Каждый автор, определяющий профиль DNS-SD для обнаружения экземпляров определенного типа сервиса, должен определить базовый набор атрибутов ключ / значение, которые действительны для этого типа сервиса.

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

Имя целевого хоста и номер порта TCP (или UDP) службы указаны в записи SRV. Эта информация — имя целевого хоста и номер порта — НЕ ДОЛЖНА дублироваться с использованием атрибутов ключ / значение в записи TXT.

Целью записей DNS-SD TXT является передача небольшого количества полезной дополнительной информации об услуге. В идеале клиенту не нужно извлекать эту дополнительную информацию, прежде чем он сможет с пользой установить соединение со службой. Для хорошо разработанного прикладного протокола, даже если в записи TXT вообще нет информации, должно быть возможно, зная только имя хоста, номер порта и используемый протокол, связаться с этим процессом прослушивания и затем выполнить версию — или согласование функций для определения любых дополнительных параметров или возможностей экземпляра службы. Например, при подключении к серверу AFP (Apple Filing Protocol) [AFP] по TCP клиент вступает в обмен протоколом с сервером, чтобы определить, какую версию AFP реализует сервер и какие дополнительные функции или возможности (если таковые имеются) имеется в наличии.

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

Существуют устаревшие протоколы, которые не предоставляют возможности согласования функций, и в этих случаях может быть полезно передать необходимую информацию в записи TXT. Например, при печати с использованием LPR [RFC1179] протокол LPR не предоставляет клиенту возможности определить, принимает ли конкретный принтер PostScript, какую версию PostScript и т. Д. В этом случае целесообразно встраивать эту информацию в запись TXT. [BJP], потому что альтернатива была бы хуже — передача письменных инструкций пользователям, непонятная ручная настройка файлов «/ etc / printcap» и т. Д.

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

 

6.4. Правила для ключей в парах ключ-значение DNS-SD

Ключ ДОЛЖЕН быть как минимум одним символом. Строки записи DNS-SD TXT, начинающиеся с символа «=» (т. Е. Ключ отсутствует), ДОЛЖНЫ игнорироваться.

Ключ ДОЛЖЕН быть длиной не более девяти символов. Это связано с тем, что для эффективности сети выгодно сохранять небольшие размеры пакетов. При использовании DNS-SD в сочетании с многоадресным DNS [RFC6762] это важно, поскольку многоадресный трафик особенно дорог в беспроводных сетях 802.11 [IEEEW], но даже при использовании обычного одноадресного DNS сохранение небольших записей TXT помогает повысить вероятность того, что ответы будут вписывается в исходный предел размера DNS 512 байт [RFC1035]. Кроме того, каждая составляющая строка записи TXT DNS ограничена 255 байтами, поэтому чрезмерно длинные ключи уменьшают пространство, доступное для значений этого ключа.

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

Символы ключа ДОЛЖНЫ быть печатаемыми значениями US-ASCII (0x20-0x7E) [RFC20], исключая ’=’ (0x3D).

Пробелы в ключе имеют большое значение, будь то ведущий, тянущийся или посередине, поэтому не включайте пробелы, если вы действительно не собираетесь этого делать.
При интерпретации ключа регистр игнорируется, поэтому «paperize = A4», «PAPERSIZE = A4» и «Papersize = A4» все идентичны.

Если в строке записи DNS-SD TXT нет ‘=’, то это логический атрибут, просто идентифицируемый как присутствующий, без значения.

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

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

Таким образом, при проверке записи TXT для заданного ключа могут быть возвращены четыре категории результатов:

• Атрибут отсутствует (отсутствует)
• Атрибут присутствует без значения (например, «passreq» — пароль, необходимый для этой услуги)
• Атрибут присутствует с пустым значением (например, «PlugIns =» — сервер поддерживает плагины, но в настоящее время они не установлены)
• Атрибут присутствует с непустым значением (например, «PlugIns = JPEG, MPEG2, MPEG4»)

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

• Отсутствует подразумевает «ложь»
• Настоящее подразумевает «истинное»

Для других ключей может быть целесообразно определить другую семантику, такую ​​как значение / нет значения / неизвестно:

• Подарок со значением подразумевает это значение. (например, «Color = 4» для четырехцветного струйного принтера или «Color = 6» для шестицветного струйного принтера)
• Представление с пустым значением подразумевает «ложь». (например, не цветной принтер)
• Отсутствует подразумевает «Неизвестно». (например, сервер печати, подключенный к какому-либо неизвестному принтеру, где сервер печати фактически не знает, выполняет ли принтер цвет или нет — что дает очень плохой пользовательский интерфейс и его следует избегать, где это возможно)

Обратите внимание, что это гипотетический пример, а не пример фактических ключей / значений ключей, используемых сетевыми принтерами DNS-SD, которые описаны в «Спецификации печати Bonjour» [BJP].

 

6.5. Правила для значений в парах ключ / значение DNS-SD

Если в строке записи DNS-SD TXT есть ’=’, то все, что находится после первого ’=’ до конца строки, является значением. Значение может содержать любые восьмибитные значения, включая ’=’. Значение НЕ ДОЛЖНО быть заключено в дополнительные кавычки или любые подобные знаки препинания; любые кавычки или начальные или конечные пробелы являются частью значения.

Значение непрозрачных двоичных данных. Часто значением для определенного атрибута будет текст US-ASCII [RFC20] или UTF-8 [RFC3629], но допустимо, чтобы значением были любые двоичные данные.

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

Авторам, определяющим профили DNS-SD, НЕ СЛЕДУЕТ в общем случае преобразовывать типы данных двоичных атрибутов в печатный текст с использованием шестнадцатеричного представления, Base-64 [RFC4648] или кодировки Unix-to-Unix (UU), просто для того, чтобы данные выглядели как печатный текст при просмотре в общем инструменте отладки. Это просто увеличивает размер записи TXT, фактически не делая данные более понятными для тех, кто смотрит на них в общем инструменте отладки.

6.6. Пример записи TXT

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

6.7. Версия тега

Авторам, определяющим профили DNS-SD, рекомендуется включать атрибут вида «txtvers = x», где «x» — это десятичный номер версии в тексте US-ASCII [RFC20] (например, «txtvers = 1» или «txtvers»). = 8 «) и требуют, чтобы она была первой парой ключ / значение в записи TXT. Эта информация в записи TXT может быть полезна, чтобы помочь клиентам поддерживать обратную совместимость со старыми реализациями, если со временем возникнет необходимость изменить или обновить спецификацию. Даже если автор профиля не предвидит необходимости каких-либо будущих несовместимых изменений, наличие номера версии в записи TXT обеспечивает полезную страховку на случай, если несовместимые изменения станут неизбежными [RFC6709]. Клиенты ДОЛЖНЫ игнорировать записи TXT с номером txtvers, большим (или меньшим), чем у версий, которые они знают как интерпретировать.

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

Если необходимо указать, какой номер (а) версии протокола приложения реализует служба, рекомендуемый ключ для этого — «Protovers».

6.8. Экземпляры обслуживания с несколькими записями TXT

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

Наличие нескольких записей TXT для описания одного экземпляра службы очень редко, и на сегодняшний день из многих сотен зарегистрированных типов служб DNS-SD [SN] только одна использует эту возможность, а именно печать LPR [BJP]. Эта возможность используется, когда принтер концептуально поддерживает несколько имен логических очередей, где каждое другое имя логической очереди реализует свой язык описания страниц, такой как 80-колоночный простой текст, семибитный Adobe PostScript, восьмибитный («двоичный») PostScript, или какой-то проприетарный язык описания страниц. Когда несколько записей TXT используются для описания нескольких логических имен очереди LPR для одной и той же базовой службы, принтеры включают два дополнительных ключа в каждую запись TXT: «qtotal», которая указывает общее количество записей TXT, связанных с этой записью SRV, и «приоритет» ‘, который дает относительное предпочтение принтера для этой конкретной записи TXT. Затем клиенты выбирают наиболее предпочтительную запись TXT, которая соответствует потребностям клиента [BJP]. Единственная причина, по которой используются несколько записей TXT, заключается в том, что протоколу LPR не хватает возможностей согласования характеристик внутри полосы, чтобы клиент и сервер могли согласовать представление данных для задания на печать, поэтому вместо этого эту информацию необходимо передавать вне диапазона. используя записи DNSSD TXT. Будущие проекты протоколов не должны следовать этому плохому примеру, имитируя эту неадекватность протокола печати LPR.

7. Сервисные имена

Часть <Service> в имени экземпляра службы состоит из пары меток DNS в соответствии с соглашением, уже установленным для записей SRV [RFC2782].

Первая метка пары — это символ подчеркивания, за которым следует имя службы [RFC6335]. Имя службы определяет, что служба делает и какой протокол приложения она использует для этого.

Для приложений, использующих TCP, вторая метка — «_tcp».

Для приложений, использующих любой транспортный протокол, кроме TCP, вторая метка — «_udp». Это относится ко всем другим транспортным протоколам, включая протокол пользовательских дейтаграмм (UDP), протокол передачи управления потоком (SCTP) [RFC4960], протокол управления перегрузкой дейтаграмм (DCCP) [RFC4340], протокол Adobe Media Time Flow Flow (RTMFP) и т. Д. Оглядываясь назад, возможно, спецификация SRV вообще не должна была использовать метки «_tcp» и «_udp», а вместо этого должна была бы использовать одну метку «_srv» для выделения субдомена пространства имен DNS для этого использования, но эта спецификация уже опубликовано и развернуто. На данный момент нет никакой пользы в изменении устоявшейся практики. Хотя «_srv» может быть эстетически лучше, чем «_udp», это не видимая пользователем строка, и все, что требуется для протокола, — это (i) метка, которая может формировать точку делегирования DNS, и (ii) ) что он должен быть коротким, чтобы он не занимал слишком много места в пакете, и в этом отношении «_udp» или «_srv» одинаково хороши. Таким образом, имеет смысл использовать «_tcp» для служб на основе TCP и «_udp» для всех других транспортных протоколов — которые фактически в современном мире часто инкапсулируются по UDP — вместо того, чтобы определять новый поддомен для каждого нового транспортного протокола.

Обратите внимание, что это использование метки «_udp» для всех протоколов, кроме TCP, применяется исключительно к рекламе службы DNS-SD, то есть к услугам, рекламируемым с использованием соглашения PTR + SRV + TXT, указанного в этом документе. Это не требование записей SRV в целом. Другие спецификации, которые не зависят от DNS-SD и не предназначены для взаимодействия с записями DNS-SD, никоим образом не ограничены тем, как работает DNS-SD, только потому, что они также используют тип данных записи DNS SRV [RFC2782]; они могут по своему усмотрению указывать свои собственные соглашения об именах.

Правила для сервисных имен [RFC6335] гласят, что они могут быть длиной не более пятнадцати символов (не считая обязательного подчеркивания), состоящие только из букв, цифр и дефисов, должны начинаться и заканчиваться буквой или цифрой и не должны содержать последовательные дефисы и должны содержать хотя бы одну букву. Требование содержать хотя бы одну букву состоит в том, чтобы запретить имена служб, такие как «80» или «6000-6063», которые могут быть неверно интерпретированы как номера портов или диапазоны номеров портов. Хотя для ясности мнемоники могут использоваться как заглавные, так и строчные буквы, регистр игнорируется для сравнения, поэтому строки «HTTP» и «http» относятся к одной и той же службе.

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

Во многих случаях Имя службы просто именует и ссылается на используемый формат сообщения и семантику. FTP — это «ftp», IPP-печать — это «ipp» и так далее.

Тем не менее, принято «заимствовать» существующий протокол и переназначить его для новой задачи. Это вполне разумная и обоснованная инженерная практика, но это не значит, что новый протокол предоставляет ту же семантическую услугу, что и старый, даже если он заимствует те же форматы сообщений. Например, сетевой протокол обмена музыкой, реализованный iTunes на Macintosh и Windows, основан на командах «HTTP GET». Однако это * не * означает, что разумно или полезно попытаться получить доступ к одному из этих музыкальных серверов, подключившись к нему через стандартный веб-браузер. Следовательно, сервис DNS-SD, рекламируемый (и просматриваемый) iTunes, называется «_daap._tcp» (Протокол цифрового аудиодоступа), а не «_http._tcp».

Если бы iTunes объявил, что предлагает услугу «_http._tcp», это привело бы к появлению серверов iTunes в обычных веб-браузерах (Safari, Camino, OmniWeb, Internet Explorer, Firefox, Chrome и т. Д.), Которые с тех пор мало используются. музыкальная библиотека iTunes не предлагает HTML-страниц, содержащих удобочитаемый контент, который может отображать веб-браузер.

Точно так же, если iTunes будет искать службу «_http._tcp», это приведет к тому, что она обнаружит общие веб-серверы, такие как встроенные веб-серверы в устройствах, таких как принтеры, что бесполезно, так как принтеры обычно не имеют много музыки предлагать.

Аналогично, сетевая файловая система (NFS) Sun Microsystems построена на основе механизма удаленного вызова процедур (Sun RPC) Sun Microsystems, но это не означает, что для сервера NFS имеет смысл объявить, что он предоставляет услугу «Sun RPC». Аналогично, файловая служба Microsoft Server Message Block (SMB) построена поверх Netbios, работающего по IP, но это не означает, что для файлового сервера SMB имеет смысл объявить, что он предоставляет услугу «Netbios-over-IP». DNS-имя службы должно содержать как «что» (семантика), так и «как» (реализация протокола) службы, поскольку знание того и другого необходимо клиенту для осмысленного использования службы. Простая реклама того, что сервис был построен поверх Sun RPC, бесполезна, если клиент не знает, что делает сервис.

Другой распространенный вопрос — должен ли тип службы, рекламируемый iTunes, быть «_daap._http._tcp». Это также будет неправильно. Аналогично, разработчик протокола, реализующий сетевую службу, которая использует простой протокол доступа к объекту [SOAP], не должен чувствовать, что в имени службы указано «_soap». Частично путаница заключается в том, что наличие «_tcp» или «_udp» в части <Service> имени экземпляра службы заставило людей предположить, что видимая структура <Service> должна отражать частную внутреннюю структуру того, как протокол был реализован. Это не правильно. Все, что требуется, — это идентифицировать службу по уникальному непрозрачному имени службы. Создание названия службы на английском языке, которое хотя бы незначительно описывает то, что делает служба, может быть удобным, но отнюдь не обязательным.

7.1. Выборочное перечисление экземпляров (подтипы)

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

Тем не менее, существуют некоторые ограниченные обстоятельства, когда сужение набора результатов может быть полезным. Например, многие сетевые принтеры предлагают веб-интерфейс пользователя для управления и администрирования с использованием HTML / HTTP. Веб-браузер, желающий обнаружить все рекламируемые веб-страницы, выдает запрос «_http._tcp. <Domain>». С другой стороны, есть случаи, когда пользователи желают управлять принтерами конкретно, а не открывать веб-страницы в целом, и это хорошо для этого. В этом случае мы определяем подтип «_printer» для «_http._tcp», и для обнаружения только подмножества страниц, объявленных как обладающие этим свойством подтипа, веб-браузер выдает запрос для «_printer._sub._http._tcp. < Домен>».

Веб-браузер Safari в Mac OS X 10.5 «Leopard» и более поздних версиях использует таким образом подтипы. Если служба «_http._tcp» обнаруживается как с помощью просмотра «_printer._sub._http._tcp», так и с помощью просмотра «_http._tcp», то она отображается в разделе «Принтеры» пользовательского интерфейса Safari. Если служба обнаружена только при просмотре «_http._tcp», она отображается в разделе «Веб-страницы» пользовательского интерфейса Safari. Это можно увидеть с помощью приведенных ниже команд в Mac OS X для рекламы двух «поддельных» сервисов. Экземпляр службы «Веб-страница» отображается в разделе «Веб-страницы» в списке Bonjour Safari, а экземпляр «Веб-страница принтера» отображается в разделе «Принтеры».

dns-sd -R «A web page» _http._tcp local 100
dns-sd -R «A printer’s web page» _http._tcp,_printer local 101

Обратите внимание, что имя экземпляра службы объявленной веб-страницы не изменяется при использовании подтипов — оно по-прежнему имеет вид «Server._http._tcp.example.com.», И рекламируемая веб-страница по-прежнему может быть обнаружена с использованием стандартного просмотр запроса на услуги типа «_http._tcp». Субдомен, в котором регистрируются записи SRV сервера HTTP, определяет пространство имен, в котором имена серверов HTTP являются уникальными. Дополнительные подтипы (например, «_printer») базового типа службы (например, «_http._tcp») служат для того, чтобы клиенты могли запрашивать более узкий набор результатов, а не создавать больше пространства имен.

Используя синтаксис файла зоны DNS, экземпляр службы «Веб-страница» объявляется с использованием одной записи PTR, а экземпляр «Веб-страница принтера» объявляется с использованием двух: основной тип службы и дополнительный подтип. Хотя услуга «Веб-страница принтера» рекламируется двумя разными способами, обе записи PTR ссылаются на имя одной и той же пары записей SRV + TXT:

; One PTR record advertises «A web page»
_http._tcp.local. PTR A\032web\032page._http._tcp.local.

; Two different PTR records advertise «A printer’s web page»
_http._tcp.local. PTR A\032printer’s\032web\032page._http._tcp.local.
_printer._sub._http._tcp.local.
PTR A\032printer’s\032web\032page._http._tcp.local.

Подтипы подходят, когда желательно, чтобы разные типы клиентов могли просматривать службы на двух уровнях детализации. В приведенном выше примере мы описываем два класса HTTP-клиентов: обычные клиенты для просмотра веб-страниц, которые заинтересованы во всех веб-страницах, и специальные инструменты управления принтерами, которые хотели бы обнаруживать только страницы веб-интерфейса, рекламируемые принтерами. Набор HTTP-серверов в сети одинаков в обоих случаях; Разница в том, что некоторые клиенты хотят обнаружить их все, тогда как другие клиенты хотят найти только подмножество HTTP-серверов, целью которых является администрирование принтера.

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

Если все клиенты просматривают какой-то конкретный подтип, и не существует ни одного клиента, который просматривает родительский тип, следует определить новое имя службы, представляющее логическую службу, и программное обеспечение должно просто рекламировать и просматривать этот конкретный тип службы напрямую. В частности, то, что конкретная сетевая служба оказывается реализованной в терминах какого-либо другого базового протокола, такого как HTTP, Sun RPC или SOAP, не означает, что целесообразно, чтобы эта служба была определена как подтип «_http» , «_sunrpc» или «_soap». Это было бы полезно, если бы существовал некоторый класс клиентов, для которых разумно сказать: «Я хочу обнаружить службу в сети, и мне все равно, что она делает, если она делает это с использованием SOAP. Механизм XML RPC. »

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

Строки подтипа (например, «_printer» в приведенном выше примере) могут быть созданы с использованием произвольных 8-битных значений данных. Во многих случаях этими значениями данных могут быть представления текста в UTF-8 [RFC3629] или даже (как в примере выше) обычный ASCII [RFC20], но это не обязательно. Однако обратите внимание, что даже при использовании произвольных 8-битных данных для строк подтипа сравнения DNS-имен по-прежнему не чувствительны к регистру, поэтому (например) байтовые значения 0x41 и 0x61 будут считаться эквивалентными для сравнения подтипов.

7.2. Ограничения длины имени службы

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

Полное доменное имя может иметь длину до 255 байт, плюс один байт для конечной конечной корневой метки в конце. Доменные имена, используемые DNS-SD, принимают следующие формы:

<sn>._tcp . <servicedomain> . <parentdomain>.
<Instance> . <sn>._tcp . <servicedomain> . <parentdomain>.
<sub>._sub . <sn>._tcp . <servicedomain> . <parentdomain>.

Первый пример показывает имя, используемое для запросов PTR. Вторая показывает имя экземпляра службы, то есть имя записей службы SRV и TXT. Третий показывает имя просмотра подтипа, то есть имя записи PTR, указывающей на имя экземпляра службы (см. Раздел 7.1, «Выборочное перечисление экземпляра»).

Имя службы <sn> может быть длиной до 15 байтов, плюс байты подчеркивания и длины, что в сумме составляет 17. Включая «_udp» или «_tcp» и его длину, это составляет 22 байта.

Имя экземпляра <Instance> может содержать до 63 байтов. Включая длину байта, используемого форматом DNS, когда имя хранится в пакете, это составляет 64 байта.

При использовании подтипов идентификатор подтипа может иметь длину до 63 байтов, плюс длина байта, составляющая 64. Включая «_sub» и его длину, это составляет 69 байтов.

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

Из наших доступных 255 байтов мы теперь составили 69 + 22 + 64 = 155 байтов. Это оставляет 100 байтов для размещения существующего доменного имени организации <parentdomain>. При использовании с многоадресной DNS <parentdomain> является «локальным», что легко подходит. При использовании с родительскими доменами размером не более 100 байт полная функциональность DNS-SD доступна без ограничений. При использовании с родительскими доменами длиной более 100 байтов протокол рискует превысить максимально возможную длину доменных имен, что приведет к сбоям. В этом случае тщательный выбор коротких имен <servicedomain> может помочь избежать переполнения. Если <servicedomain> и <parentdomain> являются слишком длинными, то экземпляры службы с длинными именами экземпляров не будут обнаруживаемыми или разрешаемыми, и приложения, использующие длинные имена подтипов, могут завершиться ошибкой.

Из-за этого ограничения мы решили ограничить имена служб до 15 символов или менее. Разрешение большего количества символов не увеличит выразительную силу протокола и излишне уменьшит максимальную длину <parentdomain>, которую можно безопасно использовать.

Обратите внимание, что длины имен <Instance> влияют на максимальное количество сервисов данного типа, которое может быть обнаружено в данном <servicedomain>. Наибольший ответ Unicast DNS, который может быть отправлен (обычно с использованием TCP, а не UDP), составляет 64 КБ. При использовании сжатия имен DNS запись PTR перечисления экземпляра службы требует 2 байта для (сжатого) имени, плюс 10 байтов для типа, класса, длины ttl и rdata. Для данных записи PTR требуется до 64 байтов для части имени <Instance>, плюс 2 байта для указателя сжатия имени на общий суффикс, что составляет максимум 78 байтов. Это означает, что с помощью имен <Instance> максимального размера в данном <servicedomain> может быть обнаружено до 839 экземпляров данного типа сервиса.

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

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

 

8. Флагманское Наименование

В некоторых случаях может быть доступно несколько сетевых протоколов, которые выполняют примерно одну и ту же логическую функцию. Например, в мире печати существуют протокол линейной печати (LPR) [RFC1179] и протокол печати через Интернет (IPP) [RFC2910], которые приводят к тому, что отпечатанные листы выводятся из принтеров практически одинаково. Кроме того, многие поставщики принтеров отправляют свои собственные проприетарные данные языка описания страниц (PDL) по TCP-соединению на TCP-порт 9100, который в данном документе обычно называется протоколом «pdl-datastream». В идеальном мире у нас был бы только один протокол сетевой печати, и было бы достаточно хорошо, чтобы никто не чувствовал острой необходимости изобретать другой. Однако на практике существует несколько унаследованных протоколов, и протокол обнаружения услуг должен учитывать это.

Многие принтеры реализуют все три протокола печати: LPR, IPP и pdl-datastream. В интересах клиентов, которые могут говорить только по одному из этих протоколов, все три рекламируются.

Однако некоторые клиенты могут реализовать два или все три из этих протоколов печати. Когда клиент ищет все три типа услуг в сети, он обнаруживает три различных сервиса — сервис LPR, сервис IPP и сервис pdl-datastream — все из них вызывают отправку печатных листов из одного физического принтер.

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

Как описано выше, все это работает очень хорошо. Однако рассмотрим случай: какой-нибудь будущий принтер, который поддерживает только печать IPP, и некоторый другой будущий принтер, который поддерживает только печать pdl-datastream.

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

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

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

Примечание. При использовании с многоадресной DNS [RFC6762] целевое поле хоста записи SRV-заполнителя НЕ ДОЛЖНО быть пустой корневой меткой. Запись SRV должна содержать реальное имя целевого хоста, чтобы могли работать правила обнаружения конфликтов многоадресной DNS. Если бы два разных устройства должны были создавать записи SRV-заполнителей, использующие нулевое целевое имя хоста (только корневую метку), то эти две записи SRV будут рассматриваться как согласованные, и конфликт не будет обнаружен.

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

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

9. Перечисление типов услуг

В общем, обычный клиент не заинтересован в поиске * всех * сервисов в сети, а просто сервисов, которые клиент знает, как использовать.

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

Для этого определен специальный мета-запрос. Запрос DNS для записей PTR с именем «_services._dns-sd._udp. <Domain>» выдает набор записей PTR, где rdata каждой записи PTR — это имя с двумя именами <Service> плюс тот же домен, например , «_http._tcp. <Домен>». Включение домена в данные PTR позволяет немного улучшить сжатие имен в одноадресных ответах DNS, но только первые две метки имеют отношение к перечислению типов услуг. Эти типы обслуживания с двумя метками могут затем использоваться для создания последующих запросов PTR перечисления экземпляров службы, в этом <Domain> или других, для обнаружения экземпляров этого типа службы.

10. Заполнение DNS информацией

То, как записи PTR, SRV и TXT службы попадают в DNS, выходит за рамки этого документа, но для иллюстрации приводятся некоторые примеры.
В некоторых сетях администратор может вручную ввести записи в файл конфигурации сервера имен.

Средство мониторинга сети может вывести стандартный файл зоны для чтения на обычный DNS-сервер. Например, инструмент, который может находить сетевые лазерные принтеры PostScript с помощью AppleTalk NBP, может находить список принтеров, связываться с каждым из них, чтобы узнать его IP-адрес, версию PostScript, установленные параметры и т. Д., А затем записывать файл зоны DNS, описывающий эти принтеры и их возможности с использованием записей ресурсов DNS. Затем эта информация будет доступна клиентам, использующим только IP, которые реализуют DNS-SD, но не AppleTalk NBP.

Устройство диспетчера принтеров, которое знает о принтерах в сети через некоторый другой протокол управления, также может выводить файл зоны или использовать обновление DNS [RFC2136] [RFC3007].

В качестве альтернативы, устройство управления принтером может реализовать достаточно протокола DNS, чтобы оно могло отвечать на запросы DNS напрямую, а главный DNS-сервер Example Co. мог делегировать «_ipp._tcp.example.com». субдомен к диспетчеру принтера.

IP-принтеры могут использовать динамическое обновление DNS [RFC2136] [RFC3007] для автоматической регистрации своих собственных записей PTR, SRV и TXT на DNS-сервере.

Принтеры Zeroconf отвечают на многоадресные DNS-запросы по локальной ссылке для своих собственных имен PTR, SRV и TXT, заканчивающихся на «.local». [RFC6762].

11. Обнаружение просмотра и регистрации доменов (перечисление доменов)

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

Это обнаружение выполняется с использованием DNS-запросов, с использованием Unicast или Multicast DNS. Для этого зарезервировано пять специальных имен RR:

b._dns-sd._udp.<domain>.
db._dns-sd._udp.<domain>.
r._dns-sd._udp.<domain>.
dr._dns-sd._udp.<domain>.
lb._dns-sd._udp.<domain>.

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

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

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

Часть <domain> имени запроса перечисления доменов может быть «локальной». (что означает «выполнить запрос с использованием многоадресной рассылки локальной ссылки») или его можно узнать с помощью другого механизма, такого как опция DHCP «Домен» (код опции 15) [RFC2132], опция DHCP «Поиск домена» (код опции 119) [RFC3397] или Опции объявления маршрутизатора IPv6 [RFC6106].

Часть <domain> имени запроса также может быть получена не так, как IP-адрес хоста. Хост берет свой IP-адрес и вычисляет логическое И этого адреса и свою маску подсети, чтобы получить «базовый» адрес подсети («сетевой адрес» этой подсети или, что эквивалентно, IP-адрес «всех»). -зеро ‘адрес хоста в этой подсети). Затем он создает обычное DNS-имя «обратного сопоставления», соответствующее этому базовому адресу, и использует его в качестве части <domain> имени для запросов, описанных выше. Например, если хост имеет адрес 192.168.12.34 с маской подсети 255.255.0.0, тогда «базовым» адресом подсети является 192.168.0.0, и для обнаружения рекомендованных доменов автоматического просмотра для устройств на этом В подсети хост выдает DNS-запрос PTR на имя «lb._dns-sd._udp.0.0.168.192.in-addr.arpa».

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

Полученные из адресов запросы Перечисления доменов НЕ ДОЛЖНЫ выполняться для локальных адресов каналов IPv4 [RFC3927] или локальных адресов каналов IPv6 [RFC4862].

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

12. Генерация дополнительных записей DNS

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

В этом разделе рекомендуется, какие дополнительные записи СЛЕДУЕТ генерировать для повышения эффективности сети, как для ответов Unicast, так и Multicast DNS-SD.

Обратите внимание, что хотя серверам СЛЕДУЕТ добавлять эти дополнительные записи для повышения эффективности, как и для всех дополнительных записей DNS, клиент несет ответственность за определение того, доверять им или нет.

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

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

12.1. PTR Records

При включении записи PTR перечисления экземпляра службы DNS-SD или выборочного перечисления экземпляра (подтипа) в пакет ответа сервер / респондент ДОЛЖНЫ включать следующие дополнительные записи:

• Записи SRV, названные в данных PTR.
• Запись TXT, указанная в данных PTR.
• Все записи адресов (типа «A» и «AAAA»), названные в SRV rdata.

12.2. SRV Records

При включении записи SRV в пакет ответа, сервер / ответчик ДОЛЖЕН включать следующие дополнительные записи:

• Все записи адресов (типа «A» и «AAAA»), названные в SRV rdata.

12.3. TXT Records

При включении записи TXT в пакет ответа никаких дополнительных записей не требуется.

12.4. Другие типы записей

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

13. Рабочие примеры

Следующие примеры были подготовлены с использованием стандартного неизмененного nslookup и стандартного неизмененного BIND, работающего на GNU / Linux.

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

13.1. Какие веб-страницы рекламируются на dns-sd.org?

nslookup -q=ptr _http._tcp.dns-sd.org.
_http._tcp.dns-sd.org
name = Zeroconf._http._tcp.dns-sd.org
_http._tcp.dns-sd.org
name = Multicast\032DNS._http._tcp.dns-sd.org
_http._tcp.dns-sd.org
name = Service\032Discovery._http._tcp.dns-sd.org
_http._tcp.dns-sd.org
name = Stuart’s\032Printer._http._tcp.dns-sd.org

Ответ: их четыре: «Zeroconf», «Multicast DNS», «Service Discovery» и «Stuart’s Printer».

Обратите внимание, что nslookup экранирует пробелы как «\ 032» для целей отображения, но графический браузер DNS-SD не должен.

13.2. Какие веб-страницы конфигурации принтера существуют?

nslookup -q=ptr _printer._sub._http._tcp.dns-sd.org.
_printer._sub._http._tcp.dns-sd.org
name = Stuart’s\032Printer._http._tcp.dns-sd.org

Ответ: «Принтер Стюарта» — это пользовательский веб-интерфейс сетевого принтера.

13.3. Как получить доступ к веб-странице под названием «Обнаружение служб»?

nslookup -q=any «Service\032Discovery._http._tcp.dns-sd.org.»
Service\032Discovery._http._tcp.dns-sd.org
priority = 0, weight = 0, port = 80, host = dns-sd.org
Service\032Discovery._http._tcp.dns-sd.org
text = «txtvers=1» «path=/»
dns-sd.org nameserver = ns1.dns-sd.org
dns-sd.org internet address = 64.142.82.154
ns1.dns-sd.org internet address = 64.142.82.152

Ответ: Вам необходимо подключиться к порту 80 dns-sd.org, путь «/». Также указан адрес dns-sd.org (64.142.82.154).

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

IPv6 имеет только незначительные отличия от IPv4.

Адрес целевого хоста записи SRV задается соответствующими адресными записями IPv6 «AAAA» вместо (или в дополнение к) IPv4 «A» записей.

Запросы перечисления доменов на основе адресов выполняются с использованием имен в дереве обратного сопоставления IPv6, которое отличается от дерева обратного сопоставления IPv4 и содержит более длинные имена.

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

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

Для запросов DNS следует использовать расширения безопасности DNS (DNSSEC) [RFC4033], если важна достоверность информации.

Для обновлений DNS обычно следует использовать защищенные обновления [RFC2136] [RFC3007], чтобы контролировать, какие клиенты имеют разрешение на обновление записей DNS.

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

IANA управляет пространством имен уникальных сервисных имен [RFC6335].

Когда спецификация рекламы службы протокола включает в себя подтипы, они должны быть задокументированы в соответствующей спецификации протокола и / или в поле «примечания» запроса на регистрацию, отправленного в IANA. Если новый подтип становится релевантным после публикации спецификации протокола, это можно записать, запросив IANA добавить его в поле «примечания». Например, производители сетевых принтеров рекламируют свои встроенные веб-серверы, используя подтип _printer. Это позволяет клиентам управления принтером просматривать только веб-серверы, связанные с принтером, путем поиска подтипа _printer. Хотя существование подтипа _printer _http._tcp не имеет прямого отношения к спецификации протокола HTTP, полезно зарегистрировать это использование в реестре IANA, чтобы избежать непреднамеренного использования другим сообществом разработчиков той же строки подтипа для другой цели. Пространство имен возможных подтипов является отдельным для каждого отдельного типа сервиса. Например, существование подтипа _printer _http._tcp не означает, что подтип _printer определен или имеет какое-либо значение для любого другого типа сервиса.

Когда IANA записывает регистрацию имени службы, если новый протокол приложения является тем, который концептуально дублирует существующую функциональность более старого протокола, и разработчики желают использовать флагманское именование, описанное в разделе 8, тогда регистрант должен запросить, чтобы IANA записала имя Флагманский протокол в поле «Примечания» новой регистрации. Например, регистрации для «ipp» и «pdl-datastream» ссылаются на «принтер» в качестве флагманского имени для этого семейства протоколов, связанных с печатью.

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

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

18. Ссылки

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

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

[RFC1033] Lottor, M., «Domain Administrators Operations Guide», RFC 1033, November 1987.

[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.

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2782, February 2000.

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

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

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

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

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

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

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, «Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry», BCP 165, RFC 6335, August 2011.

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

[AFP] Mac OS X Developer Library, «Apple Filing Protocol Programming Guide», <http://developer.apple.com/documentation/Networking/Conceptual/AFP/>.

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

[BJP] Bonjour Printing Specification, <https://developer.apple.com/bonjour/printing-specification/bonjourprinting-1.0.2.pdf>.

[IEEEW] IEEE 802 LAN/MAN Standards Committee, <http://standards.ieee.org/wireless/>.

[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>.

[RFC1179] McLaughlin, L., «Line printer daemon protocol», RFC 1179, August 1990.

[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.

[RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and J. Wenn, «Internet Printing Protocol/1.1: Encoding and Transport», RFC 2910, September 2000.

[RFC4960] Stewart, R., Ed., «Stream Control Transmission Protocol», RFC 4960, September 2007.

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

[RFC4340] Kohler, E., Handley, M., and S. Floyd, «Datagram Congestion Control Protocol (DCCP)», RFC 4340, March 2006.

[RFC3397] Aboba, B. and S. Cheshire, «Dynamic Host Configuration Protocol (DHCP) Domain Search Option», RFC 3397, November 2002.

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

[RFC4648] Josefsson, S., «The Base16, Base32, and Base64 Data Encodings», RFC 4648, October 2006.

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

[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, «IPv6 Router Advertisement Options for DNS Configuration», RFC 6106, November 2010.

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

[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, «Design Considerations for Protocol Extensions», RFC 6709, September 2012.

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

[RFC6762] Cheshire, S. and M. Krochmal, «Multicast DNS», RFC 6762, February 2013.

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

[SOAP] Mitra, N., «SOAP Version 1.2 Part 0: Primer», W3C Proposed Recommendation 24 June 2003, <http://www.w3.org/TR/2003/REC-soap12-part0-20030624>.

[Unicode6] The Unicode Consortium. The Unicode Standard, Version 6.0.0, (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6)
<http://www.unicode.org/versions/Unicode6.0.0/>.

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

Приложение А. Обоснование использования DNS в качестве основы для обнаружения служб

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

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

Для специальных сетей, таких как среды Zeroconf, подходят одноранговые многоадресные протоколы. Использование DNS-SD для многоадресной DNS [RFC6762] обеспечивает обнаружение специальных служб с нулевой конфигурацией, сохраняя семантику DNS-SD и типы записей, описанные здесь.

В более крупных сетях большой объем многоадресного IP-трафика в масштабах предприятия может быть нежелательным, поэтому любой надежный протокол обнаружения служб, предназначенный для более крупных сетей, должен обеспечивать некоторые средства для агрегирования регистраций и поисков на центральном сервере (или серверах) вместо того, чтобы работать исключительно с использованием многоадресной рассылки. Это требует написания, отладки, развертывания и обслуживания некоторого программного обеспечения сервера агрегации обнаружения служб. Это также требует, чтобы некоторый протокол регистрации обнаружения службы был внедрен и развернут для клиентов, чтобы зарегистрироваться на центральном сервере агрегации. Практически каждая компания с IP-сетью уже использует DNS-сервер, а DNS уже имеет протокол динамической регистрации [RFC2136] [RFC3007]. Учитывая, что практически каждая компания уже в любом случае должна эксплуатировать и поддерживать DNS-сервер, имеет смысл воспользоваться этим опытом, вместо того чтобы изучать, эксплуатировать и поддерживать другой сервер регистрации сервисов. Следует еще раз подчеркнуть, что использование одного и того же программного обеспечения и протоколов не обязательно означает использование одного и того же физического оборудования. Функции обнаружения службы DNS-SD не обязательно должны предоставляться тем же оборудованием, которое в настоящее время предоставляет службу имен DNS компании. Субдомены «_tcp. <Domain>» и «_udp. <Domain>» могут быть делегированы другому оборудованию. Тем не менее, даже если служба DNS-SD предоставляется другим аппаратным обеспечением, это все равно такое же знакомое программное обеспечение DNS-сервера, с тем же синтаксисом файла конфигурации, тем же форматом файла журнала и т. д.

Обнаружение службы должно быть в состоянии обеспечить соответствующую безопасность. DNS уже имеет существующие механизмы безопасности [RFC4033].

В итоге:

• Для обнаружения службы требуется центральный агрегирующий сервер. У DNS уже есть один: DNS-сервер.
• Обнаружение службы требует протокола регистрации службы. DNS уже имеет один: динамическое обновление DNS.
• Обнаружение службы требует протокола запроса. DNS уже имеет один: запросы DNS.
• Обнаружение службы требует механизмов безопасности. DNS уже имеет механизмы безопасности: DNSSEC.
• Обнаружение службы требует многоадресного режима для специальных сетей. Использование DNS-SD в сочетании с Multicast DNS обеспечивает это, используя одноранговую многоадресную рассылку вместо DNS-сервера.

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

Приложение B. Заказ компонентов имени экземпляра сервиса

Были вопросы о том, почему службы именуются с помощью имен экземпляров служб DNS в форме:

Имя экземпляра службы = <Экземпляр>. <Сервис>. <Домен>

Service Instance Name = <Instance> . <Service> . <Domain>

вместо:

Имя экземпляра службы = <Сервис>. <Экземпляр>. <Домен>

Service Instance Name = <Service> . <Instance> . <Domain>

Существует три причины, по которым полезно указывать экземпляры службы имен с родительским доменом в качестве наиболее значимой (самой правой) части имени, затем абстрактный тип службы в качестве следующего наиболее значимого и затем конкретное имя экземпляра в качестве наименее значимого (самая левая) часть имени. Эти причины обсуждаются ниже в разделах B.1, B.2 и B.3.

B.1. Семантическая структура

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

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

Следовательно, наличие имен экземпляров в виде листьев дерева согласуется с этой семантической моделью.

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

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

Когда ответ DNS содержит несколько ответов, сжатие имен работает более эффективно, если все имена содержат общий суффикс. Если многие ответы в пакете имеют одинаковые <Service> и <Domain>, то каждое вхождение имени экземпляра службы может быть выражено с использованием только части <Instance>, за которой следует двухбайтовый указатель сжатия, ссылающийся на предыдущее появление «< Сервис>. <домен>». Эта эффективность была бы невозможна, если бы компонент <Service> появился первым в каждом имени.

В.3. Операционная гибкость

Эта структура имени позволяет делегировать субдомены вдоль логических границ сервиса. Например, сетевой администратор в Example Co. может выбрать делегирование «_tcp.example.com». субдомен к другой машине, так что машина, обрабатывающая обнаружение службы, не обязательно должна быть машиной, которая выполняет другие повседневные операции DNS. (Это может быть тот же компьютер, если администратор этого захочет, но администратор может сделать этот выбор.) Более того, если сетевой администратор желает делегировать всю информацию, связанную с принтерами IPP, машине, предназначенной для этой конкретной задачи, это легко сделать, делегировав «_ipp._tcp.example.com». поддомен для нужной машины. Также удобно устанавливать политики безопасности для каждой зоны / субдомена. Например, администратор может включить динамическое обновление DNS [RFC2136] [RFC3007] для принтеров, зарегистрированных на «_ipp._tcp.example.com». поддомен, но не для других зон / поддоменов. Эта легкая гибкость не существовала бы, если бы компонент <Service> появлялся первым в каждом имени.

Приложение C. То, что вы видите, это то, что вы получаете

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

Проблема с этим подходом состоит в том, что он отделяет восприятие пользователя от сетевой реальности:

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

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

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

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

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

Приложение D. Выбор заводских имен по умолчанию

Когда служба DNS-SD объявляется с использованием многоадресной DNS [RFC6762], если уже существует другая служба того же типа, рекламирующаяся с таким же именем, то произойдет автоматическое разрешение конфликта имен. Как описано в спецификации многоадресной DNS [RFC6762], при обнаружении конфликта служба должна:

1. Автоматически выберите новое имя (как правило, добавляя или увеличивая цифру в конце имени),
2. Попробуйте рекламу с новым именем, и
3. В случае успеха запишите новое имя в постоянное хранилище.

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

Некоторые примеры хороших имен по умолчанию:

Brother 5070N
Canon W2200
HP LaserJet 4600
Lexmark W840
Okidata C5300
Ricoh Aficio CL7100
Xerox Phaser 6200DX

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

(a) В случае, когда у пользователя есть только один сетевой принтер, простое имя, например (для использования независимого от поставщика примера), «Принтер» более удобно для пользователя, чем уродливое имя, такое как «Printer_0001E68C74FB». Добавление уродливого шестнадцатеричного цикла в конец имени, чтобы убедиться, что имя уникально, не имеет значения для пользователя, который в любом случае имеет только один принтер.

(b) В случае, когда пользователь получает второй сетевой принтер, новый принтер обнаруживает, что имя «Принтер» уже используется и вместо этого автоматически называет себя «Принтер (2)», обеспечивает хороший пользовательский опыт. Для большинства пользователей запомнить, что старый принтер — это «Принтер», а новый — «Принтер (2)», легко и интуитивно понятно. Просмотр принтера с именем «Printer_0001E68C74FB» и другого принтера с именем «Printer_00306EC3FD1C» намного менее полезен.

(c) В случае сети с десятью сетевыми принтерами при просмотре списка из десяти имен вся форма «Printer_xxxxxxxxxxxx» фактически взяла то, что должно было быть списком удобных для пользователя имен расширенного текста (с поддержкой смешанного регистра, пробелов, знаки препинания, нелатинские символы и другие символы) и превратили его в самый худший из представленных пользовательских интерфейсов: список непонятных случайных строк букв и цифр. В сети с большим количеством принтеров было бы целесообразно, чтобы люди, настраивающие принтеры, уделили время, чтобы дать каждому из них описательное имя, но в случае, если они этого не делают, предоставляя пользователям список последовательно пронумерованных Принтеры — намного более желательный пользовательский интерфейс по умолчанию, чем показ списка необработанных адресов Ethernet.

Приложение E. Кодировки имен в системе доменных имен

Хотя исходные спецификации DNS [RFC1033] [RFC1034] [RFC1035] рекомендуют, чтобы имена хостов содержали только буквы, цифры и дефисы (из-за ограничений пользовательских интерфейсов, основанных на типизации той эпохи), имена экземпляров служб не являются именами хостов. , Пользователи обычно получают доступ к сервису, выбирая его из списка, представленного пользовательским интерфейсом, а не вводя его имя экземпляра сервиса. «Разъяснения к спецификации DNS» [RFC2181] непосредственно обсуждает тему допустимого набора символов в Разделе 11 («Синтаксис имени») и прямо заявляет, что традиционное правило букв-цифр-символов применяется только к обычным именам хостов:

• Иногда предполагается, что система доменных имен служит только для сопоставления имен узлов Интернета с данными и сопоставления адресов Интернета с именами узлов. Это неверно, DNS является общей (хотя и несколько ограниченной) иерархической базой данных и может хранить практически любые данные практически для любых целей.
• Сам DNS накладывает только одно ограничение на конкретные метки, которые можно использовать для идентификации записей ресурсов. Это одно ограничение относится к длине этикетки и полному имени. Длина любой метки ограничена от 1 до 63 октетов. Полное доменное имя ограничено 255 октетами (включая разделители). Полное имя нулевой длины определяется как представляющий корень дерева DNS, и обычно записывается и отображается как «.». Помимо этих ограничений, любая двоичная строка может использоваться в качестве метки любой записи ресурса. Точно так же любая двоичная строка может служить значением любой записи, которая включает в себя доменное имя как часть или все его значения (SOA, NS, MX, PTR, CNAME и любые другие, которые могут быть добавлены). Реализации протоколов DNS не должны накладывать каких-либо ограничений на метки, которые можно использовать. В частности, DNS-серверы не должны отказываться обслуживать зону, поскольку она содержит метки, которые могут быть неприемлемы для некоторых клиентских программ DNS.

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

Приложение F. Модель просмотра «Непрерывное прямое обновление»

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

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

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

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

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

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

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

1. Отображение начального списка обнаруженных сервисов должно быть практически мгновенным, то есть обычно 0,1 секунды, а не 10 секунд.
2. Список обнаруженных сервисов не должен становиться устаревшим и устаревшим с момента его отображения. Список должен быть «живым» и должен обновляться по мере обнаружения новых служб. Из-за задержек, потерь пакетов и повторных передач, присущих сетевым технологиям, следует ожидать, что иногда, после отображения начального списка, отображающего большинство обнаруженных сервисов, несколько оставшихся отставших могут продолжать поступать в течение последующих нескольких секунд. Даже после того, как этот стабильный список будет создан и отображен, он должен оставаться «живым» и продолжать обновляться. В любое время, будь то минуты, часы или даже дни спустя, если будет обнаружена новая служба нужного типа, она должна автоматически отображаться в списке без необходимости нажимать кнопку «обновить» или выполнять какие-либо действия. другое явное действие для обновления дисплея.
3. Поскольку у пользователей появляется привычка оставлять открытыми окна обнаружения служб и ожидать, что они будут непрерывно отображать текущую сетевую реальность, это дает нам дополнительное требование: удаление устаревших служб. Когда в списке обнаружения служб в определенный момент времени отображается только статический моментальный снимок, ситуация проста: либо служба была обнаружена и появилась в списке, либо ее не было и нет. Однако, когда наш список активен и постоянно обновляется с обнаружением новых сервисов, это подразумевает следствие: когда сервис уходит, он должен * исчезнуть * из списка обнаружения сервисов. В противном случае список обнаружения услуг будет просто монотонно расти со временем, накапливая устаревшие данные, и потребует периодического «обновления» (или полного удаления и восстановления) для восстановления правильного отображения.
4. Еще одним следствием того, что пользователи оставляют окна обнаружения служб открытыми в течение продолжительных периодов времени, является то, что эти окна должны обновляться не только в ответ на приход и уход служб, но также в ответ на изменения в конфигурации и подключении самого клиентского компьютера. Например, если пользователь открывает окно обнаружения службы, когда клиентский компьютер не имеет сетевого подключения, то окно обычно будет выглядеть пустым, без обнаруженных служб. Когда пользователь подключает кабель Ethernet или присоединяется к беспроводной сети 802.11 [IEEEW], окно должно автоматически заполняться обнаруженными службами, не требуя каких-либо явных действий пользователя. Если пользователь отключает кабель Ethernet или отключает беспроводную связь 802.11, все службы, обнаруженные через этот сетевой интерфейс, должны автоматически исчезать. Если пользователь переключается с одной беспроводной точки доступа 802.11 на другую, окно обнаружения служб должно автоматически обновляться, чтобы удалить все службы, обнаруженные через старую точку беспроводного доступа, и добавить все службы, обнаруженные через новую.

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

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

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

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