DNS không phân giải trên Mac OS X

Một số đồng nghiệp của tôi gặp sự cố trên máy Mac của họ - Độ phân giải DNS không hoạt động trong Mac OS X. Họ đang chạy Snow Leopard 10.6.8. Họ có thể sử dụng DNS trong máy ảo Windows 7 (VMware Fusion 3.1.3) chạy trên OS X. Các máy tính này là 15 "MacBook Pro, model đầu năm 2011.

Những điều họ đã thử mà không hiệu quả:

• bật / tắt sân bay
• khởi động lại
• sử dụng kết nối có dây thay vì wifi
• xóa thông tin đăng nhập kết nối và thêm lại
• tắt tường lửa Mac
• sử dụng IP tĩnh cố định
• cài đặt thủ công máy chủ DNS
• khởi động lại mDNSResponder
• các bản sửa lỗi từ câu hỏi khác này

Phản hồi EDIT Câu trả lời của Martín:

• Bạn có thể ping DNS bạn muốn sử dụng không?

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

• Địa chỉ IP của (các) DNS bạn muốn sử dụng là gì?

Đây là một máy chủ DNS của công ty được cung cấp với DHCP, nó hoạt động tốt cho những người khác. Tôi cũng đã dùng thử 8.8.4.4 và 205.171.3,65 của Google (mà tôi thấy từ Điểm chuẩn DNS của GRC là nhanh nhất).

• Bạn đã thử sử dụng 8.8.8.8 (google) hoặc bất kỳ OpenDNS 208.67.222.222 hoặc 208.67.220.220 chưa?

Nó không hoạt động, xem đầu ra Google Chrome:

Không thể tìm thấy máy chủ tại www.apple.com vì việc tra cứu DNS không thành công. DNS là dịch vụ mạng dịch tên của một trang web thành địa chỉ Internet của nó. Lỗi này thường xảy ra do không có kết nối với Internet hoặc mạng bị định cấu hình sai. Nó cũng có thể do máy chủ DNS không phản hồi hoặc tường lửa ngăn Google Chrome truy cập mạng.

• Bạn có thể ping những máy chủ đó không?

$ 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

• tạo một người dùng trống

Một tài khoản người dùng khách đã được tạo, sự cố DNS vẫn còn đó khi sử dụng tài khoản khách.

• nslookup và đào cả hai đều hoạt động tốt

$ 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

• cũng xóa bộ đệm DNS đã được thực hiện nhưng không có ích

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

Hóa ra giải pháp là trả lại mDNSResponder:

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

Điều này có được bởi một đồng nghiệp khác từ câu hỏi Lỗi Máy chủ này .

OS X 10.10.0 - 10.10.3, Yosemite

Rõ ràng , mDNSResponder không tồn tại trong Yosemite (OS X 10.10). Thay vào đó, bạn có thể khởi động lại descoveryd để khắc phục những sự cố này.

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

Trong OSX 10.10.4, mDNSResponder đã được giới thiệu lại . Vì vậy, sử dụng đầu tiên sẽ làm việc lại.

Trên thực tế, tôi nghĩ rằng bạn có thể muốn sử dụng

scutil --dns

scutil -r hostname

Các lệnh này sử dụng lưu trữ động trong configd, trái ngược với các tệp phẳng trong / etc, thường chỉ được đọc trong chế độ người dùng đơn và cho các hệ thống không nối mạng.

man scutil   # or

scutil --help  

Độ phân giải tên trong OSX (và UNIX nói chung) được lấy từ các địa chỉ IP của DNS trong tệp nằm trong /etc/resolv.conf (mà OS X tự động tạo ra theo như tôi có thể nhớ).

Vì bạn đã thử hầu như mọi thứ xuất hiện trong đầu tôi, tôi muốn hỏi bạn:

• Bạn có thể ping DNS bạn muốn sử dụng không?
• Địa chỉ IP của (các) DNS bạn muốn sử dụng là gì?
• Bạn đã thử sử dụng 8.8.8.8 (google) hoặc bất kỳ OpenDNS 208.67.222.222 hoặc 208.67.220.220 chưa?
• Bạn có thể ping những máy chủ đó không?

Cuối cùng, một thử nghiệm thường hay bao gồm tạo một người dùng trống và xem liệu người dùng mới đó có biểu hiện vấn đề tương tự không. Nếu không, thì bạn có thể bắt đầu đào những gì người dùng hiện tại của bạn có thể gây ra sự cố; nếu nó cũng thất bại, thì bạn biết đây là một cái gì đó liên quan đến "hệ thống" hơn.

Ngoài ra, hãy nhìn xung quanh Bảng điều khiển để xem liệu bạn có thể phát hiện điều gì đó có thể liên quan (và muốn dán xung quanh đây).

Cuối cùng nhưng không kém phần quan trọng, máy Mac của bạn đi kèm với hai lệnh DNS quan trọng nslookupvà dig.

Vì vậy, để giải quyết www.apple.com bằng máy chủ của google, bạn nhập:

nslookup "máy chủ để giải quyết" "Máy chủ DNS sẽ sử dụng". Ví dụ:

$ 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 là một lệnh cũ (đáng lẽ đã bị từ chối vài năm trước và được thay thế bởi DIG, nhưng cú pháp dễ sử dụng của nó quá tốt để giết tôi đoán.), "Thay thế" của nó là digmột lệnh mạnh hơn nhiều, có cú pháp mạnh hơn là điên rồ hơn

Để thực hiện cùng một truy vấn, bạn nhập:

đào @ 8.8.8.8 www.apple.com

ANd đây là đầu ra:

$ 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

Như bạn có thể thấy, dig là "verbose" hơn nhiều (rất tốt để gỡ lỗi những gì đang diễn ra). Sức mạnh của đào đến từ thực tế là bạn có thể chỉ định loại truy vấn nào bạn muốn thực hiện (Trong số những thứ khác).

Trong mọi trường hợp, hãy cho chúng tôi biết đầu ra chính xác của các lệnh này.

Tôi đã gặp phải vấn đề tương tự. Và trong khi khởi động lại mDNSResponder dường như "hoạt động", khởi động lại nó một vài lần mỗi giờ.

Vì vậy, hiện tại, tôi đã "giải quyết" vấn đề bằng cách chạy dnsmasq cục bộ. Để làm việc đó:

• Xây dựng dnsmasq (tải xuống tgz và makehoặc brew install dnsmasq)

• Đặt cái này trong một dnsmasq.conftập tin:

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

• Đặt cái này trong một resolv.conftệp nằm trong cùng thư mục với dnsmasq.conftệp (nb: not /etc/resolv.conf ):

  nameserver 8.8.8.8
  nameserver 4.2.2.1
  nameserver 4.2.2.2
  

• Chạy dnsmasqvới sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf. Đầu ra sẽ trông giống như:

  ...
  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
  

• Mở Tùy chọn mạng và đảm bảo rằng đó 127.0.0.1là máy chủ DNS duy nhất (tùy chọn mạng -> nâng cao -> DNS -> thêm 127.0.0.1)

Mọi thứ sẽ bắt đầu hoạt động tốt trở lại.

Khi mọi thứ đang hoạt động, bạn có thể chạy dnsmasqmà không có các tùy chọn --no-daemonvà --log-queriesvì vậy nó sẽ bắt đầu ở chế độ nền và bạn không cần phải mở cửa sổ Terminal.

Tôi có cùng một triệu chứng giống nhau (và mất một thời gian để khắc phục sự cố) nhưng tôi đã có thể giải quyết nó khi tôi nhận ra rằng tôi đã nhầm /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistlẫn và những gì tôi làm được bằng cách nào đó được hiểu là không đúng. Tôi đã khôi phục từ bản sao lưu và máy có thể giải quyết tên máy chủ một lần nữa.

Trước khi đến với giải pháp, tôi cũng nhận ra rằng tôi có thể duyệt internet nếu tôi sử dụng proxy SOCKS5 thông qua ssh -Dvà thử tra cứu DNS qua đường hầm.

