Крайне презабавную проблему недавно решил у себя. На полноценную статью не тянет. Так, заметка для младоадминов.
Долгое время было лень глянуть, с чего у меня в локальной сети крайне странно отдавались устройства с включённым 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