У меня есть два веб-сервера с CentOS 6.0. Один управляет нашим основным маркетинговым веб-сайтом (производственным сервером), а другой является промежуточным сервером для производственного сервера, так что почти точная копия. Оба они защищены межсетевым экраном и имеют частные IP-адреса. Брандмауэр подключен к нашему главному офису через VPN-туннель типа "сеть-сеть". Оба сервера имеют свои серверы имен, настроенные для использования наших внутренних DNS-серверов здесь, в нашем главном офисе.
На производственном сервере я сталкиваюсь с точно такая же проблема, даже с тем же именем хоста phx1-ss-2-lb.cnet.com. Проблема в том, что всякий раз, когда я пингую несуществующее доменное имя, я получаю взамен это имя хоста cnet.com. Даже в моих собственных доменах, если я сделаю somestupidsubdomain.mydomain.com, он вернется с адресом cnet. В этой беседе они сказали, что это был захват NXDOMAIN и что им следует использовать другие серверы имен. В моей ситуации этот производственный сервер использует те же серверы имен, что и все остальные в компании, но это не проблема ни для кого другого. Даже промежуточный сервер, являющийся зеркалом рабочего сервера, не имеет проблемы.
Я проверил файл / etc / hosts и там ничего необычного. Я посмотрел, как очистить локальный кеш DNS через nscd или bind, и ни один из них даже не установлен. Я использовал nslookup и запросил два назначенных мне DNS-сервера, и они вернулись с ошибками «домен не найден», как и следовало ожидать.
Где мне искать дальше?
РЕДАКТИРОВАТЬ
Я использовал tcpdump на порте 53, а затем пропинговал какой-то домен треп, и это результат, который я получил
14: 55: 39.884442 IP 192.168.4.11.59726> 192.168.0.22. Домен: 27749+ A? asdfjjjf.com. (30) 14: 55: 39.905778 IP 192.168.0.22.domain> 192.168.4.11.59726: 27749 NXDomain 0/1/0 (103) 14: 55: 39.905930 IP 192.168.4.11.46752> 192.168.0.22.domain: 18476 + А? asdfjjjf.com.com. (34) 14: 55: 39.926982 IP 192.168.0.22.domain> 192.168.4.11.46752: 18476 2/0/0 CNAME phx1-ss-2-lb.cnet.com., A 64.30.224.112 (82)
14: 55: 39.962067 IP 192.168.4.11.44686> 192.168.0.22. Домен: 5275+ PTR? 112.224.30.64.in-addr.arpa. (44)
14: 55: 39.983324 IP 192.168.0.22. Домен> 192.168.4.11.44686: 5275 1/0/0 PTR phx1-ss-2-lb.cnet.com. (79)
Итак, если я правильно это понимаю, означает ли это, что мой DNS-сервер определенно отвечает адресом cnet.com? Если я использую nslookup, устанавливаю его на сервер 192.168.0.22 и запрашиваю тарабарную запись A в доменах, она ничего не возвращает.
Ага! У вас есть поисковый суффикс com - ваш первый запрос к asdfjjjf.com получил надлежащий NXDOMAIN, а второй - asdfjjjf.com.com вернулся с точной информацией о том, что очевидно является подстановочным знаком CNAME в *.com.com. Отбросьте этот суффикс поиска, и все будет в порядке.
Теперь более подробное обсуждение продолжается на
http://centos.org/modules/newbb/viewtopic.php?topic_id=36693&forum=59
Использование "strace" в "ping" ясно показывает, что проблема действительно в локальных библиотеках. Трассировка показывает вызовы DNS, и локальная библиотека действительно вставляет дополнительный ".com" при повторных попытках запроса DNS. На трассировке четко видно, что библиотека делает запрос DNS для «noexample.com», затем пытается «noexample.com», а затем использует результат «noexample.com» для проверки связи.
Я видел точно такую же ситуацию на выделенном сервере, расположенном в Codero. Это полноценный выделенный сервер, 64-битная CentOS 6, без виртуализации, управляемая с помощью Webmin. Он не запускается "по имени"; все DNS-запросы отправляются на внутренние DNS-серверы Codero. Как и в примере выше, «ping» (и все, что использует getaddrinfo), учитывая несуществующий домен в «.com», вернет хост в CNET:
ping noexample.com PING phx1-ss-2-lb.cnet.com (64.30.224.112) 56 (84) байтов данных. 64 байта с phx1-ss-2-lb.cnet.com (64.30.224.112): icmp_seq = 1 ttl = 246 time = 11,8 мс 64 байта с phx1-ss-2-lb.cnet.com (64.30.224.112): icmp_seq = 2 ttl = 246 время = 12,0 мс
Однако «nslookup» и «host» правильно не находят «noexample.com». Так что DNS-серверы Codero этого не делают.
/etc/resolv.conf (сгенерированный WebMin) выглядит следующим образом:
сервер имен 69.64.66.11 сервер имен 69.64.66.10
Если я попробую "noexample.net", он не найдет IP-адрес. Это проблема только в зоне .com.
Я заметил, что «getaddrinfo» теперь пытается прикрепить «.com» к окончанию проблем, которые не разрешаются. Если я попытаюсь разрешить «example», он найдет «example.com». Так что у меня появилась идея записи A.
Похоже на ошибку в "getaddrinfo". Никогда не следует добавлять ".com" к тому, в чем он уже есть.
Вот что происходит.
Думаю, я понимаю, что происходит. См. Страницу руководства для "resolv.conf:
http://linux.die.net/man/5/resolv.conf
Обратите внимание на значение по умолчанию:
домен Локальное доменное имя. Большинство запросов для имен в этом домене могут использовать короткие имена относительно локального домена. Если запись о домене отсутствует, домен определяется по локальному имени хоста, возвращаемому функцией gethostname (2); под доменной частью понимается все, что находится после первого '.'. Наконец, если имя хоста не содержит части домена, предполагается корневой домен.
В этом случае имя сервера по умолчанию - «sitetruth.com». Таким образом, «доменная часть» - это «.com», и любые неудачные попытки поиска повторяются с добавлением «.com».
Почему это не происходит все время? Потому что большинство серверов имеют имена, присвоенные какой-либо службой хостинга, например "gator123.hostgator.com". В таких случаях доменом по умолчанию является hostgator.com, и это то, что добавляется при неудачных поисках домена. Однако, если ваш сервер имеет двухкомпонентное имя в качестве основного имени, возникает проблема.
Неправильно выбрано значение по умолчанию в "resolv".
Возвращаясь к исходному вопросу, когда проблема возникла только на производственном сервере, я готов поспорить, что рабочий сервер имеет имя, например, «companyname.com», а тестовый сервер имеет более длинное имя, например «test.companyname». com ". Этого достаточно, чтобы создать такую ситуацию.
Установка «ndots» в 0 или предоставление пустой строки «search» должны отключить это поведение, но пока этого не происходит. Так что у меня пока нет исправления.