Intereting Posts

Не удается разрешить домены .local внутри моей локальной сети офиса

В Linux Debian 9 я могу разрешить определенный локальный домен, например my.sample-domain.local используя некоторые команды, такие как nslookup или host , но не с помощью некоторых других команд, таких как ping или клиент Postgres psql .

Я думаю, что такие вещи, как Network Manager, правильно настроили мой DNS-распознаватель (содержимое /etc/resolv.conf ), поэтому я не уверен, почему это происходит?

Я проверил с коллегой, использующим Windows 10, и у них нет никакой пользовательской записи в файле хоста, хотя в их случае версия ping Windows и пользовательский интерфейс их базы данных для Postgres работают, как и ожидалось, при преобразовании домена в IP-адрес.

Пожалуйста, смотрите ниже:

 $ ping my.sample-domain.local ping: my.sample-domain.local: Name or service not known $ host my.sample-domain.local my.sample-domain.local has address  $ ping -c 5  PING  () 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=128 time=1.16 ms 64 bytes from : icmp_seq=2 ttl=128 time=0.644 ms 64 bytes from : icmp_seq=3 ttl=128 time=0.758 ms 64 bytes from : icmp_seq=4 ttl=128 time=0.684 ms 64 bytes from : icmp_seq=5 ttl=128 time=0.794 ms ---  ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4056ms rtt min/avg/max/mdev = 0.644/0.808/1.160/0.183 ms $ nslookup my.sample-domain.local Server:  Address: #53 Non-authoritative answer: Name: my.sample-domain.local Address:  $ cat /etc/resolv.conf domain  search  nameserver  nameserver  

РЕДАКТИРОВАТЬ:

Тем временем я понял, что в той же офисной локальной сети есть виртуальная машина Ubuntu 16, поэтому я вошел в нее и попробовал команду ping которая там работает.

Кроме того, у Ubuntu VM нет особых настроек в /etc/hosts (так же, как на моем ноутбуке Debian 9 с ненастроенными /etc/hosts ).

Оба /etc/resolv.conf выглядят одинаково (некоторые общие домены / IP-адреса, некоторые другие IP-адреса для одного и того же домена).

Однако файл /etc/nsswitch.conf отличается, так что я думаю, что с этим mdsn4_minimal и порядком разрешения хостов там что-то происходит, например, mdsn4_minimal перед dns :

 hosts: files mdns4_minimal [NOTFOUND=return] dns 

и на Ubuntu:

 hosts: files dns 

РЕДАКТИРОВАТЬ 2:

Виртуальная машина Ubuntu 16 и мой ноутбук Debian 9 могут разрешить этот домен .local с помощью команды dig .

host и nslookup выполняют поиск DNS, однако большинство приложений используют переключатель службы имен glibc, чтобы решить, как искать имена хостов.

Ваш /etc/nsswitch.conf может включить mDNS, что может вызвать проблемы при разрешении имен .local . Вы можете изменить порядок выполнения поиска или просто удалить службу mDNS, если считаете, что она вам не понадобится.

Ваш nsswitch.conf имеет mdns4_minimal , который выполняет поиск в mDNS (для имен .local ). [NOTFOUND=return] после этого вызывает остановку поиска, и поэтому DNS никогда не используется, и ваше приложение не может разрешить имя хоста. Вы можете либо удалить весь mdns4_minimal [NOTFOUND=return] , чтобы поиск mDNS не использовался, либо просто удалить действие NOTFOUND, чтобы поиск DNS выполнялся в случае сбоя поиска mDNS.

Для получения дополнительной информации я рекомендую ознакомиться с документацией по переключателю службы имен .

Большая проблема здесь: известно, что доменные имена DNS, оканчивающиеся на .local не должны использоваться при настройке инфраструктур DNS.

Использование .local зарезервировано для использования zeroconf / avahi aka bonjour, которые являются параллельными службами для разрешения локальных имен / служб помимо DNS.

