Habilitando DDNS com BIND e DHCP remoto

marcocouto

Descrevo o cenário de um servidor DHCP atualizando dinamicamente a base de dados de um servidor BIND remoto. Não irei abordar a instalação do BIND nem do DHCP pois a Internet está repleta de artigos a esse respeito. É necessário uma máquina rodando BIND e outra rodando DHCP para executar a sequência de procedimentos que seguem.

[ Hits: 22.590 ]

Por: Marco Couto Ferreira em 01/08/2012

0 0

Denuncie Favoritos Indicar Impressora

Preparando o BIND para atualizações dinâmicas

Todos os passos foram executados no Debian mas que, como sabemos, com pouca ou nenhuma alteração é possível implementá-lo em outros sabores de Linux.

Vamos primeiramente criar a chave que será usada na comunicação entre os servidores:

# dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER DDNS_UPDATE

Com esse comando o sistema irá criar um arquivo Kddns_update.+157....private e outro com o final .key

Olhando dentro do arquivo Kddns_update.+157....private tem uma linha denominada:

Key: abcde0TS4D123456789xyz==

Pega o conteúdo parecido com esse que está na linha Key: do seu arquivo .private e e adiciona dentro do seguinte novo arquivo:

# vi /etc/bind/ddns.key

key DDNS_UPDATE {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret "abcde0TS4D123456789xyz==";
};

Depois, vamos ajustar a segurança alterando a permissão e o grupo do arquivo com o seguinte comando:

# chown root:bind /etc/bind/ddns.key
# chmod 640 /etc/bind/ddns.key

O próximo passo é habilitar a atualização da base de dados do BIND para requisições que usarem essa chave. Para isso, altere no seu arquivo de configuração do BIND acrescentando antes das demais inclusões:

# vi /etc/bind/named.conf

include "/etc/bind/ddns.key";
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

Feito isso, vamos fazer as alterações necessárias nas configurações das zonas. Primeiramente vamos criar uma cláusula controls que permitirá que o BIND seja manipulado pelo servidor de DHCP, para isso colocaremos as seguintes linhas dentro do arquivo de configuração do BIND, onde estão configuradas as zonas, no meu caso é /etc/bind/named.conf.local:

controls {
inet * allow { 192.168.0.5; } keys { "DDNS_UPDATE"; };
};

Lembrando que o endereço IP 192.168.0.5 deve ser alterado para o endereço do seu servidor de DHCP.

Agora vamos fazer as devidas alterações também na sessão das zonas sem esquecer de também alterar a sessão dos registros reversos. No meu caso ficou assim:

zone "teste.br" in {
        type master;
        notify no;
        file "db.teste.br";
        allow-update { key DDNS_UPDATE; };
};

