Um nome de domínio é lido da direita para a esquerda. Temos os domínios primários (top level domains, ou TLD’s), como .com, .net, .info, .cc, .biz, etc., e em seguida os domínios secundários (country code TLD’s), que recebem o prefixo de cada país, como .com.br ou .net.br. Neste caso, o “com” é um subdomínio do domínio “br”.
A Internic cuida dos registros dos domínios raiz (.com, .org, .info e outros), enquanto a Fapesp 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 na Fapesp ou na Internic, você precisará fornecer dois endereços de DNS, para onde serão enviadas as consultas referentes ao seu domínio.
É aqui que entra a questão da autoridade. Sempre que é necessário resolver um domínio, o cliente faz uma requisição para o servidor DNS da rede, ou do provedor, informado na configuração da rede. O servidor contata um dos root servers e pergunta sobre o domínio. Se for um domínio .br, eles encaminham a requisição ao servidor da Fapesp, que é a autoridade responsável. Ele, por sua vez, verifica em sua base de dados quem é o servidor responsável pelo domínio e encaminha novamente a requisição para ele.
Ao registrar um domínio, você passa a ter autoridade sobre ele, e pode criar subdomínios a forma como quiser, como “fulano.meunome.com.br” ou “vendas.minhaempresa.com“. Veja o caso dos servidores de hospedagem gratuita, como o HPG & cia. que criam milhões de subdomínios para as páginas hospedadas.
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.
É por isso que, às vezes, você não consegue acessar um determinado site usando o DNS do provedor (que está desatualizado), mas consegue usando um DNS local, ou outro servidor qualquer.
Ao configurar um servidor web com o Apache, podemos hospedar vários sites no mesmo servidor (virtual host). Neste caso, especificamos o domínio e o diretório local correspondente a cada site, como em:
<VirtualHost *> ServerAdmin webmaster@kurmin.com.br ServerName www.kurumin.com.br ServerAlias kurumin.com.br DocumentRoot /var/www/kurumin </VirtualHost>
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 na Fapesp, Internic ou outro órgão responsável. Ao registrar, você precisa fornecer dois endereços de DNS. Em muitos 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.
Ao alugar um servidor dedicado, é comum que você receba dois ou mais endereços IP’s válidos. Originalmente, seu servidor vai estar configurado para usar apenas um deles, mas você pode ativar o segundo (mesmo que o servidor possua apenas uma placa de rede) usando o ifconfig.
Se o segundo IP é o “64.234.23.13” e a placa de rede é a eth0, o comando seria:
# ifconfig eth0:1 64.234.23.13
A partir daí, seu servidor passa a responder pelos dois endereços IP, e você pode usá-lo simultaneamente como DNS primário e secundário.
Em casos onde o sistema não permite continuar sem fornecer o segundo endereço, e você realmente não tem um segundo IP, nem nenhum amigo que possa ser o secundário, existe mais 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 seu servidor DNS, que precisa responder por ele.
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, no 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 nosso seu servidor DNS, e daí para o servidor Apache.
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 na Fapesp, 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 responsáveis pelo seu domínio:
Naturalmente você vai precisar de um endereço IP válido e fixo, seja com um servidor “in house“, com um link dedicado, ou um servidor dedicado hospedado num datacenter.
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). A existência deste arquivo separado, visa separar a configuração geral do servidor, da configuração dos domínios, minimizando a possibilidade de erros. Mas, na verdade, o efeito de editar qualquer um dos dois arquivos é o mesmo.
O “zone “kurumin.com.br” na primeira linha indica o domínio que estamos configurando, como registrado na Fapesp.
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.
Estas linhas dizem que o servidor é o responsável pelo domínio “kurumin.com.br” (type master;), que sempre que receber uma requisição vai responder de acordo com o especificado no arquivo db.kurumin (file “/etc/bind/db.kurumin”;) e que, o servidor “64.234.23.13” (o DNS secundário) pode assumir a responsabilidade sobre o domínio em caso de problemas com o titular (allow-transfer).
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. Caso queira incluir comentários, use “;” ao invés de “#”, como em outros arquivos. Você pode baixar o exemplo, como digitado aqui no:
https://www.hardware.com.br/kurumin/modelos/bind/db.exemplo
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. (
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 num endereço de e-mail.
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.
O ponto se refere ao domínio raiz, de responsabilidade dos rootservers. No exemplo, nosso servidor é o responsável pelo domínio “kurumin”, 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 . kurumin.
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 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.
Muita gente prefere especificar estes valores em segundos. Uma configuração muito comum é separar os valores por linha, incluindo comentários, 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 três subdomínios, o “www”, “ftp” e “smtp”, 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” e “www3”, onde cada um é um servidor diferente, configurados para dividir os acessos.
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. Em casos onde o mesmo servidor dedicado responde pelos dois endereços IP, ou seja, você se está usando a mesma máquina como DNS primário e secundário, você pode simplesmente inventar um nome fictício para o segundo IP.
Você pode também usar a diretiva “IN CNAME” para criar aliases, ou seja, subdomínos que atuam como apelidos para outros. Veja um exemplo:
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 joao A 200.123.23.2 maria IN CNAME joao
Neste caso o subdomínio “maria” é simplesmente um alias para o “joao”, que aponta para um IP externo. Você pode criar quantos subdomínios de aliases precisar.
Ao terminar,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
Ambos devem devolver a mesma resposta.
Veja também
Sobre o Autor
Deixe seu comentĂ¡rio