DNS Mac OS X पर हल नहीं कर रहा है


100

मेरे कुछ सहकर्मियों को अपने Mac पर परेशानी हो रही है - Mac OS X के तहत DNS रिज़ॉल्यूशन काम नहीं करता है। वे स्नो लेपर्ड 10.6.8 चला रहे हैं। वे ओएस एक्स के तहत चलने वाले विंडोज 7 वर्चुअल मशीन (वीएमवेयर फ्यूजन 3.1.3) में डीएनएस का उपयोग कर सकते हैं। कंप्यूटर 15 "मैकबुक प्रोस, 2011 के शुरुआती मॉडल हैं।

जिन चीजों की उन्होंने कोशिश की है, उन्होंने काम नहीं किया है:

  • एयरपोर्ट को चालू / बंद करना
  • रिबूट
  • वाईफ़ाई के बजाय वायर्ड कनेक्शन का उपयोग करना
  • कनेक्शन क्रेडेंशियल्स को हटाना और इसे फिर से जोड़ना
  • मैक फ़ायरवॉल को बंद करना
  • स्थिर स्थिर IP का उपयोग करना
  • मैन्युअल रूप से DNS सर्वर सेट करना
  • mDNSResponder को पुनरारंभ करना
  • इस अन्य प्रश्न से सुधार

EDIT की प्रतिक्रिया मार्टीन का जवाब:

क्या आप उस डीएनएस को पिंग कर सकते हैं जिसका आप उपयोग करना चाहते हैं?

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

आप जिस DNS (ओं) का उपयोग करना चाहते हैं, उसका आईपी पता (तों) क्या है?

यह एक कंपनी DNS सर्वर है जो डीएचसीपी के साथ दिया गया है, यह अन्य लोगों के लिए अच्छा काम करता है। मैंने Google की 8.8.4.4 और 205.171.3.65 (जो मैंने जीआरसी की डीएनएस बेंचमार्क से सबसे तेज पाया) की कोशिश की है।

क्या आपने 8.8.8.8 (google) या किसी भी OpenDNS 208.67.222.222 या 208.67.222020 का उपयोग करने की कोशिश की है?

यह काम नहीं करता, 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

डीएनएस कैश फ्लश किया गया था, लेकिन यह मदद नहीं की

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

मेरे लिए भी शेर पर है।
21

मेरे लिए मावेरिक्स पर, 10.9.4
greg7gkb

यह एक ऐतिहासिक समस्या की तरह दिखती है, जिसने तेंदुए से लेकर योसेमाइट तक के उपयोगकर्ताओं और नेटवर्क के प्रवेश को प्रभावित किया है। यदि कोई व्यक्ति अभी भी इस समस्या को देखता है, तो कृपया स्पष्ट रूप से रिपोर्ट करें कि क्या आपके पास एक से अधिक इंटरफ़ेस सक्रिय है और इसके अलावा इसकी जानकारी मिल रही है। एक डीएचसीपी सर्वर से (विभिन्न पक्षों से)। क्यों? मैंने कभी भी किसी अन्य यूनिक्स और मेरे मैक पर (मैं बहुत कुछ) इस तरह की समस्या नहीं देखी, लेकिन उनमें से किसी के पास DNS जानकारी स्रोत की ओर बात करने वाले एक से अधिक इंटरफ़ेस नहीं हैं।
डैन

अपने DNS विन्यास (परिवर्तन आदेश या प्रविष्टियों निकालने के लिए) को बदलने के लिए है कि मेरे लिए एक ही समस्या को हल करने का प्रयास करें,
एमईएमएस

जवाबों:


90

यह पता चला कि समाधान mDNSResponder को उछाल देना था:

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

यह एक अलग सहकर्मी द्वारा इस सर्वर दोष प्रश्न से प्राप्त किया गया था ।

ओएस एक्स 10.10.0 - 10.10.3, योसेमाइट

जाहिरा तौर पर , YDemite (OS X 10.10) में mDNSResponder मौजूद नहीं है। आप इन मुद्दों को ठीक करने के बजाय डिस्कोवरी को पुनरारंभ कर सकते हैं।

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

