DNS无法在Mac OS X上解析

100

我的一些同事在Mac上遇到麻烦-DNS解析在Mac OS X下不起作用。他们正在运行Snow Leopard 10.6.8。他们可以在OS X下运行的Windows 7虚拟机（VMware Fusion 3.1.3）中使用DNS。计算机为15英寸MacBook Pro，2011年初型号。

他们尝试过的未成功的事情：

  • 打开/关闭机场
  • 重新启动
  • 使用有线连接代替wifi
  • 删除连接凭据并再次添加
  • 关闭Mac防火墙
  • 使用固定的静态IP
  • 手动设置DNS服务器
  • 重新启动mDNSResponder
  • 从修复这个问题，其他

编辑回复马丁的答案：

• 您可以ping您要使用的DNS吗？

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

• 您要使用的DNS的IP地址是什么？

这是DHCP附带的公司DNS服务器，对其他人很好用。我还尝试了Google的8.8.4.4和205.171.3.65（我从GRC的DNS基准测试中发现是最快的）。

• 您是否尝试过使用8.8.8.8（google）或任何OpenDNS 208.67.222.222或208.67.220.220？

它不起作用，请参阅Google Chrome输出：

找不到www.apple.com上的服务器，因为DNS查找失败。DNS是将网站名称转换为其Internet地址的网络服务。此错误通常是由于没有连接到Internet或配置错误的网络引起的。原因还可能是DNS服务器没有响应或防火墙阻止了Google Chrome浏览器访问网络。

• 您可以ping那些主机吗？

$ 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和dig都可以正常工作

$ 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

编辑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
macos  macbook  snow-leopard  network  dns 
— 卡琼·路克
source
对我来说，在狮子身上也是如此。
— dkagedal 2012年
为我在小牛队上发生的
— 10.9.4
这看起来像是一个历史问题，使用户和网络管理员的生活从豹纹变成了优胜美地。如果仍然有人看到此问题，请明确报告您是否有多个接口处于活动状态，并且获得了它的配置。从DHCP服务器（来自不同方面）。为什么？我从未在任何其他Unix上以及我的Mac（我有很多）上看到过这样的问题，但是它们都没有一个以上与DNS信息源进行通信的接口。
— 2015年
尝试更改您的DNS配置（更改订单或删除条目），为我解决了相同的问题
— mems，2017年

Answers:

90

事实证明，解决方案是反弹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，优胜美地

显然，优胜美地（OS X 10.10）中不存在mDNSResponder。您可以重新启动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+，优胜美地

在OSX 10.10.4中，已重新引入了mDNSResponder 。因此，使用第一个将再次起作用。

— 卡琼·路克
source
5
但这并不是一个令人满意的答案。我首先需要知道如何阻止它的发生。
— dkagedal，2012年
1
@dkagedal这实际上是我们将要获得的一个很好的答案-发生这种情况是因为您的mac缓存了DNS条目，以避免每次DNS查找都访问DNS服务器（可能是路由器）-这种情况经常发生。该缓存是必要的，并且很好，但是如果在找不到条目时有更好的行为（我认为这是一个错误），那将是很好的。无论如何，缓存中都会有一些超时。当我在机器上等待约10分钟时，这种情况自行解决。对于大多数用户而言，现有的行为很好，因此Apple不太可能很快改变它。
— 马特2012年
2
当然，这并不尽如人意。没有其他操作系统有此问题。DNS没有错，www.google.com的记录没有丢失，只是MacOS缓存以某种方式丢失了它并且不会重新获取它。那是一个需要修复的错误。
— dkagedal
1
在10.9上遇到了此问题，解决方案运行完美。就我而言，DNS解析的是全名，但不是简短的。
— 索林2013年
1
@Matteo也许文件不一定存在，或者可能需要为优胜美地更新答案。你有这个问题吗？运行这些命令是否可以解决问题？
— CajunLuke
10

实际上，我认为您可能想使用

scutil --dns

scutil -r hostname

这些命令使用configd中的动态存储，与/ etc中的平面文件相反，后者通常仅在单用户模式下和非联网系统中读取。

man scutil   # or

scutil --help
— gg
source
3
您无需解释为什么这些命令可以解决此问题。他们甚至吗？还是说这是对其他答案之一或其他内容的评论？
— dkagedal，2012年
scutil的一项可能优势是，不管计算机是否已发现或mDNSResponder，它都可以工作。它始于其介绍之前。
— DA文森特2015年
1
这些命令不能解决问题
— Radu Simionescu
7

OSX（通常是UNIX）下的名称解析是从/etc/resolv.conf文件中的DNS的IP地址获取的（据我所记得，OS X会自动生成该文件）。

既然您尝试了几乎所有想到的方法，所以我想问您：

  • 您可以ping您要使用的DNS吗？
  • 您要使用的DNS的IP地址是什么？
  • 您是否尝试过使用8.8.8.8（google）或任何OpenDNS 208.67.222.222或208.67.220.220？
  • 您可以ping那些主机吗？

