configurando o bind para trabalhar com nsupdate (SERVFAIL)

Question

Estou tentando atualizar meu servidor DNS dinamicamente usando o nsupdate.

Pré-requisito

Estou usando o Debian 6 no meu DNS-Server e Debian 4 no meu cliente.

Eu criei um par de chaves pública / privada usando:

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

Eu então editei meu named.conf.local para conter minha chave pública e a nova zona que desejo atualizar. Agora parece com isso (nota: eu também tentei allow-update {any;}; sem sucesso):

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";
};

Em seguida, eu copiei o arquivo de chave privada ( key.private ) para outro servidor do qual eu quero atualizar a zona. Eu também criei um arquivo de texto ( update ) neste servidor que continha as informações de atualização (nota: eu tentei brincar com essas coisas também. Sem sucesso):

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

Agora estou tentando atualizar a zona usando:

nsupdate -k key.private -v update

O problema

Esse comando me fornece a seguinte saída:

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

chamado debug Level 3 me fornece as seguintes informações quando eu emito o comando nsupdate no servidor remoto (nota: ofusquei o IP do cliente):

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

Mas isso não faz nada. A zona não é atualizada, nem o meu nsupdate muda nada. Não tenho certeza se o arquivo /etc/bind/primary/sub.example.com deve existir antes da primeira atualização ou não. Eu tentei sem o arquivo, com um arquivo vazio e com um arquivo de zona pré-configurado. Sem sucesso.

As informações esparsas que encontrei na net apontaram para as permissões de arquivo e pasta referentes ao diretório de trabalho bind, então alterei as permissões de / etc / bind e / var / cache / bind (que é o diretório home do meu usuário "bind").

Eu não tenho 100% de certeza se as permissões estão corretas ... mas parece bom para mim:

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

    

Answer 1

Eu tinha praticamente exatamente o mesmo problema em um servidor Ubuntu e acabaram sendo dois problemas:

(1) apparmor

Eu não sei se o mesmo é verdade para o Debian, mas no Ubuntu bind9 é executado com o apparmor ativado. Isso significa que só é permitido escrever em determinados lugares. Os locais estão listados em /etc/apparmor.d/usr.sbin.named e é geralmente aconselhável ficar dentro desses diretórios. Você pode instalar o pacote apparmor-utils e (temporariamente) desativar o apparmor para vincular para ver se isso causa o seu problema:

sudo aa-status

deve mostrar /usr/sbin/named na lista de perfis impostos. Então corra

sudo aa-complain /usr/sbin/named

para colocá-lo no modo de reclamação.

(2) arquivo de zona

Quase nenhum manual / tutorial menciona isso, mas bind9 espera que um arquivo de zona (pré-) existente funcione corretamente. O erro end of file pode ser causado pelo fato de o arquivo de zona ainda não existir ( /etc/bind/primary/example.com e /etc/bind/primary/sub.example.com em seu exemplo). Você pode simplesmente criar um assim:

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

    

Answer 2

Eu estava tendo problemas muito semelhantes até que eu mudei o local onde eu armazenei meus arquivos de zona.

O Bind tinha permissão para gravar em /var/cache/bind , mas seus arquivos de zona são armazenados em /etc/bind/... . No momento, o Bind não tem permissão para gravar arquivos em /etc/bind/... , portanto, você precisaria atualizar as permissões do Bind ou armazenar os arquivos de zona em um diretório no qual o Bind possui as permissões apropriadas. Eu cobrirei as etapas simples para mover os arquivos de zona para o diretório recomendado para zonas dinâmicas ( /var/lib/bind/ ).

1. Mova os arquivos de zona com mv (provavelmente precisa ser executado como root)

   mv /etc/bind/primary/example.com /var/lib/bind/primary/
   mv /etc/bind/primary/sub.example.com /var/lib/bind/primary/
   

2. Atualize o caminho do arquivo nas configurações de named.conf . No seu caso, isso significa atualizar /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. Reinicie o vínculo com service bind9 restart

Answer 3

Veja a seção no 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.

Então, se você fosse reformatá-lo no

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

forma e deixe que em um arquivo funcione ou, alternativamente, -k K{name}.+157.+{random}.*

    

Answer 4

Para atualizações do dyndns, o BIND deve poder gravar nas pastas usadas pelas zonas. Parece-me que / etc não é um lugar certo para armazenar tais informações, e olhando para suas permissões, etc, não é gravável por bind.

Eu sugiro tentar o diretório / var / bind, para que o bind possa escrever nele.