ओएस एक्स 10.10.4+, योसेमाइट

OSX 10.10.4 में mDNSResponder को फिर से शुरू किया गया है । इसलिए पहले एक का उपयोग करें फिर से काम करेंगे।


5
लेकिन यह वास्तव में एक संतोषजनक जवाब नहीं है। मुझे यह जानने की जरूरत है कि इसे पहली जगह में होने से कैसे रोका जाए।
23

1
@dkagedal यह वास्तव में उतना ही अच्छा उत्तर है जितना कि हम प्राप्त करने जा रहे हैं - ऐसा इसलिए होता है क्योंकि आपका मैक हर DNS लुकअप के लिए अपने DNS सर्वर (संभवतः आपके राउटर) से टकराने से बचने के लिए DNS प्रविष्टियों को कैश करता है - जो बहुत कुछ होता है। यह कैश आवश्यक है, और अच्छा है, लेकिन यह अच्छा होगा यदि कोई प्रविष्टि न मिलने पर बेहतर व्यवहार हो (मैं इसे एक बग मानता हूं)। किसी भी मामले में, कैश में कुछ समयबाह्य है; जब मैंने अपनी मशीन पर 10 मिनट या अधिक प्रतीक्षा की, तो यह स्थिति स्वयं हल हो गई। अधिकांश उपयोगकर्ताओं के लिए, मौजूदा व्यवहार ठीक है, इसलिए Apple द्वारा जल्द ही कभी भी बदले जाने की संभावना नहीं है।
मैट

2
निश्चित रूप से यह उतना अच्छा नहीं है जितना यह मिलता है। किसी अन्य ओएस में यह समस्या नहीं है। डीएनएस के साथ कुछ भी गलत नहीं है, www.google.com के लिए रिकॉर्ड गायब नहीं हुआ, यह सिर्फ मैकओएस कैश है जो किसी भी तरह से इसे खो दिया है और इसे फिर से भरना नहीं होगा। और यह एक बग है जिसे ठीक करने की आवश्यकता है।
22

1
10.9 पर इस समस्या को हल किया और समाधान पूरी तरह से काम किया। मेरे मामले में DNS पूर्ण नामों के लिए हल कर रहा था, लेकिन कम नहीं।
सोरिन

1
@Matteo शायद फ़ाइल मौजूद नहीं है, या हो सकता है कि उत्तर को Yosemite के लिए अपडेट किया जाए। क्या आपके पास यह मुद्दा है? उन आदेशों को चलाने से यह ठीक हो जाता है?
CajunLuke

10

वास्तव में, मुझे लगता है कि आप उपयोग करना चाह सकते हैं

scutil --dns

scutil -r hostname

ये कमांड्स configd में डायनेमिक स्टोर का उपयोग करते हैं, जैसा कि फ्लैटफाइल्स / / आदि के विपरीत है, जो अक्सर केवल एकल उपयोगकर्ता मोड में और गैर नेटवर्क सिस्टम के लिए पढ़ा जाता है।

man scutil   # or

scutil --help  

3
आप यह नहीं समझाते हैं कि ये आदेश इस समस्या में मदद क्यों करेंगे। क्या वे भी? या इसका मतलब दूसरे उत्तरों में से एक या कुछ के लिए एक टिप्पणी के रूप में था?
19

स्कूटिल का एक संभावित लाभ यह है कि यह कंप्यूटर की खोज या mDNSResponder की परवाह किए बिना काम कर सकता है। यह उनके परिचय से पहले से है।
DA विंसेंट

1
ये आदेश समस्या को हल नहीं करते हैं
Radu Simionescu

7

OSX (और सामान्य रूप से UNIX) के तहत नाम रिज़ॉल्यूशन /etc/resolv.conf (जो OS X स्वचालित रूप से जहाँ तक मुझे याद है) में स्थित फ़ाइल में DNS के IP पते से लिया गया है।

