Habilitando DDNS com BIND e DHCP remoto

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.056 ]

Por: Marco Couto Ferreira em 01/08/2012


Subindo e descendo... quero dizer, testando



No servidor de DHCP iremos iniciar seus serviços com o comando:

# service isc-dhcp-server start

Se não apresentar nenhum erro significa que subiu com sucesso ou você não está vendo direito :)

Brincadeiras à parte, verificar qualquer erro em /var/log/syslog.

No servidor DNS que roda o BIND iremos reiniciar os serviços também com o comando:

# service bind9 start

Podemos proceder da mesma forma e verificar os erros em /var/log/syslog.

Para quem não conhece, com o comando abaixo visualizamos as últimas linhas do arquivo e também todas as futuras alterações que ocorram no arquivo:

# tail -f /var/log/syslog

Se você não vê nenhum erro significa que o serviço subiu corretamente

Vejamos o que acontece quando um novo cliente solicita endereço no servidor de DHCP. Podemos ver as seguintes linhas no arquivo de log:

Jul 29 00:11:34 ddns dhcpd: DHCPDISCOVER from 08:00:27:78:58:a6 via eth0
Jul 29 00:11:35 ddns dhcpd: DHCPOFFER on 192.168.0.12 to 08:00:27:78:58:a6 (clientelinux) via eth0
Jul 29 00:11:35 ddns dhcpd: Added new forward map from clientelinux.teste.br to 192.168.0.12
Jul 29 00:11:35 ddns dhcpd: added reverse map from 12.0.168.192.in-addr.arpa. to clientelinux.teste.br
Jul 29 00:11:35 ddns dhcpd: DHCPREQUEST for 192.168.0.12 (192.168.0.5) from 08:00:27:78:58:a6 (clientelinux) via eth0
Jul 29 00:11:35 ddns dhcpd: DHCPACK on 192.168.0.12 to 08:00:27:78:58:a6 (clientelinux) via eth0
Jul 29 00:15:23 ddns dhcpd: DHCPREQUEST for 192.168.0.14 from 08:00:27:db:24:05 (admin_linux) via eth0
Jul 29 00:15:43 ddns dhcpd: DHCPREQUEST for 192.168.0.12 from 08:00:27:78:58:a6 (clientelinux) via eth0
Jul 29 00:15:43 ddns dhcpd: DHCPACK on 192.168.0.12 to 08:00:27:78:58:a6 (clientelinux) via eth0


A linha "addedd new forward map from ..." indica que foi enviada a solicitação para atualização do registro DNS do host para o servidor de nomes (BIND).

Vamos agora observar se a solicitação foi processada com sucesso, olhando o mesmo arquivo de log agora no servidor de DNS que roda o BIND:

Jul 29 00:11:35 named named[1409]: client 192.168.0.5#44878: signer "ddns_update" approved
Jul 29 00:11:35 named named[1409]: client 192.168.0.5#44878: updating zone 'teste.br/IN': adding an RR at 'clientelinux.teste.br' A
Jul 29 00:11:35 named named[1409]: client 192.168.0.5#44878: updating zone 'teste.br/IN': adding an RR at 'clientelinux.teste.br' TXT
Jul 29 00:11:35 named named[1409]: client 192.168.0.5#39149: signer "ddns_update" approved
Jul 29 00:11:35 named named[1409]: client 192.168.0.5#39149: updating zone '0.168.192.in-addr.arpa/IN': deleting rrset at '12.0.168.192.in-addr.arpa' PTR
Jul 29 00:11:35 named named[1409]: client 192.168.0.5#39149: updating zone '0.168.192.in-addr.arpa/IN': adding an RR at '12.0.168.192.in-addr.arpa' PTR


Muito bem, parece que funcionou. Mas, para ter certeza vamos verificar se o BIND está respondendo solicitações de DNS para esse registro. Para isso, vamos testar a resolução de nomes para esses registros:

# host clientelinux.teste.br

Saída:
clientelinux.teste.br has address 192.168.0.12

# host 192.168.0.12

Saída:
12.0.168.192.in-addr.arpa domain name pointer clientelinux.teste.br.

Como podemos ver, o servidor de DNS está atualizado com as informações que chegaram via DDNS do servidor DHCP.

É isso aí pessoal, com este artigo espero ter ajudado, eu que sempre postei minhas dúvidas e obtive ótimas soluções no VOL e espero ter contribuído de alguma forma dessa vez.

"O mundo que deixaremos para os nossos filhos vai depender muito dos filhos que deixaremos para o nosso mundo"

Página anterior    

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 CACIC (parte 1) - Atualizado

Driver nVidia se sua placa tem chipset da SiS

Local Web Server visível na Internet com DynDNS

Slackware no notebook Toshiba Satellite M55-S3262

Slackware Current redondo com XFCE

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

parabéns pelo artigo

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

Gostei do artigo!

Muito útil atualizações dinâmicas.

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

ponto para vocês rsrsrs

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

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

[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



[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?

[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

[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

[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!

[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

[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

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

[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


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts