Wie ist es möglich, dass ich einen Host-Lookup durchführen kann, aber keinen Curl?

Hat das schon mal jemand gesehen? Beachten Sie, dass dies nicht nur bei google.com geschieht, sondern bei jeder Domain, die ich versuche. Es ist eine drahtlose Verbindung (WEP), aber ich bin nicht sicher, wie das relevant wäre:

$ 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

Grundsätzlich kann keine Anwendung, einschließlich Firefox, Namenssuchen durchführen. Außerdem ist alles in Ordnung, wenn ich das WLAN offline schalte und ein Ethernet-Kabel einstecke.

Vielleicht haben Sie einige sehr seltsame und restriktive SELinux-Regeln (oder Sicherheitsregeln ...)?

Wenn nicht, versuchen Sie strace -o /tmp/wtf -fF curl -v google.com, aus der /tmp/wtfAusgabedatei herauszufinden, was los ist.

Verwenden Sie dazu: https://www.centos.org/modules/newbb/viewtopic.php?topic_id=39343

Ich habe einen Tastaturbefehl gefunden, der mir bei der Fehlerbehebung geholfen hat:

[root @ localhost ~] # wget -6 URL fehlgeschlagen

[root @ localhost ~] # wget -4 URL funktioniert

Dies hat etwas mit dem Standard-IPv6-Stack zu tun, der bei bestimmten Utils Probleme verursacht. Deaktivieren Sie ipv6 zum Auflösen.

Überprüfen Sie Ihre /etc/nsswitch.conf. Wenn in der hostsZeile so etwas steht

hosts:      files dns

Ich bin so verwirrt wie du. Aber wenn es so aussagt

hosts:      files

Dann hosthilft die Tatsache, dass DNS funktioniert (siehe Ausgabe des Befehls), nicht beim Einrollen, da die Namensauflösung über die Standard-Betriebssystembibliotheken erfolgt, die angewiesen wurden, das DNS nicht zu verwenden.

Ich hatte das gleiche Problem - Host, Nslookup löst ok, Curl - kann nicht auf den gleichen Hostnamen.

Nach tcpdumping-Kommunikation stellte ich fest, dass curl versucht, eine TCP-Verbindung (zusätzlich zu UDP) zum DNS-Port herzustellen, der in meinem Router geschlossen wurde. Nachdem TCP-Port 53 aktiviert wurde, begann Curl einwandfrei zu funktionieren.

Eine andere seltsame Sache ist, dass dieses Problem nicht auftritt, wenn der DNS-Server eine reguläre Bindungsinstallation durchführt. Wenn ich in Router eingebetteten DNS-Server verwende, versucht curl plötzlich, TCP-Ports zu verwenden, auch wenn er bereits vor 2ms (!) Eine Antwort über UDP erhalten hat. Ich vermute, das ist ein Fehler.

Ich hatte heute dasselbe Problem mit meinem VE (läuft auf meinem Laptop) und fand es ziemlich überraschend. Dig und NSlookup funktionieren, aber Curl schlägt fehl.

Also zum Beispiel:

# 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'

Aber als ich den Beitrag von David T hier sah, beschloss ich, es mit Locken zu versuchen. Während dies fehlschlägt:

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

Das gelingt:

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

Die -6 gibt an, dass Curl IPv6 verwendet, und die -4, um IPv4 zu verwenden. Ich bekomme die gleichen Fehler bei der Verwendung von wget, also definitiv einige Probleme mit dem IPv6-Stack auf dem Host.

Alle anderen Änderungen an der Datei nsswitch.conf und anderen BIND conf-Dateien haben nicht geholfen, da das Problem nicht bei diesen Dienstprogrammen liegt.

Wenn dies bei Personen auftritt, die versuchen, DNS für eine AWS EC2-Instanz einzurichten, müssen Sie auch die IPv6-Regeln (:: / 0) für HTTP und HTTPS in der von dieser Instanz verwendeten Sicherheitsgruppe aktivieren.

War Ihre Curl-Installation reibungslos? Versuchen Sie nach Möglichkeit, curl erneut zu installieren.

Versuchen Sie curl -v google.com, eine ausführlichere Ausgabe für das Debuggen zu erhalten.

z.B:

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'

Erhalten Sie ähnliche Ergebnisse?

Möglicherweise liegt ein Fehler in Ihrer Datei /etc/resolv.conf vor, den nslookup toleriert, Curl jedoch nicht.

Die gestellte Frage lautete: "Wie ist es möglich, dass ich einen Host-Lookup durchführen kann, aber keinen Curl?"

Dies ist möglich, weil curl den FQDN mit getaddrinfo () auflöst, nslookup nicht. Stattdessen, glaube ich, analysiert nslookup /etc/resolv.conf mithilfe einer anderen Funktion oder Bibliothek oder über seinen eigenen benutzerdefinierten Code. Ich habe mir den Quellcode nicht angesehen, um dies zu überprüfen, aber Sie können dies beweisen, indem Sie in /etc/resolv.conf ein Leerzeichen vor dem Nameserver-Token einfügen. nslookup kann dies analysieren, getaddrinfo () jedoch nicht.

Example /etc/resolv.conf
 nameserver 8.8.8.8

Wenn Ihre resolv.conf diesen Fehler aufweist oder andere Fehler, die von nslookup, aber nicht von getaddrinfo () toleriert werden, können Sie einen vollqualifizierten Domänennamen mit nslookup auflösen, aber Sie können Curl für diesen vollqualifizierten Domänennamen nicht verwenden.

Fix: Bearbeiten Sie als root /etc/resolv.conf und entfernen Sie alle führenden Leerzeichen in der Nameserver-Zeile.