Configurando o Bind

Na configuração do Apache, especificamos o domínio e o diretório local correspondente para cada site. A idéia aqui é que o visitante digita o nome de domínio do site no navegador e o Apache se encarrega de enviá-lo ao diretório correto. Mas, para que o cliente chegue até o servidor, faltam mais duas peças importantes.

A primeira é o registro do domínio, que pode ser feito no Registro.br, Internic ou outro órgão responsável. Ao registrar, você precisa fornecer dois endereços de DNS. Na maioria dos casos, o segundo DNS não é obrigatório, ele é apenas uma segurança para o caso do primeiro sair fora do ar. Uma opção muito usada para o segundo DNS é pedir para que algum amigo que também possua um servidor dedicado seja seu DNS secundário. Ele precisará apenas adicionar a configuração do seu domínio na configuração do DNS, o que é rápido e indolor.

Em casos onde o sistema não permite continuar sem fornecer o segundo endereço, existe um pequeno truque: conecte-se via modem na hora de fazer o registro, assim você terá dois endereços (o do link e o do modem) e conseguirá concluir o registro. Naturalmente, neste caso, você perde a redundância: se o seu DNS principal cair seu site ficará fora do ar.

Note que nem sempre esta questão da redundância é realmente um problema, pois se o servidor DNS está hospedado no mesmo servidor que seu site, não faz muita diferença ter dois servidores DNS, pois se o servidor principal cair, o site ficará fora do ar de qualquer forma. Sites maiores possuem sistemas de redundância e muitas vezes servidores DNS separados, o que cria uma malha de segurança. É por isso que é muito raro a página de um portal ficar fora do ar, por exemplo.

É aqui que acaba o trabalho deles e começa o seu. Ao acessar o domínio, o visitante é direcionado para o endereço de DNS fornecido no registro. Isto significa que… bingo! além do Apache você vai precisar de um servidor DNS :).

Quando alguém tenta acessar um dos domínios registrados, a requisição vai do DNS do provedor para um dos 14 root servers disponíveis na internet, que são responsáveis por todos os domínios.

Na verdade, os root servers não armazenam uma tabela local. Ao invés disso eles redirecionam a requisição para o Registro.br, ou outra entidade responsável, que por sua vez redireciona para o seu servidor. O ciclo se fecha e o cliente consegue finalmente acessar a página.

Resolver um nome de domínio é uma operação que pode demorar alguns segundos, por isso os servidores DNS armazenam um cache de domínios já resolvidos, minimizando o número de requisições. É por isso que quando você faz alguma mudança na configuração do domínio, demoram algumas horas para que ela se replique.

Se seu servidor estiver hospedando subdomínios, ou seja, endereços como “www.fulano.guiadohardware.net“, “www.ciclano.guiadohardware.net“, etc., como fazem serviços como o hpg, a configuração continua basicamente a mesma. Você especifica o sub-domínio do cliente na configuração do VirtualHost do Apache e também no servidor de DNS.

Uma observação importante é que para o Apache, o domínio “www.fulano.guiadohardware.net” é diferente de apenas “fulano.guiadohardware.net“. Para que o site possa ser acessado tanto com o www quanto sem ele, é necessário incluir um “ServerAlias” na configuração de cada site, como vimos a pouco, na configuração do Apache.

Como no caso anterior, você deve informar o endereço do seu servidor de DNS no registro do domínio. Como os servidores de registro de domínio lêem as URLs de trás para a frente, todos os acessos a subdomínios dentro do guiadohardware.net serão enviados para o seu servidor DNS e daí para o servidor Apache.

A Internic cuida dos registros dos domínios raiz (.com, .org, .info e outros), enquanto o Registro.br responde pelos domínios com extensão .br (.com.br, .org.br, etc.).

O registro de domínios na Internic é menos burocrático, pois você não precisa ter uma empresa registrada. De qualquer forma, registrando seu domínio no Registro.br ou na Internic, você precisará fornecer dois endereços de DNS, para onde serão enviadas as consultas referentes ao seu domínio.

