Настройка bind для работы с nsupdate (SERVFAIL)

Я пытаюсь обновить свой DNS-сервер динамически с помощью nsupdate.

необходимое условие

Я использую Debian 6 на моем DNS-сервере и Debian 4 на моем клиенте.

Я создал пару открытый / закрытый ключ, используя:

dnssec-keygen -C -a HMAC-MD5 -b 512 -n USER sub.example.com.

Затем я отредактировал свой named.conf.local, чтобы он содержал мой открытый ключ и новую зону, которую я хочу обновить. Теперь это выглядит так (примечание: я также пробовал allow-update { any; }; безуспешно):

zone "example.com" {
        type master;
        file "/etc/bind/primary/example.com";
        notify yes;
        allow-update { none; };
        allow-query { any; };
};

zone "sub.example.com" {
        type master;
        file "/etc/bind/primary/sub.example.com";
        notify yes;
        allow-update { key "sub.example.com."; };
        allow-query { any; };
};

key sub.example.com. {
        algorithm HMAC-MD5;
        secret "xxxx xxxx";
};

Затем я скопировал файл закрытого ключа (key.private) на другой сервер, с которого я хочу обновить зону. Я также создал текстовый файл (обновление) на этом сервере, который содержал информацию об обновлении (примечание: я тоже пытался играть с этим материалом. Безуспешно):

server example.com
zone sub.example.com
update add sub.example.com. 86400 A 10.10.10.1
show
send

Сейчас я пытаюсь обновить зону, используя:

nsupdate -k key.private -v update

Эта проблема

Эта команда дает мне следующий вывод:

Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags: ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;sub.example.com.       IN  SOA

;; UPDATE SECTION:
sub.example.com.    86400   IN  A   10.10.10.1

update failed: SERVFAIL

именованный уровень отладки 3 дает мне следующую информацию, когда я запускаю команду nsupdate на удаленном сервере (примечание: я запутал клиентский IP):

06-Aug-2012 14:51:33.977 client X.X.X.X#33182: new TCP connection
06-Aug-2012 14:51:33.977 client X.X.X.X#33182: replace
06-Aug-2012 14:51:33.978 clientmgr @0x2ada3c7ee760: createclients
06-Aug-2012 14:51:33.978 clientmgr @0x2ada3c7ee760: recycle
06-Aug-2012 14:51:33.978 client @0x2ada475f1120: accept
06-Aug-2012 14:51:33.978 client X.X.X.X#33182: read
06-Aug-2012 14:51:33.978 client X.X.X.X#33182: TCP request
06-Aug-2012 14:51:33.978 client X.X.X.X#33182: request has valid signature
06-Aug-2012 14:51:33.978 client X.X.X.X#33182: recursion not available
06-Aug-2012 14:51:33.978 client X.X.X.X#33182: update
06-Aug-2012 14:51:33.978 client X.X.X.X#33182: send
06-Aug-2012 14:51:33.978 client X.X.X.X#33182: sendto
06-Aug-2012 14:51:33.979 client X.X.X.X#33182: senddone
06-Aug-2012 14:51:33.979 client X.X.X.X#33182: next
06-Aug-2012 14:51:33.979 client X.X.X.X#33182: endrequest
06-Aug-2012 14:51:33.979 client X.X.X.X#33182: read
06-Aug-2012 14:51:33.986 client X.X.X.X#33182: next
06-Aug-2012 14:51:33.986 client X.X.X.X#33182: request failed: end of file
06-Aug-2012 14:51:33.986 client X.X.X.X#33182: endrequest
06-Aug-2012 14:51:33.986 client X.X.X.X#33182: closetcp

Но это ничего не делает. Зона не обновляется, и моя nsupdate ничего не меняет. Я не уверен, должен ли файл /etc/bind/primary/sub.example.com существовать до первого обновления или нет. Я попробовал это без файла, с пустым файлом и с предварительно настроенным файлом зоны. Безуспешно.

Разреженная информация, которую я нашел в сети, указала мне на права доступа к файлам и папкам в отношении рабочего каталога bind, поэтому я изменил разрешения для / etc / bind и / var / cache / bind (который является домашним каталогом моего "bind"). пользователь).

Я не уверен на 100%, если права правильные.. но это выглядит хорошо для меня:

ls -lah /var/cache/bind/
total 224K
drwxrwxr-x  2 bind bind 4.0K Aug  6 03:13 .
drwxr-xr-x 12 root root 4.0K Jul 21 11:27 ..
-rw-r--r--  1 bind bind 211K Aug  6 03:21 named.run

