DNS Crocante, Nutritivo e Dinâmico! (Agora com BIND 9)

Esta matéria está focada em demonstrar a praticidade e flexibilidade de um DNS dinâmico usando o BIND 9 e como a sua topologia lógica pode ser melhor gerenciável, caso seja adotada como tecnologia em sua rede; abordaremos os recursos de um DNS Dinâmico na plataforma *nix e Windows, dando destaques nos seguintes tópicos:

- Histórico e definição; (Básico)- DNS Dinâmico no BIND, e seu funcionamento- Principais tipos de registros; (Resource Records)- Instalando e Configurando BIND 9 com suporte a Dynamic Updates (*nix/win32)- Referências

Histórico & Definições (Básico)

Não é de hoje que você abre seu navegador e digita os tão perturbadores www e entra em um site a sua escolha, ou acessa a rede interna de sua empresa em notação UNC, como filmes, mal sabe você que por traz deste processo existe toda uma tecnologia, DNS, NetBIOS e outros, sua principal função nada mais e nada menos que fazer uma conversão, resolução de nomes á IPs.

Como tudo começou?

Basicamente durante os anos 70, ARPANET era uma pequena comunidade, composta por algumas centenas de hosts. Um único arquivo, HOSTS.txt, continha toda a informação necessária sobre as maquinas da rede. Este arquivo continha nome para endereçar cada host conectado a ARPANET. O arquivo era mantido pela Network Information Center (NIC) e distribuído por um único host, SRI-NIC.

Naquela época os administradores da ARPANET enviavam ao NIC, por e-mail, quaisquer mudanças que tivessem sido efetuadas e periodicamente SRI-NIC atualizava-o, assim como o arquivo HOST.txt.

A Organização Básica!

Existe uma solução mais simples do que a utilização do DNS para a resolução de nomes quando sua infra-estrutura é limitada fisicamente; consiste no uso de um arquivo texto como na tabela abaixo (em cinza), na qual faz o mapeamento de endereços numéricos IPs para os nomes.

127.0.0.1 localhost

10.5.3.5 smtp-gw.mundoerva.com.br

192.168.1.161 gw-intranet.digerati.com

Este arquivo deve conter entradas para todas as máquinas da rede, observe que cada linha corresponde a um mapeamento específico; este arquivo deve ser copiado pelo administrador ao final de cada dia e repassar a cada usuário, pois se deve copiá-lo para cada máquina. Este método é conhecido como HOSTS, assim como na ARPANET.

As desvantagens são óbvias, não!?

O usuário final tem uma responsabilidade grande neste processo e quase sempre não é confiável delegar tal encargo. Sua gerência e manutenção são centralizadas o que pode causar um grande overhead administrativo.

Em grandes redes, como a Internet, este método torna-se totalmente inviável, pois a quantidade de máquinas é absurdamente grande para ser gerenciada de forma centralizada. O arquivo texto seria infinitamente grande e os debugs de erros e as atualizações seriam de difícil execução; além disso, seria um caos resolver problemas de conflitos de nomes e IP’s.

Claro, nem por isso o método HOSTS é deixado de ser usado; Em conjunto, o HOSTS, pode trabalhar de forma independente com o DNS, é o mais comum nos dias de hoje, pode-se definir primeiro uma busca a ser feita no HOSTS, caso não encontre, a busca seja feita no DNS ou vice-versa.

Esta pesquisa pode ser otimizada, fazendo-a primeiro no arquivo HOSTS e logo em seguida no DNS pois a busca em um arquivo texto local é muito mais eficiente e se ganha em tempo e velocidade. Além disto, em redes corporativas o acesso é feito geralmente entre as máquinas internas; se estas forem incluídas ao arquivo HOSTS a performance será ainda melhor. O sistema utilizado pela Microsoft funciona deste modo, primeiro é feita uma busca no arquivo hosts.sam e depois em servidores de nomes, o DNS.

O que é DNS?

DNS é a sigla do inglês de “Domain Name System”; é um protocolo que atua em maior proporção na Internet e toma como base usar estruturas de nomes F.Q.D.N. (Fully Qualified Domain Name), como por exemplo: “www.mundoerva.com.br" e traduz este nome a um endereço IP do computador que realmente roda o serviço que você está tentando acessar, neste caso www, Serviço WEB na porta 80.