चूँकि आपने लगभग कुछ भी कोशिश की है जो मेरे दिमाग में आई है, मैं आपसे पूछना चाहता हूँ:

  • क्या आप उस डीएनएस को पिंग कर सकते हैं जिसका आप उपयोग करना चाहते हैं?
  • DNS (ओं) का आईपी एड्रेस (एस) क्या आप उपयोग करना चाहते हैं?
  • क्या आपने 8.8.8.8 (google) या किसी भी OpenDNS 208.67.222.222 या 208.67.220.220 का उपयोग करने की कोशिश की है?
  • क्या आप उन मेजबानों को पिंग कर सकते हैं?

अंत में, आमतौर पर एक अच्छा परीक्षण एक खाली उपयोगकर्ता बनाने और यह देखने के लिए होता है कि क्या नया उपयोगकर्ता उसी समस्या को प्रदर्शित करता है। यदि ऐसा नहीं होता है, तो आप खुदाई शुरू कर सकते हैं जो आपके वर्तमान उपयोगकर्ता के पास समस्या का कारण हो सकता है; यदि यह भी विफल रहता है, तो आप जानते हैं कि यह कुछ और "सिस्टम" से संबंधित है।

कंसोल के चारों ओर एक नज़र डालें कि क्या आप कुछ ऐसा देख सकते हैं जो संबंधित हो सकता है (और इधर-उधर चिपकाना चाहेंगे)।

अंतिम लेकिन कम से कम, आपका मैक दो महत्वपूर्ण डीएनएस कमांड के साथ आता है, 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

जैसा कि आप देख सकते हैं, खुदाई बहुत अधिक है "क्रिया" (जो कि क्या हो रहा है डिबग करना अच्छा है)। खुदाई की शक्ति इस तथ्य से आती है कि आप निर्दिष्ट कर सकते हैं कि आप किस प्रकार की क्वेरी करना चाहते हैं (अन्य बातों के अलावा)।

किसी भी स्थिति में, आइए इन कमांडों के सटीक आउटपुटों को जानते हैं।


प्रश्न को मेरा संपादन देखें।
काजुनलुक

@CajunLuke हम्म्म्म दिलचस्प ... मेरा मन अपने सवाल का उत्पादन जोड़ने के लिए: बिल्ली /etc/resolv.conf?
मार्टिन मारकोसिनी

संपादित। (टिप्पणी फिट करने के लिए पैडिंग।)
CajunLuke

@CajunLuke मैं हैरान हूँ। चलो जड़ों पर वापस जाएं… यह केवल इस मशीन पर होता है, और केवल OSX के तहत, VMs ठीक हैं। मुझे संदेह होने लगा है कि समानताएं या वीएमवेयर कुछ परेशानी पैदा कर सकते हैं। ये VM किस प्रकार के नेटवर्क का उपयोग कर रहे हैं? पाट? साझा?
मार्टिन मारकोसिनी

1
या यदि आप वास्तव में कम चाहते हैं तो आप हमेशा कर सकते हैं ... एक
सेब डॉट खोदें

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विकल्प, तो यह पृष्ठभूमि में शुरू होगा और आप एक टर्मिनल विंडो को खुला रखने की जरूरत नहीं है।


मैं सिर्फ यह बताना चाहूंगा कि 16 घंटे के बाद इंटरनेट पर दस्तखत करना, यह एकमात्र समाधान है जो मैंने पाया है कि दोनों मुझे आंतरिक कंपनी के नाम को हल करने की अनुमति देता है और ठीक से काम करने के लिए विभाजित नेटवर्किंग की अनुमति देता है। इस टिप्पणी करने के लिए बहुत बहुत धन्यवाद।
रॉन थॉम्पसन

मैं यह भी कहना चाहता हूं कि OS X El Capitan पर, स्क्रिप्ट सेट अप करने के लिए, मैंने अपने openconnectकमांड को एक अजगर स्क्रिप्ट में लपेटा , साथ ही जैसे कमांड्स networksetup -setdnsservers 127.0.0.1और networksetup -setsearchdomains "$COMPANY_NAME".com। अपने dnsmasqआदेश में जोड़ें और यह सब सेट है! इस टिप्पणी के लिए आखिरकार मेरे पास एक स्थिर वीपीएन समाधान है।
रॉन थॉम्पसन