ls -lah /etc/bind/
total 72K
drwxr-sr-x  3 bind bind 4.0K Aug  6 14:41 .
drwxr-xr-x 87 root root 4.0K Jul 30 01:24 ..
-rw-------  1 bind bind  125 Aug  6 02:54 key.public
-rw-------  1 bind bind  156 Aug  6 02:54 key.private
-rw-r--r--  1 bind bind 2.5K Aug  6 03:07 bind.keys
-rw-r--r--  1 bind bind  237 Aug  6 03:07 db.0
-rw-r--r--  1 bind bind  271 Aug  6 03:07 db.127
-rw-r--r--  1 bind bind  237 Aug  6 03:07 db.255
-rw-r--r--  1 bind bind  353 Aug  6 03:07 db.empty
-rw-r--r--  1 bind bind  270 Aug  6 03:07 db.local
-rw-r--r--  1 bind bind 3.0K Aug  6 03:07 db.root
-rw-r--r--  1 bind bind  493 Aug  6 03:32 named.conf
-rw-r--r--  1 bind bind  490 Aug  6 03:07 named.conf.default-zones
-rw-r--r--  1 bind bind 1.2K Aug  6 14:18 named.conf.local
-rw-r--r--  1 bind bind  666 Jul 29 22:51 named.conf.options
drwxr-sr-x  2 bind bind 4.0K Aug  6 03:57 primary/
-rw-r-----  1 root bind   77 Mar 19 02:57 rndc.key
-rw-r--r--  1 bind bind 1.3K Aug  6 03:07 zones.rfc1918

ls -lah /etc/bind/primary/
total 20K
drwxr-sr-x 2 bind bind 4.0K Aug  6 03:57 .
drwxr-sr-x 3 bind bind 4.0K Aug  6 14:41 ..
-rw-r--r-- 1 bind bind  356 Jul 30 00:45 example.com

4 ответа

Решение

У меня была почти такая же проблема на сервере Ubuntu, и оказалось, что это две проблемы:

(1) одежда

Я не знаю, верно ли это для Debian, но в Ubuntu bind9 запускается с включенным apparmor. Это означает, что разрешено писать только в определенные места. Места перечислены в /etc/apparmor.d/usr.sbin.namedи, как правило, рекомендуется оставаться в этих каталогах. Вы можете установить apparmor-utils пакет и (временно) отключите apparmor для привязки, чтобы увидеть, если это вызывает вашу проблему:

sudo aa-status

должен показать /usr/sbin/named в списке принудительных профилей. Тогда беги

sudo aa-complain /usr/sbin/named

перевести его в режим жалобы.

(2) файл зоны

Практически ни одно руководство / учебное пособие не упоминает об этом, но bind9 ожидает, что (предварительно) существующий файл зоны будет работать должным образом. end of file ошибка может быть вызвана тем, что файл зоны еще не существует (/etc/bind/primary/example.com а также /etc/bind/primary/sub.example.com в твоем примере). Вы можете просто создать такой как это:

echo "; DO NOT EDIT MANUALLY - use the \"nsupdate\" utility to prevent data loss
;
\$ORIGIN example.com.
\$TTL 86400  ; 1 day
@    IN SOA  ns1.example.com. hostmaster.example.com. (
       2009074711 ; serial
       7200       ; refresh (2 hours)
       300        ; retry (5 minutes)
       604800     ; expire (1 week)
       60         ; minimum (1 minute)
       )
   IN  NS  ns1.example.com.
ns1    IN  A  <IP of your bind server>" | sudo -u bind tee /etc/bind/primary/example.com

У меня были очень похожие проблемы, пока я не изменил место хранения файлов зон.

У Бинда было разрешение написать /var/cache/bind, но файлы вашей зоны хранятся в /etc/bind/..., В настоящее время Bind не имеет разрешения на запись в файлы в /etc/bind/..., поэтому вам необходимо обновить разрешения Bind или сохранить файлы зоны в каталоге, где Bind имеет соответствующие разрешения. Я расскажу о простых шагах по перемещению файлов зон в каталог, рекомендуемый для динамических зон (/var/lib/bind/).

  1. Переместите файлы зоны с помощью mv (вероятно, должен быть выполнен как root)

    mv /etc/bind/primary/example.com /var/lib/bind/primary/
    mv /etc/bind/primary/sub.example.com /var/lib/bind/primary/
    
  2. Обновите путь к файлу в вашем named.conf конфигурации. В вашем случае это означает обновление /etc/bind/named.conf.local

    zone "example.com" {
      type master;
      file "/var/lib/bind/primary/example.com";  //this line changed
      //other stuff removed for clarity
    };
    
    zone "sub.example.com" {
      type master;
      file "/var/lib/bind/primary/sub.example.com";  //this line changed
      //other stuff removed for clarity
    };
    
  3. Перезапустите Bind with service bind9 restart

Для обновлений dyndns BIND должен иметь возможность записи в папки, используемые зонами. Мне кажется, что / etc не является подходящим местом для хранения такой информации, и просмотр ваших разрешений и т. Д. Невозможен для записи посредством bind.

Я предлагаю попробовать каталог /var/bind, чтобы bind мог писать в него.

Смотрите раздел в nsupdate

   With the -k option, nsupdate reads the shared secret from the file
   keyfile. Keyfiles may be in two formats: a single file containing a
   named.conf-format key statement, which may be generated automatically
   by ddns-confgen, or a pair of files whose names are of the format
   K{name}.+157.+{random}.key and K{name}.+157.+{random}.private, which
   can be generated by dnssec-keygen. The -k may also be used to specify a
   SIG(0) key used to authenticate Dynamic DNS update requests. In this
   case, the key specified is not an HMAC-MD5 key.

Так что, если вы должны были переформатировать его в

key sub.example.com. {
        algorithm HMAC-MD5;
        secret "xxxx xxxx";
};

сформировать и оставить в файле это будет работать, или в качестве альтернативы -k K{name}.+157.+{random}.*

Другие вопросы по тегам