DNS не вирішується на Mac OS X

У деяких моїх колег виникають проблеми з Macs - роздільна здатність DNS не працює в Mac OS X. У них працює Snow Leopard 10.6.8. Вони можуть використовувати DNS у віртуальній машині Windows 7 (VMware Fusion 3.1.3), що працює під ОС X. Комп'ютери мають 15-дюймовий MacBook Pros, модель початку 2011 року.

Те, що вони спробували, не спрацювало:

• включення / вимкнення аеропорту
• перезавантаження
• використовуючи дротовий зв’язок замість wifi
• видалення облікових даних підключення та додавання їх знову
• відключення брандмауера Mac
• з використанням фіксованого статичного IP
• ручне налаштування DNS-серверів
• перезапуск mDNSResponder
• виправлення з цього іншого питання

Відповідь EDIT Відповідь Мартіна:

• Чи можете ви про ping DNS, який ви хочете використовувати?

$ ping apple.com
ping: cannot resolve apple.com: Unknown host

• Що таке / є IP-адреса DNS, які ви хочете використовувати?

Це сервер DNS компанії, який надається з DHCP, він добре працює для інших людей. Я також спробував 8.8.4.4 та 205.171.3.65 Google (які я виявив, що DNS Benchmark GRC є найшвидшим).

• Чи намагалися ви використовувати 8.8.8.8 (google) або будь-який із OpenDNS 208.67.222.222 або 208.67.220.220?

Не працює, див. Вихід Google Chrome:

Неможливо знайти сервер на веб-сайті www.apple.com, оскільки не вдалося знайти DNS. DNS - послуга мережі, яка переводить ім’я веб-сайту на його Інтернет-адресу. Ця помилка найчастіше викликана відсутністю підключення до Інтернету чи неправильно налаштованої мережі. Він також може бути викликаний невідповідним сервером DNS або брандмауером, що перешкоджає Google Chrome отримувати доступ до мережі.

• Чи можете пінг цих хостів?

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from
8.8.8.8: icmp_seq=0 ttl=58 time=3.925 ms

• створення порожнього користувача

Було створено обліковий запис гостя, проблема DNS все ще існувала під час використання облікового запису гостя.

• nslookup і копати обидві роботи добре

$ nslookup www.apple.com 8.8.8.8
Server:  8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
www.apple.com canonical name = www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net canonical name = e3191.c.akamaiedge.net.
Name: e3191.c.akamaiedge.net
Address: 184.24.141.15

$ dig @8.8.8.8 www.apple.com
; <<>> DiG 9.6.0-APPLE-P2 <<>> @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11298
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;www.apple.com.   IN A
;; ANSWER SECTION:
www.apple.com.  1041 IN CNAME www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 38 IN CNAME www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 8794 IN CNAME e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 17 IN A 184.24.141.15
;; Query time: 4 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Oct 4 09:25:28 2011
;; MSG SIZE  rcvd: 158

• також було виконано промивання кешу DNS, але це не допомогло

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

EDIT 2 :

$ cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
domain {redacted}.com
nameserver 8.8.8.8
nameserver 208.67.222.222

Виявляється, рішення полягало у відмовці mDNSResponder:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Це було отримано іншим колегою з цього питання про помилку сервера .

OS X 10.10.0 - 10.10.3, Йосеміт

Мабуть , mDNSResponder не існує в Йосеміті (OS X 10.10). Ви можете перезапустити descoveryd замість цього, щоб виправити ці проблеми.

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist

OS X 10.10.4+, Yosemite

В OSX 10.10.4 mDNSResponder був знову введений . Тому використовуйте перший, він спрацює знову.

Насправді, я думаю, ви можете скористатися

scutil --dns

scutil -r hostname

Ці команди використовують динамічне зберігання в configd, на відміну від flatfiles в / etc, які часто читаються лише в режимі одиночного користувача та для немережевих систем.