Obviamente é muito mais didático memorizar um nome do que um número IP de um host, exatamente por isso que o serviço de DNS torna-se um item indispensável para World Wide Web e seus usuários.

O DNS é um sistema robusto no quesito gerenciamento de nomes, totalmente hierárquico e distribuído; com ele, define-se a sintaxe dos nomes usados pela Web, regras para delegação de autoridade na definição de nomes, banco de dados distribuído na qual associa nomes a atributos (entre eles, endereços IPs) e um algoritmo distribuído para mapear nomes em endereços, o mesmo está especificado nas RFCs 882, 883 e 973; por padrão as aplicações de DNS utilizam endereços IP de 32 bits (IPv4) no sentido de abrir uma conexão ou enviar um datagrama IP.

Porém, grande maioria dos usuários prefere identificar as maquinas através de nomes ao invés de números. Assim é necessário um banco de dados que permita a uma aplicação encontrar um endereço, já que ela conhece o nome da maquina com a qual se deseja comunicar na rede. Um conjunto de servidores de nomes mantém o banco de dados com os nomes e endereços das maquinas conectadas à Internet. (Server Primary e Slave)

Figura 1 - Estrutura DNS

NOTA: O que é uma RFC?

Request For Comments, são notas de trabalho da comunidade de pesquisa e desenvolvimento da Internet; na grande maioria, as RFCs são descrições de protocolos de rede ou serviços, na qual são frequentemente detalhados os procedimentos e formatos para sua implementação; normas pré-definidas.

Note que é usado um conjunto de servidores interconectados (Figura 1), ao invés de um único servidor centralizado. Existem atualmente tantas instituições conectadas à Internet que seria impraticável exigir que elas notificassem uma autoridade central toda vez que uma máquina fosse instalada ou trocasse de lugar; Assim, a autoridade para atribuição de nomes é delegada a instituições individuais.

Os servidores de nomes formam uma árvore, correspondendo á estrutura institucional. Os nomes também adotam uma estrutura similar, por exemplo: www.mundoerva.com.br, para encontrar seu endereço Internet, pode ser necessário o acesso em até 4 servidores DNS.

DNS Dinâmico no BIND, e seu funcionamento

A partir do BIND 8, existe uma característica interessante no seu serviço de DNS, as atualizações dinâmicas, apenas a capacidade de modificar dados de uma zona de DNS sem precisar editar manualmente o arquivo da zona, isto o torna, tão mais nutritivo quanto imaginamos. Embora atualizações dinâmicas sejam úteis elas acrescentam um risco adicional à integridade da sua zona de DNS, tal risco pode ser amenizado (o lado crocante de toda essa ideologia) com o uso de assinaturas digitais (DNSSEC ou TSIG).

Atualizações Dinâmicas

Serão bastante utilizadas no futuro com a popularização de modalidades tarifarias e a banda larga; cada vez mais pessoas vão montar seus serviços de internet em suas residências e vão querer acessar de qualquer lugar e a qualquer momento e a única referência que temos é o endereço IP (quase sempre, dinâmico), na qual é fornecida pelo provedor de acesso.

O termo atualizações dinâmicas é a habilidade individual sobre certas condições, como adicionar, modificar ou até mesmo deletar uma referência, por allowupdate ou updatepolice em arquivos de zonas principais, sem a necessidade de editá-los manualmente, pode ser usadas junto com servidores DHCP, atualizando estes registros DNS de hosts com endereço IP dinâmico.

NOTA: O que é DHCP?

Dynamic Host Configuration Protocol é um protocolo e serviço para automatizar a configuração de computadores que usam o protocolo TCP/IP, é usado para atribuir automaticamente os endereços IPs e outros dados igualmente importantes, nomeadamente: a máscara de rede, o default gateway, DNS e outros.

Grande parte das mudanças realizadas nas zonas usando atualizações dinâmicas é guardada em um arquivo denominado Journal, na qual automaticamente é criado pelo servidor quando a primeira atualização dinâmica acontece, este arquivo tem sua extensão formada por .jnl ao nome do arquivo da zona correspondente, e este é em formato binário e não deve ser editado manualmente, sua execução ocorre quando o servidor/serviço de DNS (named) trava ou é desligado (shutdown), incorporando na zona, quaisquer atualizações que aconteceram antes da última escrita da zona.

