DNS, Mac OS X’te çözülmüyor

İş arkadaşlarımdan bazıları Mac'lerinde sıkıntı yaşıyor - DNS çözünürlüğü Mac OS X altında çalışmıyor. Snow Leopard 10.6.8 kullanıyorlar. DNS'yi OS X altında çalışan bir Windows 7 sanal makinesinde (VMware Fusion 3.1.3) kullanabilirler.

Denemedikleri şeyler işe yaramadı:

• havaalanını açmak / kapatmak
• rebooting
• wifi yerine kablolu bağlantı kullanma
• bağlantı kimlik bilgilerini silip tekrar ekleme
• Mac güvenlik duvarını kapatma
• sabit statik IP kullanarak
• DNS sunucularını el ile ayarlama
• mDNSResponder'ı yeniden başlatma
• bu diğer sorunun düzeltmeleri

EDIT cevabı Martín'in cevabı:

• Kullanmak istediğiniz DNS'ye ping atabilir misiniz?

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

• Kullanmak istediğiniz DNS (ler) in IP adresleri nelerdir?

Bu DHCP ile verilen bir şirket DNS sunucusudur, diğer insanlar için iyi çalışır. Ayrıca, Google’ın 8.8.4.4 ve 205.171.3.65’ini de (GRC’nin DNS Benchmark’ından en hızlı buldum) denedim.

• 8.8.8.8 (google) veya OpenDNS 208.67.222.222 veya 208.67.220.220'den herhangi birini kullanmayı denediniz mi?

Çalışmıyor, bkz. Google Chrome çıktısı:

DNS araması başarısız olduğu için www.apple.com adresinde sunucu bulunamadı. DNS, bir web sitesinin adını İnternet adresine çeviren bir şebeke servisidir. Bu hataya çoğunlukla, İnternet bağlantısı ya da yanlış yapılandırılmış bir ağ bağlantısının olmaması neden olur. Ayrıca yanıt vermeyen bir DNS sunucusu veya Google Chrome'un ağa erişmesini engelleyen bir güvenlik duvarı nedeniyle olabilir.

• Bu ev sahiplerine ping yapabilir misiniz?

$ 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

• boş kullanıcı oluşturma

Bir misafir kullanıcı hesabı oluşturuldu, misafir hesabı kullanılırken DNS sorunu hala oradaydı.

• nslookup ve her iki işe iyi kazmak

$ 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

• Ayrıca DNS önbelleğini temizleme işlemi de yapıldı ancak bu işe yaramadı

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

Çözümün mDNSResponder'ı zıplatması ortaya çıktı:

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

Bu, bu Sunucu Hatası sorusundan farklı bir iş arkadaşı tarafından elde edildi .

OS X 10.10.0 - 10.10.3, Yosemite

Anlaşılan , mDNSResponder Yosemite'de mevcut değil (OS X 10.10). Bu sorunları düzeltmek yerine kurtarmayı yeniden başlatabilirsiniz.

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'te mDNSResponder yeniden tanıtıldı . Yani ilkini kullanıp tekrar çalışacak.

Aslında, kullanmak isteyebileceğini düşünüyorum.

scutil --dns

scutil -r hostname

Bu komutlar, / etc içindeki düz dosyaların aksine, yalnızca tek kullanıcı modunda ve ağa bağlı olmayan sistemler için okunan düz dosyaların aksine, configd dosyasındaki dinamik depoyu kullanır.

man scutil   # or

scutil --help  

