Depois desse breve resumo, serão abordadas duas extensões do DNS: A transferência de zona incremental e DNS NOTIFY que foram modificações sugeridas, através do RFC, para o padrão DNS.
II - Introdução
Antes de começar a falar de algumas extensões do DNS é interessante fazer um pequeno resumo do que é DNS, qual a sua finalidade e como ele funciona.
O Domain Name System (DNS) é uma banco de dados de informações sobre os computadores (hosts) de uma internet. Esse banco de dados tem a característica de ser distribuído.
Como a suite de protocolo TCP/IP é baseada nos endereços IP e esses endereços são mais difíceis de serem memorizados, utiliza-se o DNS para mapear os nomes dos computadores (hosts) em endereços IP. Essa é a principal, mas não única função do DNS. O DNS mantém também informações sobre o roteamento de mails, além de conter uma série de informações sobre os hosts da rede.
Quando uma aplicação ou usuário faz uma referência a um nome de um computador, é enviada uma mensagem para o DNS que, por sua vez, retorna o endereço IP daquela máquina e como esse endereço é que a comunicação se realiza.
Quando uma rede é pequena o mapeamento de nome de hosts e endereço IP é feito através do arquivo do UNIX /etc/hosts. Esse arquivo começou a ficar muito grande com a ampliação na rede da empresa e inviável a sua manutenção com o aparecimento da Internet, onde os principais problemas relacionados eram: a quantidade de linhas do arquivo /etc/hosts era muito grande, a atualização era lenta e trabalhosa, pois cada hosts tinha que ter uma cópia desse arquivo e não é possível ter um arquivo com o nome de todos os hosts da Internet em um único lugar.
A solução para esses problemas foi proposta por Paul Mockapetris em 1983 e vem sendo estendida até hoje, essa proposta foi chamada de Domain Name System (DNS).
III - A estrutura do banco de dados do DNS
A estrutura do banco de dados do DNS é muito semelhante a estrutura do sistemas de arquivos do UNIX, uma árvore no sentido contrário, a raiz em cima e as folhas embaixo. A diferença é que no UNIX o nome completo do caminho é feito de cima para baixo e a raiz é o " / " e no DNS o nome dos hosts é definido de baixo para cima e a raiz é o caracter " . ".
Ex:
Nome do caminho no UNIX: /usr/local/etc
Nome do host: sol.unitnet.com.br.
Caso o nome termine com um ponto no final a referência àquele nome é absoluta, se não terminar aquela referência é relativa a uma outro domínio que contêm a raiz.
IV - Domínios
Um domínio é simplesmente uma sub-árvore do DNS. Todos os nomes que pertencem a essa sub-árvore fazem parte desse domínio. Cada domínio é responsável por manter e atualizar o banco de dados relativo a sua sub-árvore.
Cada servidor de DNS do domínio é responsável pelas informações relativas a uma zona, que são divisões lógicas do domínio. Uma zona não pode intervir em outra.
V - Componentes do DNS
O DNS é composto basicamente de dois componentes: O cliente e o servidor. O servidor é um daemon chamado servidor de nomes que é responsável por responder as perguntas feitas ao DNS e o cliente é uma biblioteca de rotinas, chamadas resolvers, responsável por enviar as mensagens (perguntas) para o DNS. As aplicações utilizam essas rotinas para fazer qualquer tipo de pergunta ao DNS.
VI - Tipos de Servidores de Nomes
No DNS existem, basicamente, dois tipos de servidores de nomes: o servidor primário e o servidor secundário.
Em cada zona tem que existir um servidor primário e um ou vários servidores secundários, que contêm as informações dos hosts daquela zona.
No servidor primário é onde fica localizado o banco de dados na zona e cada servidor secundário contém uma cópia desse banco de dados. Caso o servidor principal fique inoperante por algum tempo, o servidor secundário fica substituindo, na resolução dos nomes, até que o servidor volte a funcionar perfeitamente.
A atualização do banco de dados é feita no servidor primário e atualizada periodicamente para os servidores secundários. Esse processo será descrito mais adiante pois é ponto principal das extensões que se encontram nesse trabalho.
Poderíamos também dizer que existe o servidor caching-only que é apenas um servidor que guarda uma cache, em memória, dos últimos nomes que foram resolvidos. Ele somente guarda os nomes válidos.
VII - Como o DNS trabalha
Quando uma aplicação ou o usuário quer fazer uma referência a uma host da rede ele invoca as funções do resolver para fazer a pergunta ao servidor. A primeira pergunta é feita ao servidor da rede local. Se o servidor não souber responder, o servidor faz a mesma pergunta para os servidores roots da Internet, esses servidores são servidores especiais que conhecem o host procurado ou pelo menos outro servidor que saiba onde se encontra aquele host.
Existe uma características nesses servidores que devem ser observadas: eles podem ser servidores recursivos ou não. Um servidor recursivo é aquele que só informa a resposta quando ela é uma referência exata ou quando um erro ocorre. Ele assume a responsabilidade de repassar a pergunta para vários servidores de nomes. Os servidores não recursivos, como é o caso dos servidores roots, eles respondem apenas a referência exata, se ele souber, ou informam uma referência a outro servidor de nomes. Ele jamais repassa a pergunta para outro servidor de nome. A resposta vai para que perguntou e aí sim a pergunta é refeita, caso seja necessário.
Legenda:
1 - Servidor de nomes A recebe uma pergunta de um resolver
2 - Servidor A (recursivo) não sabe responder a pergunta para o resolver e por ser recursivo ele fica com a responsabilidade de responder ao resolver. O segundo servidor a ser perguntado é o servidor root B. Servidor A faz uma pergunta a B.
3 - B não é um servidor recursivo e como ele não conhece a resposta exata, ele responde com uma referência a outro servidor
4 - A pergunta a C
5 - C responde com uma referência para o servidor D
6 - A pergunta a D
7 - Aquela pergunta faz parte do banco de dados de D e D responde com uma referência exata.
8 - A retorna a resposta para o resolver.
VIII - Tipo de Dados do DNS
O formato básico do banco de dados do DNS obedece ao seguinte padrão:
[nome] [ttl] [classe] tipo dados
OBS: Os campos entre colchetes são opcionais.
O campo nome deve começar na coluna um e identifica o host ou o domínio.
A ttl especifica o tempo, em segundos, que a informação pode ficar na cache e permanecer válida.
A classe especifica o tipo de rede. Normalmente usamos IN (Internet).
O campo tipo pode ser:
SOA - marca o começo na zona e a autoriza sobre ela
NS - identifica servidores de nomes para a zona
A - traduz de nome para endereço (IP)
PTR - traduz de endereço (IP) para nome
MX - controla roteamento de e-mails
CNAME - apelido para os hosts
HINFO - informa sobre sist. operacional e hardware do hosts
WKS - serviços fornecidos pelo host
TXT - comentários ou informações que sem tipo.
O campo dado são as informações, propriamente ditas, que se quer armazenar.
Existe diversos novos tipos que estão sendo propostos, como experimentais, no RFC 1183. Poderíamos citar:
ISDN - representa do endereço ISDN no DNS
X25 - representa do endereço X25 no DNS
RT - indica o roteamento necessário para encontrar um host ou domínio via ISDN ou X.25
RP - contado técnico para o hardware
IX - Atualização de Dados (transferência de zona)
Quando uma atualização é necessária no banco de dados do DNS, ela deve ser feita no servidor primário. Posteriormente os servidores secundários são atualizados. Nos dados do registro tipo SOA existe duas informações importantes nessa atualização: o campo serial number e o campo refresh.
Todas as vezes que o banco de dados for atualizado o campo serial number deve ser incrementado. Essa é a maneira que o servidor secundário sabe que está com informação desatualizada, comparando o serial number seu com o do servidor primário.
O campo refresh indica o número de segundos depois que os servidores secundários devem estar atualizados. Quando expira esse tempo, todo o banco de dados é transferido para os servidores secundários. Esse processo é conhecido como transferência de zona.
Com isso finalizamos o resumo sobre DNS e nos situamos no contexto das extensões que são pretendidas.
X - Extensões
As principais e últimas extensões do DNS se concentraram na área de transferência de zona, sendo publicadas duas RFC (1995 e 1996) em agosto de 1996.
Esses documentos estavam preocupados, principalmente, com o problema encontrado no DNS relacionado com a transferência de zona.
As Extensões apresentadas serão:
a) Transferência de Zona Incremental
b) DNS Notify
XI - Transferência de Zona Incremental
No RFC 1035 foi proposta uma mudança do DNS original para permitir que a transferência de zona pudesse ser incremental e não total como hoje é feito.
A transferência de zona incremental (IXFR) diminuiria o esforço envolvido para enviar todo o banco de dados para os servidores secundários, quando uma mudança ocorresse no servidor principal.
Muitas vezes essa modificação é muito pequena e ao invés de enviar todo o banco de dados, somente as modificações seriam enviadas. Esse é um mecanismo bem mais eficiente que o anterior.
Descrição do Protocolo
Nesse trabalho quando servidor secundário faz um pedido de IXFR ele passa a ser chamado de cliente IXFR e quando um servidor primário ou secundário responde a um pedido, é chamado de servidor IXFR.
Quando é necessária uma transferência de zona, verificada através do conteúdo do campo refresh ou , como veremos depois, através de uma mecanismo de notify, o cliente envia uma mensagem IXFR, contendo o serial number no seu registro SOA.
O servidor mantém a versão mais atualizada da zona e as diferenças entre as copias mais antigas. Quando a mensagem chega ao servidor os serial numbes são comparados. Se a versão do cliente IXFR for a mesma do servidor IXFR nada é transferido, mas se for menor, somente as diferenças das versões são enviadas. O Servidor pode optar também por fazer a transferência de zona completa (AXFR), dependendo o número de modificações da versão.
A versão antiga do cliente é armazenada durante a transmissão, pois se ocorrer qualquer problema antes do termino da operação, a versão antiga é restaurada, para evitar inconsistências.
O protocolo de transporte utilizado nessas mensagens é o UDP ou TCP. Se uma mensagem é enviada via UDP a resposta deve ser enviada via UPD, caso possa ser enviada em uma única mensagem. Se isso não for possível, uma mensagem é enviada para o cliente para que o mesmo envie uma mensagem TCP. Por questões de segurança o checksum do UPD deve ser verificado sempre e o servidor deve solicitar uma mensagem TCP sempre que o campo checksum estiver zerado.
Se o servidor não souber responder a uma mensagem IXFR, uma transferência AXFR é realizada para manter a compatibilidade como versões antigas.
O formado da pergunta IXFR é o mesmo de uma mensagem normal do DNS, com o tipo da pergunta IXFR e a seção de autoridade contendo o serial number do SOA do cliente.
Na resposta, se o transferência incremental não estiver disponível, todos os registros são transferidos com o SOA no início e fim da mensagem.
Na resposta, com a transferência incremental, somente as diferenças entre as versões são retornadas. As diferenças consistem de registros excluídos e adicionados (uma alteração é feita através de uma remoção e uma adição). A primeira RR de um registro deletado é a SOA antiga e a primeira RR de um registro adicionado é a SOA nova.
A seqüência de atualização é feita da mais antiga para a mais nova.
Existe uma questão importante nesse ponto: o servidor deve guardar até quando as diversas versões do banco de dados? A resposta é até quando as diferenças não superem o tamanho da mensagem enviando o banco de dados todo
Opcionalmente, uma condensação pode ser feita entre múltiplas versões (múltiplas diferenças entre versões serem condensadas em uma única diferença). Em alguns casos isso é benéfico e em outros não. Um caso que as diferenças originais entre as versões são necessárias é quando um cliente IXFR acessa dois servidores IXFR A e B, com resultados inconsistentes de condensação. A corrente versão do cliente IXFR, recebida do servidor A, pode ser desconhecida para o servidor B. Neste caso, o servidor B pode não fornecer uma transferência incremental e uma versão desconhecida e uma transferência de zona completa é necessária.
Exemplo (RFC 1035)
Dados três gerações de dados com o corrente serial number 3
| JAIN.AD.JP. | IN SOA NS.JAIN.AD.JP. (1 600 600 3600000 604800) |
| IN NS NS.JAIN.AD.JP. | |
| NS.JAIN.AD.JP. | IN A 133.69.136.1 |
| NEZU.JAIN.AD.JP. | IN A 133.69.136.5 |
NEZU.JAIN.AD.JP. é removida e JAIN-BB.JAIN.AD.JP. é adicionada.
| JAIN.AD.JP. | IN SOA NS.JAIN.AD.JP. (2 600 600 3600000 604800) |
| IN NS NS.JAIN.AD.JP. | |
| NS.JAIN.AD.JP. | IN A 133.69.136.1 |
| JAIN-BB.JAIN.AD.JP. | IN A 133.69.136.4 |
| IN A 192.41.197.2 |
Um endereço IP de JAIN-BB.JAIN.AD.JP. é modificado
| JAIN.AD.JP. | IN SOA NS.JAIN.AD.JP (3 600 600 3600000 604800). |
| IN NS NS.JAIN.AD.JP. | |
| NS.JAIN.AD.JP. | IN A 133.69.136.1 |
| JAIN-BB.JAIN.AD.JP. | IN A 133.69.136.3 |
| IN A 192.41.197.2 |
A pergunta IXFR é:
| Cabeçalho | OPCODE=SQUERY |
| Pergunta | QNAME= JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
| Resposta | < VAZIO> |
| Autoridade | JAIN.AD.JP. IN SOA serial=1 |
| Adicional | < VAZIO> |
Uma resposta usando transferência de zona completa seria:
| Cabeçalho | OPCODE=SQUERY, RESPONSE |
| Pergunta | QNAME= JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
| Resposta | JAIN.AD.JP. IN SOA serial=3
JAIN.AD.JP. IN SOA serial=3 NS.JAIN.AD.JP. IN A 133.69.136.1 JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 JAIN.AD.JP. IN SOA serial=3 |
| Autoridade | < VAZIO> |
| Adicional | < VAZIO> |
Uma resposta usando transferência de zona incremental seria:
| Cabeçalho | OPCODE=SQUERY, RESPONSE |
| Pergunta | QNAME= JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
| Resposta | JAIN.AD.JP. IN SOA serial=3
JAIN.AD.JP. IN SOA serial=1 NEZU.JAIN.AD.JP. IN A 133.69.136.5 JAIN.AD.JP. IN SOA serial=2 JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 JAIN.AD.JP. IN SOA serial=2 JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 JAIN.AD.JP. IN SOA serial=3 JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 JAIN.AD.JP. IN SOA serial=3 |
| Autoridade | < VAZIO> |
| Adiciona | < VAZIO> |
A resposta com transferência de zona incremental condensada seria:
| Cabeçalho | OPCODE=SQUERY, RESPONSE |
| Pergunta | QNAME= JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
| Resposta | JAIN.AD.JP. IN SOA serial=3
JAIN.AD.JP. IN SOA serial=1 NEZU.JAIN.AD.JP. IN A 133.69.136.5 JAIN.AD.JP. IN SOA serial=3 JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 JAIN.AD.JP. IN SOA serial=3 |
| Autoridade | < VAZIO> |
| Adicional | < VAZIO> |
|XII - DNS Notify
O DNS Notify é um mecanismo em que o servidor, dito primário (master), avisa aos servidores secundários (slaves) que uma atualização do banco de dados do DNS ocorreu e uma atualização é necessária, mesmo antes do tempo de campo refresh do registro SOA expirar.
O DNS Notify tenta diminuir o problema da inconsistência do bando de dados entre o master o os slaves sem causar uma sobrecarga no master.
O problema da inconsistência dos servidores secundários por um certo período pode ser amenizado diminuindo-se o tempo do campo refresh, mas isso causa uma sobrecarga no master pois, constantemente, isso tem que ser comparado para verificar se houve ou não uma mudança de versão.
Quando o servidor master é atualizado é enviado uma mensagem para todos os servidores slaves que têm interesse nessa modificação. Essa mensagem usa o mesmo formato das outras mensagens do DNS com alguns campos zerados.
Quando a resposta do slave é enviada o master retira aquele slave da fila que será notificada. Se uma resposta demorar um determinado período de tempo para chegar, uma nova mensagem é enviada.
Assim que uma mensagem é chegada no slave ele inicia o processo de transferência de zona IXFR ou AXFR.
O protocolo de transporte usado é o UDP, a menos que o master exija TCP, por exemplo, se um firewall estiver sido instalado entre o master e o slave e somente o TCP é o único protocolo permitido ou a mensagem for muito grande para caber no datagrama UDP.
XIII - Conclusão
Esse trabalho mostrou algumas extensões do DNS principalmente na área de transferência de zona, sempre se preocupando com as seguintes questões: cópias desatualizadas por um certo período, sobrecarga do servidor para realizar consultas desnecessárias de serial numbers que não estão desatualizados e principalmente a quantidade de informações que estão trafegando na rede para atualizar os servidores secundários.
Esses esforços mostram como a comunidade da Internet está preocupada com o DNS, propondo modificações nos seus padrões para tornar os recursos mais bem aproveitados e eficientes.
Alguns estudos ainda têm que ser feitos com o objetivo de se avaliar e melhorar a carga que as consultas ao DNS provocam na Internet. Praticamente qualquer que seja a aplicação, voltada para a Internet, antes de iniciar a comunicação origem - destino, algumas consultas são feitas ao DNS provocando assim um tráfego significante na Internet.
O DNS foi uma maneira encontrada para resolver o problema da tradução de nomes em endereço IP, mas pode ser que surja uma maneira mais eficiente de realizar essa conversão provocando menos tráfego na rede.
XIV - Bibliografia
Ohta, M., Incremental Zone Transfer", RFC 1995, Agosto 1996
Vixie, P., "A Mechanism for Promp Notification of Zone Changes (DNS NOTIFY), RFC 1996, Agosto 1996
Everhart, C. E outros, New DNS RR Definitions, RFC 1183, Outubro de 1990.
Albitz, Paul e Liu, Cricket. DNS and BIND in a Nutshell. O'Reilly & Associates. 1992. USA
Nemety, Evi e outros. Unix System Administration Handbook. 2nd edition. Prentice Hall, Inc. 1995. USA
Notas de aula do curso de Administração de Sistemas Distribuídos - 1996/2