Устранение проблем с разрешением DNS-имен для домена .local в современенных дистрибутивах Linux

by Anton Chernousov aka GITA-DEV


Опубликовано: 26 Фев 2018 (последние правки 4 недели)


Устранение проблем с разрешением DNS-имен для домена .local в современенных дистрибутивах Linux

То, что мы сегодня будем разбирать - это не проблема, а просто "песня". Такого рода вопросы очень любят мои коллеги, так как они предоставляют им возможность поспорить на тему баг это или фича, перетряхнуть древние записи на Stack Overflow, разлиться мыслью по древу или банально затеять обсуждение на пару сотен комментариев под заданным в профильной группе вопросом.

То, что мы сегодня будем разбирать - это не проблема, а просто "песня". Такого рода вопросы очень любят мои коллеги, так как они предоставляют им возможность поспорить на тему баг это или фича, перетряхнуть древние записи на Stack Overflow, разлиться мыслью по древу или банально затеять обсуждение на пару сотен комментариев под заданным в профильной группе вопросом.

Сразу скажу, что ничего этого мы делать не будем, а будем разбираться с химией и волшебством вопроса....

Итак, как я уже говорил - это не проблема, а просто "песня" какая-то и сейчас я объясню почему... Как вы знаете, в Windows-среде, почему-то, принято создавать внутренний домен Active Directory вида <имя-компании>.local и вот только недавно от такой практики стали немного отходить из-за конфликта, как раз таки, с доменом .local. А домен .local, в современном понимании - это понятие из терминологии Zeroconf для автоматически конфигурируемых сетей и "родила" его корпорация Apple и ,так как в яблоках эта штука работает на ура, производители принтеров и ряда другого оборудования стали его активно пользовать.

Если вы решите почитать Википедию на эту тему, то найдете там вот такую запись:

Существует два способа разрешения имен. Apple Computer использует Multicast DNS (mDNS), а Microsoft — Link-local Multicast Name Resolution (англ.) (LLMNR). Эти протоколы имеют мало отличий. mDNS выбирает имя в пространстве «.local» и объявляет его на некоторый мультикаст-адрес. Это приводит к специальной семантике для пространства имен .local, что считается проблемой для некоторых членов IETF. Текущий черновик LLMNR позволяет устройству выбрать любое доменное имя, что рассматривается как недостаток в безопасности некоторыми членами IETF . mDNS совместим с DNS-SD как описано ниже, а LLMNR не совместим.

Википедия Zeroconf

Теперь вы ,наверное, поняли из-за чего происходит этот конфликт интересов. Как мы знаем, Active Directory довольно ответственно относиться к обновлению DNS-записей и хранит сведения о записях домена в LDAP, а mDNS - это некий безбашенный субпродукт, созданный без оглядки на безопасность, но безопасность это еще меньшая из зол, так как рабочей станции надо будет разобраться с чем в этом хаосе ей работать и запрашивать у "виртуальной принтерной сети" сведения о контроллерах домена бесполезно.

Все описания пространных ситуаций с выстраиванием цепочек для передачи запросов сначала домену mDNS, а если там не помогло, то уже DNS-серверам домена иногда работают, а иногда нет. Причем, совершенно непонятна может быть точка отказа. И если в Windows это было решено набором внутренних "костылей", то запрос DNS в современных дистрибутивах Linux производиться максимально извращенно, чтобы системный администратор сошел с ума окончательно.

Сначала система смотрит nsswitch.conf на предмет правил разрешения имен и, когда доходим до правил разрешения dns (отправить запрос к DNS), отправляем запрос не тому DNS который мы получили по DHCP, а локальному mdns-серверу, который уже перешлет вышестоящему (если перешлет конечно). Проблема может проявляться в нескольких вариантах и в первом случае DNS-запрос nslookup для .local домена не вернет данных, а во втором случае DNS-запрос вернет данные, но ,например, команда ping не сможет обнаружить домен .local.

Я противник использования в корпоративных сетях разного рода mdns, а если уж вам так захотелось дать имя принтеру, то соизвольте его завести в виде записи в оснастке управления DNS-сервером. Как я уже говорил, я рекомендую начать с "приведения в порядок" /etc/nsswitch.conf.

Изначально интересующий нас раздел содержит следующие записи:

hosts:          files mdns4_minimal [NOTFOUND=return] dns

Соответственно, в этом режиме сначала производится поиск в файле /etc/hosts, затем запрос идет к mdns, после чего возвращается ответ "не найдено". Теоретически mdns чего-то там кэширует, работает с демоном Avahi и производит много прочей хипстерской дичи, без которой жили раньше. Я сразу же модифицирую эту "схему" к классическому виду:

hosts:          files dns

Это схема "Здорового системного администратора", и я рекомендую использовать ее для сохранения вашего "душевного здоровья". Но тут кроется еще один сюрприз, а именно, то что это сработает только на "серверных системах", где не установлен пакет Avahi, а попытка удалить пакет Avahi на современной рабочей станции утащит за собой в ад половину системы. В независимости от полученных по DHCP-настроек в /etc/resolv.conf будет записан адрес DNS-сервера 127.0.0.1, а сам файл resolv.conf автоматически пересоздается отдельным демоном.

Можно, кстати, поинтересоваться у Network manager, что он вообще думает по этому поводу при помощи команды:

# nmcli dev show | grep DNS

Следовательно, при использовании NetworkManager и копать надо в эту сторону, а разгадка обычно находится в параметре dns=dnsmasq и для отключения использования mdns службой NetworkManager можно закомментировать в файле /etc/NetworkManager/NetworkManager.conf параметр:

#dns=dnsmasq

Он может быть и не в этом файле и в расположение этого параметра издевательски изменяется от версии к версии, поэтому я рекомендую использовать поиск.


Есть вопросы?
Спрашивайте и я обязательно вам отвечу!

* Поля обязательные для заполнения .

Блог это некоммерческий проект! Если вам понравился мой блог и то что я пишу помогло вам на практике, то можете сказать спасибо материально.