最后，通常不错的测试包括创建一个空白用户，然后查看该新用户是否存在相同的问题。如果没有，那么您可以开始挖掘当前用户所拥有的可能导致问题的原因。如果它也失败了，那么您就知道这与“系统”有关。

还可以在控制台周围看一看，看看是否可以发现可能相关的内容（并希望在此处粘贴）。

最后但并非最不重要的一点是，您的Mac带有两个重要的DNS命令，nslookup和dig。

因此，要使用Google的服务器解析www.apple.com，请输入：

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

如您所见，dig更加“冗长”（这对于调试到底发生的事情很有好处）。挖掘的力量来自于这样一个事实，您可以指定要执行的查询类型（除其他事项外）。

无论如何，让我们知道这些命令的确切输出。

— 马丁·马可西尼（Martin Marconcini）
source
请参阅我对问题的编辑。
— CajunLuke 2011年
@CajunLuke hmmmm有趣……我介意将cat /etc/resolv.conf的输出添加到您的问题中？
— Martin Marconcini
编辑。（填充以使评论合适。）
— CajunLuke 2011年
@CajunLuke我很困惑。让我们回到根源上吧……这仅在本机上发生，并且只有在OSX下，VM才能正常运行。我开始怀疑Parallels或VMware可能会引起一些麻烦。这些VM使用哪种网络？桥接？共享？
— Martin Marconcini
1
或者，如果您想真正做空，可以随时做... 挖+做一个apple.com做空 ...
— Pryftan
7

我也遇到过同样的问题……而且，在重新启动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选项的情况下运行，因此它将在后台启动，并且无需保持终端窗口打开。

— 大卫·沃尔沃
source
我想指出的是，这是我连续16小时浏览互联网后发现的唯一解决方案，既可以让我解析公司内部名称，又可以使拆分网络正常运行。非常感谢您发表此评论。
— 罗恩·汤普森
我还要指出的是，在OS X El Capitan上，为了进行脚本设置，我将openconnect命令以及诸如networksetup -setdnsservers 127.0.0.1和包裹在python脚本中networksetup -setsearchdomains "$COMPANY_NAME".com。添加您的dnsmasq命令，一切就绪！多亏了此评论，我终于有了一个稳定的VPN解决方案。
— 罗恩·汤普森
对于将来的读者，我发现最简单的方法是在工作中放入我的盒子，确定名称服务器具有哪个IP，然后将这些IP硬编码到8.8.8.8以下的我的resolv.conf（谷歌DNS服务器）中。这样一来，所有非公司名称都可以正确解析，而不必通过公司服务器，我发现这对于保护隐私和提高速度非常有用。就硬编码而言，这些IP不会很快改变，如果确实如此，我将不会是唯一受影响的IP，并且编辑两行应该是微不足道的。
— 罗恩·汤普森
当我尝试启动dnsmasq时，它说地址127.0.0.1已被使用。我需要做什么？High Sierra
— IceFire '17
@IceFire我知道这很旧，但这意味着该端口上已经有一个服务绑定（53）。从技术上讲，这意味着它收到错误EADDRINUSE，但我不会去::至于这个答案，我觉得很有趣。我有一个类似的问题，但是我认为（希望）其他答案可以解决该问题，因为我有自己的权威DNS服务器（至少有一个我不需要为我的家庭网络启用它）本地以及我使用的是什么）。Otoh作为一个长期的Unix用户，我可以使用/etc/resolv.conf的事实很吸引人，但是将首先尝试其他方法。
— Pryftan
6

我有完全相同的症状（花了一些时间进行故障排除），但是当我意识到自己搞砸了/System/Library/LaunchDaemons/com.apple.mDNSResponder.plist并且所做的事情被解释为格式错误时，我能够解决它。我从备份还原，并且计算机能够再次解析主机名。

在提出解决方案之前，我还意识到，如果我使用SOCKS5代理ssh -D并尝试通过隧道进行DNS查找，则能够浏览Internet 。

— 冷冻花生
source
1
我的公司已经存在这个问题好几个月了，每次都会把Mac带到“ Genius bar”上，其唯一解决方案是擦除硬盘并重新开始。我看到了您的帖子，并删除了com.apple.mDNSResponder.plist，重新启动后，问题已解决。希望我能投票十亿次。
— Thomas Thorogood
1
注意删除com.apple.mDNSResponder.plist！我按照@TomThorogood的建议做了。我很难回去。即使我放回文件并重新启动，我也无法从Internet得到任何响应。该sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist比帮助。
— Pavel Binar 2014年
5

我有一个非常非常相似的问题，只是症状略有不同。

我的用户无法解析任何名称（本地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

显然，此还原将删除所有自定义规则。

我想分享这个问题的版本，因为它使我数月不休，这使我感到悲伤，这篇文章是网上可能的解决方案的最佳集合！

— 西蒙·史密斯
source
4

我在优胜美地（10.10）上遇到了这个问题。原来，一个关键守护程序，discoveryd由于消耗了太多CPU而被杀死。

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

