Как это возможно, что я могу сделать поиск хоста, но не скручивание?

Кто-нибудь когда-нибудь видел это раньше? Обратите внимание, что это происходит не только с google.com, но и с каждым доменом, который я пробую. Это беспроводное соединение (WEP), но я не уверен, насколько это уместно:

$ 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

По сути, любое приложение, включая Firefox, не может выполнять поиск имен. Более того, если я отключу Wi-Fi и подключу кабель Ethernet, все будет хорошо.

Возможно, у вас есть какие-то очень странные и строгие правила SELinux (или grsecurity ...)?

Если нет, попробуйте strace -o /tmp/wtf -fF curl -v google.comи попробуйте определить из /tmp/wtfвыходного файла, что происходит.

Используя это: https://www.centos.org/modules/newbb/viewtopic.php?topic_id=39343

Я нашел ключевую команду, которая помогла мне устранить неполадки:

[root @ localhost ~] # wget -6 Сбой URL-адреса

[root @ localhost ~] # wget -4 URL работал

Это связано со стеком ipv6 по умолчанию, что вызывает проблемы с некоторыми утилитами. Отключить ipv6 для разрешения.

Проверьте свой /etc/nsswitch.conf. Если hostsстрока говорит что-то вроде

hosts:      files dns

Я так же смущен, как и ты. Но если это говорит что-то вроде

hosts:      files

тогда тот факт, что DNS работает (см. вывод hostкоманды), не поможет curl, который выполняет разрешение имен через стандартные библиотеки ОС, которым сказано не использовать DNS.

У меня была та же проблема - хост, nslookup решает нормально, curl - не может на тех же именах хостов.

После связи tcpdumping я обнаружил, что curl пытается установить TCP (в дополнение к UDP) соединение с портом DNS, который был закрыт в моем маршрутизаторе. После включения TCP-порта 53 curl начал работать без сбоев.

Другая странная вещь заключается в том, что эта проблема не возникает, если на DNS-сервере выполняется обычная установка bind. Если я использую встроенный в маршрутизатор DNS-сервер, curl внезапно пытается использовать порты TCP, даже если он уже получил (!) Ответ через UDP за 2 мс до этого. Я полагаю, это ошибка.

У меня была такая же проблема на моем VE (работающем на моем ноутбуке) сегодня, и я нашел это довольно удивительным. Копать и NSlookup работает, но скручивание не удается.

Так, например:

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

Но когда я увидел пост Дэвида Т. здесь, я решил попробовать его с помощью curl. Итак, пока это не удается:

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

Это успешно:

# 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 указывает, что curl использует IPv6 и -4 для использования IPv4. Я получаю те же ошибки при использовании wget, поэтому определенно возникают проблемы со стеком IPv6 на хосте.

Все остальные модификации файла nsswitch.conf и других conf-файлов BIND не помогли, так как проблема не в этих утилитах.

Если это происходит для тех, кто пытается настроить DNS для экземпляра AWS EC2, обязательно включите также правила IPv6 (:: / 0) для HTTP и HTTPS в группе безопасности, используемой этим экземпляром.

Была ли ваша скручиваемость гладкой? Если возможно попробуйте переустановить curl.

Попробуйте curl -v google.comполучить более подробный вывод для отладки.

например:

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'

Вы получаете похожий вывод?

В файле /etc/resolv.conf может быть ошибка, которую допускает nslookup, а curl - нет.

Задаваемый вопрос был: «Как это возможно, что я могу выполнить поиск хоста, но не завиток?»

Это возможно, потому что curl использует getaddrinfo () для разрешения полного доменного имени, а nslookup - нет. Вместо этого я считаю, что nslookup анализирует /etc/resolv.conf, используя какую-то другую функцию или библиотеку, или через свой собственный код. Я не смотрел исходный код, чтобы проверить это, но вы можете доказать это, добавив пробел перед токеном сервера имен в /etc/resolv.conf. nslookup может разобрать это, но getaddrinfo () не может.

Example /etc/resolv.conf
 nameserver 8.8.8.8

Если ваш resolv.conf имеет эту ошибку или другие ошибки, которые допускаются nslookup, но не getaddrinfo (), вы можете разрешить полное доменное имя с помощью nslookup, но вы не сможете использовать curl для этого полного доменного имени.

Исправьте: как root, отредактируйте /etc/resolv.conf и удалите все начальные пробелы в строке сервера имен.