Come è possibile che io possa fare una ricerca host ma non un ricciolo?

20

Qualcuno l'ha mai visto prima? Nota che questo non accade solo con google.com, ma con ogni dominio che provo. È una connessione wireless (WEP), ma non sono sicuro di come sarebbe rilevante:

$ 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

Fondamentalmente qualsiasi applicazione, incluso Firefox, non può funzionare per effettuare ricerche di nomi. Inoltre, se porto offline il wifi e collego un cavo Ethernet, va tutto bene.

domain-name-system wifi curl

— Daniel Quinn
fonte

1

Forse aggiungi qualche informazione in più - è solo arricciata? Che dire di wget, browser, ping ecc.?

— Sandman4,

Vedo che hai segnato una risposta, ma qual è stato esattamente il problema e la soluzione? Era un problema SELinux?

— Belmin Fernandez,

La "soluzione" era proprio che la rete sembra essere gibbosa a destra. Non eseguo SELinux sul laptop e la "rete" è semplicemente gestita da un rozzo router WiFi acquistato in negozio. Quella risposta è stata quella che mi ha aiutato a capire che stavo lasciando cadere i pacchetti dappertutto, quindi ho pensato che fosse qualcosa che non potevo risolvere e ho dato a quel ragazzo il merito. Perché, hai un'idea migliore?

— Daniel Quinn,

pingchiama getaddrinfo con parametri leggermente diversi github.com/iputils/iputils/blob/master/ping/ping.c#L574 ai_protocol = IPPROTO_UDP forse che confonde getaddrinfo in modo diverso in qualche modo? Sembra che il hostcomando non sia sempre quello che viene utilizzato: unix.stackexchange.com/a/553438/8337

— rogerdpack

8

Forse hai delle regole SELinux (o grsecurity ...) molto strane e restrittive in atto?

In caso contrario, prova strace -o /tmp/wtf -fF curl -v google.coma individuare dal /tmp/wtffile di output cosa sta succedendo.

— Janne Pikkarainen
fonte

1

Sembra che sia la stessa connessione wifi. Il file di output è COMPLETO di cose come questa:9344 poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 1000) = 0 (Timeout)

— Daniel Quinn,

@Daniel Quinn, puoi pubblicare un output di /tmp/wtf?

— Sachin Divekar,

Ecco l'output: pastebin.com/1y5Z48NK

— Daniel Quinn,

Hmm, sembra che stia facendo la query al 192.168.1.201. Puoi fare "host google.com 192.168.1.201" per sanità mentale? Fondamentalmente, la ricerca DNS è specifica per il tuo server DNS.

— cjc,

Fatto (aggiunto alla domanda). E questo funziona perfettamente, il che ha senso dato che l'emissione dell'host senza un argomento del server funziona anche correttamente. Sembra che siano solo vere e proprie chiamate HTTP, dal momento che ICMP (principalmente, rilascia il primo ping) funziona.

— Daniel Quinn,

8

Utilizzando questo: https://www.centos.org/modules/newbb/viewtopic.php?topic_id=39343

Ho trovato un comando chiave che mi ha aiutato a risolvere:

[root @ localhost ~] # wget -6 URL non riuscito

[root @ localhost ~] # wget -4 URL ha funzionato

Ha a che fare con lo stack ipv6 predefinito che causa problemi con alcuni programmi di utilità. Disabilita ipv6 per la risoluzione.

— David T
fonte

5

Controlla il tuo /etc/nsswitch.conf. Se la hostslinea dice qualcosa di simile

hosts:      files dns

Sono confuso quanto te. Ma se dice qualcosa del genere

hosts:      files