Tôi đã có một vấn đề rất, rất giống nhau, ngoại trừ các triệu chứng hơi khác nhau.

Người dùng của tôi không thể giải quyết bất kỳ tên nào (NAS cục bộ, Google, v.v.) nhưng một người dùng khách trên cùng một iMac (OS X 10.7.4) đã hoạt động tốt.

Flushing và khởi động lại mDNSResponder như đã đề cập trong một thời gian. Mặc dù nó sẽ vẫn hoạt động khi iMac được đặt ở chế độ ngủ, nhưng nó sẽ luôn bị lỗi khi được khởi động lại.

Khi xả / khởi động lại ngừng hoạt động tôi đã tìm kiếm các lý do / giải pháp khác và tôi thấy rằng nó có liên quan đến tường lửa của tôi. Tôi không biết những gì trong cài đặt tường lửa (OS X) của tôi đã gây ra nó, nhưng nếu tôi khôi phục cài đặt tường lửa thì nó hoạt động.

Để khôi phục cài đặt mặc định tôi đã sử dụng:

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

Rõ ràng bất kỳ quy tắc tùy chỉnh sẽ được gỡ bỏ với khôi phục này.

Tôi muốn chia sẻ phiên bản của mình về vấn đề này vì nó đã khiến tôi đau buồn trong nhiều tháng và bài đăng này là bộ sưu tập tốt nhất các giải pháp có thể có trên mạng!

Tôi gặp vấn đề này trên Yosemite (10.10). Hóa ra là một daemon quan trọng discoveryd, đã bị giết vì nó đang tiêu tốn quá nhiều 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 

Việc khởi động lại một cách kỳ lạ đã không khiến nó được khởi động lại.

Tôi tự khởi động lại dịch vụ với:

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

và bây giờ tất cả đều tốt

Tôi đang gặp vấn đề tương tự với 10.6.8. Chuyến đi đầu tiên đến Apple Store đã dẫn đến việc khôi phục hệ thống. Nhưng, sau đó, DNS lại bị hỏng khi tôi ở nước ngoài và không có DVD hệ thống với tôi. Lúc đó tôi đã tìm thấy chủ đề này và xóa /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistmỗi @freezingpeanuts và @Tom Thorogood.

Nó đã khắc phục sự cố, nhưng thật đáng ngạc nhiên, DNS đã bị hỏng lần thứ ba vài ngày sau đó. Tôi đã săn lùng một hình ảnh hệ thống của 10.6.3 và:

1. Sao chép /System/Library/LaunchDaemons/com.apple.mDNSResponder.plisttừ hình ảnh hệ thống.
2. sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
3. Khởi động lại

Điều đó đã khắc phục vấn đề.

Nó phá vỡ định kỳ đối với tôi bây giờ (mỗi tháng một lần hoặc lâu hơn) và quy trình khôi phục được thực hiện theo các bước ở trên, ngoại trừ thay vì khởi động lại, bạn có thể:

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

Xin lưu ý với bất kỳ ai vẫn gặp sự cố, bạn có thể phải xóa mọi máy chủ DNS công cộng cho đến khi bộ nhớ cache bị xóa.

Tôi dường như có cùng một vấn đề với OP. Sử dụng bộ công cụ mạng, tôi thấy rằng với tên mạng đã cho, một số DNS sai đã được định cấu hình:

networksetup -getdnsservers <networkname>

liệt kê 192.168.0.1 dưới dạng DNS. Sử dụng scutil --dns Tôi đã có kết quả tương đương, liệt kê trình phân giải # 2 đã sử dụng máy chủ tên [0]: 192.168.0.1.

Sử dụng lệnh

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

Tôi đã có thể cấu hình lại DNS cho mạng đã cho và giải quyết tên của các máy cục bộ và toàn cầu khi được kết nối với VPN.

