Чем scutil --dns отличается от настроек сети
В графическом интерфейсе и в networksetup вы видите то, что задано для службы: ручные адреса или пустое поле. Но реальный выбор сервера для каждого запроса macOS делает по более сложным правилам. Утилита scutil обращается к системной конфигурации и показывает итог, который складывается из нескольких источников: роутера, ручных значений и других настроек системы.
Поэтому «DNS-серверы не заданы» в настройках не означает отсутствие DNS. Если там пусто, итоговые адреса приходят по DHCP, и увидеть их можно именно здесь. Верно и обратное: вы могли вписать адреса вручную, а в итоговом выводе видите их среди нескольких резолверов и можете понять, какой из них отвечает за конкретный домен.
Команда безопасна: она только читает конфигурацию и ничего не меняет. Права администратора не нужны.
Структура вывода: блоки resolver
Вывод состоит из двух больших частей. Сначала идёт DNS configuration, затем DNS configuration (for scoped queries). Каждая часть разбита на блоки resolver с номерами: resolver #1, resolver #2 и так далее.
- nameserver[0], nameserver[1] — адреса DNS-серверов в порядке использования;
- search domain — домены, которые подставляются к коротким именам;
- domain — если задан, этот резолвер обслуживает только указанную зону;
- if_index — номер и имя интерфейса, к которому относится резолвер, например en0;
- flags и reach — служебные признаки и статус доступности адреса;
- order — порядок, в котором резолверы рассматриваются при выборе.
Обычно основной интерфейс виден в первом блоке, где нет строки domain. Именно он отвечает на запросы для большинства имён. Блоки с указанными доменами нужны, когда для отдельной зоны определён особый сервер, например в корпоративной сети или при включённых специальных профилях.
Если внутри вывода вы видите адреса, которых не вписывали, это не повод для паники. Чаще всего это адреса роутера или сервера, выданные при подключении к сети.
Как найти нужный резолвер за минуту
Полный вывод может занимать десятки строк. Чтобы быстро получить главное, отфильтруйте его: scutil --dns | grep nameserver. Команда покажет только адреса серверов. Чтобы увидеть интерфейсы, используйте scutil --dns | grep if_index. Для поисковых доменов подойдёт grep search.
Дальше сопоставьте найденное с реальным поведением.
- Определите, какой интерфейс у маршрута по умолчанию: route -n get default.
- Найдите блок resolver с тем же интерфейсом.
- Проверьте адреса nameserver: отвечают ли они на запрос через dig.
- Если нужного домена в блоках с ограничением нет, он обслуживается основным резолвером.
В результате у вас будет ясная картина, какой сервер получит ваш запрос. Без этой проверки люди часто «чинят» не тот DNS: меняют значение в настройках Wi-Fi, а запросы идут через другой интерфейс.
Когда вывод помогает найти проблему
Разберём типичные ситуации, при которых scutil --dns даёт ответ быстрее прочих способов.
| Симптом | Что смотреть в выводе |
|---|---|
| Сайты открываются по IP, но не по имени | Есть ли nameserver у основного резолвера и отвечает ли он |
| Имя внутренней сети не находится | Есть ли блок с нужным domain и нужным сервером |
| После смены DNS ничего не изменилось | Какие адреса стоят в nameserver на нужном интерфейсе |
| Имена открываются медленно | Не стоит ли первым недоступный адрес, а рабочий только вторым |
| Результат отличается на Wi-Fi и по кабелю | Различаются ли блоки resolver у разных интерфейсов |
Если первым стоит недоступный сервер, а рабочий идёт вторым, система может тратить время на ожидание ответа от первого, и страницы загружаются с заметной паузой. Решение — убрать неработающий адрес из настроек сети или на роутере.
Когда вывод пустой или в нём нет ни одного nameserver, система вообще не знает, куда отправлять запросы. Проверьте, подключена ли сеть и получен ли адрес.
Что делать после чтения вывода
Сама команда ничего не исправляет, она лишь указывает на причину. Дальше действуйте по обстоятельствам.
Если адреса не те, что нужно, измените их там, где они заданы: на роутере, если они выдаются по DHCP, или в настройках службы, если вы указывали их вручную. Как это сделать в терминале, показано на странице про networksetup, а как через интерфейс системы — в отдельной инструкции.
Если адреса верные, но имена не находятся, проверьте сам сервер запросом dig с указанием этого адреса, как описано в материалах про dig. Различайте ответ NXDOMAIN, который означает «имени нет», и отсутствие ответа, которое говорит о недоступности сервера.
После любых изменений полезно сбросить DNS-кэш, чтобы не видеть старые ответы, а затем снова выполнить scutil --dns и убедиться, что конфигурация обновилась. Если конфигурация меняется сама через короткое время, возможно, настройки перезаписывает какая-то программа или профиль управления устройством; это стоит уточнить у администратора.
Сопоставление с проверкой запросов
Список резолверов отвечает на вопрос «куда уйдёт запрос», а чтобы убедиться, что сервер действительно отвечает, выполните живой запрос. Возьмите адрес из строки nameserver и обратитесь к нему напрямую: dig @адрес example.com. Если в ответе есть секция ANSWER, сервер работает. Если ответа нет или он приходит с большой задержкой, нашлась причина медленных страниц.
Проверьте и обратную сторону: выполните обычный запрос без указания сервера и посмотрите в конце вывода, какой сервер ответил. Строка SERVER показывает адрес, который использовала система. Он должен совпадать с одним из адресов в блоке нужного интерфейса.
Если не совпадает, значит, запрос обслужил другой резолвер, например по правилу для отдельного домена. Такое возможно, когда на компьютере включены специальные настройки для рабочей сети. Это нормальное поведение, а не сбой, но о нём полезно знать при диагностике.