O servidor DNS mais usado no Linux é o Bind, que aprenderemos a configurar aqui. Não existe problema em instalá-lo no mesmo servidor onde foi instalado o Apache e o Proftpd, embora do ponto de vista da segurança o ideal seja utilizar servidores separados ou um chroot.

Para instalar o Bind, procure pelo pacote “bind” ou “bind9” no gerenciador de pacotes da distribuição usada. No Debian ou Kurumin você instala com um “apt-get install bind” e no Mandriva com um “urpmi bind“. No Slackware você encontra o pacote dentro da pasta “n” do primeiro CD. Ao instalar, verifique a versão incluída na distribuição. Use sempre o Bind 8 ou 9; nunca o Bind 4, que está em desuso.

O arquivo de configuração principal é o “/etc/bind/named.conf“. Em versões antigas, o arquivo pode ser simplesmente “/etc/named.conf”.

Por padrão, o Bind já vem configurado para trabalhar como um servidor DNS de cache para a rede local. Inicie o serviço com o comando “/etc/init.d/bind start” ou “service bind start” e configure os micros da rede interna para utilizarem o endereço IP do servidor onde foi instalado o bind como DNS (192.168.0.1 por exemplo), e você verá que eles já serão capazes de navegar normalmente, sem precisar mais do DNS do provedor.

O próximo passo é configurar o Bind para responder pelos domínios que você registrou. Vamos usar como exemplo o domínio “kurumin.com.br“.

Como é um domínio .br, ele é registrado no Registro.br, 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 de DNS do seu servidor.

Naturalmente você vai precisar de um endereço IP válido e fixo. O ideal é usar um link dedicado, mas como eles são muito caros no Brasil, muitas empresas optam por usar conexões ADSL. Em geral as operadoras fornecem endereços IP fixos nos planos empresariais.

Outra opção (mais recomendável, tanto do ponto de vista da confiabilidade, quanto do ponto de vista do custo) é alugar um servidor dedicado, hospedado em um datacenter estrangeiro. Os preços variam de US$ 50 a US$ 200 mensais, dependendo da configuração e link. Alguns exemplos de empresas de hospedagem são o http://ev1servers.net/, http://www.serverbeach.com e http://www.layeredtech.com.

Os servidores hospedados no Brasil acabam saindo sempre muito mais caro, devido ao custo dos links, que são muito mais caros aqui do que no exterior. Existem ainda algumas empresas brasileiras, como a http://braslink.com, que locam servidores hospedados no exterior.

Depois de se decidir sobre onde hospedar e concluir o registro do domínio, falta configurar o Bind para responder pelo domínio registrado. Vou usar como exemplo o domínio “kurumin.com.br”.

Comece adicionando as seguintes linhas no final do arquivo “/etc/bind/named.conf” (sem modificar as demais):

zone “kurumin.com.br” IN {
type master;
file “/etc/bind/db.kurumin”;
};

Ao usar um servidor DNS secundário, inclua a linha “allow-transfer”, especificando o endereço IP do segundo servidor, como em:

zone “kurumin.com.br” IN {
type master;
file “/etc/bind/db.kurumin”;
allow-transfer { 64.234.23.13; };
};

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), mas na verdade o efeito é o mesmo.

O “zone “kurumin.com.br” na primeira linha indica o domínio que estamos configurando, como registrado no Registro.br.

O “file “/etc/bind/db.kurumin” especifica o arquivo onde vai a configuração deste domínio. Na verdade você pode salvar este 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.

Em seguida você precisa adicionar a configuração do domínio no arquivo “/etc/bind/db.kurumin” que foi citado na configuração. O conteúdo do arquivo fica:

@ IN SOA servidor.kurumin.com.br. hostmaster.kurumin.com.br. (
2006040645 3H 15M 1W 1D )
NS servidor.kurumin.com.br.
IN MX 10 servidor.kurumin.com.br.
kurumin.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

