Кто-нибудь видел такое раньше? Обратите внимание, что это происходит не только с 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, все будет в порядке.
Используя это: https://www.centos.org/modules/newbb/viewtopic.php?topic_id=39343
Я нашел ключевую команду, которая помогла мне устранить неполадки:
[root @ localhost ~] # wget -6 Ошибка URL
[root @ localhost ~] # wget -4 URL сработал
Это как-то связано со стеком ipv6 по умолчанию, который вызывает проблемы с некоторыми утилитами. Отключите ipv6 для разрешения.
Возможно, у вас есть какие-то очень странные и ограничивающие правила SELinux (или grsecurity ...)?
Если нет, попробуйте strace -o /tmp/wtf -fF curl -v google.com и попытайтесь определить от /tmp/wtf выходной файл, что происходит.
Проверьте свои /etc/nsswitch.conf. Если hosts строка говорит что-то вроде
hosts: files dns
Я сбит с толку, как и ты. Но если там написано что-то вроде
hosts: files
то факт, что DNS работает (см. вывод host command) не поможет curl, который выполняет разрешение имен через стандартные библиотеки ОС, которым было сказано не использовать DNS.
У меня была та же проблема - хост, nslookup разрешает нормально, curl - не может на тех же именах хостов.
После связи tcpdumping я обнаружил, что curl пытается установить TCP (в дополнение к UDP) соединение с портом DNS, который был закрыт в моем маршрутизаторе. После включения 53 порта tcp curl начал работать без сбоев.
Еще одна странность заключается в том, что эта проблема не возникает, если днс сервер проходит обычную установку привязки. Если я использую встроенный в маршрутизатор DNS-сервер, curl внезапно пытается использовать TCP-порты, даже если он уже получил (!) Ответ через UDP 2 мс раньше. Полагаю, это ошибка.
Сегодня у меня была такая же проблема на моем VE (работающем на моем ноутбуке), и это показалось мне весьма удивительным. Dig и NSlookup работают, но curl не работает.
Так например:
# 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 и других файлов конфигурации 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 для этого полного доменного имени.
Исправление: отредактируйте /etc/resolv.conf от имени пользователя root и удалите все начальные пробелы в строке сервера имен.