Ведомое устройство BIND не синхронизирует с ведущим устройством, пока оно не перезапущено
Используя GRUB (в госте) потребовал бы BIOS, который в свою очередь Xen может только выполнить при аппаратных средствах виртуализации. установка личинки поэтому может оказаться бесполезной, больше если Ваш виртуальный диск работает без таблицы разделов.
Пакет xen-инструментов поставлется, программа, названная pygrub (похож на личинку, но автономен), который извлекает ядро и initramfs от виртуального диска (с или без таблицы разделов) на хосте и заставляет xen запускаться с этого. Позитивный аспект - то, что обновления ядра и модификации grub/menu.lst в госте становятся "немедленно допустимыми".
Более старая альтернатива указывает изображение ядра для загрузки в/etc/xen/vm/yourmachine.conf, хотя необходимо вручную обновить yourmachine.conf каждый раз.
Из вашего описания я не могу точно сказать, в чем проблема, но я могу помочь вам исключить несколько вещей.
Настройки размера кеша и ttl кеша настройки предназначены для кэшированных данных рекурсивного запроса и (как вы уже подозревали) не применяются к достоверным данным. Аналогичным образом rndc flush здесь неприменим.
Предлагаемый метод устранения неполадок:
- Убедитесь, что уведомления отправляются мастером, как ожидалось. Проверьте журналы и / или проанализируйте трафик между ведущим и ведомым.
- Убедитесь в журналах, что уведомляющее сообщение получено ведомым.
- Если вы не видите, что ведомое устройство получает уведомление, устраните неполадки как проблему уведомления , т.е. дважды проверьте параметры уведомления в named.conf на главном сервере, убедившись, что они определены так, как вы ожидаете, и не переопределены позже, и имеют соответствующую область видимости. Я рекомендую использовать "явное уведомление"; with "also-notify {slave-server;};"
- Если подчиненный видит уведомление, ваша проблема заключается в выяснении, почему файл зоны не обновляется так, как вы ожидали. Что должно произойти , так это то, что после получения уведомления ведомое устройство должно сделать запрос SOA, сравнить с его текущим SOA и выполнить AXFR (или IXFR, если вы его включили), чтобы получить обновленную копию зоны ( при условии, что SOA на главном сервере выше.) Вы должны иметь возможность наблюдать за всем этим происходящим с помощью сниффера, и вы также должны видеть доказательства этого в журналах на обоих серверах.
- Если операции не происходят так, как вы ожидали , начните с ручного сравнения серийных номеров SOA на двух серверах (dig @server $ zonename SOA), чтобы убедиться, что вы этого не сделали.
Пожалуйста, не забывайте увеличивать серийный идентификатор из файлов зон, когда вы вносите изменения в главный сервер перед перезагрузкой, иначе файлы зон не будут реплицированы на подчиненный сервер.
Я столкнулся с той же ситуацией. Мои исследования привели меня к следующему осознанию. Если вы используете views, то dig@local машина будет обслуживать только то, что находится в localhost-view. localhost-view обновляется только при перезапуске имени. Но последний файл зоны (переданный от ведущего) все еще доступен на ведомом устройстве и будет обслуживаться всеми запросами, поступающими из внешних источников или внешних видов. Поэтому вам нужно сделать так, чтобы ваш localhost-просмотр обновлялся.
.