mDNS: протокол обнаружения служб в локальных сетях без DNS-сервера. Bonjour, Avahi, Windows 10 – реализация и применение. Zero-configuration networking.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Протокол обнаружения служб
Service discovery protocol
В компьютерных сетях протокол Multicast DNS (mDNS) преобразует имена хостов в IP-адреса в небольших сетях, не использующих локальный DNS-сервер. Это технология нулевой конфигурации, использующая те же программные интерфейсы, форматы пакетов и принципы работы, что и стандартная система доменных имен (DNS). Она разработана для работы как самостоятельно, так и в совместимости со стандартными DNS-серверами. mDNS использует IP-пакеты протокола User Datagram Protocol (UDP) с мультивещательной рассылкой и реализован в программных пакетах Apple Bonjour и Avahi с открытым исходным кодом, которые входят в большинство дистрибутивов Linux. Изначально реализация в Windows 10 ограничивалась обнаружением сетевых принтеров, но в последующих версиях появилась возможность разрешения имен хостов. mDNS может использоваться совместно с DNS Service Discovery (DNS SD) – другой технологией сетевой настройки нулевой конфигурации, описанной отдельно в .
In computer networking, the multicast DNS (mDNS) protocol resolves hostnames to IP addresses within small networks that do not include a local name server. It is a zero configuration service, using essentially the same programming interfaces, packet formats and operating semantics as unicast Domain Name System (DNS). It was designed to work as either a stand alone protocol or compatible with standard DNS servers. It uses IP multicast User Datagram Protocol (UDP) packets and is implemented by the Apple Bonjour and open source Avahi software packages, included in most Linux distributions. Although the Windows 10 implementation was limited to discovering networked printers, subsequent releases resolved hostnames as well. mDNS can work in conjunction with DNS Service Discovery (DNS SD), a companion zero configuration networking technique specified separately in .
История
Многоадресный DNS был впервые предложен Биллом Вудкоком и Биллом Мэннингом в IETF в 2000 году и опубликован как стандарт Стюартом Чеширом и Марком Крохмалом тринадцать лет спустя.
Multicast DNS was first proposed by Bill Woodcock and Bill Manning in the IETF in 2000, and was eventually published as standards track by Stuart Cheshire and Marc Krochmal thirteen years later.
Обзор протокола
Когда клиенту mDNS требуется разрешить имя хоста, он отправляет IP-многоадресный запрос, который просит хост с этим именем представиться. Целевой хост затем рассылает многоадресное сообщение, включающее его IP-адрес. Все хосты в этой подсети могут использовать эту информацию для обновления своих кэшей mDNS. Любой хост может отказаться от имени, отправив ответный пакет с временем жизни (TTL), равным нулю. По умолчанию mDNS разрешает только имена хостов, заканчивающиеся локальным доменом верхнего уровня. Это может вызывать проблемы, если локальная сеть включает хосты, не поддерживающие mDNS, но доступные через обычный одноадресный DNS-сервер. Разрешение таких конфликтов требует изменений в конфигурации сети, чего mDNS и была разработана, чтобы избежать.
When an mDNS client needs to resolve a hostname, it sends an IP multicast query message that asks the host having that name to identify itself. That target machine then multicasts a message that includes its IP address. All machines in that subnet can then use that information to update their mDNS caches. Any host can relinquish its claim to a name by sending a response packet with a time to live (TTL) equal to zero. By default, mDNS exclusively resolves hostnames ending with the local top level domain. This can cause problems if local includes hosts that do not implement mDNS but that can be found via a conventional unicast DNS server. Resolving such conflicts requires network configuration changes that mDNS was designed to avoid.
Вопросы
Формат представления данных для записей в разделе запросов немного отличается от формата в одноадресном DNS, добавляя однобитовое поле UNICAST RESPONSE. + mDNS Поля раздела запроса Поле Описание Длина (биты) QNAME Имя узла, к которому относится запрос Переменная QTYPE Тип запроса, то есть тип записи ресурса, который должен быть возвращен в ответах 16 UNICAST RESPONSE Булевский флаг, указывающий, требуется ли одноадресный ответ 1 QCLASS Код класса, 1, также известный как "IN" для Интернета и IP-сетей 15
The wire format for records in the query section is slightly modified from that in unicast DNS, adding the single bit UNICAST RESPONSE field. + mDNS Query section fields Field Description Length bits QNAME Name of the node to which the query pertains Variable QTYPE The type of the query, i. e. the type of Resource Record which should be returned in responses. 16 UNICAST RESPONSE Boolean flag indicating whether a unicast response is desired 1 QCLASS Class code, 1 a. k. a. "IN" for the Internet and IP networks 15
Как и в одноадресном DNS, поле QNAME состоит из серии подполей "длина/значение", называемых метками. Каждая метка представляет одну из подстрок, разделенных точками, в полностью квалифицированном доменном имени (FQDN). Список завершается либо одним нулевым байтом, представляющим корень DNS, либо байтом с установленными двумя старшими битами (значение 192), чтобы указать на косвенный указатель на другое место в сообщении. Это известно как сжатие имени в RFC 6762. Поле UNICAST RESPONSE используется для минимизации ненужных широковещательных рассылок в сети: если бит установлен, отвечающие узлы ДОЛЖНЫ отправлять направленный одноадресный ответ непосредственно запрашивающему узлу, а не транслировать ответ во всю сеть. Поле QCLASS идентично полю, используемому в одноадресном DNS.
As in unicast DNS, the QNAME field consists of a series of length/value sub fields called labels. Each label represents one of the dot separated substrings in a fully qualified domain name (FQDN). The list is terminated by either a single null byte representing the root of the DNS, or by a byte with the two high order bits set (value 192) to signal an indirect pointer to another location in the message. This is known as name compression in RFC 6762. The UNICAST RESPONSE field is used to minimize unnecessary broadcasts on the network: if the bit is set, responders SHOULD send a directed unicast response directly to the inquiring node rather than broadcasting the response to the entire network. The QCLASS field is identical to that found in unicast DNS.