Mac os теряет dns
Обновлено: 06.07.2024
Кэш DNS может быть поврежден по ряду причин, включая сетевые атаки или вирусы. Когда это происходит, сопоставление IP-адресов становится поврежденным для некоторых популярных веб-сайтов.
Очистка кеша DNS удаляет всю сохраненную информацию поиска DNS. Затем ваш компьютер получает обновленные данные с DNS-серверов при следующей отправке запроса на поиск.
Как очистить кэш DNS в Windows
Очистка кеша DNS - это простой и быстрый процесс. Процедура одинакова для почти всех систем Windows . Для примера ниже мы будем использовать Windows 10 .
Чтобы очистить DNS на вашем компьютере с Windows:
Загрузите командную строку от имени администратора. Откройте меню «Пуск» и начните вводить "командная строка" или "cmd", пока не увидите ее в результатах. Загрузите командную строку от имени администратора. Откройте меню «Пуск» и начните вводить "командная строка" или "cmd", пока не увидите ее в результатах. Введите ipconfig/flushdns, когда командная строка загрузится, и нажмите Enter на клавиатуре. Введите ipconfig/flushdns, когда командная строка загрузится, и нажмите Enter на клавиатуре.База данных кэша DNS на вашем компьютере теперь очищена. Вы должны получить правильное и обновленное сопоставление IP-адресов с DNS-серверов в следующий раз, когда ваш компьютер отправит DNS-запрос.
Очистить кэш DNS на Mac
Есть несколько разных команд для очистки кеша DNS в OS X и macOS в зависимости от используемой версии.
Поскольку процедура одинакова для всех версий, в этой статье подробно описано, как очистить DNS в macOS Mojave (10.14) , а затем перечислены команды для других версий в таблице.
Сброс DNS на MacOS Mojave (версия 10.14)
Чтобы очистить кэш DNS на MacOS Mojave, используйте приложение Terminal :
Запустите Terminal.app, используя ваш предпочтительный метод. Вы можете запустить приложение из Приложения -> Утилиты или нажать Ctrl + Space, чтобы запустить Spotlight и выполнить поиск терминала. Запустите Terminal.app, используя ваш предпочтительный метод. Вы можете запустить приложение из Приложения -> Утилиты или нажать Ctrl + Space, чтобы запустить Spotlight и выполнить поиск терминала.- Введите sudo killall -HUP mDNSResponder и нажмите Enter на клавиатуре.
После окончания процесса не будет никаких оповещений
Команды для очистки DNS-кэша в старых версиях macOS и Mac OS X
В таблице ниже перечислены команды для очистки кэша DNS в большинстве версий MacOS и Mac OS X. Вы можете скопировать и вставить их прямо из таблицы в свой терминал.
Mojave (version 10.14)
High Sierra (version 10.13)
Sierra (version 10.12)
Mountain Lion (version 10.8)
Lion (version 10.7)
sudo killall -HUP mDNSRespondeEl Capitan (version 10.11)
Mavericks (version 10.9)
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Yosemite (version 10.10)
sudo discoveryutil mdnsflushcache
sudo discoveryutil udnsflushcaches
Snow Leopard (version 10.6)
Leopard (version 10.5)
sudo dscacheutil -flushcache
Tiger (version 10.4)
lookupd -flushcache
Как очистить кэш DNS в Linux
Дистрибутивы Linux немного отличаются от компьютеров с Windows и Mac. Каждый дистрибутив Linux может использовать свою службу DNS. Некоторые дистрибутивы, такие как Ubuntu , вообще не имеют службы DNS по умолчанию.
Это зависит от того, какая служба используется в вашем дистрибутиве и включена ли она по умолчанию. Некоторые из них - NCSD (Name Service Caching Daemon), dnsmasq и BIND (Berkely Internet Name Domain).
Для каждого дистрибутива вам нужно запустить окно терминала. Нажмите Ctrl + Alt + T на клавиатуре и используйте соответствующую команду, чтобы очистить кэш DNS для службы, работающей в вашей системе Linux.
Очистить локальный DNS-кэш NCSD
Используйте эту команду для очистки DNS-кэша NCSD на вашем Linux-компьютере:
sudo /etc/init.d/nscd restart
Введите свой пароль, если это необходимо. Процесс останавливается, а затем запускает службу NCSD в течение нескольких секунд.
Очистить локальный DNS-кэш dnsmasq
Используйте эту команду для очистки DNS-кэша dnsmasq на вашем Linux-компьютере:
sudo /etc/init.d/dnsmasq restart
Введите пароль еще раз, если терминал попросит вас. Вы увидите ответ, когда служба останавится и запустится снова.
Очистить локальный DNS-кэш BIND
Если вы используете BIND для службы DNS, есть несколько команд, которые вы можете использовать для очистки его кеша DNS. Вам может потребоваться ввести пароль для завершения процесса.
Некоторые из моих коллег испытывают проблемы на своих Mac - разрешение DNS не работает под Mac OS X. Они работают под управлением Snow Leopard 10.6.8. Они могут использовать DNS на виртуальной машине Windows 7 (VMware Fusion 3.1.3), работающей под OS X. Компьютеры - это 15-дюймовый MacBook Pro, модель начала 2011 года.
То, что они пробовали, не сработало:
- включение / выключение аэропорта
- перезагрузка
- используя проводное соединение вместо Wi-Fi
- удаление учетных данных подключения и добавление их снова
- отключение брандмауэра Mac
- используя фиксированный статический IP
- настройка DNS-серверов вручную
- перезапуск mDNSResponder
- исправления из этого другого вопроса
РЕДАКТИРОВАТЬ ответ Мартин ответ:
• Можете ли вы пропинговать DNS, который хотите использовать?
• Какой IP-адрес (а) DNS (а) вы хотите использовать?
Это DNS-сервер компании, который предоставляется с DHCP, он хорошо работает для других людей. Я также попробовал Google 8.8.4.4 и 205.171.3.65 (который я нашел из DNS Benchmark GRC, чтобы быть самым быстрым).
• Вы пытались использовать 8.8.8.8 (Google) или любой из OpenDNS 208.67.222.222 или 208.67.220.220?
Это не работает, смотрите вывод Google Chrome:
• Можете ли вы пинговать этих хостов?
• создание пустого пользователя
Учетная запись гостя была создана, проблема DNS все еще существовала при использовании гостевой учетной записи.
• nslookup и копать оба работают нормально
• также была выполнена очистка кеша DNS, но это не помогло
РЕДАКТИРОВАТЬ 2 :
Это похоже на историческую проблему, которая погубила жизнь пользователей и сетевых администраторов от Leopard до Yosemite. Если кто-то все еще видит эту проблему, пожалуйста, сообщите четко, если у вас есть более одного активного интерфейса и, более того, получите его conf. с DHCP-сервера (с разных сторон). Почему? Я никогда не видел такой проблемы ни в одном другом Unix и ни на одном из моих Mac (у меня их много), но ни у одного из них не было более одного интерфейса, говорящего с источником информации DNS. Попробуйте изменить настройки DNS (порядок изменения или удаления записей), то решить тот же вопрос для меняОказывается, решение было отказов mDNSResponder:
Это было получено другим коллегой из этого вопроса о сбое сервера .
OS X 10.10.0 - 10.10.3, Йосемити
По-видимому , mDNSResponder не существует в Yosemite (OS X 10.10). Вместо этого вы можете перезапустить descoveryd, чтобы устранить эти проблемы.
OS X 10.10.4+, Йосемити
В OSX 10.10.4 mDNSResponder был вновь введен . Так что использование первого снова будет работать.
Но это не совсем удовлетворительный ответ. Мне нужно знать, как остановить это в первую очередь. @dkagedal На самом деле это хороший ответ, который мы получим - это происходит потому, что ваш Mac кэширует записи DNS, чтобы избежать попадания на ваш DNS-сервер (скорее всего, на ваш маршрутизатор) при каждом поиске DNS - что часто случается. Этот кеш необходим и хорош, но было бы неплохо, если бы поведение было лучше, когда запись не найдена (я считаю это ошибкой). В любом случае в кеше есть тайм-аут; когда я подождал около 10 минут на моей машине, эта ситуация разрешилась сама собой. Для большинства пользователей существующее поведение в порядке, поэтому Apple вряд ли изменится в ближайшее время. Получил эту проблему на 10,9 и решение работало отлично. В моем случае DNS разрешал полные имена, но не короткие. @ Matteo Возможно, файл не должен существовать, или, возможно, необходимо обновить ответ для Yosemite. У вас есть эта проблема? Исправляет ли выполнение этих команд?На самом деле, я думаю, что вы можете использовать
Эти команды используют динамическое хранилище в configd, в отличие от плоских файлов в / etc, которые часто читаются только в однопользовательском режиме и для не сетевых систем.
Одним из возможных преимуществ scutil является то, что он может работать независимо от того, обнаружен ли компьютер или mDNSResponder. Это датируется до их введения.Я столкнулся с той же проблемой . И хотя перезапуск mDNSResponder, похоже, "работает", перезапускать его пару раз в час - это отстой.
Итак, на данный момент я «решил» проблему, запустив dnsmasq локально. Для этого:
-
Сборка dnsmasq (скачать тгз и make или brew install dnsmasq )
Поместите это в dnsmasq.conf файл:
Поместите это в resolv.conf файл, который находится в том же каталоге, что и dnsmasq.conf файл (nb: not /etc/resolv.conf ):
Беги dnsmasq с sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf . Вывод должен выглядеть примерно так:
Откройте «Сетевые настройки» и убедитесь, что 127.0.0.1 это единственный DNS-сервер (сетевые настройки -> «Дополнительно» -> DNS -> добавить 127.0.0.1).
Все должно начать работать снова хорошо.
После того, как все заработает, вы можете работать dnsmasq без параметров --no-daemon и --log-queries , поэтому он будет запускаться в фоновом режиме, и вам не нужно держать окно терминала открытым.
Я просто хотел бы отметить, что после 16 часов работы в Интернете это единственное решение, которое я обнаружил, и то, и другое позволяет мне разрешать внутренние названия компаний и позволяет правильно функционировать разделенным сетям. Большое вам спасибо за этот комментарий. Для будущих читателей я обнаружил, что проще всего просто ssh зайти в мой ящик на работе, определить, какие IP-адреса он имел для серверов имен, а затем жестко закодировать эти IP-адреса в мой resolv.conf ниже 8.8.8.8 (DNS-сервер Google). Это позволяет правильно разрешать имена всех компаний, не обращаясь к серверам компании, что я считаю полезным для обеспечения конфиденциальности и скорости. Что касается жесткого кодирования, то эти IP не изменятся в ближайшее время, и если они это сделают, я не буду единственным затронутым, и это должно быть тривиально редактировать две строки. Он говорит, что адрес 127.0.0.1 уже используется, когда я пытаюсь запустить dnsmasq. Что мне нужно сделать? Высокая Сьерра @IceFire Я знаю, что это старый, но это означает, что к этому порту уже привязан сервис (53). Технически это означает, что он получает ошибку EADDRINUSE, но я не пойду туда :) Что касается этого ответа, я нахожу это интригующим. У меня похожая проблема, но я думаю (надеюсь), что другой ответ разрешит ее только потому, что мне не нужно включать ее, по крайней мере, для моей домашней сети, так как у меня есть свои собственные авторитетные DNS-серверы (и один из них оказывается местный и чем пользуюсь). Как давний пользователь Unix, тот факт, что я могу использовать /etc/resolv.conf , привлекателен, но сначала попробую другой.Разрешение имен в OSX (и UNIX в целом) берется из IP-адресов DNS в файле, расположенном в /etc/resolv.conf (который OS X генерирует автоматически, насколько я помню).
Поскольку вы попробовали практически все, что приходит мне в голову, я хотел бы спросить вас:
- Можете ли вы пропинговать DNS, который хотите использовать?
- Какой IP-адрес (а) DNS (а) вы хотите использовать?
- Вы пытались использовать 8.8.8.8 (Google) или любой из OpenDNS 208.67.222.222 или 208.67.220.220?
- Можете ли вы пинговать этих хостов?
Наконец, обычно хороший тест состоит в создании пустого пользователя и проверке того, имеет ли этот новый пользователь ту же проблему. Если это не так, то вы можете начать копать то, что у вашего текущего пользователя может быть причиной проблемы; если это также не помогает, то вы знаете, что это нечто более «системное».
Также осмотрите консоль, чтобы увидеть, можете ли вы найти что-то, что может быть связано (и хотели бы вставить сюда).
И последнее, но не менее важное: ваш Mac поставляется с двумя важными командами DNS nslookup и dig .
nslookup "хост для разрешения" "DNS-сервер для использования". Например:
NSLookup - старая команда (которая должна была быть устаревшей несколько лет назад и заменена на DIG, но ее простой в использовании синтаксис был слишком хорош, чтобы ее убивать, я думаю), ее «замена» - dig гораздо более мощная команда, синтаксис которой более сумасшедший
Чтобы выполнить тот же запрос, вы должны набрать:
Как вы можете видеть, dig гораздо более "многословен" (что хорошо для отладки того, что происходит, черт возьми). Сила копания заключается в том, что вы можете указать, какой тип запроса вы хотите выполнить (среди прочего).
В любом случае, дайте нам знать точные результаты этих команд.
@CajunLuke Хмммм интересно . Я не против добавить вывод: cat /etc/resolv.conf к вашему вопросу? Ред. (Дополнение, чтобы сделать комментарий подходящим.) @CajunLuke я озадачен. Давайте вернемся к корням . это происходит только на этой машине, и только под OSX с виртуальными машинами все в порядке. Я начинаю подозревать, что Parallels или VMware могут вызывать некоторые проблемы. Какой тип сети используют эти виртуальные машины? Мостовой? Общий?У меня были те же самые симптомы (и я потратил некоторое время на устранение неисправностей), но я смог их устранить, когда понял, что я испортил /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist и то, что я сделал, было как-то интерпретировано как неправильно сформированное. Я восстановился из резервной копии, и машина снова смогла разрешить имена хостов.
Прежде чем перейти к решению, я также понял, что смогу просматривать Интернет, если использовал прокси-сервер SOCKS5 ssh -D и пробовал поиск DNS через туннель.
Моя компания сталкивалась с этой проблемой месяцами и месяцами, каждый раз выводя Mac на «панель Genius», единственное решение которой состояло в том, чтобы стереть жесткие диски и начать все сначала. Я увидел ваш пост и удалил com.apple.mDNSResponder.plist, перезагрузился, и проблема была решена. Хотел бы я, чтобы тебя голосовали миллиард раз. Не забудьте удалить com.apple.mDNSResponder.plist ! Я сделал это, как предложил @TomThorogood. Мне трудно вернуться. Даже я положил файл обратно и перезапустить, я не смог получить ответ из Интернета. Чем sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist помог.У меня была очень, очень похожая проблема, за исключением того, что симптомы были немного другими.
Мой пользователь не смог разрешить ни одного имени (локальное NAS, Google и т. Д.), Но гостевой пользователь на том же iMac (OS X 10.7.4) работал нормально.
Промывка и перезапуск mDNSResponder, как уже упоминалось, работали некоторое время. Хотя он будет работать, когда iMac переведен в спящий режим, он всегда будет выходить из строя после перезагрузки.
Когда сброс / перезапуск перестал работать, я искал другие причины / решения и обнаружил, что это связано с моим брандмауэром. Я не знаю, что в моих настройках брандмауэра (OS X) вызывало это, но если я восстановил настройки брандмауэра, это сработало.
Для восстановления настроек по умолчанию я использовал:
Очевидно, что любые пользовательские правила будут удалены с этим восстановлением.
Я хотел поделиться своей версией этой проблемы, так как она месяцами вызывает у меня горе и эта публикация - лучшая коллекция возможных решений в сети!
Я столкнулся с этой проблемой на Йосемити (10.10). Оказывается, что ключевой демон, discoveryd был убит, поскольку он потреблял слишком много ресурсов процессора.
Как ни странно, перезагрузка не привела к перезапуску.
Я вручную перезапустил сервис с:
и сейчас все хорошо.
Это было решением для меня и на Йосемити. Некоторые детали: host, dig и Chrome работали нормально, но ping, telnet, ssh, firefox и safari не могли разрешить имена хостов. Это решение исправило мою проблему. Раздражает это случается все время для меня. Приходится перезапускать сервис.У меня такая же проблема с 10.6.8. Первая поездка в Apple Store привела к восстановлению системы. Но после этого DNS снова сломался, когда я был за границей, и у меня не было системного DVD. В то время я нашел эту /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist ветку и удалил по @freezedpeanuts и @Tom Thorogood.
Это решило проблему, но, что удивительно, DNS сломался в третий раз пару дней спустя. Я нашел системный образ 10.6.3 и:
- Скопировано /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist из образа системы.
- sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
- Rebooted
Это решило проблему.
Сейчас он периодически выходит из строя (раз в месяц или около того), и процедура восстановления идет до описанных выше шагов, за исключением того, что вместо перезагрузки вы можете:
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
Обратите внимание, что всем, у кого все еще есть проблемы, возможно, придется удалить все публичные DNS-серверы, пока кэш не будет очищен.
@DAVincent Несколько лет спустя, но эта ссылка разочаровывает. Это явно ошибка Apple, но они связывают ее с ошибкой пользователя.У меня была такая же проблема, как у ОП. Используя инструмент networksetup, я обнаружил, что для заданного имени сети был настроен неправильный DNS:
Мне удалось перенастроить DNS для данной сети и разрешить имена локальных и глобальных машин при подключении к VPN.
Это, вероятно, никому не поможет, но на случай, если я случайно некоторое время назад создал файл в папке, когда DNS не работал для определенного домена:
/ И т.д. / резольвера /
и это препятствовало тому, чтобы определенное имя когда-либо было решено, два года спустя.
Большое спасибо, это была моя проблема. Я часами отлаживал, и когда я заглянул в / etc / resolver, я, конечно, нашел файл с именем «test» с ошибочными IP-адресами .В моем случае все остальное было в порядке: mDNSResponder работал и работал host / nslookup работал, /etc/resolv.conf и networksetup сообщал о правильных DNS-серверах и т. Д. Несмотря на все это, разрешение DNS в целом (например, с ping ) неизбежно перестало работать в какой-то момент через несколько часов после загрузки.
Эта конкретная проблема может быть несколько маловероятной, но я все равно опишу ее здесь как ответ.
Я заметил только, когда машина начала замедляться, но было запущено много одинаковых процессов . sensu-client конкретно.
Мы запустили его в launchd с этим файлом plist:
-b Флаг sensu-client делает его раскошелиться на задний план, действующий в качестве демона. Однако все launchd видят, что исходный процесс завершен, поэтому (в соответствии с KeepAlive флагом) он перезапускает его. Это оставляет тысячи разветвленных процессов в фоновом режиме, и даже тогда launchd не будет мудрее того факта, что он запущен.
Я полагаю, что эти несколько тысяч процессов (все sensu-client , программное обеспечение, для которого мы написали конфигурацию launchd), возможно, одновременно делали запросы к mDNSResponder, эффективно приводя к локальному отказу в обслуживании кэша DNS . Уничтожение этих процессов и исправление списка, предоставленного launchd, в конечном итоге решили проблему.
Исправление -b plist заключалось в удалении флага (background / daemonise) из вызова sensu-client. Обратите внимание, что это не вина Сенсу; этот список был написан бывшим системным администратором в этой компании.
Недавно передо мной встала задача отладить процесс резолва DNS имен в MacOS. Полноценного материала, о том как именно он происходит, я не нашел, пришлось собирать информацию самому.
Вот что удалось выяснить.
За задачи, связанные с DNS в macOS, отвечает демон по имени mDNSResponder. В его жизни встречались приключения — на его смену приходил демон discoveryd (Yosemite), который много что поломал и создал кучу проблем. Через год Apple опомнилась и вернула (El Capitan) проверенный mDNSResponder, что сразу починило около 300 багов и вернуло стабильность.
mDNSResponder является частью Bonjour — набора технологий нацеленных на работу устройства в сети без необходимости конфигурации, включает в себя поиск сервисов, автоназначение адреса и резолв имен. Именно Bonjour используется когда вы достаете свой iPhone и ищете Apple TV или принтер.
У Bonjour открытый исходный код, и у mDNSResponder соответственно тоже. Это упрощает задачу, если вам нужно докопаться до конечной истины и показать все что скрыто. В архиве уже есть готовые реализации под Windows, Posix и VxWorks.
Демон обрабатывает unicastDNS и multicastDNS. UnicastDNS — это обычный DNS к которому мы привыкли и знаем. MulticastDNS — это протокол для использования DNS в локальных сетях, не требующий сервера. Если устройству нужно кого-то найти — оно отправляет вопрос — «question» мультикаст пакетом и получает ответ от устройства с запрошенным именем (если оно конечно существует). Сам протокол подробно описан в одноименном RFC.
Именно особенностями MulticastDNS злоупотребляет Responder — софт для атак в локальной сети. После запуска он коварно начинает отвечать на все mDNS запросы, заманивая ничего не подозревающих жертв в свои лапы.
Это было лирическое отступление — а теперь к главному вопросу — как увидеть текущий DNS кеш и общий статус DNS настроек.
Итак, выполняем следующие шаги:
-
В терминале пишем:
и в фильтре пишем mDNSResponder
Cache — здесь непосредственно хранится DNS cache:
Содержимое файла /etc/hosts — на всякий случай:
Статистика по mDNS — дубликаты имен, количество пакетов, события интерфейсов:
Список сетевых интерфейсов:
Список DNS серверов:
Мир внутренних и внешних взаимодействий подсистем MacOS обширен и полон загадок. Работа с доменными именами — лишь его маленькая часть. Для дальнейшего чтения рекомендую:
Некоторые из моих коллег испытывают проблемы на своих компьютерах Macintosh - разрешение DNS не работает под Mac OS X. Они запускают Snow Leopard 10.6.8. Они могут использовать DNS на виртуальной машине Windows 7 (VMware Fusion 3.1.3), работающей под OS X. Компьютеры - это 15 "MacBook Pros, модель начала 2011 года.
Вещи, которые они пробовали, которые не сработали:
- включение /выключение аэропорта
- перезагрузка
- используя проводное соединение вместо wifi
- удаление учетных данных подключения и добавление его снова
- отключить брандмауэр Mac
- с использованием фиксированного статического IP
- настройка DNS-серверов вручную
- перезапуск mDNSResponder
- исправления из этот другой вопрос
ИЗМЕНИТЬ ответ MartÃn:
â € ¢ Вы можете использовать DNS-сервер, который хотите использовать?
â € ¢ Что такое IP-адрес (ы) DNS-адресов, которые вы хотите использовать?
Это DNS-сервер компании, который предоставляется с DHCP, он хорошо работает для другие люди. Я также пробовал Google 8.8.4.4 и 205.171.3.65 (который я нашел из теста GRC DNS Benchmark как самый быстрый).
â € ¢ Пробовали ли вы использовать 8.8.8.8 (google) или любой из OpenDNS 208.67.222.222 или 208.67.220.220?
Это не работает, см. вывод Google Chrome:
â € ¢ Вы можете пинговать эти хосты?
â € ¢ создание пустого пользователя
Была создана гостевая учетная запись гостя, проблема DNS была гостевой аккаунт.
â € ¢ nslookup и копайте оба, работайте нормально
â € ¢ также очистка кеша DNS была выполнена, но это не помогло
РЕДАКТИРОВАТЬ 2 :
Получается, что решение было отскочить mDNSResponder:
Это было получено другим сотрудником из этот вопрос о неисправности сервера .
OS X 10.10.0 Â 10.10.3, Yosemite
OS X 10.10.4+, Yosemite
В OSX 10.10.4 mDNSRответчик был повторно введено . Так что используйте первый, который снова будет работать.
На самом деле, я думаю, вы можете использовать
Эти команды используют динамическое хранилище в configd, в отличие от файлов flatfiles в /etc, которые часто читаются только в однопользовательском режиме и для не-сетевых систем.
У меня возникла одна и та же проблема . И при перезапуске mDNSResponder, похоже, «работает», перезагружая его пару раз каждый час, вроде отстой.
Итак, на данный момент я «решил» проблему, выполнив dnsmasq локально. Для этого:
-
Создайте dnsmasq (загрузите tgz и make или brew install dnsmasq )
Поместите это в файл dnsmasq.conf :
Поместите это в файл resolv.conf , который находится в том же каталоге, что и файл dnsmasq.conf (nb: not /etc/resolv.conf ):
Запустите dnsmasq с помощью sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf . Результат должен выглядеть примерно так:
Откройте настройки сети и убедитесь, что 127.0.0.1 - единственный DNS-сервер (сетевые настройки -> advanced -> DNS -> добавить 127.0.0.1)
Вещи должны снова начать работать хорошо.
Как только все работает, вы можете запустить dnsmasq без параметров --no-daemon и --log-queries , поэтому начнется в фоновом режиме, и вам не нужно открывать окно терминала.
Разрешение имен под OSX (и UNIX в целом) берется из IP-адресов DNS в файле, расположенном в файле /etc/resolv.conf (который OS X автоматически генерирует, насколько я помню).
Поскольку вы пробовали практически все, что приходит мне на ум, я хотел бы спросить вас:
- Вы можете проверить DNS, который хотите использовать?
- Каковы IP-адреса (имена) DNS-серверов, которые вы хотите использовать?
- Вы пытались использовать 8.8.8.8 (google) или любой из OpenDNS 208.67.222.222 или 208.67.220.220?
- Вы можете пинговать эти хосты?
Наконец, обычно хороший тест состоит в создании пустого пользователя и в том, что этот новый пользователь демонстрирует ту же проблему. Если это не так, вы можете начать копать то, что ваш текущий пользователь имеет, что может вызвать проблему; если он также терпит неудачу, то вы знаете, что это нечто большее, чем «система».
Также просмотрите Консоль, чтобы увидеть, можете ли вы обнаружить что-то, что может быть связано (и хотелось бы здесь вставить).
И последнее, но не менее важное: ваш Mac поставляется с двумя важными командами DNS, nslookup и dig .
nslookup "для разрешения" "DNS-сервера для использования". Например:.
NSLookup - это старая команда (которая должна была быть устаревшей несколько лет назад и заменена DIG, но ее простой в использовании синтаксис был слишком хорош, чтобы убить, я думаю.), его «замена» - это dig , гораздо более мощная команда, синтаксис которой более сумасшедший.
Чтобы выполнить тот же запрос, вы должны ввести:
ANd Вот результат:
Как вы можете видеть, копать гораздо более «многословно» (что хорошо, чтобы отлаживать то, что происходит). Сила dig зависит от того, что вы можете указать, какой тип запроса вы хотите выполнить (между прочим).
В любом случае, дайте нам знать точные выходы этих команд.
У меня были те же самые те же симптомы (и тратить некоторое время на устранение неполадок), но я смог его решить, когда понял, что я испортился с помощью /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist и то, что я сделал, было каким-то образом интерпретировано как искаженное. Я восстановил из резервной копии, и машина снова смогла разрешить имена хостов.
Прежде чем приступить к решению, я также понял, что мне удалось просмотреть интернет, если я использовал прокси-сервер SOCKS5 через ssh -D и пробовал поиск DNS через туннель.
У меня была очень и очень схожая проблема, за исключением того, что симптомы были несколько разными.
Мой пользователь не смог разрешить любое имя (локальное NAS, Google и т. д.), но гость-пользователь на том же iMac (OS X 10.7.4) работал нормально.
Попытка и перезапуск mDNSRsponder, как упоминалось, работали некоторое время. Пока он будет работать, когда iMac будет переведен в спящий режим, после перезагрузки будет всегда сбрасываться.
Когда перезагрузка /перезагрузка перестала работать, я искал другие причины /решения, и я обнаружил, что это связано с моим брандмауэром. Я не знаю , что в моих настройках брандмауэра (OS X) вызывало его, но если бы я восстановил настройку брандмауэра, он сработал.
Чтобы восстановить настройки по умолчанию, которые я использовал:
Очевидно, что любые пользовательские правила будут удалены при этом восстановлении.
Я хотел поделиться своей версией этой проблемы, так как это заставляло меня печалиться в течение нескольких месяцев, и этот пост - лучшая коллекция возможных решений в сети!
Я ударил эту проблему по Йосемити (10.10). Оказывается, что демон ключей, discoveryd , был убит, поскольку он потреблял слишком много CPU.
Странная перезагрузка не вызвала перезапуска.
Я вручную перезапустил службу с помощью
, и теперь все хорошо.
У меня такая же проблема с 10.6.8. Первая поездка в Apple Store привела к восстановлению системы. Но после этого DNS снова сломался, когда я был за границей, и у меня не было системного DVD-диска. В то время я нашел этот поток и удалил /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist за @freezedpeanuts и @Tom Thorogood.
Устранила проблему, но, как ни странно, DNS прорвался в третий раз через пару дней. Я искал системный образ 10.6.3 и:
- Скопировано /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist из образа системы.
- sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
- перезагружается
Это устранило проблему.
Он прерывается периодически для меня сейчас (один раз в месяц или около того), а процедура восстановления работает до тех пор, пока не будет выполнена перезагрузка, но вы можете:
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
Обратите внимание на тех, кто по-прежнему имеет проблемы, возможно, вам придется удалить все общедоступные DNS-серверы до тех пор, пока не будет очищен кеш.
У меня была, похоже, та же проблема, что и у ОП. С помощью сетевого набора инструментов я обнаружил, что для данного сетевого имени был настроен некорректный DNS:
Я смог перенастроить DNS для данной сети и разрешить имена локальных и глобальных компьютеров при подключении к VPN.
Включение и выключение Wi-Fi снова помогло.
MacBook Pro с 10.9.1
Особенно, если вы отключите Wi-Fi и перезагрузитесь. Дополнительная задержка и запуск без IP /сетевого соединения гарантируют, что запрос на подключение к сети имеет лучшие шансы на успех.
В моем случае все остальное было хорошо: mDNSResponder работал и работал, host / nslookup работал, как /etc/resolv.conf и networksetup сообщили о правильных DNS-серверах и т. д. Несмотря на это, разрешение DNS в целом (например, с помощью ping ) неизбежно перестало работать в какой-то момент через несколько часов после загрузки.
Эта конкретная проблема может быть несколько маловероятной, но я все равно буду документировать ее здесь как ответ.
Я заметил только, когда машина начала замедляться, но было много идентичных процессов, выполняющихся . sensu-client , в частности.
Мы установили его в launchd с этим файлом plist:
Флаг -b для sensu-client делает его fork на фоне, действуя как демон. Тем не менее, все launchd видит, что исходный процесс завершен, поэтому (в соответствии с флагом KeepAlive ) он перезапускает его. Это оставляет тысячи разветвленных процессов в фоновом режиме, и даже тогда launchd не будет более мудрой в том, что он работает.
Я считаю, что эти несколько тысяч процессов (все sensu-client , программное обеспечение, на которое мы написали конфигурацию launchd для), возможно, одновременно отправляли запросы на mDNSRsponder, эффективно что приводит к локальному отказу в обслуживании кеша DNS . Убив эти процессы и зафиксировав plist, данный для запуска, в конечном итоге решил проблему.
Исправление plist состояло в том, чтобы удалить флаг -b (background /daemonise) из вызова sensu-client. Обратите внимание, что это не ошибка сенсу; этот plist был написан бывшим системным администратором в этой компании.
Вот несколько расширенных команд, которые могут помочь устранить проблему DNS:
Чтобы отладить процесс mDNSResponder , следующая команда может помочь:
Вышеуказанная команда отправит сигнал SIGINFO в процесс, который будет выгружать детали отладки в выходной журнал, который можно прочитать и проанализировать.
Как выясняется, для решения проблемы вам необходимо настроить домен поиска и добавить его в поле поискового домена в настройке dns конфигурации системы. В принципе, поисковый домен будет работать так, как это делает .local, но вместо этого он будет.
Для этого вам необходимо настроить свой поисковый домен как главную зону на вашем DNS-сервере.
У меня аналогичная проблема с поиском хост-сервера. У нас есть 21 iMacs, запущенный с сервера (El Capitan, недавно обновленный), и только один не будет связываться. Исправление обычно довольно просто через пользователей и группы в SysPref. Удаление хост-сервера и повторная привязка, поиск доступного сервера в раскрывающемся списке, но по какой-то неизвестной причине сервер указан как unkown-00-00-12-34-56-78.home , который я нашел, является MAC-адресом сервера. Я запустил это в терминале:
вернулся для привязки к серверу в SysPref, и вскоре появилась правильная опция имени сервера, а затем вернулась к «unkown-00-00-12-34-56-78.home» прямо перед моими глазами!
Это, вероятно, никому не поможет, но в случае, когда я случайно случайно создал файл в папке, когда DNS был недоступен для определенного домена:
/и т.д. /резольвера /
, и это препятствовало тому, чтобы определенное имя когда-либо разрешалось, два года спустя.
К сожалению, ничто из этого не помогло мне, и оказалось, что через час попытаться понять это и избить голову на журнальный столик .. что-то, каким-то образом . удалил /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist , и именно поэтому я столкнулся с этой проблемой.
Вот код из этой строки:
При выполнении следующих команд из принятого ответа:
вы можете столкнуться с предупреждением:
Работа не разрешена, пока включена защита целостности системы
После перехода с Snow Leopard на старую книгу Mac на Mountain Lion система не смогла разрешить DNS. Попытка, перезагрузка, ничего не помогли. Изменение WiFi на другую точку доступа (мой телефон) помогло.
Mountain Lion добавляет новое клиентское поле в настройки сети DHCP. Заполнение этого поля показало, что точка доступа Wi-Fi счастлива. Оставив его в пустом значении, ничего не получалось, хотя соединение Wi-Fi казалось успешным.
Читайте также: