Com o Bind instalado, o próximo passo é configurar o serviço para responder pelos domínios que você registrou. Vamos usar como exemplo o domínio “gdhn.com.br“.
Como ele é um domínio .br, ele é registrado através do http://registro.br. Depois de pagar e fornecer os dados da empresa e do responsável pelo domínio, é necessário fornecer os endereços dos dois endereços (nomes e endereços IP) dos dois servidores DNS responsáveis pelo seu domínio, como no screenshot abaixo:
É através dessa interface de gerenciamento que você pode alterar a configuração do seu domínio, alterar os endereços dos servidores DNS (caso você migre seu site para outro servidor, ou outra empresa de hospedagem, por exemplo), ou mesmo transferí-lo para outra pessoa. A senha definida ao criar sua conta é essencial, já que qualquer um que tenha acesso às suas informações de login poderia se apoderar do seu domínio (é possível recuperá-lo depois caso você seja o responsável legal pela empresa, mas o processo é demorado).
É possível registrar o domínio usando um plano ADSL empresarial, ou outra modalidade de conexão onde você tenha um endereço IP fixo. Não seria recomendável hospedar o site da sua empresa (ou nem mesmo seu site pessoal) em um servidor ligado a um link ADSL, pois o acesso dos visitantes seria muito ruim, mas, de qualquer forma, na falta de um servidor dedicado, você pode montar um servidor de internet doméstico para fins de estudo ou de testes. A dica para conseguir registrar o domínio tendo um único endereço IP é utilizar um modem discado (ou qualquer outro tipo de conexão temporária) para obter um segundo endereço e assim conseguir efetuar o processo de registro do domínio.
Não faria muito sentido tentar registrar um domínio usando uma conexão doméstica, com IP dinâmico, já que a entrada ficaria desatualizada assim que o IP mudasse, fazendo com que o domínio deixasse de funcionar. A única solução viável nesse caso é utilizar um serviço de DNS dinâmico (no-ip.com, dyndns.com, etc.).
Continuando, a checagem dos servidores DNS é feita durante a fase final do registro, de forma que, para concluir o registro do domínio, seu DNS já deve estar funcionando. Vamos então à configuração do Bind.
Comece adicionando as seguintes linhas no final do arquivo “/etc/bind/named.conf” do servidor (sem modificar as demais):
type master;
file “/etc/bind/db.gdhn”;
allow-transfer { 64.234.23.12; };
};
Na configuração, o “zone “gdhn.com.br” na primeira linha indica o domínio que estamos configurando, como registrado no Registro.br.
O “file “/etc/bind/db.gdhn” especifica o arquivo onde vai a configuração desse domínio. Na verdade, você pode salvar esse arquivo em qualquer lugar, muita gente usa a pasta “/var/named”. Aqui estou seguindo o padrão do Debian, colocando os arquivos dentro da pasta “/etc/bind”, junto com os demais arquivos de configuração do Bind.
Estas linhas dizem que o servidor é o responsável pelo domínio “gdhn.com.br” (type master;) e que sempre que receber uma requisição vai responder de acordo com o especificado no arquivo db.gdhn (file “/etc/bind/db.gdhn”;).
A linha “allow-transfer” indica quais servidores terão permissão para realizar transferências de zona. Ao utilizar um servidor DNS secundário, a linha conteria o endereço IP do segundo servidor, que seria o único autorizado a realizar as transferências. Se você estiver utilizando um único servidor, utilize o próprio endereço IP do servidor (como no exemplo). Não deixe de utilizar a opção, caso contrário qualquer servidor poderá realizar transferências, o que permite obter diversas informações sobre seu domínio, que poderão então serem utilizadas para formular ataques.
No caso do Debian, é recomendado que você use o arquivo “/etc/bind/named.conf.local“, que é processado como se fosse parte do named.conf principal. No arquivo named.conf do Debian, você encontra as seguintes linhas:
include “/etc/bind/named.conf.local”;
A existência desse arquivo separado visa separar a configuração geral do servidor e a configuração dos domínios, minimizando a possibilidade de erros, mas, na verdade, o efeito de editar qualquer um dos dois arquivos é o mesmo.
Em seguida vem a parte principal, que é adicionar a configuração do domínio no arquivo “/etc/bind/db.gdhn“, que foi citado na configuração. Este é um exemplo de configuração:
2008061645 3H 15M 1W 1D )
NS servidor.gdhn.com.br.
IN MX 10 servidor.gdhn.com.br.
gdhn.com.br. A 64.234.23.12
www A 64.234.23.12
ftp A 64.234.23.12
smtp A 64.234.23.12
Nesse arquivo a formatação é especialmente importante. Você pode usar espaços e tabs (ambos têm o mesmo efeito) para organizar as opções, mas existem algumas regras. As linhas “IN SOA” até “IN MX” precisam ficar justificadas (como no exemplo) e você não pode esquecer dos espaços entre as opções. Caso queira incluir comentários, use “;” ao invés de “#”, como em outros arquivos.
Pesquisando no Google, você pode encontrar inúmeros templates como esse, mas é difícil encontrar alguma explicação clara de cada uma das opções. Isso faz com que configurar um servidor DNS pareça muito mais complicado do que realmente é. Vamos então a uma descrição detalhada de cada um dos campos, começando pela primeira linha:
A “@” na primeira linha indica a origem do domínio e, ao mesmo tempo, o início da configuração. Ela é sempre usada, assim como em um endereço de e-mail.
O “IN” é abreviação de “internet” e o “SOA” de “Start of autority”. Em seguida vem o nome do seu servidor (que você checa usando o comando “hostname”), seguido do e-mail de contato do administrador (você).
Note que, no caso do e-mail, temos a conta separada do domínio por um ponto, e não por uma “@”. O mais comum é criar uma conta chamada “hostmaster”, mas isso não é uma regra. Você poderia usar “fulaninho.meudominio.com.br”, por exemplo. A principal observação é que você não deve usar um e-mail contendo pontos na porção antes da arroba.
Note também que existe um ponto depois do “servidor.gdhn.com.br” e do “hostmaster.gdhn.com.br”, que faz parte da configuração. Como citei no início, na realidade todos os nomes de domínio terminam com um ponto; em muitas situações o ponto é omitido (como acessar um site através do navegador), mas ele é obrigatório dentro da configuração do Bind.
O ponto se refere ao domínio raiz, de responsabilidade dos rootservers. No exemplo, nosso servidor é o responsável pelo domínio “gdhn”, que faz parte do domínio “.com.br”, que, por sua vez, faz parte do domínio raiz. Lembre-se que os domínios são lidos da direita para a esquerda, de forma que, ao resolver o domínio, o cliente leria: raiz . br . com . gdhn.
A linha diz algo como: na internet, o servidor “servidor” responde pelo domínio “gdhn.com.br” e o e-mail do responsável pelo domínio é “hostmaster@gdhn.com.br”.
A primeira linha termina com um parênteses, que indica o início da configuração do domínio. Temos então:
O “2008061645” é o valor de sincronismo, que permite que o servidor DNS secundário se mantenha sincronizado com o principal, detectando alterações na configuração. O servidor DNS checa periodicamente as informações disponibilizadas pelo servidor primário e realiza uma atualização sempre que percebe que o número de sincronismo do servidor é mais alto que o seu (do servidor secundário).
Não existe uma regra específica para a formatação do número de sincronismo; você pode simplesmente usar um número de 10 dígitos aleatório e aumentá-lo a cada mudança na configuração.
Uma convenção popular é usar a data da última alteração (como em: 20080616) e um número de dois dígitos qualquer, aumentando sequencialmente a cada mudança. Ela acaba sendo útil, pois faz com que você nunca se esqueça de atualizar o número de sincronismo ao alterar a configuração do servidor. 🙂
Sempre que editar a configuração ou sempre que configurar um servidor DNS a partir de um template qualquer, lembre-se de atualizar o número de sincronismo, usando a data atual ou outro número definido por você. Uma observação é que o número no servidor primário deve ser sempre superior ao número no servidor secundário, caso contrário a atualização nunca é disparada. Veja que a convenção de usar a data evita esse problema, já que ela faz com que o servidor que foi atualizado por último tenha sempre o número mais alto.
Continuando, os quatro campos seguintes (3H 15M 1W 1D) orientam o servidor DNS secundário (caso você tenha um). O primeiro campo indica o tempo que o servidor aguarda entre as atualizações (3 horas). Caso ele perceba que o servidor principal está fora do ar, ele tenta fazer uma transferência de zona, ou seja, tenta assumir a responsabilidade sob o domínio. Caso a transferência falhe e o servidor principal continue fora do ar, ele aguarda o tempo especificado no segundo campo (15 minutos) e tenta novamente.
O terceiro campo indica o tempo máximo que ele pode responder pelo domínio, antes que as informações expirem (1 semana, tempo mais do que suficiente para você arrumar o servidor principal 😉 e o tempo mínimo antes de devolver o domínio para o servidor principal quando ele retornar (1 dia). Se você acha que uma semana é pouco tempo, você pode aumentar o valor, usando, por exemplo, “4W” (4 semanas). Com isso você tem mais tempo para restaurar o servidor primário em caso de catástrofe.
Esses são os valores padrão, por isso não existem muitos motivos para alterá-los. A transferência do domínio para o DNS secundário é sempre uma operação demorada, por causa do cache feito pelos diversos servidores DNS espalhados pelo mundo: demora de um a dois dias até que todos atualizem suas tabelas de endereços. A principal prioridade deve ser evitar que o servidor principal fique indisponível em primeiro lugar.
Muitos preferem especificar esses valores em segundos. Uma configuração muito comum é separar os valores por linha, incluindo comentários, como em:
10800; refresh, seconds
900; retry, seconds
604800; expire, seconds
86400 ); minimum, seconds
O resultado é exatamente o mesmo. A única diferença é que você vai acabar digitando várias linhas a mais.
As duas linhas a seguir concluem a seção inicial:
IN MX 10 servidor.gdhn.com.br.
A linha “NS” (Name Server) diz quem são os servidores DNS responsáveis pelo domínio. Ao usar apenas um servidor DNS, você simplesmente repete o nome do servidor, seguido pelo domínio, como adicionamos na primeira linha. Caso você esteja usando dois servidores, então você precisa declarar ambos, como em:
NS ns2.gdhn.com.br.
A linha “IN MX” (Mail Exchangers) é necessária sempre que você pretende usar um servidor de e-mails (você pode escolher entre usar o Postfix, Qmail, Sendmail ou outro MTA). Aqui estou simplesmente usando a mesma máquina para tudo, por isso novamente citei o “servidor.gdhn.com.br”, que acumula mais esta função. Assim como no caso do DNS, você pode especificar um servidor de e-mails secundário, que passa a receber os e-mails caso seu servidor principal saia fora do ar. Nesse caso, você adiciona uma segunda linha, como em:
IN MX 20 outroservidor.outrodominio.com.br.
Os números indicam a prioridade de cada servidor. O servidor da primeira linha tem prioridade 10, por isso é o primário. O segundo tem prioridade 20 e por isso só assume em casos de problemas com o primário. Usar um segundo servidor de e-mails, em um domínio separado, adiciona uma camada extra de redundância e evita que você perca e-mails caso seu servidor fique temporariamente fora do ar.
Em grandes redes, é possível adicionar um volume muito maior de servidores, de forma a garantir a operação do serviço em qualquer situação. É possível até mesmo terceirizar o serviço, adicionando os servidores de uma empresa externa. Ao usar o Google apps for your domain (https://www.google.com/a/), que permite criar contas do Gmail com o domínio do seu site, por exemplo, você é orientado a adicionar as seguintes linhas na configuração:
IN MX 5 ALT1.ASPMX.L.GOOGLE.COM.
IN MX 5 ALT2.ASPMX.L.GOOGLE.COM.
IN MX 10 ASPMX2.GOOGLEMAIL.COM.
IN MX 10 ASPMX3.GOOGLEMAIL.COM.
IN MX 10 ASPMX4.GOOGLEMAIL.COM.
IN MX 10 ASPMX5.GOOGLEMAIL.COM.
Com isso, os e-mails são recebidos pelos servidores do Google (veja que são usados nada menos do que 7 servidores diferentes), que os armazenam nas contas apropriadas. O servidor DNS do seu site passa a apenas encaminhar as requisições.
Uma observação é que o protocolo SMTP prevê falhas nos links entre os servidores, de forma que, caso o servidor de e-mail principal esteja inativo, o emissor tenta contactá-lo durante um longo período (o default são 3 dias) antes de tentar o servidor secundário. Com isso, usar vários servidores não resolve o problema completamente, já que em caso de falha no servidor primário, as mensagens passarão a chegar com um grande atraso.
Outra observação é que os endereços dos domínios da configuração fornecida pelo Google aparecem em letras maiúsculas, mas, apesar disso, a configuração funciona sem problemas. Isso acontece porque, diferente de outras configurações, os nomes de domínio são case-insensitive, de forma que tanto faz escrevê-los usando letras minúsculas ou maiúsculas.
Depois dessas linhas iniciais, temos a parte mais importante, em que você especifica o endereço IP do servidor e pode cadastrar subdomínios, como em:
www A 64.234.23.12
ftp A 64.234.23.12
smtp A 64.234.23.12
Nesse exemplo, incluí também três subdomínios, o “www”, “ftp” e “smtp”, ambos relacionados ao IP do servidor. Isso permite que os visitantes digitem “www.gdhn.com.br” ou “ftp.gdhn.com.br” no navegador. Ao trabalhar com subdomínios, você pode relacioná-los com IP’s ou domínios diferentes. Por exemplo, muitos portais possuem vários subdomínios, como “www1”, “www2” e “www3”, onde cada um é um servidor diferente, configurados para dividir os acessos.
Ao trabalhar com dois servidores DNS, adicione também uma entrada para o servidor secundário, especificando o nome do segundo servidor (ns2 no exemplo) e o endereço IP, como em:
www A 64.234.23.12
ftp A 64.234.23.12
smtp A 64.234.23.12
ns2 A 64.234.23.13
Note o segundo DNS usa o IP .13, enquanto o servidor principal usa o .12, mas ambos estão dentro da mesma faixa de endereços.
Deixe seu comentário