भविष्य के पाठकों के लिए, मुझे काम पर सिर्फ अपने बॉक्स में ssh करना आसान लगा, यह निर्धारित करें कि IP का नाम सर्वरों के लिए है, और फिर 8.8.8.8 (नीचे googles DNS सर्वर) के नीचे उन IP के मेरे resolv.conf में हार्डकोड करें। यह सभी गैर कंपनी नामों को कंपनी सर्वरों के माध्यम से जाने के बिना ठीक से हल करने की अनुमति देता है, जो मुझे गोपनीयता और गति के लिए उपयोगी लगता है। जहाँ तक हार्डकॉउंडिंग की बात है, उन IP का जल्द ही कोई बदलाव नहीं होने जा रहा है, और अगर वे ऐसा करते हैं, तो मैं केवल एक ही प्रभावित नहीं होगा और इसे दो पंक्तियों को संपादित करने के लिए तुच्छ होना चाहिए।
रॉन थॉम्पसन

यह कहता है कि पता 127.0.0.1 पहले से ही उपयोग में है, जब मैं dnsmasq शुरू करने की कोशिश करता हूं। मुझे क्या करना होगा? हाई सिएरा
आइसफ़ायर

@IceFire मुझे पता है कि यह पुराना है लेकिन इसका मतलब है कि उस पोर्ट (53) पर पहले से ही एक सेवा है। तकनीकी रूप से इसका मतलब है कि यह त्रुटि EADDRINUSE को मिल रही है, लेकिन मैं वहां नहीं जाऊंगा :) जैसा कि इस उत्तर के लिए मुझे यह पेचीदा लगता है। मेरे पास एक समान समस्या है, लेकिन मुझे लगता है कि मेरे लिए (आशा) यह है कि दूसरा उत्तर केवल यह निर्धारित करेगा कि मुझे अपने घर नेटवर्क के लिए कम से कम इसे सक्षम करने की आवश्यकता नहीं है क्योंकि मेरे पास अपने आधिकारिक DNS सर्वर हैं (और एक होने के लिए होता है) स्थानीय और मैं क्या उपयोग करता हूं)। ओटोह एक लंबे समय के यूनिक्स उपयोगकर्ता के रूप में मैं /etc/resolv.conf का उपयोग कर सकता है तथ्य यह है कि दूसरे से पहले की कोशिश करेंगे।
प्रियेफ्तान

6

मेरे पास एक ही सटीक लक्षण थे (और थोड़ी देर के लिए समस्या निवारण) लेकिन मैं इसे हल करने में सक्षम था जब मुझे एहसास हुआ कि मैंने गड़बड़ कर /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistदी थी और मैंने जो किया वह किसी भी तरह से विकृत था। मैंने एक बैकअप से पुनर्स्थापित किया और मशीन होस्टनामों को फिर से हल करने में सक्षम थी।

समाधान में आने से पहले, मुझे यह भी एहसास हुआ कि यदि मैं ssh -Dसुरंग के माध्यम से DNS लुकअप के माध्यम से एक SOCKS5 प्रॉक्सी का उपयोग करता हूं तो मैं इंटरनेट ब्राउज़ करने में सक्षम था ।


1
मेरी कंपनी हर महीने और महीनों के लिए इस मुद्दे को उठाती रही है, हर बार मैक को "जीनियस बार" में ले जाती है, जिसका एकमात्र समाधान हार्ड ड्राइव को पोंछना और शुरू करना था। मैंने आपकी पोस्ट देखी, और com.apple.mDNSResponder.plist को हटा दिया, रिबूट किया और समस्या हल हो गई। काश, मैं आपको एक अरब गुना बढ़ा सकता।
थॉमस थोरोगूड

