Instalando um servidor DNS

Introdução
Na Internet, os servidores DNS formam uma gigantesca base de dados distribuída, que
tem uma função crítica no funcionamento da rede. No topo da cadeia, temos os root
servers, 14 servidores espalhados pelo mundo que tem como função responder a todas
as requisições de resolução de domínio. Na verdade eles não respondem nada, apenas
delegam o trabalho para servidores menores, responsáveis individuais dos domínios.

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:
http://www.guiadohardware.net/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.

DNS reverso
O DNS reverso é um recurso que permite que outros servidores verifiquem a
autenticidade do seu servidor, checando se o endereço IP atual bate com o endereço IP
informado pelo servidor DNS. Isso evita que alguém utilize um domínio que não lhe
pertence para enviar spam, por exemplo.

Qualquer um pode enviar e-mails colocando no campo do remetente o servidor do seu

domínio, mas um servidor configurado para checar o DNS reverso vai descobrir a farsa
e classificar os e-mails forjados como spam.

O problema é que os mesmos servidores vão recusar seus e-mails, ou classificá-los

como spam caso você não configure seu servidor DNS corretamente para responder às
checagens de DNS reverso. Chegamos a um ponto em que o problema do spam é tão
severo, que quase todos os servidores importantes fazem esta checagem, fazendo com
que, sem a configuração, literalmente metade dos seus e-mails não sejam entregues.

O primeiro passo é checar os arquivos "/etc/hostname" e "/etc/hosts" (no servidor), que

devem conter o nome da máquina e o domínio registrado.

O arquivo "/etc/hostname" deve conter apenas o nome da máquina, como em:

servidor

No Fedora e em algumas outras distribuições, o nome da máquina vai dentro do arquivo

"/etc/sysconfig/network".
No arquivo "/etc/hosts" deve conter duas entradas, uma para a interface de loopback, o
127.0.0.1, e outra para o IP de internet do seu servidor, que está vinculado ao domínio,
como em:

127.0.0.1 localhost.localdomain localhost

64.234.23.12 servidor.kurumin.com.br servidor

A partir daí, falta adicionar a zona reversa no bind complementando a configuração do

domínio, que já fizemos. Começamos adicionando a entrada no "/etc/bind/named.conf"
ou "/etc/bind/named.conf.local":

zone "23.234.64.in-addr.arpa" {
type master;
file "/etc/bind/db.kurumin.rev";
};

No nosso exemplo, o endereço IP do servidor é 64.234.23.12. Se retiramos o último

octeto e escrevemos o restante do endereço de trás pra frente, temos justamente o
"23.234.64" que usamos no registro reverso. A terceira linha indica o arquivo onde a
configuração do domínio reverso será salva. Neste caso indiquei o arquivo
"db.kurumin.rev", mas você pode usar qualquer nome de arquivo.

Este arquivo "db.kurumin.rev" é bem similar ao arquivo com a configuração do

domínio, que acabamos de configurar. As três linhas iniciais são idênticas (incluindo o
número de sincronismo), mas ao invés de usar o "A" para relacionar o domínio e cada
subdomínio ao IP correspondente, usamos a diretiva "PTR" para relacionar o endereço
IP de cada servidor ao domínio (é justamente por isso que chamamos de DNS reverso
;).

No primeiro arquivo, usamos apenas os três primeiros octetos do endereço (a parte

referente à rede), removendo o octeto final (o endereço do servidor dentro da rede).
Agora, usamos apenas o número omitido da primeira vez.

O IP do servidor é "64.234.23.12", removendo os três primeiros octetos ficamos apenas

com o "12". Temos também o endereço do DNS secundário, que é 64.234.23.13, de
onde usamos apenas o "13". Relacionando os dois a seus respectivos domínios, o
arquivo fica:

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

2006040645 3H 15M 1W 1D )
NS servidor.kurumin.com.br.
NS ns1.kurumin.com.br.
12 PTR kurumin.com.br.
13 PTR ns1.kurumin.com.br.

Caso você não esteja usando um DNS secundário, é só omitir as linhas referentes a ele,
como em:

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

2006040645 3H 15M 1W 1D )
NS servidor.kurumin.com.br.
12 PTR kurumin.com.br.

Depois de terminar, reinicie o Bind e verifique usando o dig. Comece checando o

domínio, como em:

# dig kurumin.com.br

Na resposta, procure pela seção "ANSWER SECTION", que deverá conter o IP do

servidor, como configurado no bind:

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

Faça agora uma busca reversa pelo endereço IP, adicionando o parâmetro "-x", como
em:

# dig -x 64.234.23.12

Na resposta você verá:

;; ANSWER SECTION:
12.23.234.64.in-addr.arpa. 86400 IN PTR kurumin.com.br.

