यह कैसे संभव है कि मैं एक होस्ट लुकअप कर सकता हूं लेकिन कर्ल नहीं?

20

क्या पहले कभी किसी ने ऐसा देखा है? ध्यान दें कि यह न केवल google.com के साथ होता है, बल्कि प्रत्येक डोमेन के साथ मैं कोशिश करता हूं। यह एक वायरलेस कनेक्शन (WEP) है, लेकिन मुझे यकीन नहीं है कि यह कैसे प्रासंगिक होगा:

$ curl -v google.com
# This takes about 60s to return
* getaddrinfo(3) failed for google.com:80
* Couldn't resolve host 'google.com'
* Closing connection #0
curl: (6) Couldn't resolve host 'google.com'

$ wget google.com
--2011-11-28 14:44:08--  http://google.com/
Resolving google.com... failed: Name or service not known.
wget: unable to resolve host address `google.com'

$ ping google.com
PING google.com (209.85.148.147) 56(84) bytes of data.
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=2 ttl=54 time=136 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=3 ttl=54 time=34.0 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=4 ttl=54 time=34.3 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=5 ttl=54 time=42.5 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=6 ttl=54 time=44.7 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=7 ttl=54 time=34.5 ms
^C
--- google.com ping statistics ---
8 packets transmitted, 6 received, 25% packet loss, time 7007ms
rtt min/avg/max/mdev = 34.063/54.376/136.026/36.758 ms


$ host google.com
google.com has address 209.85.148.106
google.com has address 209.85.148.147
google.com has address 209.85.148.99
google.com has address 209.85.148.103
google.com has address 209.85.148.104
google.com has address 209.85.148.105
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.

$ host google.com 192.168.1.201
Using domain server:
Name: 192.168.1.201
Address: 192.168.1.201#53
Aliases: 

google.com has address 209.85.148.103
google.com has address 209.85.148.104
google.com has address 209.85.148.105
google.com has address 209.85.148.106
google.com has address 209.85.148.147
google.com has address 209.85.148.99
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.

$ cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 192.168.1.201

$ cat /etc/hosts
127.0.0.1       localhost
::1             localhost

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.254   0.0.0.0         UG        0 0          0 wlan0
127.0.0.0       127.0.0.1       255.0.0.0       UG        0 0          0 lo
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan0

मूल रूप से फ़ायरफ़ॉक्स सहित कोई भी एप्लिकेशन, नाम लुकअप करने के लिए काम नहीं कर सकता है। क्या अधिक है, अगर मैं वाईफाई और ऑफ़लाइन एक ईथरनेट केबल में प्लग करता हूं, तो सब कुछ ठीक है।

domain-name-system wifi curl

— डैनियल क्विन
स्रोत

1

शायद कुछ और जानकारी जोड़ें - क्या यह सिर्फ कर्ल है? Wget, ब्राउज़र, पिंग आदि के बारे में क्या?

— Sandman4

मैं देख रहा हूं कि आपने एक उत्तर दिया है, लेकिन वास्तव में मुद्दा और समाधान क्या था? क्या यह एक SELinux समस्या थी?

— बेलमिन फर्नांडीज

"समाधान" सिर्फ इतना था कि नेटवर्क सही-सही गिब्बल प्रतीत होता है। मैं लैपटॉप पर कोई SELinux नहीं चला रहा हूँ और "नेटवर्क" सिर्फ एक गंदे स्टोर द्वारा खरीदे गए वाईफाई राउटर द्वारा प्रबंधित किया जाता है। यह जवाब मुझे यह पता लगाने में मदद करने के लिए था कि मैं पैकेट को पूरी जगह गिरा रहा हूं, इसलिए मुझे लगा कि यह कुछ ऐसा है जिसे मैं हल नहीं कर सकता और उस आदमी को श्रेय दिया। क्यों, क्या आपके पास एक बेहतर विचार है?

— डैनियल क्विन

pingक्या कुछ अलग मापदंडों के साथ getaddrinfo को कॉल किया जाता है github.com/iputils/iputils/blob/master/ping/ping.c#L574 जो ai_protocol = IPPROTO_UDP शायद किसी भी तरह से getaddrinfo को भ्रमित करता है? लगता है कि hostकमांड का हमेशा उपयोग नहीं किया जाता है: unix.stackexchange.com/a/553438/8337

— rogerdpack

8

शायद आपके पास कुछ बहुत ही अजीब और प्रतिबंधात्मक SELinux (या grsecurity ...) नियम हैं?

यदि नहीं, तो कोशिश करें strace -o /tmp/wtf -fF curl -v google.comऔर /tmp/wtfआउटपुट फ़ाइल से हाजिर करने की कोशिश करें कि क्या हो रहा है।

— जने पिक्कारेंन
स्रोत

1

ऐसा लगता है कि यह वाईफाई कनेक्शन ही है। आउटपुट फ़ाइल इस तरह 9344 poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 1000) = 0 (Timeout)

— डैनियल क्विन

@ डैनियल क्विन, क्या आप इसका आउटपुट पोस्ट कर सकते हैं /tmp/wtf?

— सचिन दिवेकर

यहाँ आउटपुट है: pastebin.com/1y5Z48NK

— डैनियल क्विन

हम्म, ऐसा लगता है कि यह 192.168.1.201 को क्वेरी कर रहा है। क्या आप पवित्रता के लिए "host.com google2 192.168.1.2017" कर सकते हैं? असल में, DNS विशेष रूप से आपके DNS सर्वर के खिलाफ दिखता है।

— cjc 12

हो गया (प्रश्न से जोड़ा)। और यह ठीक काम करता है - जो कि सर्वर तर्क के बिना होस्ट जारी करने के बाद से समझ में आता है और साथ ही साथ सही ढंग से काम करता है। ऐसा लगता है कि यह केवल वास्तविक HTTP कॉल है, क्योंकि ICMP (ज्यादातर, यह पहला पिंग ड्रॉप करता है) काम करता है।

— डैनियल क्विन

8

इसका प्रयोग: https://www.centos.org/modules/newbb/viewtopic.php?topic_id=393

मुझे एक महत्वपूर्ण आदेश मिला जिसने मुझे समस्या निवारण में मदद की:

[root @ localhost ~] # wget -6 URL विफल

[root @ localhost ~] # wget -4 URL काम किया

यह डिफ़ॉल्ट IPv6 स्टैक के साथ कुछ करना है जो कुछ बर्तनों के साथ समस्या पैदा कर रहा है। IPv6 को हल करने के लिए अक्षम करें।

— डेविड टी
स्रोत

5

अपनी जाँच करें /etc/nsswitch.conf। अगर hostsरेखा कुछ ऐसा कहती है

hosts:      files dns

मैं आप के रूप में उलझन में हूँ। लेकिन अगर यह ऐसा कुछ कहता है

hosts:      files

तब तथ्य यह है कि डीएनएस काम कर रहा है ( hostकमांड का आउटपुट देखें ) कर्ल की मदद नहीं करेगा, जो मानक ओएस पुस्तकालयों के माध्यम से नाम समाधान कर रहा है, जिसमें डीएनएस का उपयोग नहीं करने के लिए कहा गया है।

— MadHatter मोनिका का समर्थन करता है
स्रोत

हम्म। मैं उस के बारे में सोचा नहीं था, लेकिन मैं सिर्फ जाँच की है और यह कहता है files dnsतो मुझे लगता है कि यह नहीं है :-(

— डैनियल क्विन

1

मेरा, मेजबानों की लाइन पर बहुत अधिक सामान था। "डीएनएस" को "[NOTFOUND = वापसी]" के बाद सूचीबद्ध किया गया था, जो मेरी समझ में, कॉन्फ़िगर किए गए DNS सर्वरों की जांच करने से पहले सिस्टम को वापस नहीं मिलने का कारण बनता है! "डीएनएस" को आगे बढ़ने से पहले नोटफाउंड चीज़ ने मेरे सिस्टम को ठीक किया (रिबूट करना पड़ा)।

— trebormf

3

मुझे एक ही समस्या थी - मेजबान, nslookup ठीक हल करता है, कर्ल - एक ही होस्टनाम पर नहीं कर सकता।

Tcpdumping संचार के बाद मैंने पाया कि कर्ल DNS पोर्ट से टीसीपी (यूडीपी के अलावा) कनेक्शन स्थापित करने की कोशिश करता है, जो मेरे राउटर में बंद था। Tcp पोर्ट 53 के सक्षम होने के बाद कर्ल त्रुटिपूर्ण रूप से काम करना शुरू कर दिया था।

एक और विचित्र बात यह है कि यह समस्या सतही नहीं है यदि डीएनएस सर्वर नियमित रूप से बाइंड इंस्टॉलेशन है। यदि मैं राउटर DNS सर्वर में एम्बेडेड का उपयोग करता हूं, तो कर्ल अचानक यूपीडी 2ms से पहले ही प्राप्त (!) उत्तर के बावजूद टीसीपी पोर्ट का उपयोग करने की कोशिश करता है। मुझे लगता है कि यह बग है।

— एंड्रयू
स्रोत

1

मुझे अपने VE (अपने लैपटॉप पर चलने) पर आज भी यही समस्या थी, और यह काफी आश्चर्यजनक लगा। डिग और एनएसएग्यूप काम करता है, लेकिन कर्ल विफल रहता है।

उदाहरण के लिए:

# curl -v google.com
* getaddrinfo(3) failed for google.com:80
* Couldn't resolve host 'google.com'
* Closing connection #0
curl: (6) Couldn't resolve host 'google.com'

लेकिन जब मैंने यहां डेविड टी की पोस्ट देखी, तो मैंने इसे कर्ल के साथ आजमाने का फैसला किया। तो जबकि यह विफल रहता है:

# curl  google.com -6
curl: (6) Couldn't resolve host 'google.com'

यह सफल होता है:

# curl  google.com -4
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>

-6 निर्दिष्ट करता है कि कर्ल IPv6 और -4 का उपयोग करता है, IPv4 का उपयोग करने के लिए। मुझे wget का उपयोग करते समय समान त्रुटियां मिलती हैं, इसलिए निश्चित रूप से होस्ट पर IPv6 स्टैक के साथ कुछ समस्याएं हैं।

Nsswitch.conf फ़ाइल और अन्य BIND conf फ़ाइलों के लिए अन्य सभी संशोधनों ने मदद नहीं की क्योंकि समस्या इस उपयोगिताओं के साथ नहीं है।

— Akino
स्रोत

1

यदि यह किसी एडब्ल्यूएस ईसी 2 उदाहरण के लिए डीएनएस को स्थापित करने की कोशिश कर रहा है, तो उस उदाहरण द्वारा उपयोग किए गए सुरक्षा समूह में HTTP और HTTPS के लिए IPv6 नियम (:: / 0) को सक्षम करना सुनिश्चित करें।

— डेविड नाथन
स्रोत

0

क्या आपकी कर्ल स्थापना चिकनी थी? यदि संभव हो तो कर्ल को फिर से स्थापित करने का प्रयास करें।

curl -v google.comडिबगिंग के लिए अधिक वर्बोज़ आउटपुट प्राप्त करने का प्रयास करें ।

उदाहरण के लिए:

curl -v dnserror.test
* getaddrinfo(3) failed for dnserror.test:80
* Couldn't resolve host 'dnserror.test'
* Closing connection #0
curl: (6) Couldn't resolve host 'dnserror.test'

क्या आपको भी इसी तरह का आउटपुट मिल रहा है?

— सचिन दिवेकर
स्रोत

बिल्कुल वैसा ही :-( मैंने आउटपुट के साथ प्रश्न को अपडेट किया है।

— डैनियल क्विन

0

आपकी /etc/resolv.conf फ़ाइल में कोई त्रुटि हो सकती है जिसे nslookup सहन करता है लेकिन कर्ल नहीं करता है।

पूछा गया प्रश्न "यह कैसे संभव है कि मैं एक होस्ट लुकअप कर सकता हूं लेकिन कर्ल नहीं?"

यह संभव है क्योंकि कर्ल FQDN को हल करने के लिए getaddrinfo () का उपयोग करता है, जबकि nslookup नहीं करता है। इसके बजाय, मेरा मानना है कि nslookup पार्स /etc/resolv.conf कुछ अन्य फ़ंक्शन या लाइब्रेरी का उपयोग करके, या अपने स्वयं के कस्टम कोड के माध्यम से। मैंने इसे सत्यापित करने के लिए स्रोत कोड को नहीं देखा, लेकिन आप इसे /etc/resolv.conf में नेमसेवर टोकन के सामने व्हॉट्सएप जोड़कर साबित कर सकते हैं। nslookup इसे पार्स कर सकता है लेकिन getaddrinfo () नहीं कर सकता।


Example /etc/resolv.conf
 nameserver 8.8.8.8

यदि आपकी resolv.conf में यह त्रुटि है, या अन्य त्रुटियां जो nslookup द्वारा सहन की जाती हैं, लेकिन getaddrinfo () नहीं हैं, तो आप nslookup के साथ FQDN को हल कर सकते हैं, लेकिन आप उस FQDN पर Ll का उपयोग नहीं कर पाएंगे।

फिक्स: रूट के रूप में, /etc/resolv.conf को संपादित करें और नेमसर्वर लाइन पर किसी भी प्रमुख व्हाट्सएप को हटा दें।

— mrjmh
स्रोत

straceउत्पादन से पता चलता है DNS क्वेरी उत्तर प्राप्त करने के बिना भेजा जा रहा है। उस पर पार्सिंग त्रुटि की परिकल्पना का समर्थन नहीं करता है /etc/resolv.conf। हालांकि यह संभव है कि पुनरावर्ती दोषपूर्ण है और एक अलग पुनरावर्ती का उपयोग करने से मदद मिल सकती है।

— कास्परड