Zeroconf

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

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

В истории развития сетей протоколы делились на локальные (LAN), где требовалось минимальное вмешательство для добавления новых устройств, и глобальные (WAN), где адреса и имена зачастую назначались вручную администратором. Примером ранней системы с нулевой конфигурацией выступает AppleTalk, представленный компанией Apple Inc. для компьютеров Macintosh в 1980-х годах. Устройства с поддержкой AppleTalk подключались к сети простым включением — все настройки происходили автоматически: адреса назначались через AppleTalk Address Resolution Protocol (AARP), локальный каталог формировался с использованием Name Binding Protocol (NBP), включавшего в себе имя устройства, тип и дополнительные характеристики. Пользовательский поиск происходил через приложение Chooser.

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

Каждому узлу сети необходимо присвоить уникальный IP-адрес, чтобы он мог взаимодействовать с другими устройствами. В ряде случаев адреса раздаёт центральный сервер, но для автоматизации этой задачи как в IPv4, так и в IPv6 предусмотрены механизмы автоконфигурации адресов. Например, для link-local адресации IPv4 используется диапазон , а для IPv6 — префикс . Чаще адреса выдаёт DHCP-сервер, встроенный в роутеры или хосты.

Для большинства устройств на IPv4 link-local адресация применяется как запасной вариант при недоступности DHCP. Обычно IPv4-узлы используют DHCP-адрес для любых коммуникаций. Это связано с тем, что IPv4 не требует поддерживать множественные адреса на одном интерфейсе, хотя некоторые реализации это позволяют. Кроме того, не все IPv4-устройства поддерживают распределённое разрешение имён, затрудняя нахождение автоматически выданных адресов. Некоторые сети используют DNS-серверы с автоматическим обновлением, получая сведения о хостах и адресах от DHCP.

В IPv6 поддержка нескольких адресов на интерфейс обязательна. Более того, каждый IPv6-узел должен иметь link-local адрес даже при наличии глобального. Дополнительно IPv6 может самостоятельно конфигурировать адреса по сообщениям router advertisement, что устраняет необходимость в DHCP-сервере.

В обоих случаях устройства могут случайным образом генерировать уникальную часть автоматического адреса. Для IPv6 это обычно комбинация префикса и 64 бит, производимых из глобального MAC-адреса по схеме EUI-64. В протоколе IPv6 реализован механизм обнаружения конфликтов адресов. В IPv4 эту процедуру называют автоматическая настройка link-local-адресов. Microsoft использует для неё термин APIPA^[1] или Автоматическая конфигурация интеренет-протокола (IPAC). В Windows функция поддерживается начиная с Windows 98^[2].

IP-протоколы используют адреса для коммуникаций, но они неудобны для человека, особенно в IPv6, где адреса длинные и сложны для запоминания и ввода. Для решения этой проблемы используется DNS, позволяющая сопоставлять доменное имя в человекочитаемом виде с IP-адресом. Программное обеспечение ищет IP-адрес по имени через иерархическую базу DNS^[3].

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

DNS предназначена для поддержания единой системы имён для устройств внутри одной административной области — например, имя printer.example.org назначается вручную с административным доступом. При изменении конфигурации оборудование, например сетевые принтеры, часто требует ручного управления записями DNS при изменении IP^[3].

Для автоматизации Microsoft внедрила NetBIOS Name Service, частью которого является Computer Browser Service, функционирующая ещё в Windows for Workgroups 3.11^[4] — с 1992 года. На сетях с одной подсетью NetBIOS Name Service работает в нулевой конфигурации, также возможна интеграция с WINS или DNS-сервером, поддерживающим автоматическую регистрацию. Протоколы NetBIOS входят в семейство SMB, которые доступны и для Linux/iOS, но Windows поддерживает больше вариантов (диалектов) реализации. Например, служба Computer Browser на серверных ОС Windows избирается главным master browser для координации^[4]

В 2000 году Билл Мэннинг и Билл Вудкок предложили Multicast Domain Name Service^[5]., породивший реализации от Apple и Microsoft. Реализации схожи: Apple выпустила mDNS (), Microsoft — LLMNR (), стандартно поддерживаемый Windows начиная с Vista^[6] (служит альтернативой/заменой NetBIOS; в IPv6 NetBIOS не поддерживается). Реализация Bonjour с 2002 года является частью Mac OS X и доступна под лицензией Apache 2; она применяется в Android Jelly Bean и новее^[7][8].

