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

настройка 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 чтобы содержать мой открытый ключ и новую зону, которую я хочу обновить. Теперь это выглядит так (примечание: я также пробовал разрешить обновление {любой; }; безуспешно):

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

named debug Level 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 должен существовать до первого обновления или нет. Я пробовал без файла, с пустым файлом и с предварительно настроенным файлом зоны. Безуспешно.

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

Я не уверен на 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

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

(1) apparmor

Я не знаю, верно ли то же самое для Debian, но на Ubuntu bind9 запускается с включенным apparmor. Это означает, что разрешено писать только в определенные места. Места перечислены в /etc/apparmor.d/usr.sbin.named, и обычно рекомендуется оставаться в этих каталогах. Вы можете установить apparmor-utils package и (временно) отключите 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 с помощью service bind9 restart

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

Я предлагаю попробовать каталог / 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}.*