Назад | Перейти на главную страницу

Ведомое устройство BIND не синхронизируется с ведущим, пока не будет перезапущено

У меня есть два DNS-сервера, на которых запущен BIND9, один главный и один подчиненный. Когда файл зоны обновляется на главном сервере, я хочу, чтобы подчиненный сервер немедленно начал обслуживать измененные записи, но BIND дает мне некоторую болтовню.

Передача зоны DNS между ведущим и ведомым уже работает правильно. Я могу войти на подчиненный сервер и запустить dig @dnsmaster myzone. AXFR и распечатывает все содержимое зоны. Чтобы это работало, мастер DNS настроен с notify yes и also-notify { dnsslave }. Точно так же ведомое устройство настроено с allow-transfer { dnsmaster }.

Когда dnsmaster обновлен, я запускаю rndc reload и он сообщает мне, что отправляются уведомления. Это подтверждается на ведомом устройстве путем проверки файлов зон в /var/named/slavedata/. Они содержат самые свежие данные, соответствующие тому, что знает мастер.

А теперь самое странное.

Подчиненный сервер будет продолжать обслуживать старые устаревшие записи DNS, полностью игнорируя тот факт, что новые данные доступны на диске после уведомления от ведущего. я использую dig чтобы проверить результаты с помощью этой команды: dig @slaveserver record.zone.tld.

Я подумал, что BIND может хранить в памяти кеш своих авторитетных зон, поэтому я установил max-cache-size и max-cache-ttl до 0, но это не повлияло.

Я пробовал другие способы очистки этого предполагаемого кеша, выполнив такие команды, как rndc flush и rndc reload на подчиненном сервере, но он по-прежнему возвращает старые устаревшие записи.

Наконец я заметил, что MINTTL в зоне было установлено значение 86400 (24 часа), поэтому я временно изменил MINTTL до 15 секунд и перезапустил подчиненный сервер. Никакого эффекта - ведомое устройство будет предоставлять обновленные результаты DNS только после перезапуска службы.

Что тут происходит? Каково ожидаемое поведение BIND9 при получении уведомления об обновлении зоны? Всегда ли уважает TTL и MINTTL? Я предполагаю, что он всегда будет использовать самые свежие доступные данные.

В конце концов, я подумываю о настройке crontab для ежечасного перезапуска подчиненных серверов BIND, просто чтобы избежать обслуживания устаревших данных. есть что-нибудь получше?

Из вашего описания я не могу точно сказать, что является проблема, но я могу помочь вам исключить несколько вещей.

Параметры размера кеша и параметры ttl кеша предназначены для кэшированных данных рекурсивного запроса и (как вы уже подозревали) не применяются к достоверным данным. Точно так же rndc flush здесь не применяется.

Предлагаемый метод устранения неполадок:

  1. Убедитесь, что уведомляющие сообщения отправляются мастером, как ожидалось. Проверьте журналы и / или проанализируйте трафик между ведущим и ведомым.
  2. Проверьте по журналам, что уведомляющее сообщение получено ведомым устройством.
  3. Если вы не видите, что ведомое устройство получает уведомление, устраните неполадки как проблему с уведомлением, т.е. дважды проверьте параметры уведомления в named.conf на ведущем устройстве, чтобы убедиться, что они определены так, как вы ожидаете, не переопределяются позже и имеют соответствующую область видимости. Я рекомендую использовать "явное уведомление"; с "также-уведомить {подчиненный-сервер;};"
  4. Если раб является видя уведомление, ваша проблема заключается в том, чтобы выяснить, почему файл зоны не обновляется должным образом. какой должен происходит после получения уведомления, ведомое устройство должно сделать запрос SOA, сравнить с его текущим SOA и выполнить AXFR (или IXFR, если вы его включили), чтобы получить обновленную копию зоны (при условии, что SOA на главном устройстве выше .) Вы должны иметь возможность наблюдать за всем этим с помощью сниффера, и вы также должны видеть свидетельства этого в журналах на обоих серверах.
  5. Если операции выполняются не так, как вы ожидали, начните с ручного сравнения серийных номеров SOA на двух серверах (dig @server $ zonename SOA), чтобы убедиться, что вы случайно не присвоили ведомому устройству серийный номер, превышающий ожидаемый. в прошлом, который сейчас выше серийного номера мастера.

Если это не сработает, рассмотрите возможность публикации дополнительной информации, включая разделы named.conf как с главного, так и с подчиненного сервера, а также журналы с обоих серверов о том, что происходит после загрузки только что отредактированной зоны на главном сервере.

Я столкнулся с такой же ситуацией. Мои исследования привели меня к следующему выводу. Если вы используете представления, то компьютер dig @ local будет обслуживать только то, что находится в представлении localhost. localhost-view обновляется только во время перезапуска named. Но последний файл зоны (переданный с ведущего устройства) все еще доступен на ведомом устройстве и будет обслуживаться для всех запросов, поступающих из внешних источников или внешних представлений. Итак, вам нужно принять меры, чтобы ваше представление localhost обновилось.

Не забудьте увеличить серийный идентификатор из файлов зон при внесении изменений в главный сервер перед перезагрузкой с именем, иначе файлы зон не будут реплицированы на подчиненный сервер.