Jak to możliwe, że mogę przeprowadzić wyszukiwanie hosta, ale nie zawijać się?

Czy ktoś kiedykolwiek to widział? Pamiętaj, że dzieje się tak nie tylko w przypadku google.com, ale w każdej domenie, którą próbuję. Jest to połączenie bezprzewodowe (WEP), ale nie jestem pewien, jak by to miało znaczenie:

$ 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

Zasadniczo każda aplikacja, w tym Firefox, nie może wykonywać wyszukiwania nazw. Co więcej, jeśli przejdę do trybu offline i podłączę kabel Ethernet, wszystko będzie w porządku.

Być może masz jakieś dziwne i restrykcyjne reguły SELinuksa (lub grsecurity ...)?

Jeśli nie, spróbuj strace -o /tmp/wtf -fF curl -v google.comwypatrzeć z /tmp/wtfpliku wyjściowego, co się dzieje.

Za pomocą tego: https://www.centos.org/modules/newbb/viewtopic.php?topic_id=39343

Znalazłem kluczowe polecenie, które pomogło mi rozwiązać problem:

[root @ localhost ~] # wget -6 URL nie powiodło się

[root @ localhost ~] # wget -4 URL działał

Ma to coś wspólnego z domyślnym stosem ipv6, który powoduje problemy z niektórymi narzędziami. Wyłącz ipv6, aby rozwiązać.

Sprawdź swoje /etc/nsswitch.conf. Jeśli hostslinia mówi coś takiego

hosts:      files dns

Jestem tak zdezorientowany jak ty. Ale jeśli mówi coś takiego

hosts:      files

to fakt, że DNS działa (patrz dane wyjściowe hostpolecenia), nie pomoże w zwijaniu się, co powoduje rozpoznawanie nazw za pomocą standardowych bibliotek systemu operacyjnego, którym powiedziano, aby nie korzystały z DNS.

Miałem ten sam problem - host, nslookup rozwiązuje problem, curl - nie mogę na tych samych nazwach hostów.

Po komunikacji tcpdumping stwierdziłem, że curl próbuje nawiązać połączenie TCP (oprócz UDP) z portem DNS, który został zamknięty w moim routerze. Po włączeniu portu tcp 53, curl zaczął działać bezbłędnie.

Inną dziwną rzeczą jest to, że ten problem nie pojawia się, jeśli serwer dns regularnie instaluje wiązanie. Jeśli użyję wbudowanego w serwer DNS routera, curl nagle próbuje użyć portów TCP, nawet jeśli wcześniej otrzymał (!) Odpowiedź przez UDP 2ms. Przypuszczam, że to błąd.

Miałem ten sam problem na moim VE (działającym na moim laptopie) dzisiaj i było to dość zaskakujące. Dig i NSlookup działają, ale zawijanie się nie udaje.

Na przykład:

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

Ale kiedy zobaczyłem tutaj post Davida T, postanowiłem spróbować z curl. Więc dopóki to się nie powiedzie:

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

Udaje się to:

# 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 określa, że ​​curl używa IPv6 i -4, aby używać IPv4. Otrzymuję te same błędy podczas używania wget, więc na pewno niektóre problemy ze stosem IPv6 na hoście.

Wszystkie inne modyfikacje pliku nsswitch.conf i innych plików BIND conf nie pomogły, ponieważ problem nie dotyczy tych narzędzi.

Jeśli zdarzy się to każdemu, kto próbuje skonfigurować DNS dla instancji AWS EC2, upewnij się, że włączasz także reguły IPv6 (:: / 0) dla HTTP i HTTPS w grupie zabezpieczeń używanej przez tę instancję.

Czy instalacja loków była płynna? Jeśli to możliwe, spróbuj ponownie zainstalować curl.

Spróbuj curl -v google.comuzyskać więcej pełnych danych wyjściowych do debugowania.

na przykład:

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'

Czy otrzymujesz podobny wynik?

W pliku /etc/resolv.conf może występować błąd, który nslookup toleruje, ale curl nie.

Zadane pytanie brzmiało: „Jak to możliwe, że mogę przeprowadzić wyszukiwanie hosta, ale nie zwijam się?”

Jest to możliwe, ponieważ curl używa getaddrinfo () do rozwiązania FQDN, podczas gdy nslookup nie. Zamiast tego uważam, że nslookup analizuje /etc/resolv.conf za pomocą innej funkcji lub biblioteki lub za pomocą własnego niestandardowego kodu. Nie sprawdziłem tego, żeby to sprawdzić, ale możesz to udowodnić, dodając spację przed tokenem serwera nazw w /etc/resolv.conf. nslookup może to przeanalizować, ale getaddrinfo () nie.

Example /etc/resolv.conf
 nameserver 8.8.8.8

Jeśli w pliku resolv.conf występuje ten błąd lub inne błędy, które są tolerowane przez nslookup, ale nie getaddrinfo (), możesz rozwiązać FQDN za pomocą nslookup, ale nie będziesz mógł użyć curl na tej FQDN.

Napraw: jako root, edytuj /etc/resolv.conf i usuń wszelkie wiodące białe znaki w wierszu serwera nazw.