Bagaimana mungkin saya bisa melakukan pencarian host tetapi bukan curl?

20

Adakah yang pernah melihat ini sebelumnya? Perhatikan bahwa ini terjadi tidak hanya dengan google.com, tetapi dengan setiap domain yang saya coba. Ini koneksi nirkabel (WEP), tapi saya tidak yakin bagaimana itu akan relevan:

$ 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

Pada dasarnya aplikasi apa pun, termasuk Firefox, tidak dapat berfungsi untuk melakukan pencarian nama. Terlebih lagi, jika saya mengambil wifi offline dan menyambungkan kabel ethernet, semuanya baik-baik saja.

domain-name-system  wifi  curl 
— Daniel Quinn
sumber
1
Mungkin menambahkan beberapa info lagi - apakah itu hanya ikal? Bagaimana dengan wget, browser, ping dll?
— Sandman4
Saya melihat Anda menandai jawaban tetapi apa sebenarnya masalah dan solusinya? Apakah ini masalah SELinux?
— Belmin Fernandez
"Solusi" hanya bahwa jaringan tampaknya benar-tergeser. Saya tidak menjalankan SELinux di laptop dan "jaringan" hanya dikelola oleh router wifi yang dibeli di toko. Jawaban itu adalah yang membantu saya mengetahui bahwa saya menjatuhkan paket di semua tempat, jadi saya pikir itu adalah sesuatu yang tidak bisa saya selesaikan dan memberikan penghargaan kepada orang itu. Kenapa, apakah Anda punya ide yang lebih baik?
— Daniel Quinn
pingapakah memanggil getaddrinfo dengan parameter yang sedikit berbeda github.com/iputils/iputils/blob/master/ping/ping.c#L574 ai_protocol = IPPROTO_UDP mungkin entah bagaimana caranya membingungkan getaddrinfo secara berbeda? Tampaknya hostperintah itu tidak selalu apa yang digunakan: unix.stackexchange.com/a/553438/8337
— rogerdpack

Jawaban:

8

Mungkin Anda memiliki beberapa aturan SELinux (atau grsecurity ...) yang sangat aneh dan restriktif?

Jika tidak, coba strace -o /tmp/wtf -fF curl -v google.comdan coba cari dari /tmp/wtffile keluaran apa yang terjadi.

— Janne Pikkarainen
sumber
1
Sepertinya itu koneksi wifi itu sendiri. File keluaran penuh dengan hal-hal seperti ini:9344 poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 1000) = 0 (Timeout)
— Daniel Quinn
@Daniel Quinn, bisakah Anda memposting output /tmp/wtf?
— Sachin Divekar
Inilah hasilnya: pastebin.com/1y5Z48NK
— Daniel Quinn
Hmm, sepertinya sedang melakukan query ke 192.168.1.201. Bisakah Anda melakukan "host google.com 192.168.1.201" untuk kewarasan? Pada dasarnya, pencarian DNS khusus terhadap server DNS Anda.
— cjc
Selesai (menambahkannya ke pertanyaan). Dan itu berfungsi dengan baik - yang masuk akal karena mengeluarkan host tanpa argumen server juga berfungsi dengan benar. Sepertinya itu hanya panggilan HTTP yang sebenarnya juga, karena ICMP (kebanyakan, ini menjatuhkan ping pertama) berfungsi.
— Daniel Quinn
5

Periksa /etc/nsswitch.conf. Jika hostsgaris mengatakan sesuatu seperti

hosts:      files dns

Aku sama bingungnya denganmu. Tetapi jika itu mengatakan sesuatu seperti

hosts:      files

maka fakta bahwa DNS berfungsi (lihat output dari hostperintah) tidak akan membantu curl, yang melakukan resolusi nama melalui pustaka OS standar, yang telah diberitahu untuk tidak menggunakan DNS.

