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

BIND DNS Master с Zerigo Slaves - BIND не будет обновлять подчиненные серверы

Я пытался решить эту проблему самостоятельно, просмотрел Google и Stack, но не нашел ответа, который ищу.

В настоящее время на сервере VPS у меня установлен BIND DNS как ГЛАВНЫЙ DNS-сервер. Я использую службу DNS Zerigo как ВЕДОМЫЕ серверы для общего пользования: Мастер не получает запросов - его задача просто создавать и изменять записи DNS локально, которые ВЕДОМЫЙ использует для обслуживания.

Вот отрывок из журнала BIND, я установил его в журнал событий INFO:

14-Apr-2012 23:00:00.234 general: info: received control channel command 'reload'
14-Apr-2012 23:00:00.234 general: info: loading configuration from 'C:\DNS\BIND\etc\named.conf'
14-Apr-2012 23:00:00.234 general: info: using default UDP/IPv4 port range: [1024, 65535]
14-Apr-2012 23:00:00.234 general: info: using default UDP/IPv6 port range: [1024, 65535]
14-Apr-2012 23:00:00.250 general: info: reloading configuration succeeded
14-Apr-2012 23:00:00.250 general: info: reloading zones succeeded
14-Apr-2012 23:16:22.750 xfer-out: info: client 174.36.24.251#47135: transfer of 'ajmakeup.com/IN': AXFR started
14-Apr-2012 23:16:22.750 xfer-out: info: client 174.36.24.251#47135: transfer of 'ajmakeup.com/IN': AXFR ended
14-Apr-2012 23:16:23.015 xfer-out: info: client 68.71.141.22#36212: transfer of 'ajmakeup.com/IN': AXFR started
14-Apr-2012 23:16:23.031 xfer-out: info: client 68.71.141.22#36212: transfer of 'ajmakeup.com/IN': AXFR ended

Как видите, нет проблем с DNS-серверами Zerigo, запрашивающими новые данные DNS, когда я принудительно перезагружаю, т.е. Я не верю, что из-за того, как они установлены как ПОДЧИНЕННЫЕ, они проводят опрос на предмет изменений.

Однако проблема в другом; МАСТЕР не обновляет ВЕДОМЫЕ серверы при перезагрузке (на МАСТЕРЕ); это партия по 15-минутному таймеру.

Ниже мой NAMED.CONF:

key "rndc-key" {
    algorithm hmac-md5;
    secret "REMOVED FOR SECURITY";
};

acl "trusted" {
        174.36.24.251/32;
    68.71.141.22/32;
        localhost;
};

options {
    version "not currently available";
    directory "C:\DNS\BIND\etc";
    allow-query {
                trusted;
        };
};

controls {
    inet 127.0.0.1 port 953
    allow { 127.0.0.1; } 
    keys { "rndc-key"; };
};

logging{
  channel simple_log {
    file "C:\DNS\BIND\logging\bind.log" versions 3 size 5m;
    severity info;
    print-time yes;
    print-severity yes;
    print-category yes;
  };
  category default{
    simple_log;
  };
};

zone "ajmakeup.com" in {
    type master;
    file "c:\dns\BIND\zones\db.ajmakeup.com.txt";
    allow-transfer { 174.36.24.251; 68.71.141.22; };
    allow-update { none; };
};

Связана ли моя проблема с 'allow-query' в параметрах? Вы заметите, что «allow-transfer» явно установлен для каждой зоны DNS.

Если вам это нужно, вот мой RNDC.CONF:

key "rndc-key" {
    algorithm hmac-md5;
    secret "REMOVED FOR SECURITY";
};

options {
    default-key "rndc-key";
    default-server 127.0.0.1;
    default-port 953;
};

server localhost {
  key "rndc-key";
};

Примечание:

Я использую WebsitePanel в качестве своей панели хостинга, и поэтому он создает зоны, входящие в него, именно так. Хотя я знаю, что могу изменить это поведение, я не хочу этого делать и не считаю, что это корень проблемы.

Спасибо за вашу помощь.

Что нужно проверить:

  1. Убедитесь, что уведомления не отключены (поставить в известность необходимо оставить по умолчанию («да») или установить «да» или «явно»)
  2. Если у вас скрытая основная настройка (которая, похоже, может быть у вас), named не будет отправлять уведомление на главный сервер, указанный в зоне SOA, если вы не укажете его в также уведомить заявление или набор уведомить Soa
  3. Как было предложено выше, может быть лучше просто перечислить серверы, о которых вы хотите получать уведомления, в также уведомить заявление, поэтому нет двусмысленности.
  4. Убедитесь, что вы обновляете серийный номер в SOA при внесении изменений в зону. Это очень Общая ошибка. После получения уведомления ведомое устройство выполнит запрос SOA для зоны, чтобы определить, нужен ли ему AXFR. Если у него уже есть такой же серийный номер, он сочтет ненужным повторный перенос зоны. Вы должен увеличивайте серийный номер, если вы хотите, чтобы подчиненные устройства использовали AXFR без необходимости вручную запускать его.
  5. Судя по выдержке из вашего файла журнала, это не относится к вам, потому что вам кажется, что у вас есть все необходимое для разрешения AXFR, но в интересах других, у которых могут быть аналогичные проблемы, ведомым серверам обычно необходимо явно разрешить Запросы AXFR (с разрешить передачу директива.)