Neste arquivo, a formatação é importante. Você pode usar espaços e tabs (ambos tem 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.

Pesquisando no Google, você pode encontrar inúmeros templates como este, 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:

@ IN SOA servidor.kurumin.com.br. hostmaster.kurumin.com.br. (

O “@” na primeira linha indica a origem do domínio e, ao mesmo tempo, o início da configuração. Ele é sempre usado, assim como num endereço de e-mail, por isso não é preciso se preocupar muito com ele. O “IN” é abreviação de “internet” e o “SOA” de “Start of autority”. Em seguida vem o nome do servidor (que você checa usando o comando “hostname”), seguido do e-mail de contato do administrador.

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.meudomonio.com.br”, por exemplo.

Note também que existe um ponto depois do “servidor.kurumin.com.br” e do “hostmaster.kurumin.com.br”, que faz parte da configuração.

A linha diz algo como “Na internet, o servidor “servidor” responde pelo domínio kurumin.com.br e o e-mail do responsável pelo domínio é “hostmaster.kurumin.com.br”.

A primeira linha termina com um parênteses, que indica o início da configuração do domínio. Temos então:

2006061645 8H 2H 1W 1D )

O “2006061645” é o valor de sincronismo, que permite que o servidor DNS secundário mantenha-se sincronizado com o principal, detectando alterações na configuração. Este número é composto da data da última alteração (como em: 20060616), e um número de dois dígitos qualquer que você escolhe. Sempre que editar a configuração, ou sempre que configurar um servidor DNS a partir de um template qualquer, lembre-se de atualizar a data e mudar os dois dígitos.

Os quatro campos seguintes orientam o servidor DNS secundário (caso você tenha um). O primeiro campo indica o tempo que o servidor aguarda entre as atualizações (8 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 (2 horas) 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).

Estes valores são padrão, por isso não existem muitos motivos para alterá-los. A transferência do domínio para o DNS secundária é sempre uma operação demorada, por isso a principal prioridade deve ser evitar que o servidor principal fique indisponível em primeiro lugar.

Muita gente prefere especificar estes valores em segundos. Uma configuração muito comum é separar os valores por linha, como em:

2006061645; serial
28800; refresh, seconds
7200; 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 que vem a seguir concluem a seção inicial:

NS servidor.kurumin.com.br.
IN MX 10 servidor.kurumin.com.br.

A primeira, diz quem são as máquinas 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 servidor.kurumin.com.br.
NS ns2.kurumin.com.br.

A linha “IN MX” é 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.kurumin.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. Neste caso você adiciona uma segunda linha, como em:

IN MX 10 servidor.kurumin.com.br.
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, num 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.

Depois destas linhas iniciais, temos a parte mais importante, onde você especifica o IP do servidor e pode cadastrar subdomínios, como em:

kurumin.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

Neste exemplo, incluí também dois subdomínios, o “www” e “ftp”, ambos relacionados ao IP do servidor. Isso permite que os visitantes digitem “www.kurumin.com.br” ou “ftp.kurumin.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”, “www3” e assim por diante, onde cada um é um servidor diferente.

Sites como o http://no-ip.com, que oferecem “domínios virtuais”, que apontam para seu endereço IP atuais são na verdade grandes bases de dados, atualizadas automaticamente, onde cada subdomínio aponta para o IP atual do dono.

Ao trabalhar com dois servidores DNS, adicione também uma entrada para ele, especificando o nome do segundo servidor (ns2 no exemplo) e o IP, como em:

kurumin.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
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 IP’s. É comum que ao locar um servidor dedicado, você receba dois endereços IP (quase sempre dentro da mesma faixa), permitindo que você configure o segundo DNS.

Você pode testar a configuração do seu servidor DNS usando o comando dig. No Debian ele é instalado juntamente com o pacote “dnsutils”.

Faça uma busca pelo domínio, especificando o endereço IP do DNS que acabou de configurar, como em:

$ dig kurumin.com.br @64.234.23.12

Isso faz com que ele pergunte diretamente ao seu servidor, o que permite testar a configuração imediatamente, sem precisar esperar pela propagação do registro do domínio. Se tudo estiver correto, você verá algo como:

;; ANSWER SECTION:
kurumin.com.br. 86400 IN A 64.234.23.12

;; AUTHORITY SECTION:

gdhpress.com.br. 86400 IN NS servidor.kurumin.com.br.
gdhpress.com.br. 86400 IN NS ns2.kurumin.com.br.

Faça o mesmo com o IP do DNS secundário, como em:

$ dig kurumin.com.br @64.234.23.13