O processo de atualização é gravar um “dump” de todo conteúdo completo da zona atualizada para o arquivo de zona, porém este processo não acontece imediatamente após cada atualização, se não se tornaria muito lento, este update é realizado a cada 15 minutos, permitindo que atualizações adicionais ocorram.

Políticas de Updates

O BIND 9 oferece dois métodos para atualizações dinâmicas em uma zona. Podemos executar atualizações dinâmicas usando tanto allowupdate ou updatepolice.

A opção allowupdate permite atualização de qualquer registro na zona baseado apenas no endereço IP do cliente; já a opção updatepolicy, é um novo recurso do BIND 9, na qual permite um controle melhor sobre as atualizações que são executadas, onde um conjunto de políticas é especificado, e cada política permite ou nega permissões para um ou mais nomes a serem atualizados por um ou mais identificadores; tais políticas interagem apenas ás zonas master.

O Comando updatepolicy examina apenas a assinatura da mensagem; o endereço de origem é irrelevante, caso uma atualização dinâmica fosse assinada (ou seja, ela incluiria um registro TSIG ou SIG), a identidade do assinante poder ser determinada.

Se um allowupdate aparece quando um updatepolicy está presente, um erro de configuração ocorre. Forma de como é definido as políticas:

( grant | deny ) identificador tiponome nome [ tipos ]

Obviamente que cada política nega ou permite privilégios, uma vez que a mensagem combina com uma política, a operação é imediatamente permitida ou negada e nenhuma outra política será examinada, o reconhecimento da política ocorre quando o nome de um assinante combina com o campo nome, e o tipo é especificado no campo tipo. A definição das regras inclui os seguintes campos:

- grant ou deny, cite os privilégios de permissão ou negação;- identificador, cite o assinante da mensagem;- nome, cite o nome a ser atualizado;- tiponome, cite uma das seguintes opções:

- name, combine quando o nome atualizado é o mesmo do campo nome;- subdomain, coincide quando o nome atualizado é um subdomínio do nome no campo nome;- wildcard, coincide quando um nome atualizado é uma expansão válida do coringa no nome do campo nome;- self, coincide quando o nome atualizado é o mesmo do assinante da mensagem. O campo nome é ignorado.- tipo, especifica os tipos dos registros de DNS.

Se nenhum tipo é apontado, a política combina todos os tipos exceto SIG, NS, SOA, e NXT, agora você pode especificar genericamente usando o ANY, que combina com todos os tipos de registro, exceto NXT, que nunca pode ser atualizado.

NOTA: O que é TSIG?

Transaction Signatures utilizado para autenticar de maneira criptografada e verificar dados das zonas.; utiliza uma chave compartilhada, assinatura criptografada publica/secreta para autenticar autorizações em zonas de dados. O uso deste, requer que configuremos uma chave publica em seu servidor de nomes master e slave os instruindo a usar a chave para comunicação entre si, neste caso será utilizado os recursos do TSIG para garantir que as atualizações dinâmicas serão feitas a partir de nossos próprios servidores de nomes.

Principais Tipos de Registros (Resource Records) (RR)

A maioria das entradas nos arquivos de banco de dados do DNS é chamada de Resource Records. As pesquisas feitas pelo DNS ignoram se as letras são maiúsculas ou minúsculas ou misturadas. Normalmente se utilizam apenas letras minúsculas. Os RRs precisam iniciar na primeira coluna. A tabela abaixo lista os tipos principais de RRs encontrados nos arquivos de configuração do DNS:

SOAIndica a autoridade para os dados deste domínio.

NSLista os servidor de nomes, resposáveis por este domínio.

AMapeia nomes de host á para endereços IPs.

PTRMapeamento reverso, ou de endereços IPs para nomes de host.

CNAMENomes canônicos (Aliases), nomes representativos.

TXTInformações textuais.

HINFOInformações do Host.

MXInformações do Mail Exchanger.

Instalando e Configurando BIND 9 com suporte a Dynamic Updates (Linux/Windows)

Introdução

Agora, vamos implementar uma zona de domínio que poderá ser atualizada dinamicamente, o ambiente usado para a exemplificação deste estudo foi composto por um computador Pentium III 1Ghz com 512 MB RAM SDRAM PC-133, um HD de 80GB Maxtor IDE; com base nas novas distro, selecionei o Linux Fedora Core1 Kernel 2.6.2 por sua flexibilidade, robustez e segurança, e no caso do Windows, foi à versão Microsoft Windows 2000 Server, em dual boot, o hostname foi aplicado de ZEUS, em ambos os sistemas operacionais, nome ZEUS, deus grego da proteção, na qual protegia as cidades e sua própria comunidade helênica.