Ou seja, com o DNS reverso funcionando, o domínio aponta para o IP do servidor e o IP

aponta para o domínio, permitindo que os outros servidores verifiquem a autenticidade
do seu na hora de receber e-mails provenientes do seu domínio.

Lembre-se que seus e-mails podem ser classificados como spam também se seu IP
estiver marcado em alguma blacklist. Você pode verificar isso rapidamente no
http://rbls.org/.

Você vai notar, por exemplo, que praticamente endereço IP de uma conexão via ADSL
ou modem vai estar listado, muitas vezes "preventivamente", já que é muito comum que
conexões domésticas sejam usadas para enviar spam. É recomendável verificar
periodicamente os IP's usados pelo seu servidor, além de verificar qualquer novo IP ou
link antes de contratar o serviço.

Mais uma consideração importante sobre a configuração do DNS reverso é que você
precisa ter autoridade sobre a faixa de IP's para que a configuração funcione.

Quando você aluga um servidor dedicado, é de praxe que receba uma pequena faixa de
endereços IP, configurada usando uma máscara complexa, como a "255.255.255.248",
onde você fica com uma faixa de 8 IP's diferentes, como por exemplo do
"72.213.43.106" até o "72.213.43.113".

Isso também é comum ao alugar um link dedicado, onde (dependendo do plano), você
recebe uma faixa completa, com 254 IP's, ou uma faixa reduzida, com máscara
"255.255.255.240" (16 IP's), "255.255.255.248" (8 IP's) ou "255.255.255.252" (4 IP's).
Em qualquer um dos casos, o fornecedor deve delegar a autoridade sobre a sua faixa de
endereços, para que a configuração que vimos aqui funcione. Sem isto, é o servidor
deles quem responde pela sua faixa, retornando um erro qualquer, sem que seu servidor
DNS tenha chance de fazer seu trabalho.

Se você alugou um servidor ou um link dedicado e percebeu que a autoridade sobre a

faixa não foi delegada, minha primeira sugestão é que você troque de fornecedor, pois
esta é uma configuração básica. Se não fazem nem a delegação corretamente, é provável
que o serviço deixe a desejar em outras aspectos. Se isso não for possível, entre em
contato com eles cobrando a configuração.

Alguns provedores preferem configurar eles mesmos o DNS reverso para seu domínio.
Neste caso vão apenas lhe pedir a configuração e ativar o reverso no DNS deles. Esta
solução não é ideal, pois você vai precisar entrar em contato com o suporte cada vez que
precisar fazer uma alteração, mas é melhor do que nada. Esta é também a única opção
em planos onde você recebe um único IP fixo, ao invés de uma faixa de endereços.

No caso de planos de acesso doméstico, onde você recebe um único IP, quase sempre é
impossível configurar o DNS reverso, pois você não tem autoridade sobre a faixa de IP's
e a operadora não vai querer fazer a configuração para você sem que você pague mais
um um plano empresarial.

Configurando um DNS para a Intranet

Esta mesma configuração pode ser usada para criar um servidor DNS particular, para a
sua rede local. Com isso você poderá acessar todos os micros através de nomes de
domínio, como na internet, ao invés de ficar decorando endereços IP. Isso pode ser um
grande facilitador em redes de médio porte, onde já não é prático saber de cor os
endereços de todos os micros.

Neste caso, você pode "registrar" seus domínios da forma como quiser, seja criando um
domínio fictício, ou usando um domínio registrado e atribuindo sub-domínios aos
micros da rede.

Seu domínio principal pode ser, por exemplo, "gdh" com cada micro recebendo um
subdomínio, como em "administracao.gdh", "contabilidade.gdh" e "vendas.gdh". Deste
modo, ao rodar o comando "ssh vendas.gdh", por exemplo, você se conecta ao PC
especificado, a partir de qualquer um dos outros micros da rede, sem precisa especificar
o IP.

Para isso, você começa instalando o Bind no servidor da rede, ou (no caso de uma rede
doméstica) em algum PC que ficará sempre ligado. Você pode usar o próprio
gateway/firewall para mais esta tarefa.

Configure todos os micros da rede interna para utilizarem o IP deste servidor como
DNS primário e adicione a configuração dos domínios no Bind. Se, por exemplo, os
endereços dos três micros são respectivamente 192.168.0.2, 192.168.0.3 e 192.168.0.4 e
o servidor é o 192.168.0.1, a configuração ficaria:

No final do arquivo "/etc/bind/named.conf" vai a configuração do domínio principal,

ou seja "gdh". Como estamos trabalhando dentro da rede local, você pode utilizar
qualquer nome, não é necessário seguir o padrão usado na Internet:

zone "gdh" IN {
type master;
file "/etc/bind/db.gdh";
};

Falta agora a configuração dos subdomínios, que vai dentro do arquivo db.gdh:

@ IN SOA servidor.gdh. hostmaster.gdh. (

2006040656 3H 15M 1W 1D )
NS servidor.gdh.
gdh. A 192.168.0.1
administracao A 192.168.0.2
vendas A 192.168.0.3
contabilidade A 192.168.0.4

Temos aqui o "gdh", que é o próprio servidor, além do "administracao.gdh",

"vendas.gdh" e "contabilidade.gdh", respondendo pelos endereços especificados. Note
que excluí a linha "IN MX", pois ela é necessária apenas quando incluir um servidor de
e-mails.

Serviços de DNS Dinâmico

Para registrar um domínio, você precisa ter um IP fixo, de preferência um link dedicado.
Muitas tarefas como, por exemplo, rodar um servidor de e-mails ou mesmo hospedar um site
importante não podem ser feitos com confiabilidade numa linha ADSL, por isso o ideal mesmo
é usar um servidor dedicado.

Mesmo assim, você pode usar seu ADSL ou cabo para tarefas mais simples, ou mesmo para
acessar seu micro remotamente. Você pode resolver o problema do IP dinâmico usando um
serviço de DNS Dinâmico (dynamic DNS).

Nestes serviços você instala um programa "dedo-duro" no seu micro, que periodicamente
entra em contato com os servidores do serviço e atualiza automaticamente o
redirecionamento. Você recebe um endereço no estilo "seu-nome.alguma-coisa.com" que
aponta sempre para seu endereço IP corrente.

Um dos que testei e tem funcionado bem ao longo dos anos é o http://www.no-ip.com. Eles
oferecem um plano gratuito, onde basta preencher o cadastro, em que você fornece um
endereço de e-mail para contato e escolhe o nome do seu domínio.
Depois é só ir na seção de downloads e baixar o update cliente. Estão disponíveis versões para
Windows, Linux e OS X. Ele deve ficar sempre aberto, a atualização do IP é feita de meia em
meia hora ou sempre que você abrir o programa.

Se você compartilha a conexão entre vários micros, não é necessário mantê-lo instalado no
servidor, basta mantê-lo ativo em qualquer um dos micros da rede interna para que ele faça
seu serviço. Lembre-se de que, ao compartilhar a conexão entre vários micros, todos acessam
a internet utilizando o mesmo endereço IP.

Em alguns planos de banda larga (como por exemplo no Speedy da Telefonica), a porta 80,
junto com algumas outras portas são bloqueadas, justamente para dificultar o uso de
servidores. Neste caso, você deve configurar o seu Apache para utilizar uma porta diferente
(1080, por exemplo) e orientar os visitantes a incluírem a porta no endereço, como em:
http://seu-nome.no-ip.com:1080.

Para instalar o cliente for Linux do noIP, os passos são os seguintes:

 Registre sua conta no: http://www.no-ip.com/newUser.php

 Baixe o cliente for Linux na área de downloads e descompacte o arquivo. Dentro dele,
existe uma pasta chamada "binaries", com o arquivo "noip2-Linux". Este é o
executável que faz a atualização do IP. Para usá-lo, copie-o para a pasta
"/usr/local/bin":

$ tar -zxvf noip-duc-linux.tar.gz$ cd noip-2.1.1/$ cd binaries/

# sudo cp -a noip2-Linux /usr/local/bin

 O próximo passo é executar o noip2-Linux, usando a opção "-C -c" (create config), que
cria o arquivo de configuração. Você pode indicar onde o arquivo será criado, basta
indicá-lo no comando. Nesta etapa ele pedirá o login de usuário e o domínio registrado
no site:

# noip2-Linux -C -c /etc/noip.conf

 Com o arquivo de configuração criado, inicie o noip2-Linux usando o comando abaixo.

Inclua o comando no final do arquivo "/etc/rc.d/rc.local" ou "/etc/init.d/bootmisc.sh"
para que ele seja executado durante o boot. Não se esqueça de adicionar o "&" no
final do comando, ele faz o programa rodar em background. Sem ele, o comando
bloqueia o terminal, paralisando a inicialização do sistema. Note que agora usamos
apenas o segundo "c", que indica que ele deve usar o arquivo de configuração
anteriormente criado:

# noip2-Linux -c /etc/noip.conf &

Além do No-IP, existem dezenas de outros serviços semelhantes. Fornecer domínios
virtuais é um serviço muito menos custoso do que fornecer webmails, por exemplo, por
isso muitas empresas oferecem o serviço gratuitamente como uma forma de divulgação
ou buscando cobrir os custos com anúncios. Estes são alguns links:
http://www.dyndns.org
http://www.da.ru
http://hn.org
http://www.myip.org
http://www.dyndsl.com
http://dns2go.com