现在一切都很好。

— 布赖恩·德·阿尔维斯
source
1
这也是我在优胜美地上的解决方案。一些细节：host，dig和Chrome可以正常工作，但是ping，telnet，ssh，firefox和safari无法解析主机名。此解决方案解决了我的问题。
— Ryan Hoegg 2015年
烦人的事情一直在我身上发生。必须重新启动服务。
— 卡勒姆·罗杰斯
2

我在10.6.8中遇到了同样的问题。第一次访问Apple Store导致系统还原。但是，此后，当我在国外时DNS再次中断，并且没有系统DVD。当时我发现了这个线程，并/System/Library/LaunchDaemons/com.apple.mDNSResponder.plist根据@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

— DKroot
source
2

我看似和OP有同样的问题。使用工具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

连接到VPN时，我能够为给定的网络重新配置DNS并解析本地和全局计算机的名称。

— 雷克斯福德
source
2

就我而言，其他一切都很好：mDNSResponder正在运行，正在工作，host/都nslookup在工作，/etc/resolv.conf并且networksetup报告了正确的DNS服务器等。尽管如此，一般来说，DNS解析（例如使用ping）不可避免地会在数小时后的某个时间停止工作开机。

这个特定的问题可能不太可能出现，但是无论如何我都会在这里记录它作为答案。

我只是注意到机器何时开始减速，但是运行着许多相同的进程。sensu-client，特别是。

我们使用以下plist文件在启动时对其进行了配置：

<?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缓存的本地拒绝服务。杀死这些进程并修复启动后的plist最终解决了问题。

plist的修复只是-b从sensu-client调用中删除（background / daemonise）标志。请注意，这不是sensu的错。该列表由该公司的一名前系统管理员撰写。

— 得分低于
source
2

以下是一些有助于解决DNS问题的高级命令：

  • 运行dig以列出根名称服务器。
  • 运行dig example.com以运行example.com域的DNS查找。
  • 通过以下方式列出您的硬件端口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进程发送信号，该进程会将调试详细信息转储到日志输出中，以供读取和分析。

— Kenorb
source
1

再次打开和关闭Wi-Fi很有帮助。

带有10.9.1的MacBook Pro

特别是如果您关闭wifi然后重新启动。额外的延迟以及从没有IP /网络连接开始，确保重新加入网络的请求获得成功的机会更大。

— 卢卡斯·麦登（Lukasz Madon）
source
1
尽管该问题可能需要进行一些编辑，但仍表明（在撰写本文时），工作人员已尝试关闭并重新打开Wi-Fi。也许我们可以收回这个答案？
— DA文森特
我没有足够的声誉在关闭和重新打开wifi的帖子中添加评论，但这对我有用。撤消答案将是愚蠢的。
+1为建议重试。多个答案可以帮助很多人，并且每个路由器都有不同的超时和行为。
— bmike
1

这可能对任何人都无济于事，但以防万一我在一段时间前无意间在文件夹中创建了一个文件，当特定域的DNS关闭时：

/ etc / resolver /

两年后，这阻止了某个特定名称的解析。

— 杰里米
source
非常感谢，这是我的问题。我已经调试了好几个小时，当我查看/ etc / resolver时，我当然找到了一个名为“ test”的文件，其中包含错误的IP ...
— keyer
1

不幸的是，这些都没有帮助我，经过一个小时的尝试，发现它并把我的头撞在茶几上，结果证明了这一点。结果是，某种方式，某处，某处...删除了/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>
— 迈尔斯
source
0

事实证明，要解决该问题，您必须配置搜索域并将其添加到“系统偏好设置dns配置”下的搜索域字段中。基本上，搜索域的工作方式类似于.local，但实际上是。

您必须将搜索域设置为dns服务器中的主区域，此功能才能起作用。

— 艺生
source
0

查找主机服务器时遇到类似的问题。我们有21台iMac从服务器运行（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”！

— cwj73
source
0

就我而言，我过去曾安装过OpenDNS，但并未彻底删除它。有几个与dns相关的进程正在运行，例如DNSdnscrypt-proxy。我无法在“活动监视器”中强制退出它们，但是通过删除Library / LaunchDaemons中的.plist文件，可以阻止它们在重新启动时启动。

— 浩
source
0

转到设置->网络->高级-> 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
— weberc2
source
0

对我有用的是从以下网站删除DNS服务器和搜索域中的所有服务器条目：

系统偏好设置→网络→高级...→DNS

— 马塞洛
source
-1

从旧的Mac Book上的Snow Leopard升级到Mountain Lion之后，系统无法解析DNS。刷新，重新启动，没有任何帮助。将WiFi更改为其他访问点（我的手机）很有帮助。

Mountain Lion将一个新的客户端字段添加到DHCP网络设置。填写此字段似乎使wifi接入点感到高兴。将其保留为空白意味着没有任何连接，即使wifi连接似乎成功了。

— xt1
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.