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


101

İş 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

Aslan üzerinde de benim için olur.
dkagedal

Benim için Mavericks, 10.9.4
greg7gkb 20

Bu, Leopard’dan Yosemite’e kadar kullanıcıların ve ağ yöneticilerinin hayatını çürüten tarihi bir soruna benziyor. Birisi hala bu sorunu görüyorsa, aktif durumda birden fazla arabiriminiz varsa ve daha da netleşiyorsa lütfen açıkça rapor edin. DHCP sunucusundan (farklı taraflardan). Neden? Hiçbir zaman Unix'lerde ve Mac'lerimin hiçbirinde (çok şeyim yok) böyle bir sorun görmedim, ancak hiçbirinde bir DNS bilgi kaynağına yönelik birden fazla arabirim yok.
dan

Benim için aynı sorunu gideren DNS yapılandırmanızı değiştirmeye çalışın (siparişi değiştirin veya girişleri kaldırın)
mems

Yanıtlar:


91

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


5
Ancak bu gerçekten tatmin edici bir cevap değil. İlk başta bunun nasıl önleneceğini bilmem gerekiyor.
dkagedal

1
@dkagedal Bu, alacağımız kadar iyi bir cevaptır - bunun nedeni, mac'unuzun DNS girişlerini önlemesi, her DNS araması için DNS sunucunuza (büyük olasılıkla yönlendiriciniz) çarpmamak için - bu çok fazla olur. Bu önbellek gerekli ve iyi, ancak bir giriş bulunamadığında daha iyi davranışlar olsaydı iyi olurdu (Bunu bir hata olarak görüyorum). Her durumda, önbellekte bir miktar zaman aşımı vardır; Makinemde 10 dakika kadar bekledim, bu durum kendiliğinden çözüldü. Kullanıcıların çoğu için, mevcut davranış iyi, bu yüzden yakında Apple tarafından herhangi bir zamanda değiştirilmesi muhtemel değildir.
Matt

2
Tabii ki bu alabildiğince iyi değil. Başka hiçbir işletim sistemi bu sorunu yaşamıyor. DNS’te yanlış bir şey yok, www.google.com’un kaydı kaybolmadı, sadece MacOS önbelleği bir şekilde kaybetti ve geri dönmeyecek. Ve bu düzeltilmesi gereken bir hata.
dkagedal

1
10.9'da bu problemi çözdüm ve çözüm mükemmel bir şekilde çalıştı. Benim durumumda DNS tam isimleri için çözüyordu ama kısa isimler için değil.
sorin

1
@Matteo Belki de dosyanın var olması gerekmiyor ya da belki de cevabın Yosemite için güncellenmesi gerekiyor. Bu sorunun var mı? Bu komutları çalıştırmak sorunu çözdü mü?
CajunLuke

10

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  

3
Bu komutların neden bu soruna yardımcı olacağını açıklamıyorsunuz. Onlar bile mi? Veya bu, diğer cevaplardan birine veya başka bir şeye yorum yapmak anlamına mı geliyor?
dkagedal

Scutil'in olası bir avantajı, bilgisayarın keşfedip keşfetmediğine veya mDNSResponder'a bakılmaksızın çalışabileceğidir. Onların tanıtılmasından önce başlıyor.
DA Vincent,

1
bu komutlar sorunu çözmüyor
Radu Simionescu

7

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.


Sorudaki düzenlememe bakın.
CajunLuke

@CajunLuke hmmmm ilginç… Sorunuzun cevabına cat /etc/resolv.conf çıktısını eklerim?
Martin Marconcini