zone "0.168.192.in-addr.arpa" {
        type master;
        notify no;
        file "db.0.168.192.in-addr.arpa";
        allow-update { key DDNS_UPDATE; };

Tudo certo com o servidor BIND até agora, mas ainda não vamos reiniciá-lo. Passamos então para as configurações do servidor de DHCP. Para adiantar, faça a transferência do arquivo /etc/bind/ddns.key para o servidor de DHCP e salve-o em /etc/dhcp/ddns.key.

Vamos agora à configuração do DHCP, depois voltaremos aqui apenas para subir os serviços e realizar os testes.

Próxima página

Páginas do artigo

   1. Preparando o BIND para atualizações dinâmicas
   2. Preparando o DHCPD para atualizações dinâmicas
   3. Subindo e descendo... quero dizer, testando

Outros artigos deste autor

Nenhum artigo encontrado.

Leitura recomendada

Configurando o proftpd com autenticação de usuário pelo passwd

Instalando Prolink Pixelview PV-BT878P+

Habilitando e configurando Raid 1 (espelhamento) no Slackware 12

Sabayon 5.0 - Transformando Sabayon 4.0r1 em Sabayon 5.0 "Full" (parte 2)

Prevenindo acidentes com o comando RM

Comentários

[1] Comentário enviado por danniel-lara em 01/08/2012 - 12:39h

parabéns pelo artigo

0 0

[2] Comentário enviado por removido em 01/08/2012 - 13:11h

Gostei do artigo!

Muito útil atualizações dinâmicas.

0 0

[3] Comentário enviado por marcocouto em 01/08/2012 - 14:34h

ponto para vocês rsrsrs

0 0

[4] Comentário enviado por fs.schmidt em 04/08/2012 - 20:13h

Parabéns, muito bem explicado e muito útil !

0 0

[5] Comentário enviado por alexmanzo em 06/10/2012 - 17:57h

Boa tarde, não consegui, está dando o seguinte erro:

Oct 6 17:49:13 drs12-rgt01 named[2718]: client 192.168.1.2#49960: update '1.168.192.in-addr.arpa/IN' denied
Oct 6 17:49:13 drs12-rgt01 dhcpd: unable to add reverse map from 116.1.168.192.1.168.192.in-addr.arpa to VM01-PC.drs.gov: timed out

0 0

[6] Comentário enviado por alexmanzo em 06/10/2012 - 20:02h

consegui fazer funcionar parcialmente, só esta gerando journal para zona reversa... o que pode ser?

0 0

[7] Comentário enviado por marcocouto em 07/10/2012 - 22:38h

Alex, a segunda linha onde aparece o endereço reverso "116.1.168.192.1.168.192.in-addr.arpa" me parece estar errada deveria aparecer apenas 116.1.168.192.in-addr.arpa
sugiro verificar se com os registros manuais funciona para isso cadastre algo manualmente na zona reversa e teste com o comando
named-checkzone 1.168.192.in-addr.arpa /caminho/do/arquivo/da/zona
elimine os erros para depois partir para atualizações dinamicas

0 0

[8] Comentário enviado por alexmanzo em 08/10/2012 - 00:46h

Boa noite Marco, agradeço muito por responder, realmente estava gravando errado a entrada, ele inseria o endereço reverso dessa forma por causa de um erro de sintaxe no dhcpd.conf onde na declaração da zona reversa faltava um ponto após a entrada!
Quanto a zona reversa agora está gravando gerando os registros PTR tudo OK!
O meu problema agora está na zona de forward que não está gravando os registros A... não sei o que acontece porque nem log disso está gerando!!! No caso o log só aparece que está sendo feito a atualização da zona reversa e nada mais além disso.... o que acha?

segue o meu syslog:

Oct 8 00:26:28 drs12-rgt01 dhcpd: DHCPDISCOVER from 08:00:27:60:12:84 via eth0
Oct 8 00:26:28 drs12-rgt01 dhcpd: DHCPOFFER on 192.168.1.116 to 08:00:27:60:12:84 (VM01-PC) via eth0
Oct 8 00:26:28 drs12-rgt01 named[931]: client 192.168.1.2#36349: signer "rndc-key" approved
Oct 8 00:26:28 drs12-rgt01 named[931]: client 192.168.1.2#36349: updating zone '1.168.192.in-addr.arpa/IN': deleting rrset at '116.1.168.192.in-addr.arpa' PTR
Oct 8 00:26:28 drs12-rgt01 named[931]: client 192.168.1.2#36349: updating zone '1.168.192.in-addr.arpa/IN': adding an RR at '116.1.168.192.in-addr.arpa' PTR
Oct 8 00:26:29 drs12-rgt01 dhcpd: added reverse map from 116.1.168.192.in-addr.arpa. to VM01-PC.drs.gov
Oct 8 00:26:29 drs12-rgt01 dhcpd: DHCPREQUEST for 192.168.1.116 (192.168.1.2) from 08:00:27:60:12:84 (VM01-PC) via eth0
Oct 8 00:26:29 drs12-rgt01 dhcpd: DHCPACK on 192.168.1.116 to 08:00:27:60:12:84 (VM01-PC) via eth0

Segue meu arquivo de zona de forward:

$TTL 86400
@ IN SOA drs.gov. root.drs.gov. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
@ IN NS ns.drs.gov.
ns IN A 192.168.1.2
drs12-rgt01 IN A 192.168.1.2
drs12-proxy IN A 192.168.1.1
drs12-avserver IN A 192.168.1.3
_kerberos._tcp.drs.gov. IN SRV 0 0 88 drs12-rgt01.drs.gov.
_ldap._tcp.drs.gov. IN SRV 0 0 389 drs12-rgt01.drs.gov.

Mais um detalhe: A máquina é um Debian 6 rodando samba4 (instalado com make), fora isso esta com pacotes do kerberos e biblioteca ldap instalados... e o client em questão é Windows Seven e está cadastrada no AD do samba

0 0

[9] Comentário enviado por alexmanzo em 08/10/2012 - 10:12h

Marco bom dia!

Gostaria de informar que funcionou tudo, ele registrou os hosts na zona de foward normalmente!

Ele só não está registrando na zona de forward apenas os computadores que estão inseridos no AD do Samba4 mas isso eu ainda preciso descobrir... caso tiver alguma sugestão ou palpite refente a isso vou ficar eternamente agradecido (mais do que já estou! rs)

Grande abraço!

0 0

[10] Comentário enviado por MARCOCOUTO em 08/10/2012 - 20:22h

Cara, sua zona configurada é drs.gov
esta certo isso?
se estiver poste o seu named.conf.local e o seu dhcpd.conf

0 0

[11] Comentário enviado por marcocouto em 10/10/2012 - 08:32h

Alex, nunca vi o samba4 mas teoricamente ele não afetaria, A não ser que ele tenha alguma feature que implemente o dhcp, tenha certeza que as máquinas pegaram ip pelo servidor dhcp e não por outro recurso. para ver isso verifique se o registro da maquina esta em /var/lib/dhcp/dhcp.leases.
Qualquer dúvida poste ai

0 0

[12] Comentário enviado por alexmanzo em 10/10/2012 - 12:17h

Oi Marco, na verdade o Samba4 possui feature q implementa o Bind. O grupo do samba lançou recentemente uma versão "release candidate" que acabou corrigindo este problema que eu estava passando, para isso eu tive que refazer todo o samba 4 do servidor que ainda está em fase de testes com alguns computadores e maquinas virtuais do laboratorio. Acredito que em breve já teremos o samba4 em sua primeira versão estável tendo em vista os avanços do projeto!

Já está tudo OK, mas de qualquer forma segue meus arquivos:

#named.conf.local

zone "drs.gov." {
type master;
notify no;
file "/etc/bind/db.drs.gov";
allow-update { key rndc-key; };
};

zone "1.168.192.in-addr.arpa." {
type master;
notify no;
file "/etc/bind/db.1.168.192";
allow-update { key rndc-key; };
};

***************************************
#dhcpd.conf

authoritative;
allow client-updates;
allow unknown-clients;
ddns-updates on;
ddns-update-style interim;

include "/etc/bind/rndc.key";

option domain-name-servers 192.168.1.2;
option domain-name "drs.gov";
option routers 192.168.1.1;
option broadcast-address 192.168.1.255;
option ntp-servers 192.168.1.2;

default-lease-time 43200;
max-lease-time 86400;

log-facility local7;

zone drs.gov. {
primary 192.168.1.2;
key rndc-key;
}

zone 1.168.192.in-addr.arpa. {
primary 192.168.1.2;
key rndc-key;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.101 192.168.1.254;
}

0 0

[13] Comentário enviado por alexmanzo em 10/10/2012 - 12:39h

Marco, mais um detalhe: o arquivo contendo a chave rndc.key e a função controls estão no meu named.conf

Abraçao e mais uma vez obrigado, mereceu nota 10

0 0