Os pacotes referentes ao serviço de DNS no Linux, instalados são:

- cachingnameserver7.217- bindutils9.2.3- bind9.2.3

Já o pacote de instalação do DNS no Windows, você encontra em:

- bind9.2.3.zip

Diretório base onde ficam os executáveis e arquivos de configurações: (%SystemRoot%System32dnsetc)

Criando a zona e adicionando um host

O primeiro passo foi criar uma zona de domínio (mundoerva.com.br) no BIND e adicionar um host (www.mundoerva.com.br), para podermos executar testes e ter certeza que o nosso servidor DNS estava funcionando corretamente.

Para criar a zona editamos o seguinte arquivo (/etc/named.conf), e adicionamos ao arquivo a seguinte entrada referente à zona:

zone "mundoerva.com.br" IN

{

type master;

file "named.mundoerva.com.br";

};

Criamos um arquivo contendo apenas um host para esta zona; agora no diretório (/var/named/), iremos criar um arquivo com o nome exemplo.com.br.named com o seguinte conteúdo:

$TTL 86400

@ IN SOA mundoerva.com.br. r00t.mundoerva.com.br.(

1 ; Serial

28800 ; Refresh

14400 ; Retry

3600000 ; Expire

0 ) ; Minimum

IN NS localhost.

@ IN A 127.0.0.1

www IN A 127.0.0.1

Com os procedimentos acima criamos uma zona de domínio do tipo master para o nome (mundoerva.com.br) com um host que é (www.mundoerva.com.br). Reiniciamos o servidor de nomes (/etc/init.d/named stop) e logo em seguida (/etc/init.d/named start), iremos fazer um simples teste, “pingando” o host (www.mundoerva.com.br).

$ ping www.mundoerva.com.brPING www.mundoerva.com.br.com.br (127.0.0.1) 56(84) bytes of data.64 bytes from zeus (127.0.0.1): icmp_seq=0 ttl=64 time=0.041 ms64 bytes from zeus (127.0.0.1): icmp_seq=1 ttl=64 time=0.043 ms64 bytes from zeus (127.0.0.1): icmp_seq=2 ttl=64 time=0.047 ms64 bytes from zeus (127.0.0.1): icmp_seq=3 ttl=64 time=0.039 ms

Houve resposta do host, indicando que a configuração do named estava correta. Nosso próximo passo foi criar as chaves para o TSIG.

Criado as chaves

Após criar a zona de domínio e testá-la, é necessário gerarmos ás chaves necessárias para a assinatura dessas atualizações dinâmicas. Para gerar as chaves acesse o diretório (/var/named) e geramos os pares de chaves com o comando:

#dnsseckeygen –a hmacmd5 –b 128 –n HOST zeus-key.

Logo após este comando, foram gerados os seguintes arquivos, com os respectivos conteúdos:

Kzeus-key.+157+09892.key

zeus-key. IN KEY 512 3 157 o4fKj8R8TseljForr/7v9A==

Kzeus-key.+157+09892.private

Private-key-format: v1.2

Algorithm: 157 (HMAC_MD5)

Key: o4fKj8R8TseljForr/7v9A==

Para efetuar a autenticação de nossas atualizações dinâmicas, utilizaremos o arquivo (Kzeus-key.+157+09892.private), mais no próximo passo, iremos precisar da chave gerada, que no nosso caso é: o4fKj8R8TseljForr/7v9A==

Incluindo as entradas necessárias na zona

Se chegando a este ponto com sucesso, podemos deduzir que seu serviço de DNS está devidamente configurado e as chaves de criptografia foram geradas corretamente, agora nosso próximo passo, é configurar a zona para receber atualizações dinâmicas.

Para ativar a zona, a suportar os recursos para estas atualizações, editamos o arquivo (named.conf) inserindo as entradas correspondente à chave e na zona a entrada (updatepolice)

Editamos o arquivo (/etc/named.conf), antes da definição da zona (mundoerva.com.br) inserimos a seguinte entrada, referente à chave que iremos usar, como no exemplo abaixo:

key zeuskey