Düzenlenen. (Yorumun sığdırılması için
dolgu

@CajunLuke şaşırdım. Köklere geri dönelim… bu sadece bu makinede olur ve sadece OSX altında, VM'ler iyidir. Parallels veya VMware'in bazı sorunlara neden olabileceğinden şüphelenmeye başladım. Bu sanal makineler ne tür ağ kullanıyor? Köprülü? Paylaşılan?
Martin Marconcini

1
Ya da gerçekten kısa istiyorsanız her zaman yapabilirsiniz ... kazmak + kısa bir apple.com ...
Pryftan

7

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.


İnterneti araştırmak için 16 saat bekledikten sonra , hem şirket içi şirket adlarını çözmeme hem de bölünmüş ağların düzgün çalışmasına izin verdiğimi bulduğum tek çözüm olduğunu belirtmek isterim. Bu yorum yaptığınız için çok teşekkür ederim.
Ron Thompson,

Ayrıca OS X El Capitan’da, betiği ayarlamak için openconnectkomutumu bir python betiğine, networksetup -setdnsservers 127.0.0.1ve gibi komutlarla sardığımı da belirtmiştim networksetup -setsearchdomains "$COMPANY_NAME".com. dnsmasqKomuta ekle ve her şey ayarlandı! Sonunda bu yorum sayesinde kararlı bir VPN çözümüm var.
Ron Thompson,

Gelecekteki okuyucular için, işyerindeki kutuma yalnızca ssh eklemeyi, ad sunucuları için hangi IP'lere sahip olduğunu belirlemeyi ve ardından bu IP'leri resolv.conf altına 8.8.8.8 (googles DNS sunucusu) altına kodlamanın en kolay olduğunu buldum. Bu, gizlilik ve hız için yararlı bulduğum şirket sunucularına göz atmak zorunda kalmadan tüm şirket adlarının doğru şekilde çözümlenmesini sağlar. Kodlama devam ettiği sürece, bu IP'ler yakında hiçbir zaman değişmeyeceklerdir ve yaparlarsa, etkilenen tek kişi ben olmayacağım ve iki satırı düzenlemek önemsiz olmalıdır.
Ron Thompson,

Dnsmasq'ı başlatmaya çalıştığımda 127.0.0.1 adresinin zaten kullanımda olduğunu söylüyor. Ne yapmam gerek? Yüksek Sierra
IceFire

@IceFire Bunun eski olduğunu biliyorum, ancak bu bağlantı noktasına zaten bağlı bir hizmet olduğu anlamına geliyor (53). Teknik olarak bu EADDRINUSE hatası alıyor demektir ama oraya gitmeyeceğim :) Bu cevaba gelince merak uyandırıcı buluyorum. Benzer bir problemim var ama benim için diğer cevabın sadece kendi yetkili DNS sunucularım olduğu için en azından ev ağım için etkinleştirmem gerekmediğini çözeceğimi düşünüyorum (umarım) yerel ve ne kullanırım). Uzun zamandan beri Otoh Unix kullanıcısı /etc/resolv.conf kullanabildiğim gerçeği çekici ama önce diğerini deneyecek.
Pryftan

6

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 .


1
Şirketim aylarca aylarca bu sorunu yaşıyor, her seferinde Mac'leri tek çözümü sabit diskleri silmek ve yeniden başlamak olan “Genius bar” a götürüyor. Gönderinizi gördüm ve com.apple.mDNSResponder.plist'i silindi, yeniden başlatıldı ve sorun çözüldü. Keşke size milyarlarca kez karşılık verebilirsem.
Thomas Thorogood

1
Not silin com.apple.mDNSResponder.plist! @ TomThorogood'un önerdiği gibi yaptım. Geri dönmek için çok zamanım var. Hatta dosyayı geri koydum ve yeniden başlattığımda internetten herhangi bir yanıt alamadım. Yardım sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistetti.
Pavel Binar

5

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!


4

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.


1
Bu benim için Yosemite için de bir çözümdü. Bazı ayrıntılar: ana bilgisayar, kazı ve Chrome iyi çalıştı ancak ping, telnet, ssh, firefox ve safari ana bilgisayar adlarını çözemedi. Bu çözüm sorunumu çözdü.
Ryan Hoegg

Sinir bozucu benim için her zaman olur. Hizmeti yeniden başlatmanız gerek.
Callum Rogers,

2

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



2

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.


2

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


2

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 .


1

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.


1
Her ne kadar soru bir düzenlemeye ihtiyaç duysa da, yine de (bu yorumu yazarken) çalışanların Wi-Fi'yi kapatıp tekrar açmaya çalıştıklarını söylüyor. Belki bu cevabı geri çekebiliriz?
DA Vincent,

Wifi kapatıp açtıktan sonra bir yazıya bir yorum eklemek için yeterli itibar yok, ama bu benim için çalıştı. Cevabı geri çekmek aptalca olurdu.

Önerinin tekrar denemesi için +1. Birden fazla cevap birçok kişiye yardımcı olur ve her yönlendiricinin farklı zaman aşımları ve davranışları vardır.
bmike

1

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.


Çok teşekkür ederim, bu benim sorunumdu. Saatlerce hata ayıklama yaptım ve / etc / resolver'a baktığımda elbette "test" adında bir dosya buldum, hatalı IP'lerle ...
Ocak’ta

1

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>

0

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.


0

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ü!



0

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.


0

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

0

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


-1

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.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.