Я только что установил CentOs 6.3 на сервере, который будет установлен в центре обработки данных, но не могу заставить работать разрешение имен / завиток.
Я знаю, что это из-за того, что он пытается использовать ipv6, поскольку ping google.com работает, curl -4 google.com работает, но не curl google.com.
Я удалил адрес ipv6 из интерфейса, и он ничего не меняет.
Это очень проблематично, поскольку большинство системных инструментов, таких как yum в настоящее время не удается разрешить имя. Такие браузеры, как Firefox, работают, потому что они могут использовать другой инструмент для разрешения имен, чем тот, который использует curl.
Мне удалось исправить это на рабочих станциях, полностью отключив ipv6 в следующих руководствах, таких как вот этот / hardcoding разрешение имени в /etc/hosts. Но поскольку я здесь настраиваю сервер, который позже будет установлен в удаленном центре обработки данных, мне бы хотелось не напортачить, понять, что происходит, и исправить это должным образом. Кроме того, я столкнусь с той же проблемой с другими серверами, поэтому я был бы очень признателен за вашу помощь в понимании этой проблемы и способах ее решения.
Я был бы рад предоставить дополнительную информацию, если это необходимо, чтобы помочь понять, что происходит.
Текущая сетевая конфигурация представляет собой сеть небольшого предприятия с DNS-сервером (назовем его А) настраивал когда-то очень давно. dig google.com и dig -4 google.com оба отвергаются А DNS. Но это также верно и для моей рабочей станции, на которой curl работает (и да, они оба используют одно и то же А DNS-сервер). Действительно, этот неисправный сервер и моя рабочая станция имеют несколько серверов имен в /etc/resolv.conf, а второй работает нормально для них обоих, поэтому, если я удалю А от моего resolv.conf все отлично работает!
С Уважением,
Оливье
Мне пришлось устранить это, и кажется, что до версии Centos 6.x (например, 5.8 и старше) поведение по умолчанию для DNS-преобразователя glibc было таким. Клиент запрашивал у DNS-сервера адрес IPv6 (запись AAAA), а у DNS-сервера была только запись IPv4, о которой он сказал - у меня ее нет (NX). Затем клиент повторно запросил это еще 5 раз, получая тот же ответ, пока не сказал - эй, сервер, дай мне адрес IPv4. А затем сервер предоставил запись A, и клиент остался доволен. В моей сети весь этот танец длился менее 300 миллисекунд, поэтому конечные пользователи почти не заметили его.
Это изменилось в Centos 6.x, где два запроса выполнялись параллельно - одновременно запрашивалась запись IPv6 и запись IPv4. Если ваш DNS-сервер ответил NX (у меня его нет) для адреса IPv6, клиент полностью проигнорировал действительный ответ с адресом A (IPv4), потому что он пришел на долю секунды позже. Таким образом, он снова запросил DNS-сервер (выполняя запросы как IPv6, так и IPv4) и оказался в той же ситуации. Поэтому он начал выполнять эти запросы, добавляя DNS-запросы к поиску, после того как окончательно отказался.
Это было исправлено в Centos 6.7, где клиент ждет этого второго ответа IPv4 и с радостью принимает его, что в моей сети занимает около 15 миллисекунд. Вероятно, это соответствующий билет Redhat для этого - https://bugzilla.redhat.com/show_bug.cgi?id=845218 (Не ошибитесь, если один из двух ответов на AF_UNSPEC не сработает):
rpm -q --changelog glibc | sed -n '0,/2.12-1.132/p' | grep AF_UNSPEC
- Do not fail if one of the two responses to AF_UNSPEC fails (#845218).
Теперь этот билет ограничен, поэтому вот вероятный патч восходящего потока: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=16b293a7a6f65d8ff348a603d19e8fd4372fa3a9
Для получения подробной информации, вот список затронутых серверов:
SUSE Linux для сравнения:
В inet4only опция для /etc/resolv.conf никогда не была реализована, https://bugzilla.redhat.com/show_bug.cgi?id=1027452
Я решил эту проблему с помощью следующего диагностического процесса, который можно применить при решении проблем с разрешением имен и ipv6.
dig google.com и dig -4 google.com, на машине с этой проблемой и на другой в той же сети, где эта проблема отсутствует./etc/resolv.conf не настроен для ipv6. Удалите его и повторите попытку.Один кал также использовать digg @nameserver google.com для тестирования других возможных серверов имен в /etc/resolv.conf без изменения этого файла.