O servidor DNS é essencial para qualquer rede de computadores, sua instalação, manutenção e gerenciamento é bastante simples. Apesar de sua simplicidade é preciso ter o conhecimento necessário de como o servidor DNS funciona para saber administrar e realizar a manutenção adequada do mesmo. Neste post vou mostrar como você pode administrar e gerenciar seu DNS Bind de forma simples e segura.
Vamos primeiramente instalar o Bind9 para que possamos realizar nossos testes. Estarei usando o Ubuntu 10.10 para este post. Como o foco do post não é a instalação e configuração do Bind, estarei postando abaixo apenas os comandos necessários para isso, sem maiores detalhes:
#aptitude install bind9
Veja que na instalação o arquivo que contem a chave já foi criado (/etc/bind/rndc.key).
Vamos editar o arquivo /etc/resolv.conf para que o nosso sistema solicite ao nosso DNS os domínios interessados:
#vim /etc/resolv.conf
nameserver 127.0.0.1
Nosso DNS já esta funcionando como um servidor cache, sendo responsável pelo domínio osvaldohp.com.br (não vou mostrar como se faz essa configuração). No meu servidor temos dois domínios registrados: www.osvaldohp.com.br e ns.osvaldohp.com.br, veja a figura abaixo:
RNDC
O programa rndc (remote name daemon control) permite ao administrador controlar as operações de um servidor de nomes (DNS). Executando o comando sem parâmetro ira mostrar suas funções, como mostra a figura abaixo:
O comando rndc pode se comunicar com o servidor DNS de forma remota usando o protocolo TCP enviando comandos ao servidor depois de um procedimento de autenticação com assinatura digital. Na atual versão do rndc e do servidor Bind o único algoritimo suportado para a realização da autenticação é o HMAC-MD5 que utiliza uma chave secreta compartilhada em cada ponto da comunicação. Este tipo de autenticação é conhecido como TSIG, que inicialmente ficou muito conhecido pelo seu uso em servidor DNS para a atualização de base, mas o mesmo pode ser usado para a comunicação entre servidores diversos para consultas regulares.
O comando “rndc reload” serve para o bind recarregar o arquivo de configuração e as zonas, vamos ver depois outros comandos ideais para determinadas situações. Vamos criar um novo registro chamado mail.osvaldohp.com.br em seguida vamos executar o comando e ver se a partir daí o meu DNS já reconhece este novo registro:
Veja que depois que executei o comando “rndc reload” o meu servidor já passou a responder pelo novo registro mail.osvaldohp.com.br. Em muitos casos você não precisará executar este comando, imagine que o seu servidor é responsável por milhares de zonas e que toda vez que você executar este comando o arquivo de configuração do bind e todas as zonas serão recarregadas podendo sobrecarregar o servidor se o mesmo for de pequeno porte e com capacidade de memória limitada.
Vamos criar um registro chamado web.osvaldohp.com.br e ver o que acontece se no lugar de “rndc reload” executamos “rndc reconfig”, veja a figura abaixo:
Como podemos ver o nosso servidor não reconheceu o nosso novo registro, mas isso aconteceu porque o “reconfig” não carrega as zonas já existentes mesmo que tenha alguma alteração na mesma. O “reconfig” recarrega os arquivos de configuração do bind e busca por zonas novas. Este comando é ideal quando você cria uma nova zona e precisa carregar esta zona, com isso forçando o bind a buscar apenas as zonas novas sem precisar carregar todas as zonas existentes.
Neste caso podemos utilizar o comando “rndc reload nome_da_zona”, veja abaixo:
Neste exemplo o “reload” recarregou apenas a zona responsável pelo domínio osvaldohp.com.br (/var/cache/bind/osvaldohp.zone) e vimos que a partir deste momento nosso servidor passa a reconhecer nosso novo registro (web.osvaldohp.com.br).
O comando “rndc refresh” serve para forçar o servidor DNS Secundário a buscar no Primário por atualização, se caso houver uma atualização então a transferência é feita. Um exemplo deste comando seria executar o comando abaixo no DNS Secundário:
#rndc refresh osvaldohp.com.br
Nenhum comando fará uma transferência de zona se o servidor primário tem um número de série igual ou inferior. O servidor secundário irá verificar o número de série, se ver que a sua cópia de zona é atual nada acontecerá. Para forçar uma transferência de zona apague o arquivo do secundário e reinicie o servidor.
Se você precisa transferir uma zona sem precisar checar o número do serial utilize o comando abaixo:
#rndc retransfer osvaldohp.com.br
Imagina que você tem uma zona dinâmica e você precisa fazer algumas modificações manuais nesta zona, neste caso use o comando “freeze zone”. Quando você usa o “freeze” qualquer tentativa de atualização dinâmica será recusada. Veja abaixo como seria o comando:
#rndc freeze zone
#rndc freeze osvaldohp.com.br
Se a zona não for especificada todas as zonas serão congeladas. Para habilitar a zona novamente utilize “rndc thaw osvaldohp.com.br”
O procedimento de notificar um servidor secundário serve para que o mesmo seja informado que existem atualizações no primário e o secundário precisa buscar essas novas atualizações para a sua base de dado. O secundário verifica o número serial e se for maior do que o que ele tem registrado na sua base ele faz a transferência da zona. Para que você force o seu DNS primário a notificar o secundário que existe uma nova atualização use o comando “rndc notify osvaldohp.com.br”. A figura abaixo mostra o que acontece na hora de você executar este comando:
Veja que na janela maior foi executado o comando rndc notificando o secundário sobre alguma atualização e no “tcpdump” executado no secundário temos essa comunicação entre os servidores.
O comando “rndc stats” gera um arquivo chamado “named.stats” com estatísticas do servidor, o diretório para onde o arquivo é criado é definido na diretiva “directory” dentro do arquivo “/etc/bind/named.conf.options”, no meu caso não mudei esta configuração, veja abaixo algumas informações dentro do arquivo:
O comando “rndc querylog” altera o log de consulta, abaixo vamos realizar alguns testes.
Se você executar “rndc querylog” uma vez ele habilita e começa a logar todas as requisições feitas para o DNS, para desabilitar é só executar de novo, veja o que aparece no nosso log (/var/log/syslog) quando habilitamos o querylog:
Veja que o “query logging” foi habilitado. Vamos realizar uma consulta DNS e ver o que vai aparecer agora em nosso log (/var/log/syslog):
O cliente que fez a requisição tem o IP 127.0.0.1, como realizei a consulta do próprio servidor DNS e no “resolv.conf” esta configurado a opção “nameserver” apontando para o 127.0.0.1 é por isso que aparece esse IP. Qualquer cliente que faça uma consulta para o nosso DNS aparecera o IP do cliente. Se você desabilitar o “query logging” nenhuma requisição será salva no log.
O “dumpdb” joga o cache e as zonas para um arquivo chamado named_dump.db, como opção do comando podemos usar:
-cache (faz o dump só do cache, é o padrão )
-zone (faz o dump das zonas)
-all (faz ambos)
Veja abaixo o conteúdo do arquivo criado com o comando “rndc dumpdb -all”:
Lembrando que o diretório para onde o arquivo é criado é definido na diretiva “directory” dentro do arquivo “/etc/bind/named.conf.options”.
O comando “rndc stop” para o servidor DNS, mas salva todas as pendências. Veja a figura abaixo:
Logo depois que executamos o “stop” nosso DNS parou de funcionar. O rndc não implementa o que seria “start” até porque para o rndc poder executar este comando teria que primeiramente se conectar no servidor DNS, como o servidor estaria desligado então não teria como executar um “rndc start”. O comando “halt” faz a mesma coisa que o “stop”, porém faz com que o servidor pare de forma abruptamente sem salvar nenhuma alteração que esteja sendo realizado no momento.
Quando pensamos em debug o rndc tem 3 opções:
O trace que incrementa em 1 o nível de debug do servidor.
O trace level que configura o nível do debug para um nível especifico.
O notrace configura o nível do debug para 0.
Podemos usar os comandos “flushes” para limpar o cache do nosso servidor. O comando “rndc flush” limpa todo o cache do servidor e o “rndc flushname name” limpa o cache para o nome informado. Vamos aos testes.
Vamos pingar o domínio www.chamada.com.br e logo em seguida vamos usar o comando “dig” para ver se o nosso servidor DNS registrou este domínio no cache, veja abaixo saída do comando dig:
O comando “dig” esta requisitando ao nosso servidor DNS (@127.0.0.1) o IP do domínio www.chamada.com.br, porém este domínio deve ser buscado no cache ou nas zonas do servidor (+norecurse). Na saída do comando veja onde esta escrito “ANSWER SECTION” que é a resposta do nosso servidor e logo abaixo temos a linha:
www.chamada.com.br 3248 IN CNAME chamada.com.br.
O número 3248 é o valor em segundos de quanto tempo faltam para que esse valor guardado no cache do servidor seja novamente requisitado para o DNS responsável pelo domínio chamada.com.br. Se você usar o comando dig novamente perceba que esse número vai diminuir:
Quando executamos o comando “rndc flushname chamada.com.br” nosso servidor ira apagar do cache dele qualquer registro referente a este domínio. Veja a saída do comando dig depois de executa o comando rndc flushname chamada.com.br:
Veja que o nosso servidor depois do “flush” não tem mais em seu cache nenhuma informação referente ao domínio chamada.com.br. Este comando é muito utilizado quando o seu servidor tem no cache o IP antigo de um servidor e você quer atualizar o seu cache para que obtenha as novas informações sobre um determinado domínio. Para limpar todo o cache use o comando “rndc flush”.
O comando “rndc status” mostra um pequeno status sobre o servidor:
Você pode salvar em um arquivo (named.recursing) uma lista de todas as consultas recursivas que estão sendo feitas para o servidor DNS, para isso basta executar o comando “rndc recursing”. Lembrando que o diretório para onde o arquivo é criado é definido na diretiva “directory”. Veja abaixo o conteúdo do arquivo gerado:
O DNSSEC é nome dado às extensões de segurança para o protocolo DNS, essa extensão autentica todas as informações do DNS garantindo a integridade e autenticidade. Para que o servidor DNS passe a funcionar com essas extensões é necessário um procedimento de configuração adequando para isso. Se o seu servidor já esta configurado para suportar DNSSEC você pode usar o comando “rndc validation newstate” para habilitar e desabilitar a validação usando DNSSEC.
Todos os comandos executados até aqui foram na máquina local, ou seja, para que você execute terá que acessar o servidor DNS remotamente usando SSH ou fazer um “login” local. O rndc, como já dito antes, utiliza o protocolo TCP na porta 953 para enviar comandos para um servidor de DNS remoto. Vamos ver como se configura o rndc e o bind9 para que possamos de forma remota enviar comandos para o nosso DNS.
Primeiro vamos criar nossa chave que chamaremos de “chave” com o comando “dnssec-keygen”, veja a figura abaixo:
Copie a chave “wxxIkP6xnJ67LJ4KDr+9Qw==” que iremos usar na nossa configuração. Crie o arquivo “/etc/rndc.conf” com o conteúdo:
Agora vamos editar o arquivo “/etc/bind/named.conf.options” e acrescentar o conteúdo abaixo fora da seção options:
Agora reinicie o bind9 e pronto nosso servidor já aceita comandos remotos do rndc. Se você tentar executar o rndc local ele não vai aceitar, porque estará escutando na porta 953 do IP do servidor (192.168.0.1) e não no IP de loopback. Para que você possa executar o rndc localmente você precisa especificar o IP do DNS e a chave. Vamos automatizar este processo e colocar estas informações dentro de um arquivo.
Primeiramente copie o arquivo que criamos antes chamado de “/etc/rndc.conf” para dentro do diretório “/etc/bind” e acrescente o conteúdo abaixo no arquivo:
Agora você já pode executar o rndc normalmente como fazia antes. Na figura abaixo mostro o que aconteceu antes e depois de termos adicionado e copiado esse arquivo:
Estamos quase acabando, esta faltando configurar as máquinas remotas que irão enviar os comandos rndc para o nosso servidor. A primeira coisa que devemos fazer é sincronizar o horário de sistema do servidor DNS com o da máquina cliente. Vou mostrar como se faz isso no Debian, que é a máquina cliente do meu teste, o mesmo procedimento serve para o Ubuntu que é o meu servidor.
Vamos instalar o cliente para o servidor NTP:
#aptitude install ntpdate
Temos um servidor NTP com o IP 192.168.0.3, agora só é executar o comando abaixo e ele sincronizara com a hora do servidor de horas:
#ntpdate 192.168.0.3 (Ip do servidor NTP)
Faça este procedimento no servidor DNS e nos clientes. Para que este procedimento tenha efeito permanente você precisa fazer algumas alterações no arquivo “/etc/default/ntp” e instalar o “daemon” do NTP.
Precisamos instalar o programa rndc:
#aptitude install bind9utils
Crie a pasta “/etc/bind” e copie o arquivo “/etc/bind/rndc.conf” que esta no servidor DNS para esta pasta.
Agora podemos executar nosso primeiro comando remotamente:
NAMED-*
O bind9 vem com duas ferramentas que ajudam a solucionar problemas de configuração que são chamados de named-checkconf e named-checkzone.
O named-checkconf verifica a sintaxe do arquivo de configuração do bind. Abaixo segue um exemplo deste comando:
A opção -z faz um teste de todas as zonas encontradas no arquivo named.conf. Veja que na terceira linha ele encontrou um erro dizendo que não conseguiu carregar a zona reversa, isso aconteceu porque não criei esse arquivo.
O named-checkzone verifica a sintaxe e consistência dos arquivos de zona.Veja na figura abaixo a saída do comando:
Veja que ele encontrou erros no arquivo, antes de executar o comando modifiquei o arquivo colocando um erro de sintaxe.
Estes dois exemplos foi uma pequena introdução do que se pode fazer com o named-*. Para maiores informações leia o manual (man).
A ferramenta rndc e named-* são de extrema importância para qualquer Administrador de servidores DNS, a correta utilização destas ferramentas agiliza o processo na resolução de problemas e administração do servidor.
By Osvaldo H. Peixoto
Você não sabe como foi difícil achar isso, muito bom o post.
ResponderExcluir