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

20

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.

Daniel Quinn
źródło
1
Może dodaj więcej informacji - czy to tylko curl? Co z wget, przeglądarkami, pingowaniem itp.?
Sandman4,
Widzę, że zaznaczyłeś odpowiedź, ale jaki dokładnie był problem i rozwiązanie? Czy to był problem z SELinux?
Belmin Fernandez
„Rozwiązanie” polegało na tym, że sieć wydaje się być trafna. Nie korzystam z SELinuksa na laptopie, a „siecią” zarządza po prostu kiepski router Wi-Fi kupiony w sklepie. Ta odpowiedź pomogła mi zorientować się, że upuszczam paczki wszędzie, więc doszedłem do wniosku, że to coś, czego nie potrafię rozwiązać, i przypisałem temu facetowi uznanie. Dlaczego masz lepszy pomysł?
Daniel Quinn
pingczy wywołuje getaddrinfo z nieco innymi parametrami github.com/iputils/iputils/blob/master/ping/ping.c#L574 ai_protocol = IPPROTO_UDP może to w jakiś sposób dezorientuje getaddrinfo? Wygląda na to, że hostpolecenie nie zawsze jest używane: unix.stackexchange.com/a/553438/8337
rogerdpack

Odpowiedzi:

8

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.

Janne Pikkarainen
źródło
1
Wygląda na to, że to samo połączenie Wi-Fi. Plik wyjściowy jest PEŁNY takich rzeczy:9344 poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 1000) = 0 (Timeout)
Daniel Quinn
@Daniel Quinn, czy możesz opublikować dane wyjściowe z /tmp/wtf?
Sachin Divekar
Oto wynik: pastebin.com/1y5Z48NK
Daniel Quinn
Hmm, wygląda na to, że wykonuje zapytanie do 192.168.1.201. Czy możesz zrobić „host google.com 192.168.1.201” dla zdrowia psychicznego? Zasadniczo, wyszukiwanie DNS specjalnie na twoim serwerze DNS.
cjc
Gotowe (dodało to do pytania). I to działa dobrze - co ma sens, ponieważ wydawanie hosta bez argumentu serwera również działa poprawnie. Wygląda na to, że są to tylko rzeczywiste wywołania HTTP, ponieważ ICMP (przeważnie usuwa pierwszy ping) działa.
Daniel Quinn
8

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

David T.
źródło
5

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.

MadHatter obsługuje Monikę
źródło
Hmm Nie myślałem o tym, ale po prostu sprawdziłem i jest napisane, files dnswięc chyba nie o to chodzi :-(
Daniel Quinn
1
W moim przypadku na linii hostów było o wiele więcej rzeczy. „dns” został wymieniony po „[NOTFOUND = return]”, co, moim zdaniem, powoduje, że system nie został odnaleziony przed sprawdzeniem skonfigurowanych serwerów DNS! Przeniesienie „dns” do poprzedniej rzeczy naprawiło mój system (musiał się zrestartować).
trebormf
3

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.

Andrzej
źródło
1

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.

AkinO
źródło
1

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

David Nathan
źródło
0

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?

Sachin Divekar
źródło
Dokładnie to samo :-( Zaktualizowałem pytanie o dane wyjściowe.
Daniel Quinn
0

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.

mrjmh
źródło
Dane stracewyjściowe pokazują, że zapytania DNS są wysyłane bez otrzymywania odpowiedzi. To nie potwierdza hipotezy błędu analizy /etc/resolv.conf. Jednak możliwe jest, że rekursor jest uszkodzony i użycie innego rekursora może pomóc.
kasperd