Использование NetBIOS или LLMNR на Windows полностью автоматизировано: стандартные API клиента DNS сами выбирают нужную службу по имени, настройке и корпоративной политике, однако разработчик может явно обойти их для отдельных запросов.

mDNS и LLMNR различаются деталями разрешения имён. mDNS позволяет устройству выбирать доменное имя в зоне local и предъявлять его по специальному multicast-адресу, вводя отдельную роль домена .local^[9], что вызывает критику отдельных членов IETF^[10]. В LLMNR устройство может выбрать любое доменное имя, но это создаёт риски для безопасности^[11]. mDNS совместим с DNS-SD, тогда как LLMNR — нет^[12].

Такие службы, как mDNS и LLMNR, не предоставляют информацию о типе устройства. Например, появление принтера с именем Bob не говорит пользователю о типе сервиса. Обнаружение сервисов (service discovery) предоставляет дополнительные сведения и может быть интегрировано с системой имён (например, Name Binding Protocol от Apple, NetBIOS от Microsoft).

NetBIOS позволяет устройствам объявлять о своих сервисах — файловых ресурсах, принтерах. Принтер, подключённый к сети напрямую или через хост, также может транслировать свои сервисы таким образом. Клиенты Windows также поддерживают SSDP, WSD, и комбинируют эти протоколы через механизм function discovery, включающий встроенные провайдеры для PnP, реестра, NetBIOS, SSDP и WSD^[13]. Часто такая интеграция не требует какой-либо настройки на локальной подсети. Обычно NetBIOS поддерживается только корпоративными принтерами, однако некоторые недорогие модели с Wi-Fi или Ethernet реализуют его для поддержки даже с устаревшими ОС.

Web Services Dynamic Discovery (WS-Discovery) — спецификация для multicast-протокола поиска сервисов локальной сети. Использует порты TCP и UDP 3702 и IP multicast-адрес . Взаимодействие осуществляется по web-services-стандартам, включая SOAP-over-UDP. В Windows поддерживается через Web Services for Devices и Devices Profile for Web Services. Применяется, в частности, в принтерах HP и Brother.

DNS Service Discovery (DNS-SD)^[14] позволяет исчерпывающе получать список сервисов заданного типа и разрешать их имена через стандартные DNS-запросы. Она совместима с существующими серверами DNS (unicast) и системой mDNS, поддерживает автоматическую работу. Каждый экземпляр сервиса описывается записями типа SRV и TXT. Для обнаружения клиентов выполняется DNS-запрос PTR, отвечающий списком <Сервис>.<Домен> с соответствующей парой SRV/TXT. Затем разрешается A/AAAA-запись и происходит соединение.

Реестр типов сервисов ранее вёлся на DNS-SD.org^[14], теперь управляется IANA^[15].

В 1997 году Стюарт Чешир предложил адаптировать Name Binding Protocol Apple для IP-сетей для гибкого обнаружения сервисов^[16]. Позднее он присоединился к Apple, разработал черновики IETF для mDNS и DNS-SD, обеспечив переход с AppleTalk на IP. В 2002 году компания анонсировала реализацию — Rendezvous (позже переименованную в Bonjour), впервые включённую в Mac OS X 10.2, где заменила Service Location Protocol (SLP). В 2013 году спецификации стали стандартами.

mDNS использует структуру DNS-запросов, но посылает их по multicast на порт 5353 и адрес (IPv4) или (IPv6); хосты отвечают на запросы к своему .local имени (A/AAAA/CNAME). Запрос имени приводит к ответу владельца записи. DNS-SD-запросы также могут отправляться через mDNS, что обеспечивает нулевую конфигурацию. Для объявления сервисов используются записи PTR, SRV, TXT.

DNS-SD реализован в устройствах Apple, большинстве сетевых принтеров, многочисленных Linux-дистрибутивах (Debian, Ubuntu^[17]) и сторонних продуктах. В macOS через DNS-SD работают Safari, iChat, Messages и другие приложения, в Windows 10 поддержка доступна в JavaScript-приложениях^[18]; большинство клиентов мгновенных сообщений и VoIP также используют DNS-SD. В ряде Unix/BSD/Linux-дистрибутивов включён Avahi.

В стандарте UPnP реализованы протоколы для обнаружения сервисов.

SSDP — протокол в составе UPnP c HTTP-уведомлениями: содержат тип сервиса (URI) и уникальное имя USN. Реестр типов сервисов поддерживается комитетом Universal Plug and Play. SSDP поддерживают принтеры, NAS и другая бытовая техника, роутеры SOHO-класса. В Windows используется с XP и новее.