man scutil   # or

scutil --help  

Дозвіл імені в 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.

Отже, щоб вирішити www.apple.com за допомогою сервера google, слід ввести:

nslookup "хост для вирішення" "DNS-сервер для використання". Наприклад:

$ nslookup www.apple.com 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
www.apple.com   canonical name = www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net    canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net   canonical name = e3191.c.akamaiedge.net.
Name:   e3191.c.akamaiedge.net
Address: 184.24.141.15

NSLookup - це стара команда (яка мала бути устареною кілька років тому і замінена на DIG, але її простий у використанні синтаксис був надто гарним, щоб вбити, я думаю.), Її "заміна" є digнабагато більш потужною командою, синтаксис якої божевільніша.

Щоб виконати той самий запит, слід ввести:

копати @ 8.8.8.8 www.apple.com

А ось результат:

$ dig @8.8.8.8 www.apple.com

; <<>> DiG 9.7.3 <<>> @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17356
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.apple.com.         IN  A

;; ANSWER SECTION:
www.apple.com.      1782    IN  CNAME   www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 42 IN CNAME   www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 21581 IN CNAME   e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 2   IN  A   184.24.141.15

;; Query time: 26 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Oct  3 21:21:49 2011
;; MSG SIZE  rcvd: 158

Як бачите, копати набагато більше "багатослівно" (що добре налагодити, що за хек). Потужність копання походить від того, що ви можете вказати, який тип запиту ви хочете виконати (Крім усього іншого).

У будь-якому випадку, повідомте нам точні результати цих команд.

У мене виникла та ж проблема ... І під час перезавантаження mDNSResponder, здається, "працює", перезавантажуючи її пару разів кожну годину, висмоктується.

Отже, наразі я "вирішив" проблему, запустивши dnsmasq локально. Для цього:

• Побудуйте dnsmasq (завантажте tgz та makeабо brew install dnsmasq)

• Помістіть це у dnsmasq.confфайл:

  resolv-file=resolv.conf
  user=nobody
  group=nobody
  interface=lo0
  cache-size=1024
  

• Помістіть це у resolv.confфайл, який знаходиться в тому ж каталозі, що і dnsmasq.confфайл (nb: not /etc/resolv.conf ):

  nameserver 8.8.8.8
  nameserver 4.2.2.1
  nameserver 4.2.2.2
  

• Бігайте dnsmasqз sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf. Вихід повинен виглядати приблизно так:

  ...
  dnsmasq: reading resolv.conf
  dnsmasq: using nameserver 4.2.2.1#53
  dnsmasq: using nameserver 4.2.2.2#53
  dnsmasq: using nameserver 8.8.8.8#53
  dnsmasq: read /etc/hosts - 6 addresses
  

• Відкрийте налаштування мережі та переконайтесь, що 127.0.0.1це єдиний сервер DNS (налаштування мережі -> розширений -> DNS -> додати 127.0.0.1)

Речі повинні знову почати працювати добре.

Після того, як все працює, ви можете запустити dnsmasqбез параметрів --no-daemonта --log-queriesпараметрів, так що він запуститься у фоновому режимі, і вам не потрібно тримати вікно терміналу відкритим.

У мене були такі ж самі симптоми (і я витрачав деякий час на усунення несправностей), але мені вдалося усунути це, коли зрозумів, що я заплутався /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistі що я робив, якось інтерпретували як неправильне. Я відновився з резервної копії, і машина знову змогла вирішити імена хостів.

Перш ніж прийти до рішення, я також зрозумів, що мені вдається переглядати Інтернет, якщо я використовую проксі-сервер SOCKS5 ssh -Dі намагаюся шукати DNS через тунель.

У мене було дуже-дуже схоже питання, за винятком того, що симптоми були дещо іншими.

Мій користувач не міг вирішити жодне ім’я (локальні NAS, Google тощо), але гостьовий користувач у тому ж iMac (OS X 10.7.4) працював чудово.

