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
smtp-
10.5.3.5
gw.mundoerva.com.br
gw-
192.168.1.161
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:

SOA
Indica a autoridade para os dados deste domínio.

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

A
Mapeia nomes de host á para endereços IPs.

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

CNAME
Nomes canônicos (Aliases), nomes representativos.

TXT
Informações textuais.

HINFO
Informações do Host.

MX
Informaçõ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.br
PING 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 ms
64 bytes from zeus (127.0.0.1): icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from zeus (127.0.0.1): icmp_seq=2 ttl=64 time=0.047 ms
64 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/named
drwxr-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.local
drwxrwx--- 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.br
PING 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 ms
64 bytes from zeus (127.0.0.1): icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from zeus (127.0.0.1): icmp_seq=2 ttl=64 time=0.045 ms
64 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.local
drwxrwx--- 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 Abreu
Especialista em Redes de computadores
http://www.linuxmen.com.br/lkb_arq.php?cID=26