Чиним работу Avahi/Bonjour в локальной сети с собственным резолвером DNS

Apr 25, 2020 03:13

Крайне презабавную проблему недавно решил у себя. На полноценную статью не тянет. Так, заметка для младоадминов.

Долгое время было лень глянуть, с чего у меня в локальной сети крайне странно отдавались устройства с включённым Zeroconf (то есть с Avahi/Bonjour на борту). Особенность до кучи была в том, что Avahi по умолчанию работает с доменами .local, про что до сих пор не знают многие. Опытные админы уже явно приготовятся кидать в меня что-нибудь тяжёлое, но погодите возмущаться. Лучше загляните в RFC6762, который с 2013 года считается черновым, но уже крайне активно используется как известными вендорами, так и отдельными разработчиками (привет Леннарту Потеррингу, например). Более того, даннный псевдодомен первого уровня уже не рекомендовалсяк использованию в Windows Server 2003. Так что в настоящий момент данный TLD отдан под использование в сервисах mDNS.

Впрочем, отвлёкся. Итак, в чём странность?

А вот в этом:

# avahi-browse -ar

= wlp0s20f3 IPv4 Hostname _xbmc-events._udp local
hostname = [hostname.local]
address = [192.168.1.100]
port = [9777]
txt = []
= wlp0s20f3 IPv4 Hostname _xbmc-jsonrpc-h._tcp local
hostname = [hostname.local]
address = [192.168.1.100]
port = [8080]
txt = ["uuid=410d41db-e758-4593-85cf-f4d0f0569a96" "txtvers=1"]

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

Но не тут-то было:

# host hostname
hostname has address 192.168.1.100

# host hostname.local
hostname has address 127.0.0.200

«Что за ерунда?», спросите вы. Ведь хост один и тот же! Более того, если вы попробуете опросить другие устройства с суффиксом .local (в моём случае это были смартфон и планшет) он упорно будет выдавать вам адрес 127.0.0.200.

Но при использовании утилиты dig, всё становится понятным моментально:

;; ANSWER SECTION:
hostname.local. 0 IN A 127.0.0.200

;; Query time: 5 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) <== вот наши источник проблемы

Ответ прилетает от моего резолвера который установлен в роутере.

А разгадка проста. Когда была куцая прошивка от весьма дешманского роутера Xiaomi, просто не мог посмотреть в чём проблема и потому забил. После перепрошивки на что-то не столь убогое, у меня появился полноценный интерфейс с доступом к конфигурационным файлам роутера и там обнаружился всё тот же dnsmasq с пустым конфигурационным файлом.

Решение лежит на поверхности:

# Never forward plain names (without a dot or domain part)
domain-needed

# Never forward addresses in the non-routed address spaces.
bogus-priv

# Add local-only domains here, queries in these domains are answered
# from /etc/hosts or DHCP only
local=/local/

# Set the domain for dnsmasq. this is optional, but if it is set, it
# does the following things.
# 1) Allows DHCP hosts to have fully qualified domain names, as long
# as the domain part matches this setting.
# 2) Sets the "domain" DHCP option thereby potentially setting the
# domain of all systems configured by DHCP
# 3) Provides the domain part for "expand-hosts"
domain=local

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

This is crosspost from https://techquisitor.dreamwidth.org/326155.html

linux, software

Previous post Next post
Up