Промивання та перезапуск mDNSResponder, як згадувалося, працювали деякий час. Хоча він і надалі працюватиме, коли iMac перебуває у режимі сну, він завжди вийде з ладу, перезавантажившись.

Коли змивка / перезапуск перестала працювати, я шукав інші причини / рішення і виявив, що це пов’язано з моїм брандмауером. Я не знаю, що в настройках брандмауера (OS X) викликало це, але якщо я відновив налаштування брандмауера, він працював.

Для відновлення параметрів за замовчуванням я використав:

sudo cp /usr/libexec/ApplicationFirewall/com.apple.alf.plist /Library/Preferences/com.apple.alf.plist

Очевидно, що будь-які спеціальні правила будуть видалені з цим відновленням.

Я хотів поділитися своєю версією цього випуску, оскільки це викликає у мене горе і вимикання місяцями, і ця публікація - найкраща колекція можливих рішень в мережі!

Я потрапив на цю проблему на Йосеміті (10.10). Виявляється, ключовий демон, discoverydбув убитий, оскільки він споживав занадто багато процесора.

2014/10/22 3:50:07.000 PM kernel[0]: process discoveryd[49] thread 1251 caught burning CPU! It used more than 50% CPU (Actual recent usage: 68%) over 180 seconds. thread lifetime cpu usage 90.016372 seconds, (74.516637 user, 15.499735 system) ledger info: balance: 90007570271 credit: 90007570271 debit: 0 limit: 90000000000 (50%) period: 180000000000 time since last refill (ns): 131905306167 

Дивно перезавантаження не призвело до його перезавантаження.

Я вручну перезапустив службу за допомогою:

sudo launchctl kickstart -k system/com.apple.networking.discoveryd

і зараз все добре.

У мене така ж проблема з 10.6.8. Перша поїздка в Apple Store призвела до відновлення системи. Але після цього DNS знову зламався, коли я був за кордоном і не мав при собі системного DVD. Тоді я знайшов цю тему і видалив /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistper @freezedpeanuts та @Tom Thorogood.

Це вирішило проблему, але, що дивно, DNS зламався втретє через пару днів. Я знайшов зображення системи 10.6.3 і:

1. Скопійовано /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistіз зображення системи.
2. sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
3. Перезавантажено

Це вирішило проблему.

Зараз у мене періодично відбувається перерва (раз на місяць або близько того), і процедура відновлення знижується до вищезазначених кроків, за винятком випадків, замість того, щоб перезавантажувати:

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Будь ласка, зверніть увагу на те, що все ще виникають проблеми, можливо, доведеться видалити будь-які загальнодоступні сервери DNS, поки кеш не буде очищено.

У мене була, здавалося б, така ж проблема, як у ОП. Використовуючи інструмент networksetup, я виявив, що для даного мережевого імені було налаштовано кілька неправильних DNS:

networksetup -getdnsservers <networkname>

перелічено 192.168.0.1 як DNS. Використовуючи scutil --dns, я отримав порівнянні результати, перерахувавши, що роздільник 2 використовував іменний сервер [0]: 192.168.0.1.

Використання команди

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

Мені вдалося налаштувати DNS для даної мережі та вирішити назви локальних та глобальних машин при підключенні до VPN.

У моєму випадку все інше було добре: mDNSResponder працював і працював, host/ nslookupпрацював, /etc/resolv.confі networksetupповідомляв про правильні DNS-сервери тощо. Незважаючи на все, роздільна здатність DNS взагалі (наприклад, з ping) неминуче перестала працювати в якийсь момент через кілька годин після завантаження.

Ця конкретна проблема може бути дещо малоймовірною, але я все одно задокументую її як відповідь.

Я помітив лише, коли машина почала гальмувати, але там було запущено багато однакових процесів . sensu-clientконкретно.

