Возможен ли угон NXDOMAIN?
У меня есть два веб-сервера на нашем совместном предприятии под управлением 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, а затем пропинговал какой-то домен jibberish, и это вывод, который я получил
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.domain> 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 и запрашиваю запись доменов Jibberish A, она возвращается ни с чем.
4 ответа
Ага! У вас есть поисковый суффикс 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.com", а затем использует результат из "noexample.com.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 время =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) просто так:
nameserver 69.64.66.11 nameserver 69.64.66.10
Если я пытаюсь "noexample.net", он не находит IP-адрес. Это только проблема.com.
Я заметил, что "getaddrinfo" теперь пытается наклеить ".com" на конец вещей, которые не разрешаются. Если я пытаюсь разрешить "пример", он находит "example.com". Итак, я получил идею записи.
Это похоже на ошибку в "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". ком". Этого достаточно, чтобы создать эту ситуацию.
Установка "ndots" в 0 или предоставление пустой строки "search" должна отключить это поведение, но пока этого не происходит. Так что у меня пока нет решения.