Trong trường hợp của tôi, mọi thứ khác đều ổn: mDNSResponder đang chạy và hoạt động, host/ nslookupđã hoạt động, cả hai /etc/resolv.confvà networksetupbáo cáo đúng máy chủ DNS, v.v. Mặc dù vậy, độ phân giải DNS nói chung pingchắc chắn đã ngừng hoạt động vào một vài giờ sau đó khởi động.

Vấn đề cụ thể này có thể hơi khó xảy ra, nhưng dù sao tôi cũng sẽ ghi nhận nó ở đây như một câu trả lời.

Tôi chỉ nhận thấy khi máy bắt đầu chạy chậm, nhưng có rất nhiều quá trình giống hệt nhau đang chạy . sensu-client, đặc biệt.

Chúng tôi đã cấu hình nó trong launchd với tệp plist này:

<?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>

Các -blá cờ để sensu-clientlàm cho nó ngã ba để nền, đóng vai trò như một daemon. Tuy nhiên, tất cả đều launchdthấy rằng quá trình ban đầu đã chấm dứt, vì vậy (theo KeepAlivecờ) nó khởi động lại nó. Điều này để lại hàng ngàn quá trình rẽ nhánh trong nền, và thậm chí sau đó launchd sẽ không có gì khôn ngoan hơn với thực tế là nó đang chạy.

Tôi tin rằng vài nghìn quy trình này (tất cả sensu-client, phần mềm chúng tôi đã viết cấu hình launchd cho) có thể đã đồng thời thực hiện các yêu cầu tới mDNSResponder, dẫn đến việc từ chối dịch vụ bộ đệm DNS cục bộ . Giết chết các quá trình này và sửa chữa các nguyên tắc được đưa ra cho launchd cuối cùng đã giải quyết được vấn đề.

Việc sửa lỗi plist chỉ là xóa -bcờ (nền / daemonise) khỏi lệnh gọi Sensu-client. Lưu ý rằng đây không phải là lỗi của Sensu; Plist này được viết bởi một cựu quản trị hệ thống tại công ty này.

Dưới đây là một số lệnh nâng cao có thể giúp khắc phục sự cố DNS:

• Chạy digđể liệt kê các máy chủ tên gốc.
• Chạy dig example.comđể chạy tra cứu DNS cho example.comtên miền.
• Liệt kê các cổng phần cứng của bạn bằng cách : networksetup -listallhardwareports.
• Kiểm tra đầu ra của gói DHCP / BOOTP mà máy khách chấp nhận từ máy chủ DHCP / BOOTP bằng cách : ipconfig getpacket en0.
• Kiểm tra cấu hình DNS của bạn bằng cách : scutil --dns.
• Xác minh rằng mDNSResponderquá trình đang chạy bởi : ps wuax | grep mDNSResponder.
• Flush ARP mục dịch bằng cách: arp -ad(chạy man arpđể được giúp đỡ). ^nguồn

Để gỡ lỗi mDNSResponderquá trình, lệnh sau có thể giúp:

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

Lệnh trên sẽ gửi SIGINFOtín hiệu đến quá trình sẽ chuyển các chi tiết gỡ lỗi vào đầu ra nhật ký có thể được đọc và phân tích.

Tắt và bật lại Wi-Fi.

^{MacBook Pro với 10.9.1}

Đặc biệt nếu bạn tắt wifi rồi khởi động lại. Việc trì hoãn thêm và bắt đầu không có kết nối IP / mạng đảm bảo yêu cầu tham gia lại mạng có cơ hội thành công cao hơn.

Điều này có lẽ sẽ không giúp được ai, nhưng trong trường hợp, tôi đã vô tình tạo ra một tệp trong thư mục, khi DNS bị hỏng cho một tên miền cụ thể:

/ etc / decver /

và điều này đã ngăn cản một cái tên cụ thể không bao giờ được giải quyết, hai năm sau.

Thật không may, điều này không giúp được gì cho tôi, và bật ra sau một giờ cố gắng tìm ra nó và đập đầu tôi vào bàn cà phê .. một cái gì đó, bằng cách nào đó, ở đâu đó ... đã gỡ bỏ /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist tập tin, và đó là lý do tôi gặp vấn đề này.