У нас це було налаштовано під час запуску цього файлу плістів:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd>
<plist version="1.0">
  <dict>
  <key>KeepAlive</key>
  <true/>
  <key>RunAtLoad</key>
  <true/>
  <key>WorkingDirectory</key>
  <string>/etc/sensu</string>
  <key>UserName</key>
  <string>root</string>
  <key>Label</key><string>org.sensuapp.sensu-client</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/bin/sensu-client</string>
      <string>-d/etc/sensu/conf.d/</string>
      <string>-b</string>
    </array>
  </dict>
</plist>

-bПрапор sensu-clientробить його розщедритися на задній план, що діє в якості демона. Однак все launchdбачить, що початковий процес припиняється, тому (відповідно до KeepAliveпрапора) він його перезапускає. Це залишає тисячі роздвоєних процесів у фоновому режимі, і навіть тоді запущений не буде мудрішим до того, що він працює.

Я вважаю, що ці кілька тисяч процесів (все sensu-clientце програмне забезпечення, для якого ми написали конфігурацію запуску), можливо, одночасно надсилали запити до mDNSResponder, що фактично призводить до локального відмови в обслуговуванні кешу DNS . Вбивство цих процесів і виправлення списку, що дається для запуску, врешті вирішили проблему.

Виправлення в плісті полягало лише в тому, щоб видалити -bпрапор (фон / демон) із виклику sensu-client. Зауважте, що це не вина сенсу; цей список був написаний колишнім системним адміністратором цієї компанії.

Ось кілька додаткових команд, які можуть допомогти вирішити проблему з DNS:

• Виконайте digсписок серверів імен кореня.
• Запустіть, dig example.comщоб запустити пошук DNS для example.comдомену.
• Перелічіть ваші апаратні порти на: networksetup -listallhardwareports.
• Перевірте вихід DHCP / BOOTP пакета, клієнт прийнятого від сервера DHCP / BOOTP по: ipconfig getpacket en0.
• Перевірте конфігурацію DNS з допомогою: scutil --dns.
• Переконайтеся в тому, що mDNSResponderпроцес запущений з допомогою: ps wuax | grep mDNSResponder.
• Очистіть записи перекладу ARP за допомогою: arp -ad(запустіть man arpдовідку). ^{джерело}

Для налагодження mDNSResponderпроцесу може допомогти наступна команда:

(sleep 1 && sudo killall -INFO mDNSResponder &); log stream | grep mDNSResponder

Вищевказана команда буде надсилати SIGINFOсигнал до процесу, який скидає налагоджувальні дані у вихідний журнал, який можна прочитати та проаналізувати.

Вимкнення та ввімкнення Wi-Fi знову допомогло.

^{MacBook Pro з 10.9.1}

Особливо, якщо вимкнути wifi, а потім перезавантажити. Додаткова затримка та початок відсутності з'єднання IP / мережі забезпечують, що запит на повторне приєднання до мережі має більше шансів на успіх.

Це, мабуть, нікому не допоможе, але у випадку, якщо я випадково якийсь час тому створив файл у папці, коли DNS був відключений для певного домену:

/ і т.д. / резольвер /

і це заважало двом рокам пізніше вирішити конкретну назву.

На жаль, нічого з цього мені не допомогло, і виявилося через годину спроб розібратися і бити головою об журнальний столик .. щось, якось, десь ... вилучив /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistфайл, і це стало причиною виникнення цієї проблеми.

Зрозумів це, коли побачив це повідомлення про помилку: /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist: No such file or directory

Ось копія версії від El Capitan: https://gist.github.com/tripflex/e7147690d1768dc74b1dd626614573c0