{

algorithm hmacmd5;

secret "o4fKj8R8TseljForr/7v9A==";

};

E na zona, adicionamos a entrada (updatepolice), a definição da nossa zona deve ficar assim:

zone "mundoerva.com.br" IN {

type master;

file "named.mundoerva.com.br";

updatepolicy

{ grant zeuskey

subdomain mundoerva.com.br; };

};

Logo após incluir as entradas no arquivo (/etc/named.conf) é necessaário que o serviço de DNS seja reiniciado para que tais alterações passem a ser válidas, executando (/etc/init.d/named stop) e (etc/init.d/named start). Seguimos para o próximo passo; verificar as permissões dos arquivos e diretórios envolvidos no processo de atualização dinâmica.

Verificando as permissões

Este seria o penúltimo passo desta implementação, que é verificar se as permissões dos arquivos e diretórios envolvidos no processo de atualizações dinâmicas, estão com seus respectivos e corretos Owners e permissões de leitura e gravação, para a conta que executa o serviço de DNS (BIND), na grande maioria dos casos, (named).

Obviamente que a primeira permissão á ser verificada é diretório principal, onde o serviço de DNS se encontra, (/var/named):

$ ls ld /var/nameddrwxr-x--- 4 root named 4096 Fev 10 16:15 /var/named

Constatamos que o diretório só tinha permissão de escrita para a conta (root), e a conta (named) só tem permissão de leitura execução no diretório (/var/named). Observamos também as permissões dos arquivos dentro do diretório (/var/named):

$ ls l /var/named/total 32-rw------- 1 root root 61 Fev 11 10:13 Kzeus-key.+157+09892.key-rw------- 1 root root 81 Fev 11 10:13 Kzeus-key.+157+09892.private-rw-r--r-- 1 named named 195 Fev 10 16:21 localhost.zone-rw-r--r-- 1 named named 2499 Fev 10 16:21 named.ca-rw-r--r-- 1 root root 570 Fev 11 10:05 named.mundoerva.com.br-rw-r--r-- 1 named named 433 Fev 10 16:16 named.localdrwxrwx--- 2 named named 4096 Fev 11 10:06 slaves

Observe que o arquivo da zona (named.mundoerva.com.br) foi criando enquanto estávamos logado com a conta de (root) esta passa ser a dona desse arquivo e só esta conta tem permissões sobre ele.

Para o funcionamento correto das atualizações dinâmicas, a conta que executa o serviço de DNS, no nosso caso (named), deve ter permissões de leitura e escrita no diretório base do BIND (/var/named) e principalmente no arquivo da zona (named.mundoerva.com.br), então devemos setar as permissões necessárias para o diretório do BIND (/var/named):

$ chmod 770 /var/named

Logo em seguida, devemos setar o dono do arquivo da zona, da conta (root), para a conta (named), com o seguinte comando:

$ chown named.named /var/named/named.mundoerva.com.br

Tenha certeza de que os arquivos: (Kzeus-key.+157+09892.key) e

(Kzeus-key.+157+09892.private) estejam com permissão de leitura para a conta na qual vamos realizar as atualizações dinâmicas, neste caso a conta (root).

Com as permissões e proprietários devidamente setadas, vamos ao passo mais excitante de toda essa história... Os testes!!

Teste Final

Após tudo configurado e verificado vamos direto aos testes, para verificar o funcionamento das atualizações dinâmicas, em nossa zona (mundoerva.com.br) e o comportamento dos arquivos e diretórios envolvidos.

Para os testes, utilizaremos uma ferramenta que acompanha o BIND em atualizações dinâmicas, (nsupdate), execute seguindo estes parâmetros:

$ nsupdate –v –k /var/named/Kzeus-key.+157+09892.private

Ao executarmos o nsupdate, ele nos fornecerá uma interface para input de comandos, com a qual realizaremos as atualizações na zona, adicionamos um host (geek.mundoerva.com.br) á nossa zona (mundoerva.com.br):

$ nsupdate –v –k /var/named/Kzeus-key.+157+09892.private> update delete geek.mundoerva.com.br. 1 A

> update add geek.mundoerva.com.br. 1 A 127.0.0.1> send> quit

O comando acima diz ao servidor que é o responsável pelo domínio (mundoerva.com.br) para deletar o registro (A) para (geek.mundoerva.com.br), e inserir um novo registro (A) apontando para (geek.mundoerva.com.br) para o endereço IP 127.0.0.1, no caso, o número (1) é o TTL (Time To Live) para o registro (A), é obrigatório definir o valor do TTL.

