Технически запрошенное/предыдущее поведение противоречит спецификации mDNS; поэтому поймите проблемы совместимости, которые представляют. Вам нужно будет либо использовать явные сопоставления, либо сторонние инструменты с Avahi, чтобы получить желаемый результат прямо сейчас.

Вы также можете использовать более старую версию nss-mdns, которая должна помочь (похоже, она разрешается хосту перед пересылкой в ​​Avahi, в последующих версиях, похоже, такая поддержка была удалена). Но это будет работать только для каждой системы, сконфигурированной таким образом, подробное объяснение см. ниже.

Вопреки спецификации

RFC 6762, раздел 3 — Многоадресные DNS-имена:

Этот документ позволяет любому пользователю компьютера выбрать для своих компьютеров локальные для ссылки имена хостов DNS многоадресной рассылки в форме: «single- метка DNS.local.». ... В этом документе рекомендуется единое плоское пространство имен для точечно-локальных имен хостов (т. е. имен записей DNS «A» и «AAAA», которые сопоставляют имена с адресами IPv4 и IPv6), но другие типы записей DNS (например, используемые DNS-Based Service Discovery [RFC6763]) может содержать столько меток, сколько необходимо для желаемого использования.

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

Windows не поддерживает это:

Мое единственное разочарование заключается в том, что реализация Bonjour/Avahi для Windows не поддерживает псевдонимы, которые объявляет эта реализация , он увидит только обычно объявляемое основное имя хоста avahi (например, server.local в нашем примере выше).

macOS не поддерживает это:

возвращает ошибку, если имя имеет более двух меток, как в случае foo.bar.local.

README для nss-mdns ссылается на некоторые правила, которые используются минимальными вариантами, чтобы решить, должны ли они быть отправлены в Avahi для обработки. Я наткнулся на этот комментарий в репозитории nss-mdns github, в котором указаны некоторые даты для контекста:

Эвристика предела с двумя метками была реализована в Mac OS X v10.5, выпущен 26 октября 2007 г. Эвристика одноадресной SOA была реализована в Mac OS X v10.6, выпущен 28 августа 2009 г.

Эти правила были представлены в выпуске 0.11 nss-mdns в начале 2018 г., немногим более десяти лет с тех пор, как предыдущий выпуск 0.10, соответствующее примечание в журнале изменений:

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

В вопросе AskUbuntu, на который вы ссылаетесь, говорится, что изменение было введено, возможно, из выпуска Ubuntu 18.10, что понятно, поскольку 18.04 был бы выпуском LTS, что снижает вероятность одобрения обновления.

Это показывает, что nss-mdns ранее не следовал этому из-за отсутствия обслуживания/обновлений в течение столь длительного времени, оба эти изменения Apple были добавлены после выпуска 0.10. из nss-mdns. Как поясняет соответствующая проблема github с логикой обратного поиска и недостатками/рисками, которые она вызывала.

Был давний отчет об ошибке, когда mdns передавал запросы для разрешения, которые блокировались до истечения времени ожидания, прежде чем вернуться к стандартному DNS, что по понятным причинам вызвало немало проблем для пользователей, особенно тех, кто взаимодействует с не-mdns .local Полные доменные имена из Microsoft Active Directory.

Чтобы вернуться к старому поведению, я думаю, вам может понадобиться вернуться к 0.10 из nss-mdns.

Еще одна проблема заключается в том, что в 2020 году, несмотря на то, что в Windows 10, как говорят, улучшается поддержка mDNS, в Android ее по-прежнему нет (помимо того, что разработчики явно настраивают ее в своих приложениях). Существуют обходные пути, такие как Unbound или CoreDNS, у которых есть плагины для переадресации одноадресного DNS-запроса на многоадресный,однако Avahi необходимо настроить так, чтобы хосты рекламировали опубликованный адрес, чтобы их можно было обнаружить.

Avahi и NSS

Переключатель службы имен (NSS) предназначен для вашей локальной системы для обработки поисковых запросов, здесь он может быть отложен до вашего /etc/hosts, локального DNS, systemd -разрешенный, mDNS и так далее. Большая часть вашего программного обеспечения будет использовать его, но это не всегда так, особенно с некоторыми утилитами, такими как host, dig, drill, nslookup, которые обходят это и запрашивают DNS напрямую.