Ось код із цієї суті:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.apple.mDNSResponder.reloaded</string>
    <key>OnDemand</key>
    <false/>
    <key>InitGroups</key>
    <false/>
    <key>UserName</key>
    <string>_mdnsresponder</string>
    <key>GroupName</key>
    <string>_mdnsresponder</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/sbin/mDNSResponder</string>
    </array>
    <key>MachServices</key>
    <dict>
        <key>com.apple.mDNSResponder</key>
        <true/>
            <key>com.apple.mDNSResponder.dnsproxy</key>
            <true/>
    </dict>
    <key>Sockets</key>
    <dict>
        <key>Listeners</key>
        <dict>
            <key>SockFamily</key>
            <string>Unix</string>
            <key>SockPathName</key>
            <string>/var/run/mDNSResponder</string>
            <key>SockPathMode</key>
            <integer>438</integer>
        </dict>
    </dict>
    <key>POSIXSpawnType</key>
    <string>Interactive</string>
    <key>EnablePressuredExit</key>
    <false/>
</dict>
</plist>

Як виявляється, для вирішення проблеми вам доведеться налаштувати пошуковий домен та додати його до поля пошукового домену в розділі Налаштування системи dns. В основному, пошуковий домен буде працювати так, як це робить .local, але натомість він буде.

Вам потрібно налаштувати пошуковий домен як головну зону на сервері dns, щоб це працювало.

У мене схожа проблема з пошуком хост-сервера. У нас працює 21 iMacs із Сервера (El Capitan, нещодавно оновлений), і лише один не зв’яжеться. Виправлення, як правило, досить просте через користувачів та групи в SysPref. Видалення хост-сервера та повторне прив’язування, пошук наявного сервера у спадному варіанті, але з незрозумілої причини сервер вказаний як unkown-00-00-12-34-56-78.home, який я знайшов - це MAC-адреса сервера. Я запустив це в терміналі:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

і

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

повернувся, щоб прив’язатись до сервера в SysPref, і правильний варіант імені сервера ненадовго з'явився, а потім змінився назад на "unkown-00-00-12-34-56-78.home" прямо перед моїми очима!

При наступних командах із прийнятої відповіді:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

ви можете зіткнутися з попередженням:

Операція заборонена, поки захищена цілісність системи

Вимкнути його потрібно. Повна інструкція тут: https://www.howtogeek.com/230424/how-to-disable-system-integrity-protection-on-a-mac-and-why-you-shouldnt/

У моєму випадку у мене був встановлений OpenDNS раніше, і його не було видалено чисто. Було запущено кілька dns-процесів, таких як DNSdnscrypt-proxy. Я не міг змусити вийти з них у "Монітор активності", але мені вдалося зупинити їх запуск при перезапуску, видаливши файл .plist у бібліотеці / LaunchDaemons.

Перейдіть у Налаштування -> Мережа -> Додатково -> DNS. Потім внесіть буквально будь-які зміни в DNS (наприклад, переупорядкуйте записи DNS). Потім натисніть «Ок», а потім «Застосувати» на наступному екрані. Не обманюйте думки, що конкретна зміна, яку ви внесли, була суттєвою; це магія кнопки «Застосувати».

~ $  time nslookup www.google.com
;; connection timed out; no servers could be reached


real    0m21.041s
user    0m0.006s
sys     0m0.010s

 ~ $  time nslookup www.google.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   www.google.com
Address: 172.217.5.4


real    0m0.079s
user    0m0.006s
sys     0m0.010s

Мені вдалося видалити всі записи сервера з DNS-серверів та пошукових доменів:

Налаштування системи → Мережа → Розширений ... → DNS

Після оновлення від Snow Leopard до старої Mac Book до Mountain Lion система не змогла вирішити DNS. Промивання, перезапуск, нічого не допомогло. Допомогла зміна WiFi на іншу точку доступу (мій телефон).

Mountain Lion додає нове поле клієнта до налаштувань мережі DHCP. Заповнення цього поля, здається, зробить точку доступу до wifi задоволеною. Якщо залишити його порожнім, це означало, що нічого не виходить, навіть незважаючи на те, що з'єднання Wi-Fi здавалося успішним.