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