Avahi не подчиняется NSS, а скорее NSS подчиняется Avahi через nss-mdns. Таким образом, это не имеет ничего общего с тем, как обрабатываются внешние запросы через другие устройства в сети. Вы можете тестировать запросы для Avahi без участия NSS, используя avahi-resolve --name myhostname.local --verbose.

Я считаю, что другие реализации mDNS могут быть более строгими/ограниченными в плане конфигурации, поэтому имейте в виду, что независимо от того, какие клиенты Windows и macOS, скорее всего, не будут работать, подобно тому, как они могут обрабатывать только .local TLD для mDNS.

Настройка Avahi для ответа не только на имя хоста

Вы можете настроить nss-mdns, чтобы разрешить разрешение дополнительных меток через /etc/mdns.allow (когда не используя минимальный вариант в строке /etc/nsswitch.conf hosts:). Без этого все, что использует NSS, скорее всего, вместо этого отправит одноадресный DNS-запрос, пропуская mDNS.

После настройки вам может потребоваться перезапустить любой процесс, чтобы он перезагрузил эту конфигурацию, или вы можете проверить это с помощью команды CLI, например ping. Хотя это позволяет ожидаемое поведение разрешения, вы заметите общий тайм-аут ответа в 5 секунд. Сам Avahi не может найти ответ на запрос, потому что ничего не настроено для ответа на это имя хоста.

Кроме того, файл /etc/avahi/avahi-daemon.conf не поддерживает . в значениях для имя хоста или имя домена, это для отдельных меток. Однако вы можете опубликовать явное сопоставление вручную с помощью avahi-publish:

avahi-publish -a -R test.hostname.local 192.168.1.42

И демон ответит на это, но не сообщит об обнаружении с помощью avahi-browse -a. Параметр -R важен, поскольку он позволит вам публиковать для одного и того же IP-адреса (в противном случае будет отображаться конфликт локальных имен). Кроме того, вы также можете определить их в /etc/avahi/hosts, где каждая строка представляет собой IP-адрес, за которым следует имя хоста (которое также может иметь . ), должно быть некоторое комментарии и примеры в существующем файле в этом месте. Файловый подход не имеет эквивалента опции -R для avahi-publish, поэтому указание IP-адреса, который уже сопоставлен с именем хоста, будет игнорироваться. avahi-daemon не требует перезагрузки при изменении этого файла hosts.

Обратите внимание, что для работы запросов без avahi-resolve вам потребуется NSS, настроенный на использование не-минимального варианта mdns, такого как mdns4, с областью действия IPv4 (в отличие от mdns, который также охватывает IPv6) также может привести к более быстрым результатам (в отличие от ожидания 5-секундного тайм-аута и последующего получения ответа IPv4, avahi-resolve тем не менее ответит незамедлительно). Вы также можете протестировать запросы, не изменяя /etc/nsswitch.conf с getent --service=mdns4 hosts test.hostname.local, измените --service значение на mdns4_minimal, mdns и т. д.

Avahi через D-Bus

Предоставление явных IP-адресов немного противоречит цели, но если устройство работает под управлением Avahi, вы должен иметь возможность отображать ряд меток/поддоменов для имени хоста через скрипт/программу, которая взаимодействует с Avahi через D-Bus API, например этот старый Python, они переместили свои фрагменты ответов в репозиторий Github, который имеет довольно много ответвлений, включая одно портирование на python3, если старый код не устарел. Для пользователей Docker подобное можно найти на DockerHub при поиске изображений avahi, я полагаю, что был один, который интегрировался с метками Traefik и docker для предоставления контейнеров через mDNS через Avahi.

Avahi для DNS-SD

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

Другой альтернативой, которая может работать, является динамический DNS (DDNS), который позволяет устройству обновлять запись DNS для своего IP-адреса.Есть также более сложное программное обеспечение для обнаружения сервисов, такое как Hashicorp Consul.