Testamos se o nosso servidor de DNS esta resolvendo a nossa nova entrada na zona mundoerva.com.br:

$ ping geek.mundoerva.com.brPING geek.mundoerva.com.br (127.0.0.1) 56(84) bytes of data.64 bytes from zeus (127.0.0.1): icmp_seq=0 ttl=64 time=0.053 ms64 bytes from zeus (127.0.0.1): icmp_seq=1 ttl=64 time=0.043 ms64 bytes from zeus (127.0.0.1): icmp_seq=2 ttl=64 time=0.045 ms64 bytes from zeus (127.0.0.1): icmp_seq=3 ttl=64 time=0.044 ms

Realmente houve a resposta do novo host, isso indica que a atualização dinâmica foi realizada com sucesso.

Após o teste, listaremos o diretório (/var/named) e constatamos a presença de um novo arquivo com extensão .jnl (named.mundoerva.com.br.jnl) onde ficarão as entradas dinâmicas até o próximo (dump).

$ ls l /var/named/

total 32

-rw------- 1 root root 61 Fev 11 10:13 Kzeus-key.+157+09892.key-rw------- 1 root root 81 Fev 11 10:13 Kzeus-key.+157+09892.private-rw-r--r-- 1 named named 195 Fev 10 16:21 localhost.zone-rw-r--r-- 1 named named 2499 Fev 10 16:21 named.ca-rw-r--r-- 1 root root 570 Fev 11 10:05 named.mundoerva.com.br-rw-r--r-- 1 named named 580 Fev 12 15:57 named.mundoerva.com.br.jnl-rw-r--r-- 1 named named 433 Fev 10 16:16 named.localdrwxrwx--- 2 named named 4096 Fev 11 10:06 slaves

Com toda essa salada de comandos que seguimos acima, podemos concluir que as configuração da nossa zona de domínio (mundoerva.com.br) está preparada para receber atualizações dinâmicas, desde, que as mesmas estejam assinadas digitalmente.

Conclusão

As atualizações dinâmicas trazem nova visão para o gerenciamento de zonas de domínio, embora acrescente algum risco à integridade da zona do domínio, o uso de assinaturas digitais com criptografia forte reduz bastante este risco, ficamos então com os benefícios de não precisar de IP fixos para associar nomes de domínios. O que é de extrema utilidade na nossa atual situação onde os endereços de IP reais (acessível pela Internet) estão cada vez mais escassos por causa do protocolo IPv4. Enquanto o IPV6 não pega comercialmente, atualizações dinâmicas de nomes de domínios são uma alternativa viável.

Já nas empresas que utilizam DHCP para configurações automáticas de seus computadores,

atualizações dinâmicas podem substituir serviços como o ultrapassado WINS. Trabalhos futuros poderiam verificar o funcionamento de atualizações dinâmicas com o IPv6, também o funcionamento de atualizações dinâmicas em ambientes “chrooted” e a integração de atualizações dinâmicas e servidores DHCP.

NOTA: O que é WINS?

Windows Internet Name Services é um serviço que permite que os clientes façam o seu registro dinamicamente durante a inicialização. O cliente registra o seu nome NetBios junto com o respectivo endereço IP, com isso o WINS vai criando uma base de nomes NetBios e os respectivos endereços podendo fornecer o serviço de resolução de nomes NetBios na rede.

Referências

- Eronen, Pasi, Sars, Jonna, “Applying decentralized trust management to DNS dynamic updates”

- Internet Software Consortium, “Bind 9 Administrator Reference Manual”, 2003.

- Paul Albitz, Cricket Liu, “DNS and BIND” 4th Edition 2002 Ebook (CHM file)

- Ros Paco, “YADDA (Yet Another Dybanic DNS Aticle)”

http://bulma.net/body.phtml?nIdNoticia=1078

- Ralph Droms, “Resources for DHCP”.

http://www.dhcp.org

- Júlio Battisti, “Uma introdução ao DNS”.

http://www.juliobattisti.com.br

- Internet Systems Consortium, Inc.

http://isc.org

Renato Ricardo de AbreuEspecialista em Redes de computadoreshttp://www.linuxmen.com.br/lkb_arq.php?cID=26