Nhận ra điều này khi tôi thấy thông báo lỗi này: /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist: No such file or directory

Đây là bản sao của phiên bản từ El Capitan: https://gist.github.com/tripflex/e7147690d1768dc74b1dd626614573c0

Đây là mã từ ý chính đó:

<?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>

Hóa ra, để giải quyết vấn đề, bạn phải định cấu hình miền tìm kiếm và thêm nó vào trường miền tìm kiếm trong cấu hình dns của System Preferences. Về cơ bản, miền tìm kiếm sẽ hoạt động theo cách mà .local thực hiện, nhưng thay vào đó sẽ là như vậy.

Bạn phải thiết lập miền tìm kiếm của mình dưới dạng vùng chính trong máy chủ dns của bạn để điều này hoạt động.

Tôi gặp vấn đề tương tự với việc tìm máy chủ. Chúng tôi có 21 iMac chạy từ Máy chủ (El Capitan, được nâng cấp gần đây) và chỉ có một chiếc không bị ràng buộc. Cách khắc phục thường khá đơn giản thông qua Người dùng và Nhóm trong SysPref. Xóa máy chủ lưu trữ và liên kết lại, tìm máy chủ khả dụng trong tùy chọn thả xuống, nhưng vì một số lý do không xác định, máy chủ được liệt kê là unkown-00-00-12-34-56-78.homeđịa chỉ MAC của máy chủ. Tôi đã chạy cái này trong terminal:

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

và

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

quay trở lại để liên kết với máy chủ trong SysPref và tùy chọn tên máy chủ chính xác xuất hiện nhanh chóng và sau đó đổi lại thành "unkown-00-00-12-34-56-78.home" ngay trước mắt tôi!

Khi làm theo lệnh từ câu trả lời được chấp nhận:

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

bạn có thể gặp phải cảnh báo:

Hoạt động không được phép trong khi Bảo vệ toàn vẹn hệ thống được tham gia

Bạn cần tắt nó đi. Toàn bộ hướng dẫn tại đây: https://www.howtogeek.com/230424/how-to-disable-system-integrity-protection-on-a-mac-and-why-you-shouldnt/

Trong trường hợp của tôi, tôi đã cài đặt OpenDNS trước đây và nó không bị xóa sạch. Có một số quy trình liên quan đến dns đang chạy như DNSdscrypt-proxy. Tôi không thể buộc họ thoát khỏi Trình giám sát hoạt động nhưng tôi có thể ngăn họ khởi động lại bằng cách xóa tệp .plist trong Library / LaunchDaemons.

Chuyển đến Cài đặt -> Mạng -> Nâng cao -> DNS. Sau đó thực hiện bất kỳ thay đổi nào theo nghĩa đen đối với DNS (ví dụ: sắp xếp lại các mục DNS của bạn). Sau đó bấm "Ok" theo sau là "Áp dụng" trên màn hình tiếp theo. Đừng bị lừa khi nghĩ rằng sự thay đổi cụ thể mà bạn đã thực hiện là đáng kể; đó là điều kỳ diệu của nút "Áp dụng".

~ $  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

Điều làm việc cho tôi là xóa tất cả các mục máy chủ khỏi Máy chủ DNS và Miền tìm kiếm khỏi:

Tùy chọn hệ thống → Mạng → Nâng cao ... → DNS

Sau khi nâng cấp từ Snow Leopard trên Mac Book cũ lên Mountain Lion, hệ thống không thể phân giải DNS. Đỏ bừng, khởi động lại, không có gì giúp được. Thay đổi WiFi thành một điểm truy cập khác (điện thoại của tôi) đã giúp.

Mountain Lion thêm trường khách mới vào cài đặt mạng DHCP. Điền vào lĩnh vực này dường như làm cho các điểm truy cập wifi hạnh phúc. Để trống nó có nghĩa là không có gì được thông qua, mặc dù kết nối wifi dường như thành công.