Итак, что происходит, так это то, что ваша внутренняя служба DNS-имен наверняка конфликтует с zeroconf в некоторых сценариях. Таким образом, решение в вопросе вы приняли.

В более долгосрочной перспективе DNS-имя вашей внутренней сети не должно заканчиваться на .local .

PS Кроме этого, помимо DNS, локальные controllerы домена / AD Microsoft также не должны называться .local . У вас будут странные проблемы, если вы это сделаете.

Стандарт многоадресной DNS (mDNS).
Стандарт RFC 6762 (20 февраля 2013 г.), посвященный стандарту Internet Engineering Task Force (IETF), резервирует использование метки доменного имени local в качестве домена псевдо верхнего уровня для имен хостов в локальных сетях, которые могут быть разрешены с помощью Multicast DNS. протокол разрешения имен.

Из MS Technet (Википедия)

Если у вас есть клиентские компьютеры Macintosh, на которых установлена ​​операционная система Macintosh OS X версии 10.3 или более поздней,… рекомендуется не использовать метку .local для полного DNS-имени вашего внутреннего домена. Если вы должны использовать метку .local, вы также должны настроить параметры компьютеров Macintosh, чтобы они могли обнаруживать другие компьютеры в сети.

RFC 6762

Любой DNS-запрос на имя, заканчивающееся на «.local». ДОЛЖЕН быть отправлен на
mDNS IPv4 link-local multicast address 224.0.0.251 (или его IPv6)
эквивалент FF02 :: FB).

……

  1. Обратное сопоставление адресов

    Как и «.local.», Домены обратного сопоставления IPv4 и IPv6 также определяются как локальные:

    Любой DNS-запрос на имя, заканчивающееся на «254.169.in-addr.arpa.» ДОЛЖНЫ быть отправлены на локальный многоадресный адрес 224.0.0.251 для локального канала IPv4 mDNS или на многоадресный адрес IPv6 mDNS FF02 :: FB. Поскольку имена в этом домене соответствуют локальным адресам IPv4-ссылок, логично, что локальная ссылка является лучшим местом для поиска информации, относящейся к этим именам.

……

Не требуется никакого специального элемента управления для включения и отключения многоадресной DNS для имен, явно заканчивающихся на «.local». как введено пользователем.
Пользователю не нужен способ отключить Multicast DNS для имен, заканчивающихся на «.local.», Потому что, если пользователь не хочет использовать Multicast DNS, он может добиться этого, просто не используя эти имена.
Если пользователь вводит имя, оканчивающееся на «.local.», То мы можем с уверенностью предположить, что пользователь, вероятно, хотел, чтобы оно работало.

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

Домен .local – это домен псевдо верхнего уровня. Что это значит? Это означает, что это не официальный домен верхнего уровня, используемый (маршрутизируемый) в Интернете, но он имеет полуофициальный статус, поскольку используется в некоторых приложениях.
В случае .local он используется службой многоадресных доменных имен (mDNS). Хосты, которые реализуют этот сервис, используют .local в качестве своих доменных имен и имеют свой собственный способ разрешения имен. Обычно это не было бы проблемой; однако, если вы также внедрите DNS в своей сети с доменом верхнего уровня .local, это вызовет серьезные проблемы с разрешением имен.
Я видел, что это часто случается в системах Linux, и я думаю, что у Apple OS X, вероятно, также будут эти проблемы. Обычно в этих типах сетей обнаруживается, что разрешение имен DNS не работает вообще или работает только иногда. В конце концов, вам приходится все время использовать ip-адреса, потому что вы не знаете, может ли имя разрешиться или нет (что сводит на нет весь смысл наличия DNS-сервера в первую очередь).

Возможно, у вас есть конфликт NBNS с DNS , поэтому исправьте это, или отредактируйте ваш файл hosts , или перенесите ваши команды;

 NAME=my.sample-domain.local ping $(host $NAME | perl -pe 's/.* //g') 

DNS должен проверяться с помощью dig ;

 dig @$SERVER $NAME +short 

Я предполагаю, что хост ищет сначала NBNS (или наоборот).