завиток не работает с первой попытки

Question

Я только что установил Fedora 19 LXDE. Когда я бегу локон для URL впервые он не:

curl -v youtube.com 
* Could not resolve host: youtube.com; Name or service not known 
* Closing connection 0 
curl: (6) Could not resolve host: youtube.com; Name or service not known 

Если я повторно эту команду сразу это удается.

curl -v youtube.com 
* About to connect() to youtube.com port 80 (#0) 
* Trying 80.239.229.212... 
* Connected to youtube.com (80.239.229.212) port 80 (#0) 
> GET/HTTP/1.1 
> User-Agent: curl/7.29.0 
> Host: youtube.com 
> Accept: */* 
> 
< HTTP/1.1 301 Moved Permanently 
< Date: Tue, 10 Sep 2013 20:05:20 GMT 
< Server: gwiseguy/2.0 
< Location: http://www.youtube.com/ 
< Content-Length: 0 
< Content-Type: text/html 
< X-XSS-Protection: 1; mode=block 
< 
* Connection #0 to host youtube.com left intact 

Похоже, что если опция -4 указана, все работает правильно. В чем может быть проблема?

nslookup отлично работает, никаких проблем с разрешением.

Update:

когда я бегу Трассирование против безуспешно пытаться, я вижу следующие ошибки:

open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 
open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) 

и эхо $ LANG LANG =/en_US.UTF-8 Может ли это быть связано?

Дополнительная информация:
Я использую Fedora 15 с Gnome. Все работало нормально. Затем я попробовал Fedora 19 с LXDE и XFCE. У обоих из них одна и та же проблема с завитом.

Разрешение:
Кажется, проблема связана с IPv6.
1) Создан ~/.curlrc с "--ipv4" внутри. Он решил некоторые проблемы браузера.
2) Чтобы исправить yum, добавьте «ip_resolve = 4» в /etc/yum.conf.

Answer 1

Использование www.youtube.com против youtube.com.

Полная команда:

curl -v www.youtube.com 

HTTP 301 ошибка означает, что страница была перемещена на новый адрес. В этом случае указывается в поле «Location» в ответе сервера:

Расположение: http://www.youtube.com/

Если вы не хотите, чтобы беспокоиться об этом, вы можете указать --location/-L флаг так, что он будет следовать HTTP редирект (301 & другие), а затем вы можете использовать youtube.com:

curl -v -L youtube.com 

Answer 2

может быть проблема DNS вашего провайдера.

Попробуйте выполнить ping ваш основной DNS, чтобы подтвердить его рабочее состояние.

Answer 3

Имел такую ​​же проблему на нескольких (но не всех) компьютерах в моей домашней локальной сети на пару лет и, наконец, решил!

Что сработало для меня: у меня есть WiFi-маршрутизатор от BT (мой интернет-провайдер). Если он предоставляет свой собственный (т. Е. Шлюз) адрес в качестве обоих серверов имен через DHCP - видимо, работает как локальный DNS-кеш. Кроме того, он транслирует один домен поиска через DHCP, и он жестко закодирован как «домашний» (т. Е. В интерфейсе маршрутизатора нет возможности его перенастроить).

Наконец-то я понял, что в моих системах, не имеющих этой проблемы, было отключено использование поисковых доменов, в то время как недавно установленные (и не глубоко настроенные) системы stiil имели строку «поиск дома» в /etc/resolv.conf. Все, что мне было нужно, было поручить всем локальным клиентам DHCP отключить функцию поисковых доменов - через какое-то время через конфигурацию через скрипт: конкретный метод зависит от вашего клиента, поэтому я не могу дать один рецепт для всех.

Я могу только предположить, что первая попытка попыталась выполнить поиск, скажем, youtube.com.home, тогда маршрутизатор сам отклонит его, и в следующий раз локальный DNS-клиент запросит этот же домен без добавления суффикса поиска на некоторое короткое время до его NXDOMAIN кеш заканчивается (т. е. если следующая попытка была примерно через 15 минут, она снова не удалась).

P.S. Я много раз искал решение в Интернете и обнаружил, что многие другие люди сообщали о такой же проблеме на маршрутизаторах BT, но не предлагали никаких решений. Таким образом, даже если этот сценарий не имеет отношения к проблеме OP, я все равно оставляю свой ответ всем счастливым владельцам BT-маршрутизаторов.

Update:

Кстати, отключение ipv6 не помогло, когда я попробовал. И да, я проверял /etc/nssswitch.conf и настроил разрешение хостов, чтобы подчиняться только/etc/hosts и главному DNS, никаких других острых ощущений. Ни один из этих методов не был основной причиной,