Здесь немного странная проблема, и надеюсь, что кто-то поможет мне описать и / или исправить. Мы были в сети / 24 А.А.А.А и недавно перешел на B.B.B.B. Все серверы имен были обновлены с помощью регистратора, они отображаются на корневом сервере имен и все такое - пока все хорошо, верно? Я могу выкопать корневые серверы и получить новые IP-адреса, ну и все в порядке, и все вопросы "подключено ли оно?" фундамент выглядит отлично.
Я использую DNS в новой сети по адресу B.B.B.254 и старая сеть в A.A.A.254 поскольку изменения все еще распространяются по всему миру. В A.A.A.254 DNS-сервер фактически скармливает миру IP-адреса для B.B.B.B ловить отставших, которые еще не видели изменений в восходящем направлении, нормальный бизнес. Каждый сервер также использует обратный DNS для своего собственного диапазона IP-адресов.
ТАК! В журнале запросов на старом A.A.A.254 сервер я вижу странный запрос зоны PTR от B.B.B.254 для собственной сети обратного IP B! И это всегда для двух IP-адресов - моего брандмауэра (.4) и VPN-сервера (.6) - не других, кроме этих двух.
4 августа 2009 г. 09:56: 09.755 клиент B.B.B.254 # 37384: запрос: 4.B.B.B.in-addr.arpa IN PTR +
04 августа 2009 г. 10:00: 05.380 клиент B.B.B.254 # 37385: запрос: 6.B.B.B.in-addr.arpa IN PTR +
Почему существует такой запрос, запрашивающий IP-зону, B.B.B.254 уже хостинг, иду на мой A.A.A.254 сервер ?! Я не должен получать запросы от B.B.B.254 к A.A.A.254 вообще, но я все еще получаю эти случайные PTR-задания, которые я не могу понять. «Dig -x» из B не приводит к тому, что он переходит в A, так что все не так просто. Я просмотрел каждый файл конфигурации на B (это ящик linux / bind9) на предмет каких-либо ссылок на сеть A, ничего не нашел.
Кто-нибудь знает, что здесь происходит и как я могу это исправить? Почему новый сервер B запрашивает у A этот PTR, когда он знает, что сам размещает этот диапазон?
Я следил по разным маршрутам, таким как:
dig + norecurse 4.B.B.B.in-addr.arpa PTR @ x.arin.net
...затем...
dig + norecurse 4.B.B.B.in-addr.arpa PTR @a. [имя авторитетного сервера]
... и все в порядке. Любые идеи приветствуются, где дальше искать, чтобы отследить, что вызывает этот цикл запроса, я немного не понимаю, на что смотреть дальше.
Я счастлив (в восторге!) Сообщить, что проблема решена - на самом деле проблемный ребенок был syslogd на b.b.b.254! Alnitak направил меня по правильному пути, после того как несколько раз запустил захват tcpdump на машине b.b.b.254 и поместил named на уровень отладки 5, я наткнулся на тот факт, что DNS-запрос был сделан, но не исходил от указанного процесса.
Я не являюсь крупным экспертом по syslogd, но это как-то связано с тем фактом, что этот syslogd работает в режиме удаленной регистрации и принимает журналы с рассматриваемых устройств (.4, .6). Несмотря на то, что он правильно работал в новой сети, что-то в его маленьком мозгу демона все еще кэшировало информацию из старой сети (хотя я не совсем понимаю, как), и именно этот процесс выполнял запрос PTR к старому DNS-серверу для новый обратный диапазон IP. Простой '/etc/init.d/syslogd restart' убрал ошибочные запросы, и теперь все в порядке.
В конце концов, это всегда простые вещи, для этого требуется всего 8 часов отладки. :)
Resolv.conf включен B.B.B.254 возможно настроен на отправку запросов на старый DNS сервер? (Этого не должно быть, потому что рекурсивный и авторитетный не должны смешиваться). Также является B.B.B.254 возможно, настроен как шлюз по умолчанию для диапазона RFC1918 с NAT? В таком случае что-то позади эта машина может быть неправильно сконфигурирована относительно рекурсивного разрешения.
Кроме того, может быть полезно иметь фактические диапазоны IP-адресов, чтобы люди могли действительно изучить ваши делегации.
Дословны ли эти выдержки из журнала отдельно от IP-адресов?
Если это так, кажется удивительным, что в течение 4-минутного интервала, по-видимому, не было другого IP-трафика, о чем свидетельствует порт источника этих запросов, увеличивающийся только на один.
Я предлагаю вам попытаться подтвердить, что эти запросы действительно отправляет B.B.B.254 (запустите tcpdump на передающем хосте).
Если вы можете, попробуйте выяснить, какой процесс их вызывает. Если это named на новом сервере включите больше журналов, чтобы узнать, почему (rndc trace и rndc querylog).
Обратите внимание, что если вы перенумеровали свою сеть и перенастроили свои машины, не отключая их, то любые давно работающие демоны могут по-прежнему иметь старые /etc/resolv.conf кешируется в них.
Попасть в страну программирования, потому что /etc/resolv.conf читается только res_init() функция из библиотеки резолвера при первом вызове любой программы gethostbyname() или gethostbyaddr(). Библиотека преобразователя не обнаруживает изменения в файле конфигурации на лету.
Выстрел в темноте: вы уверены, что очистили все кеши DNS? Я видел такие странные вещи, как этот, потому что что-то имело старое устаревшее представление DNS в каком-то кеше, которое просто по какой-то причине не сбрасывалось ...