1
नोट हटाओ com.apple.mDNSResponder.plist! मैंने इसे @TomThorogood के रूप में सुझाया। मेरे पास वापस जाने के लिए कठिन समय है। यहां तक ​​कि मैंने फ़ाइल को वापस डाल दिया और पुनः आरंभ करें मैं इंटरनेट से कोई प्रतिक्रिया प्राप्त करने में असमर्थ था। sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistमदद की तुलना में।
पावल बिनर

5

मेरे पास एक बहुत ही समान मुद्दा था, सिवाय इसके कि लक्षण थोड़े अलग थे।

मेरा उपयोगकर्ता किसी भी नाम (स्थानीय NAS, Google आदि) को हल नहीं कर सका, लेकिन उसी iMac (OS X 10.7.4) पर एक अतिथि उपयोगकर्ता ने ठीक काम किया।

MDNSResponder को फ्लशिंग और रीस्टार्ट करना जैसा कि उल्लेख किया गया है कुछ समय के लिए काम किया। जब भी आईमैक को स्लीप मोड में रखा जाता है तो यह काम करता रहेगा, एक बार रिबूट होने के बाद यह हमेशा विफल रहेगा।

जब फ्लश / पुनरारंभ ने काम करना बंद कर दिया तो मैंने अन्य कारणों / समाधानों की तलाश की और मैंने पाया कि यह मेरे फ़ायरवॉल से संबंधित था। मुझे नहीं पता कि मेरे (OS X) फ़ायरवॉल सेटिंग्स में क्या कारण था, लेकिन अगर मैंने फ़ायरवॉल को पुनर्स्थापित किया तो सेटिंग ने काम किया।

मेरे द्वारा उपयोग की गई डिफ़ॉल्ट सेटिंग्स को पुनर्स्थापित करने के लिए:

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

जाहिर है कि किसी भी कस्टम नियम को इस पुनर्स्थापना के साथ हटा दिया जाएगा।

मैं इस मुद्दे के अपने संस्करण को साझा करना चाहता था क्योंकि यह मुझे महीनों से दुखी कर रहा था और यह पोस्ट नेट पर संभावित समाधानों का सबसे अच्छा संग्रह है!


4