DLNA — набор стандартов семейства UPnP для обнаружения устройств (ТВ, NAS и др.) и обмена медиа; поддерживается всеми крупными ОС. Поддержка Discovery реализована поверх SSDP.

SLP применяется к сетевым принтерам Hewlett-Packard, а также в Novell и Sun Microsystems; описан в и для Solaris и Linux.

AllJoyn — открытый стек для IoT и ПК, обеспечивающий обнаружение и управление устройствами по Wi-Fi, Ethernet, Bluetooth, ZigBee и др.; использует mDNS, HTTP over UDP и др. Прекращён с 2016 года и не рекомендуется к использованию для новых проектов^[19].

— протокол SLP для обнаружения сервисов, опубликован в июне 1999 года группой SVRLOC IETF[20].

— стандарт для автоматического выбора адреса, выпущен IETF в марте 2005 года рабочей группой Zeroconf с участием специалистов Apple, Sun, Microsoft[21].

LLMNR предлагался IETF DNSEXT, но стандартом не стал и в январе 2007 опубликован в виде информационного ^[22].

После отказа LLMNR становиться стандартом и с учётом широкого использования mDNS/DNS-SD, IETF поручил Apple оформить mDNS/DNS-SD как информационные RFC.

В феврале 2013 mDNS и DNS-SD утверждены как стандарты и .

mDNS использует модель доверия ко всей локальной сети, в отличие от обычного DNS, где доверяют только серверу, что открывает возможности для спуфинга любым участником одной broadcast-домены. Как и SNMP и другие протоколы управления, он может использоваться злоумышленниками для быстрого сбора информации о сети^[23]. Поэтому приложениям следует проводить аутентификацию и шифрование после обнаружения хоста через DNS-SD/mDNS (например, через RSA или SSH). Аналогичные уязвимости присущи LLMNR^[24].

Bonjour от Apple реализует mDNS и DNS-SD. Компания сменила предпочтительный протокол Zeroconf с SLP на mDNS/DNS-SD между Mac OS X 10.1 и 10.2, однако SLP всё ещё поддерживается.

mDNSResponder от Apple предоставляет интерфейсы для C и Java^[25], доступен для BSD, macOS, Linux, других POSIX-систем и Windows. Windows-версия распространяется на сайте Apple^[26].

Avahi — реализация Zeroconf для Linux и BSD, поддерживающая IPv4LL, mDNS и DNS-SD. Включена в большинство дистрибутивов Linux, на некоторых предустановлена. При использовании с nss-mdns обеспечивает разрешение имён^[27].

Avahi реализует совместимость на уровне бинарных библиотек для Bonjour и исторической реализации Howl, что позволяет сторонним приложениям использовать Avahi через совместимые интерфейсы.

Microsoft Windows CE 5.0 включает собственную реализацию LLMNR.

В systemd реализованы поддержка mDNS и LLMNR в компоненте systemd-resolved.

Если DHCP-сервис недоступен, хост выбирает link-local адрес самостоятельно и может общаться только внутри локальной сети (Internet недоступен). Существуют следующие реализации поддержки link-local IPv4:

• Mac OS и Windows поддерживают link-local с Windows 98 и Mac OS 8.5 (обе 1998 года выпуска). Открытая реализация Apple доступна в пакете Darwin bootp.
• Avahi содержит утилиту avahi-autoipd для IPv4LL.
• Zero-Conf IP (zcip)^[28]
• BusyBox включает упрощённую реализацию IPv4LL.
• Stablebox^[29] (форк BusyBox) реализует модифицированный IPv4LL под названием llad.
• Zeroconf^[30] — пакет на базе Simple IPv4LL, краткого варианта IPv4LL Артура ван Хоффа^[31].

Указанные реализации — самостоятельные демоны или плагины DHCP-клиентов, которые обеспечивают только link-local-адресацию. Другой вариант — интеграция поддержки напрямую в DHCP-клиенты:

• Патч Эльвиса Пфютценройтера для uDHCP client/server^[32].
• dhcpcd^[33] — открытый DHCP-клиент с поддержкой IPv4LL для Linux и BSD, включён по умолчанию в NetBSD.

Ни одна из реализаций не решает задачи на уровне ядра, такие как широковещательные отвечающие ARP или разрыв активных соединений^[34].