— MadHatter mendukung Monica
sumber
Hmm. Saya tidak memikirkan itu, tapi saya baru saja memeriksa dan dikatakan files dnsjadi saya kira bukan itu :-(
— Daniel Quinn
1
Di tambang, ada lebih banyak barang di baris host. "dns" terdaftar setelah "[NOTFOUND = return]" yang, dalam pemahaman saya, menyebabkan sistem kembali tidak ditemukan bahkan sebelum memeriksa server DNS yang dikonfigurasi! Memindahkan "dns" sebelum hal yang belum diperbaiki memperbaiki sistem saya (harus reboot).
— trebormf
3

Saya memiliki masalah yang sama - host, nslookup menyelesaikan ok, curl - tidak bisa pada nama host yang sama.

Setelah komunikasi tcpdumping, saya menemukan bahwa curl mencoba membuat koneksi TCP (selain UDP) ke port DNS, yang ditutup di router saya. Setelah tcp port 53 diaktifkan, curl mulai bekerja dengan sempurna.

Hal aneh lainnya adalah bahwa masalah ini tidak muncul jika server dns adalah instalasi bind yang teratur. Jika saya menggunakan tertanam ke dalam server DNS router, curl tiba-tiba mencoba menggunakan port TCP bahkan jika sudah menerima (!) Menjawab melalui UDP 2ms sebelumnya. Saya kira ini adalah bug.

— Andrew
sumber
1

Saya memiliki masalah yang sama pada VE saya (berjalan di laptop saya) hari ini, dan merasa cukup mengejutkan. Dig dan NSlookup berfungsi, tetapi curl gagal.

Jadi misalnya:

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

Tetapi ketika saya melihat posting David T di sini, saya memutuskan untuk mencobanya dengan ikal. Jadi sementara ini gagal:

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

Ini berhasil:

# 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 menetapkan bahwa curl menggunakan IPv6 dan -4, untuk menggunakan IPv4. Saya mendapatkan kesalahan yang sama ketika menggunakan wget, jadi pasti beberapa masalah dengan tumpukan IPv6 di Host.

Semua modifikasi lain pada file nsswitch.conf dan file conf BIND lainnya tidak membantu karena masalahnya bukan pada utilitas ini.

— AkinO
sumber
1

Jika ini terjadi bagi siapa pun yang mencoba mengatur DNS untuk instance AWS EC2, pastikan juga mengaktifkan aturan IPv6 (:: / 0) untuk HTTP dan HTTPS dalam grup keamanan yang digunakan oleh instance tersebut.

— David Nathan
sumber
0

Apakah pemasangan ikal Anda mulus? Jika mungkin coba instal ulang ikal.

Cobalah curl -v google.comuntuk mendapatkan lebih banyak keluaran verbose untuk debugging.

misalnya:

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'

Apakah Anda mendapatkan hasil yang serupa?

— Sachin Divekar
sumber
Persis sama :-( Saya telah memperbarui pertanyaan dengan output.
— Daniel Quinn
0

Mungkin ada kesalahan pada file /etc/resolv.conf Anda yang bisa ditoleransi nslookup tetapi curl tidak.

Pertanyaan yang diajukan adalah, "Bagaimana mungkin saya bisa melakukan pencarian host tetapi bukan curl?"

Ini dimungkinkan karena curl menggunakan getaddrinfo () untuk menyelesaikan FQDN, sedangkan nslookup tidak. Sebagai gantinya, saya percaya nslookup mem-parsing /etc/resolv.conf menggunakan beberapa fungsi atau pustaka lainnya, atau melalui kode kustomnya sendiri. Saya tidak melihat kode sumber untuk memverifikasi ini, tetapi Anda dapat membuktikannya dengan menambahkan spasi putih di depan token nameserver di /etc/resolv.conf. nslookup dapat menguraikan ini tetapi getaddrinfo () tidak bisa.


Example /etc/resolv.conf
 nameserver 8.8.8.8

Jika resolv.conf Anda memiliki kesalahan ini, atau kesalahan lain yang ditoleransi oleh nslookup tetapi tidak getaddrinfo (), maka Anda dapat menyelesaikan FQDN dengan nslookup, tetapi Anda tidak akan dapat menggunakan curl pada FQDN itu.

Perbaiki: sebagai root, edit /etc/resolv.conf dan hapus spasi putih terkemuka di baris nameserver.

— mrjmh
sumber
The straceOutput menunjukkan query DNS yang dikirim tanpa menerima balasan. Itu tidak mendukung hipotesis kesalahan parsing pada /etc/resolv.conf. Namun, mungkin saja kursornya rusak dan menggunakan kursor yang berbeda dapat membantu.
— kasperd
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.