मैंने योसमाइट (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

और अब सब ठीक है।


1
मेरे लिए योसेमाइट पर भी यही समाधान था। कुछ विवरण: होस्ट, खुदाई, और क्रोम ने ठीक काम किया, लेकिन पिंग, टेलनेट, एसश, फ़ायरफ़ॉक्स और सफारी होस्टनामों को हल नहीं कर सके। इस समाधान ने मेरा मुद्दा ठीक कर दिया।
रयान होएग

मेरे लिए हर समय ऐसा होता है। सेवा को फिर से शुरू करना है।
कैलम रोजर्स

2

मैं 10.6.8 के साथ एक ही समस्या है। एक Apple स्टोर की पहली यात्रा के परिणामस्वरूप सिस्टम रिस्टोर हुआ। लेकिन, उसके बाद, डीएनएस फिर से टूट गया जब मैं विदेशी था और मेरे साथ सिस्टम डीवीडी नहीं था। उस समय मुझे यह धागा मिला और हटा दिया गया/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


2

कृपया अभी भी किसी को भी समस्या होने पर ध्यान दें, जब तक कैश साफ़ नहीं हो जाता, आपको किसी भी सार्वजनिक DNS सर्वर को निकालना पड़ सकता है।


1
शायद हमें support.apple.com/en-au/HT203244 का उल्लेख करना चाहिए ।
डीए विंसेंट

@DAVincent कुछ साल देर से, लेकिन वह लिंक निराशाजनक है। यह स्पष्ट रूप से एक Apple बग है, लेकिन वे इसे उपयोगकर्ता त्रुटि के लिए जिम्मेदार ठहरा रहे हैं।
वेबर 2

2

मैं ओपी के रूप में एक ही समस्या थी। उपकरण नेटवर्कसेटअप का उपयोग करके मैंने पाया कि दिए गए नेटवर्क नाम के लिए, कुछ गलत DNS कॉन्फ़िगर किया गया था:

networksetup -getdnsservers <networkname>

DNS के रूप में सूचीबद्ध 192.168.0.1। स्कूटिल - डीएनएस का उपयोग करने से मुझे तुलनीय परिणाम मिले हैं, जो कि रिसॉल्वर # 2 का उपयोग करने वाले नामकरण को सूचीबद्ध करता है [0]: 192.168.0.1।

कमांड का उपयोग करना

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

मैं दिए गए नेटवर्क के लिए DNS को फिर से कॉन्फ़िगर करने और वीपीएन से कनेक्ट होने पर स्थानीय और वैश्विक मशीनों के नामों को हल करने में सक्षम था।


2

मेरे मामले में, और सब कुछ ठीक था: mDNSResponder चल रहा था और काम कर रहे, host/ nslookupकाम किया, दोनों /etc/resolv.confऔर networksetupसही डीएनएस सर्वर, वह सब के बावजूद आदि, सामान्य रूप में 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प्लिस्ट फिक्स सिर्फ सेंसु-क्लाइंट इनवोकेशन से (पृष्ठभूमि / डेमनीज़) ध्वज को हटाने के लिए था । ध्यान दें कि यह सेंसु की गलती नहीं है; इस कंपनी में एक पूर्व सिस्टम एडमिनिस्ट्रेटर द्वारा यह प्लिस्ट लिखा गया था।


2

यहां कुछ उन्नत आदेश दिए गए हैं जो DNS समस्या का निवारण करने में मदद कर सकते हैं:

  • digरूट नाम सर्वर को सूचीबद्ध करने के लिए चलाएँ ।
  • डोमेन के dig example.comलिए DNS लुकअप चलाने के लिए चलाएँ example.com
  • द्वारा अपने हार्डवेयर बंदरगाहों सूची: networksetup -listallhardwareports
  • DHCP / BOOTP पैकेट के आउटपुट की जांच करें जिसे क्लाइंट ने DHCP / BOOTP सर्वर से स्वीकार किया है ipconfig getpacket en0
  • अपना डीएनएस विन्यास की जाँच करें: scutil --dns
  • सत्यापित करें कि mDNSResponderप्रक्रिया द्वारा चल रही है ps wuax | grep mDNSResponder:।
  • ARP अनुवाद प्रविष्टियों को फ्लश करें: arp -ad( man arpमदद के लिए चलाएँ )। स्रोत

mDNSResponderप्रक्रिया को डीबग करने के लिए, निम्न आदेश मदद कर सकता है:

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

उपरोक्त कमांड SIGINFOउस प्रक्रिया को संकेत भेजेगा जो डिबगिंग विवरण को लॉग आउटपुट में डंप कर देगी जिसे पढ़ा और विश्लेषण किया जा सकता है।


1

वाई-फाई को बंद करना और फिर से मदद करना।

मैकबुक प्रो 10.9.1 के साथ

खासकर यदि आप वाईफाई बंद कर देते हैं और फिर रिबूट करते हैं। अतिरिक्त देरी और बिना आईपी / नेटवर्क कनेक्शन के शुरू होने से नेटवर्क को फिर से जुड़ने का अनुरोध सुनिश्चित होता है और सफल होने के बेहतर अवसर होते हैं।


1
हालाँकि प्रश्न को कुछ संपादन की आवश्यकता हो सकती है, फिर भी यह कहता है (इस टिप्पणी को लिखने के समय) कि श्रमिकों ने पहले से ही वाई-फाई को बंद करने की कोशिश की और फिर से। शायद हम इस जवाब को वापस ले सकते हैं?
डीए विंसेंट

वाईफाई चालू करने और फिर चालू करने की पोस्ट पर टिप्पणी जोड़ने के लिए मेरे पास पर्याप्त प्रतिष्ठा नहीं है, लेकिन यह मेरे लिए काम करता है। जवाब वापस लेना मूर्खतापूर्ण होगा।

फिर से कोशिश करने के सुझाव के लिए +1। एकाधिक उत्तर बहुत से लोगों की मदद करते हैं, और प्रत्येक राउटर के पास अलग-अलग समय और व्यवहार होते हैं।
bmike

1

यह शायद किसी की मदद नहीं करेगा, लेकिन मामले में, मैंने कुछ समय पहले गलती से फ़ोल्डर में एक फ़ाइल बनाई थी, जब एक DNS एक विशेष डोमेन के लिए नीचे था:

/ Etc / समाधानकर्ता /

और यह दो साल बाद किसी विशिष्ट नाम को हल होने से रोक रहा था।


बहुत-बहुत धन्यवाद, यह मेरा मुद्दा था। मैं घंटों के लिए डिबगिंग कर रहा हूं, और जब मैंने / etc / resolver में देखा, तो मुझे निश्चित रूप से "परीक्षण" नामक एक फाइल मिली, जो कि erronous
IPs के

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

यहाँ उस gist का कोड है:

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

जैसा कि यह पता चला है, समस्या को हल करने के लिए आपको एक खोज डोमेन को कॉन्फ़िगर करना होगा और इसे सिस्टम डोमेन के तहत खोज डोमेन क्षेत्र में जोड़ना होगा। मूल रूप से, खोज डोमेन उस तरह से काम करेगा, जो .local करता है, लेकिन इसके बजाय यह होगा।

आपको अपने खोज डोमेन को अपने dns सर्वर में एक मास्टर ज़ोन के रूप में सेट करना होगा।


0

मुझे होस्ट सर्वर को खोजने के साथ एक समान समस्या है। हमारे पास सर्वर से 21 iMacs चल रहे हैं (एल कैपिटान, हाल ही में अपग्रेड किए गए) और केवल एक ही बाँध नहीं होगा। फिक्स आमतौर पर 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

SysPref में सर्वर से बाइंड करने के लिए वापस लौटा और सही सर्वर नाम विकल्प संक्षेप में दिखाई दिया और फिर मेरी आँखों के सामने "unkown-00-00-12-34-56-78.home" में वापस बदल दिया!


0

जब स्वीकृत उत्तर से आदेशों का पालन करें:

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/


0

मेरे मामले में मेरे पास OpenDNS अतीत में स्थापित किया गया था और इसे सफाई से हटाया नहीं गया था। DNSDnscrypt- प्रॉक्सी जैसी कई डीएनएस संबंधित प्रक्रियाएं चल रही थीं। मैं उन्हें एक्टिविटी मॉनिटर में छोड़ने के लिए मजबूर नहीं कर सकता था, लेकिन मैं उन्हें लाइब्रेरी / लॉन्चडैमों में .plist फ़ाइल को हटाकर पुनः आरंभ करने से रोकने में सक्षम था।


0

सेटिंग्स -> नेटवर्क -> उन्नत -> डीएनएस पर जाएं। फिर वस्तुतः 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

0

मेरे लिए जो काम किया गया वह DNS सर्वर और सर्च डोमेन से सभी सर्वर प्रविष्टियों को हटा रहा था:

सिस्टम वरीयताएँ → नेटवर्क → उन्नत ... → DNS


-1

स्नो लेपर्ड से एक पुराने मैक बुक पर माउंटेन लायन में अपग्रेड करने के बाद, सिस्टम डीएनएस को हल नहीं कर सका। फ्लशिंग, पुनरारंभ, कुछ भी मदद नहीं की। वाईफाई को एक अलग एक्सेस प्वाइंट (मेरा फोन) में बदलने से मदद मिली।

माउंटेन लायन डीएचसीपी नेटवर्क सेटिंग्स में एक नया क्लाइंट फ़ील्ड जोड़ता है। इस क्षेत्र में भरना वाईफाई एक्सेस प्वाइंट को खुश करने वाला लगता था। इसे खाली छोड़ने का मतलब था कि कुछ भी नहीं हो रहा था, भले ही वाईफाई कनेक्शन सफल हो रहा था।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.