У меня есть маршрутизатор, который также работает DNS, который содержит имена для машин в моей локальной сети. Он настроен на пересылку запросов, поэтому для любой общедоступной машины он будет обращаться к DNS, предоставленному моим провайдером. Маршрутизатор настроен так, что он является первичным DNS, а DNS провайдера указан в качестве вторичного. У меня есть несколько машин (с записями в моем личном DNS), которые имеют статические IP-адреса. Другие машины, включая Mac, который является предметом этого вопроса, получают свои адреса по DHCP.
Машины с Windows в этой сети работают отлично. Они разрешают частные имена для компьютеров в моей сети, а также имеют доступ к общедоступному Интернету.
Мой единственный ноутбук Mac не работает. Он без проблем получает доступ к общедоступному Интернету, но не получает доступ к моему внутреннему DNS, чтобы получить внутренние имена. Например, если я сделаю пинг к внутренней машине как
ping internal.example.com
Я получаю пакеты обратно, но он показывает IP-адрес, который соответствует Hover. (Очевидно, Hover создает целевую страницу для любого субдомена, для которого нет общедоступного маршрута.) Если я сделаю
nslookup internal.example.com
тем не менее, я получаю правильный (внутренний) IP для машины в моей локальной сети.
Наконец, если я снова пингуюсь, но на этот раз заставляю его использовать мой внутренний DNS (192.168.1.2),
ping internal.example.com 192.168.1.2
Я получаю ответ от правильной машины в моей локальной сети. Кажется, это указывает на то, что даже "нативный" подход может делать то, что я хочу, если он просто использует правильный DNS.
Я нашел много статей, в которых обсуждается эта проблема, но то, что я на самом деле нашел, либо устарело, либо не является полным решением моей проблемы. То, что я пока собрал вместе:
- В ходе нескольких обновлений ОС Apple меняла свою методологию разрешения DNS, поэтому ответы в Интернете быстро устаревают.
- Mac имеет (по крайней мере) две схемы разрешения DNS, работающие одновременно с El Capitan. Это связано с получением разных результатов от ping и от nslookup, как отмечено выше. Утилиты командной строки, которые работают в "обычной" системе linux, по крайней мере, документируют это на своих страницах руководства, обычно в разделе, озаглавленном "Mac OS X Notice". К сожалению, неясно, какие именно утилиты используют, не проверяя их одну за другой. (До сих пор похоже, что nslookup и dig используют методологию linux, а ping использует все, что является "родным" для Mac OS.)
- Это (более или менее) документированная особенность "родного" метода DNS, которая динамически выбирает, какой DNS использовать. В частности, это означает, что порядок, отображаемый в окнах, таких как панель управления сетью, или порядок, указанный маршрутизатором (в моем случае), не соблюдаются.
- Я получил некоторую информацию от "родного" инструмента DNS с помощью команды
sudo killall -INFO mDNSResponder
в командной строке. Это сбрасывает сообщения в/var/log/system.log
. Из этого сообщения журнала видно, что DNS моего провайдера указан первым в этой системе. (Еще раз отмечу, что он указан вторым в конфигурации маршрутизатора и на панели управления сетью. Он также указан вторым, если я запускаюscutil
.) - Я попытался очистить кеш на mDNSResponder, используя
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder;
но это не помогло. - Я попытался отредактировать файл
com.apple.mDNSResponder.plist
как в этих инструкциях (https://www.cnet.com/news/os-x-10-6-3-and-dns-server-priority-changes/) , но я не смог отредактировать файл. (Только для чтения, даже сsudo vi
.) Кроме того, файл в моей системе имеет содержимое, отличное от указанного в этих инструкциях.
Однако, несмотря на все это, у меня все еще есть Mac, который не работает в сети, полной других компьютеров, которые прекрасно работают. Я мог бы, вероятно, вынуть DNS провайдера на маршрутизаторе, чтобы он даже не предлагался, но это похоже на взлом. Есть ли хорошее решение для этого на El Capitan?
Извините, если на это уже был дан ответ. (Я чувствую, что это должно быть где-то!) Большую часть дня я копался и не нашел решения для Эль-Капитана.