Як можливо, я можу зробити пошук хостів, але не завиток?

Хтось коли-небудь бачив це раніше? Зауважте, що це відбувається не лише з 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, не може працювати під час пошуку імен. Більше того, якщо я візьму wifi офлайн і підключую кабель Ethernet, все добре.

Можливо, у вас є якісь дуже дивні та обмежувальні правила SELinux (або грубе безпеки ...)?

Якщо ні, спробуйте 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команди), не допоможе згорнутися, що робить роздільну здатність імен через стандартні бібліотеки ОС, яким було наказано не використовувати DNS.

У мене була така ж проблема - хост, nslookup вирішує "нормально", "згортати" - не може бути на тих же іменах хостів.

Після tcpdumping зв'язку я виявив, що curl намагається встановити TCP (крім UDP) з'єднання з портом DNS, який був закритий у моєму маршрутизаторі. Після ввімкнення порту tcp 53 curl почав працювати бездоганно.

Ще одна дивна річ у тому, що ця проблема не виникає, якщо dns-сервер регулярно встановлює прив'язку. Якщо я використовую вбудований DNS-сервер маршрутизатора, curl раптово намагається використовувати порти TCP, навіть якщо він вже отримав (!) Відповідь через UDP 2ms раніше. Я гадаю, це помилка.

У мене була така ж проблема на моєму VE (працює на моєму ноутбуці) сьогодні, і це було надзвичайно дивно. Dig та 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  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 використовує getaddrinfo () для вирішення FQDN, тоді як nslookup цього не робить. Натомість я вважаю, що nslookup аналізує /etc/resolv.conf, використовуючи якусь іншу функцію чи бібліотеку, або через власний спеціальний код. Я не переглянув вихідний код, щоб перевірити це, але ви можете довести це, додавши пробіл перед позначкою сервера імен у /etc/resolv.conf. nslookup може проаналізувати це, але getaddrinfo () не може.

Example /etc/resolv.conf
 nameserver 8.8.8.8

Якщо у вашій резолюції.conf є ця помилка або інші помилки, допущені nslookup, але не getaddrinfo (), ви можете вирішити FQDN за допомогою nslookup, але ви не зможете використовувати curl для цього FQDN.

Виправити: як root, відредагуйте /etc/resolv.conf та видаліть будь-який провідний пробіл у рядку сервера імен.