quindi il fatto che il DNS funzioni (vedi l'output del hostcomando) non aiuterà l'arricciatura, il che sta facendo la risoluzione dei nomi tramite le librerie del sistema operativo standard, a cui è stato detto di non usare il DNS.

— MadHatter supporta Monica
fonte

Hmm. Non ci avevo pensato, ma ho appena controllato e dice che files dnsquindi non è così :-(

— Daniel Quinn,

1

Nel mio, c'erano molte più cose sulla linea degli host. "dns" è stato elencato dopo "[NOTFOUND = return]" che, a mio avviso, fa sì che il sistema ritorni non trovato prima ancora di controllare i server DNS configurati! Lo spostamento di "dns" su prima della cosa non corretta ha risolto il mio sistema (ha dovuto riavviare).

— trebormf,

3

Ho avuto lo stesso problema - host, nslookup risolve ok, arricciatura - impossibile sugli stessi nomi host.

Dopo la comunicazione tcpdumping ho scoperto che curl tenta di stabilire una connessione TCP (oltre a UDP) alla porta DNS, che è stata chiusa nel mio router. Dopo l'attivazione della porta tcp 53, l'arricciatura ha iniziato a funzionare in modo impeccabile.

Un'altra cosa strana è che questo problema non emerge se il server DNS è una normale installazione di bind. Se uso incorporato nel server DNS del router, improvvisamente l'arricciatura tenta di utilizzare le porte TCP anche se ha già ricevuto una risposta (!) Tramite UDP 2 ms prima. Suppongo che questo sia un bug.

— Andrea
fonte

1

Ho avuto questo stesso problema sul mio VE (in esecuzione sul mio laptop) oggi e l'ho trovato abbastanza sorprendente. Dig e NSlookup funzionano, ma l'arricciatura fallisce.

Quindi per esempio:

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

Ma quando ho visto il post di David T qui, ho deciso di provarlo con il ricciolo. Quindi, mentre questo fallisce:

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

Questo riesce:

# 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 specifica che l'arricciatura usa IPv6 e -4, per usare IPv4. Ottengo gli stessi errori quando utilizzo wget, quindi sicuramente alcuni problemi con lo stack IPv6 sull'host.

Tutte le altre modifiche al file nsswitch.conf e altri file di configurazione BIND non sono state utili poiché il problema non riguarda queste utilità.

— Akino
fonte

1

Se ciò si verifica per chiunque tenti di configurare il DNS per un'istanza di AWS EC2, assicurarsi di abilitare anche le regole IPv6 (:: / 0) per HTTP e HTTPS nel gruppo di sicurezza utilizzato da tale istanza.

— David Nathan
fonte

0

La tua installazione del ricciolo è stata regolare? Se possibile, provare a reinstallare l'arricciatura.

Prova curl -v google.coma ottenere un output più dettagliato per il debug.

per esempio:

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'

Stai ottenendo un output simile?

— Sachin Divekar
fonte

Esattamente lo stesso :-( Ho aggiornato la domanda con l'output.

— Daniel Quinn,

0

Potrebbe esserci un errore nel tuo file /etc/resolv.conf tollerato da nslookup ma non arricciato.

La domanda posta era "Come è possibile che io possa fare una ricerca host ma non un ricciolo?"

Questo è possibile perché curl usa getaddrinfo () per risolvere il nome di dominio completo, mentre nslookup no. Invece, credo che nslookup analizzi /etc/resolv.conf usando qualche altra funzione o libreria, o tramite il suo codice personalizzato. Non ho esaminato il codice sorgente per verificarlo, ma puoi dimostrarlo aggiungendo spazi bianchi davanti al token del nameserver in /etc/resolv.conf. nslookup può analizzarlo ma getaddrinfo () no.


Example /etc/resolv.conf
 nameserver 8.8.8.8

Se il file resolv.conf presenta questo errore o altri errori tollerati da nslookup ma non getaddrinfo (), è possibile risolvere un nome di dominio completo con nslookup, ma non sarà possibile utilizzare l'arricciatura su quel nome di dominio completo.

Correzione: come root, modifica /etc/resolv.conf e rimuovi tutti gli spazi bianchi sulla riga del nameserver.

— mrjmh
fonte

L' straceoutput mostra le query DNS inviate senza ricevere risposte. Ciò non supporta l'ipotesi di un errore di analisi su /etc/resolv.conf. Tuttavia, è possibile che il ricursore sia difettoso e che potrebbe essere utile utilizzare un ricorritore diverso.

— Kasperd,