OSX altındaki ad çözümlemesi (ve genel olarak UNIX) /etc/resolv.conf dosyasındaki (OS X'in hatırlayabildiğim kadar otomatik olarak oluşturduğu) DNS'lerin IP adreslerinden alınır.

Neredeyse aklıma gelen her şeyi denediğiniz için, size sormak isterim:

• Kullanmak istediğiniz DNS'ye ping atabilir misiniz?
• Kullanmak istediğiniz DNS (ler) in IP adresleri nedir?
• 8.8.8.8 (google) veya OpenDNS 208.67.222.222 veya 208.67.220.220'den herhangi birini kullanmayı denediniz mi?
• Bu ev sahiplerine ping yapabilir misiniz?

Son olarak, genellikle hoş bir test, boş bir kullanıcı oluşturmaktan ve bu yeni kullanıcının aynı sorunu gösterip göstermediğini görmekten oluşur. Olmazsa, o zaman mevcut kullanıcınızın soruna neden olan şeyi kazmaya başlayabilirsiniz; Ayrıca başarısız olursa, o zaman bunun daha "sistem" ile ilgili bir şey olduğunu biliyorsunuzdur.

Ayrıca, ilişkili olabilecek bir şey tespit edip etmediğinizi (ve buraya yapıştırmak isteyip istemediğinizi) görmek için Konsolun etrafına bakın.

Son fakat en az değil, Mac'inizde iki önemli DNS komutu var nslookupve dig.

Dolayısıyla, www.apple.com'u google sunucusunu kullanarak çözmek için şunu yazmanız gerekir:

nslookup "ana makineyi" "kullanılacak DNS sunucusu" ile çözmek için. Örneğin:

$ 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 eski bir komuttur (birkaç yıl önce kullanımdan kaldırılmış ve DIG tarafından değiştirilmiş olması gerekiyordu, ancak sözdizimi kullanımı kolay sanırım öldürmek için çok iyiydi.), "Yerine koyma" digsözdizimi çok daha güçlü bir komuttur. daha çılgınca.

Aynı sorguyu gerçekleştirmek için şunu yazmanız gerekir:

8.8.8.8 @ kazmak www.apple.com

Ve burada çıktı:

$ 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

Gördüğünüz gibi, kazmak çok daha fazla "fiil" dir (ki bu haltta neler olup bittiğini hata ayıklamak iyidir). Kazmanın gücü, ne tür bir sorgu yapmak istediğinizi (başka şeylerin yanı sıra) belirtebileceğiniz gerçeğinden gelir.

Her durumda, bu komutların çıktılarını bize bildiriniz.

Aynı sorunu yaşadım… Ve mDNSResponder'ı yeniden başlatırken "çalışmak" gibi görünüyor, her saat başı emmek için birkaç kez yeniden başlatmak gibi.

Bu yüzden, şimdilik dnsmasq'ı yerel olarak çalıştırarak sorunu "çözdüm" . Bunu yapmak için:

• Dnsmasq derleyin (tgz'yi indirin makeveya brew install dnsmasq)

• Bunu bir dnsmasq.confdosyaya koyun :

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

• resolv.confBunu, dosyayla aynı dizinde bulunan bir dosyaya koyun dnsmasq.conf(nb: not /etc/resolv.conf ):

  nameserver 8.8.8.8
  nameserver 4.2.2.1
  nameserver 4.2.2.2
  

• Run dnsmasqile sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf. Çıktı şöyle bir şeye benzemelidir:

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

• Ağ Tercihleri'ni açın ve 127.0.0.1yalnızca DNS sunucusu olduğundan emin olun (ağ tercihleri ​​-> gelişmiş -> DNS -> add 127.0.0.1)

İşler tekrar güzelce çalışmaya başlamalı.

İşler bir kez çalıştıktan dnsmasqsonra --no-daemonve --log-queriesseçenekleri olmadan çalıştırabilirsiniz , böylece arka planda başlar ve bir Terminal penceresini açık tutmanıza gerek kalmaz.

Aynı kesin belirtilere sahiptim (ve sorun gidermeye biraz zaman harcadım) ancak, kendimi karıştırdığımı /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistve yaptığım şeyin bir şekilde yanlış biçimlendirilmiş olarak yorumlandığını fark ettiğimde çözebildim . Bir yedekten geri yükledim ve makine tekrar ana bilgisayar isimlerini çözebildi.

Çözüme gelmeden önce, SOCKS5 proxy kullandıysam ssh -Dve tünelden DNS aramaları denediysem internette dolaşabileceğimi de fark ettim .

Semptomların biraz farklı olması dışında, çok çok benzer bir sorun yaşadım.

Kullanıcım hiçbir adı (yerel NAS, Google vb.) Çözemedi, ancak aynı iMac'deki (OS X 10.7.4) konuk bir kullanıcı iyi çalıştı.

MDNSResponder'in temizlenmesi ve yeniden başlatılması, bir süre çalıştı. İMac uyku moduna alındığında çalışmaya devam ederse, yeniden başlatıldığında her zaman başarısız olur.

Floş / yeniden başlatma işlemi durduğunda, başka nedenler / çözümler aradım ve bunun güvenlik duvarımla ilgili olduğunu gördüm. Bilmiyorum neyi benim (OS X) güvenlik duvarı ayarlarında buna neden oldu ama ayarı güvenlik duvarı restore eğer işe yaradı.

Kullandığım varsayılan ayarları geri yüklemek için:

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

Açıkçası herhangi bir özel kural bu geri yükleme ile kaldırılmış olacak.

Bu konuyla ilgili sürümünü aylarca açıp kapatmama neden olduğu için paylaşmak istedim ve bu gönderi internetteki olası en iyi çözümler koleksiyonu!

Bu soruna Yosemite'de (10.10) çarptım. Kilit cini, çıkıyor discoverydçok fazla CPU tüketen gibi, kapalı öldürüldü.

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 

Garip bir şekilde yeniden başlatma, yeniden başlatılmasına neden olmadı.

Hizmeti şu şekilde manuel olarak yeniden başlattım:

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

ve şimdi her şey yolunda.

Aynı problemi 10.6.8 ile yaşıyorum. Bir Apple Store'a ilk gezi sistem geri yüklemesine neden oldu. Fakat ondan sonra, yurtdışındayken DNS yine bozuldu ve yanımda sistem DVD'si yoktu. O zaman bu konuyu buldum ve /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistfreezedpeanuts ve @Tom Thorogood'a göre sildim.

Sorunu çözdü, ancak şaşırtıcı bir şekilde, DNS birkaç gün sonra üçüncü kez kırıldı. 10.6.3 sistem görüntüsünü avladım ve:

1. /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistSistem görüntüsünden kopyalandı .
2. sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
3. yeniden

Bu sorunu çözdü.

Şimdi benim için düzenli aralıklarla kesiliyor (ayda bir ya da öylesine) ve geri yükleme prosedürü, yeniden başlatma yerine aşağıdaki adımları uygulamaktadır:

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

Lütfen hala sorun yaşayan herkese, önbellek temizlenene kadar genel DNS sunucularını kaldırmanız gerekebileceğini unutmayın.

Görünüşe göre OP ile aynı problem vardı. Ağ kümesi aracını kullanarak, verilen ağ adı için bazı hatalı DNS yapılandırıldığını buldum:

networksetup -getdnsservers <networkname>

192.168.0.1'yi DNS olarak listeledi. Scutil --dns kullanarak karşılaştırılabilir sonuçlara sahibim, bu # 2 çözücü adının [0] kullandığı listeleme: 192.168.0.1.

Komutu kullanmak

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

DNS'i verilen ağ için yeniden yapılandırabilir ve VPN'e bağlandığımda yerel ve küresel makinelerin adlarını çözebilirdim.

Benim durumumda, her şey iyiydi: mDNSResponder koşu ve çalışıyordu, host/ nslookupçalıştı, hem /etc/resolv.confve networksetup(örneğin tüm Buna rağmen doğru DNS sunucuları, vb genel DNS çözümlemesini bildirdi pingkaçınılmaz bir kaç saat sonra bir noktada çalışmayı durdurdu) çizme.

Bu özel problem biraz olası olmayabilir, ama yine de burada cevap olarak belgeleyeceğim.

Yalnızca makine yavaşlamaya başladığında fark ettim, ancak çalışan birçok özdeş işlem vardı . sensu-client, özellikle.

Bu plist dosya ile başlatılmasında yapılandırıldı:

<?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İçin bayrak sensu-clientbir daemon gibi davranan, arka plana çatal yapar. Bununla birlikte, tüm launchdgördüğü orijinal sürecin sona ermesidir, dolayısıyla ( KeepAlivebayrağa göre) yeniden başlatır. Bu, binlerce çatal işlemin arka planda kalmasına neden olur ve daha sonra lansman bile çalışmakta olduğu kadar akıllıca olmaz.

Bu birkaç bin işlemin (tümü sensu-clientiçin başlattığımız bir yazılım olarak yazdığımız yazılımın) eşzamanlı olarak mDNSResponder'a talepte bulunabileceğini ve etkin bir şekilde DNS önbelleğinin yerel olarak hizmet reddine yol açtığını düşünüyorum . Bu süreçleri öldürmek ve piyasaya sürmek için verilen zevki düzeltmek sonunda sorunu çözdü.

-bPist düzeltmesi sadece (arkaplan / arka plan) bayrağını sensu-istemci çağrısından kaldırmaktı . Bunun sensu'nun hatası olmadığını unutmayın; Bu pist, bu şirkette eski bir sistem yöneticisi tarafından yazıldı.

DNS sorununu gidermenize yardımcı olacak birkaç gelişmiş komut aşağıda verilmiştir:

• digKök adı sunucularını listelemek için çalıştırın .
• Etki alanı dig example.comiçin DNS araması çalıştırmak için çalıştırın example.com.
• Tarafından donanım bağlantı noktalarını listeleyin: networksetup -listallhardwareports.
• İstemci DHCP / BOOTP sunucusundan kabul DHCP / BOOTP paketinin çıkışını kontrol edin: ipconfig getpacket en0.
• Tarafından DNS yapılandırmasını kontrol edin: scutil --dns.
• Doğrulayın mDNSRespondersüreç ile çalışıyor: ps wuax | grep mDNSResponder.
• ARP çeviri girişlerini şu şekilde yıkayın: arp -ad( man arpyardım için çalıştırın ). ^kaynak

mDNSResponderİşlemde hata ayıklamak için aşağıdaki komut yardımcı olabilir:

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

Yukarıdaki komut, SIGINFOhata ayıklama ayrıntılarını okunabilen ve analiz edilebilen log çıktısına dökecek olan sürece sinyal gönderir .

Wi-Fi özelliğini kapatıp tekrar açmak yardımcı oldu.

^{MacBook Pro 10.9.1 ile}

Özellikle wifi kapatıp yeniden başlattıysanız. Ekstra gecikme ve IP / ağ bağlantısı olmadan başlatma, ağa yeniden katılma isteğinin başarılı olmak için daha iyi şansı olmasını sağlar.

Bu muhtemelen kimseye yardım etmeyecek, ancak bir süre önce yanlışlıkla bir DNS belirli bir etki alanı için aşağıdayken, klasörde bir dosya oluşturdum:

/ Etc / çözücü /

ve bu, iki yıl sonra, belirli bir ismin çözülmesini engelliyordu.

Maalesef bunların hiçbiri bana yardım etmedi ve bir saat sonra ortaya çıkmaya çalıştı ve kafamı sehpaya dayak atmaya başladı. Bir şey, bir şekilde, bir yerlerde ... /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistDosyayı kaldırdım ve bu problemin sebebi buydu.

Bu hata mesajını gördüğümde farkettim: /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist: No such file or directory

İşte El Capitan'dan bir versiyonun kopyası: https://gist.github.com/tripflex/e7147690d1768dc74b1dd626614573c0

İşte bu özlemin kodu:

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

Görünüşe göre, sorunu çözmek için, bir arama alanı yapılandırmanız ve Sistem Tercihleri ​​dns yapılandırması altındaki arama alanı alanına eklemeniz gerekir. Temel olarak, arama etki alanı .local'in yaptığı gibi çalışır, ancak bunun yerine çalışır.

Bunun için arama etki alanınızı dns sunucunuzda ana bölge olarak ayarlamanız gerekir.

Ana sunucuyu bulmakta da benzer bir sorunum var. Sunucudan çalışan 21 iMac'imiz var (El Capitan, yakın zamanda yükseltildi) ve yalnızca biri bağlanmayacak. Düzeltme genellikle SysPref'teki Kullanıcılar ve Gruplar arasında oldukça kolaydır. Ana sunucunun silinmesi ve yeniden bağlanılması, açılır seçenekte mevcut sunucunun bulunması, ancak bilinmeyen bir nedenden dolayı, sunucunun unkown-00-00-12-34-56-78.homebulduğu listelenmesi sunucunun MAC adresidir. Bu terminalde koştum:

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

ve

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

SysPref'te sunucuya geri döndü ve doğru sunucu adı seçeneği kısa bir süre belirdi ve sonra gözlerimin önündeki "unkown-00-00-12-34-56-78.home" olarak geri döndü!

Kabul edilen cevaptan gelen komutları takip ederken:

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

uyarıyla karşılaşabilirsiniz:

Sistem Bütünlüğü Koruması devrede iken işleme izin verilmez

Kapatman gerek. Buradaki tüm talimatlar: https://www.howtogeek.com/230424/how-to-disable-system-integrity-protection-on-a-mac-and-why-you-shouldnt/

Benim durumumda OpenDNS geçmişte yüklü vardı ve temiz kaldırılmadı. DNSdnscrypt-proxy gibi çalışan dns ile ilgili birkaç işlem vardı. Activity Monitor'da onları bırakmaya zorlayamadım ama .plist dosyasını Library / LaunchDaemons'taki dosyaları kaldırarak yeniden başlatmaya başlamalarını engelleyebildim.

Ayarlar -> Ağ -> Gelişmiş -> DNS. Ardından tam anlamıyla herhangi bir şekilde DNS'de değişiklik yapın (örneğin DNS girişlerinizi yeniden sıralayın). Sonra bir sonraki ekranda "Tamam" ı ve ardından "Uygula" yı tıklayın. Yaptığınız değişikliğin önemli olduğunu düşünmenize aldanmayın; "Uygula" düğmesinin büyüsü.

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

Benim için ne işe yaradı, tüm sunucu girişlerini DNS Sunucularından ve Arama Etki Alanlarından kaldırmak:

Sistem Tercihleri ​​→ Ağ → Gelişmiş ... → DNS

Eski bir Mac Book'taki Snow Leopard'dan Mountain Lion'a yükselttikten sonra, sistem DNS'yi çözemedi. Kızarma, yeniden başlatma, hiçbir şeyin yardımı olmadı. WiFi'yi farklı bir Erişim noktasına (telefonum) değiştirmek yardımcı oldu.

Mountain Lion, DHCP ağ ayarlarına yeni bir müşteri alanı ekler. Bu alanı doldurmak, wifi erişim noktasını mutlu ediyor gibiydi. Boş bırakmak, wifi bağlantısı başarılı olmuş gibi görünse de hiçbir şey yolunda gitmiyordu.