Sistemas de Informação Distribuídos/Infraestrutura/Serviços de Nomes

Usos

O uso mais básico de DNS é traduzir hostnames em endereços IP (como uma lista telefônica). Ou seja, é um sistema de localização de máquinas independente da sua localização física, totalmente transparente.

O DNS torna possível nomear destinos na Internet de forma compreensível para as pessoas, independentemente da hierarquia de roteamento física representada pelo endereço IP numérico. Por causa disto, hiperlinks e informações na internet podem permanecer o mesmo, qualquer que seja o arranjo de roteamente atual.

O DNS também distribui a responsabilidade de registro de domínios e o respectivo mapeamento deste ao seu endereço IP, deixando que um servidor autorizado a cada domínio se responsabilize pela validade dos dados modificados. Evitando a necessidade de um servidor central.

História

O nascimento do DNS como existe hoje foi pela constatação, por volta de 1982 na antiga ARPANet, de que o atual sistema HOST.TXT que fazia o mapeamento de máquinas a endereços de rede tinha um sério problema de escalabilidade e distribuição.

O HOST.TXT consiste em apenas um arquivo texto mantido e atualizado de forma centralizada em uma máquina específica no SRI Network Information Center (SRI-NIC), que distribuía o arquivo quando atualizado às demais máquinas da rede de forma direta ou indireta.

E com o crescimento do número de máquinas na rede os custos de distribuição desde arquivo (que ia crescendo) estava se tornando caro em demasia; e o sistema centralizado de administração deste não combinava com a forma distribuída que era a alma da Internet. E este problema se tornou especialmente incômodo quando com a evolução dos sistemas que usavam o NCP-ARPANET para o protocolo TCP/IP; pois neste momento a rede ARPANET deixou de ser uma rede com várias máquinas de tempo compartilhado para ser apenas um dos backbones da nova rede, a Internet. Dessa forma o número de máquinas endereçáveis pulou de apenas algumas destas máquinas de tempo compartilhado para o número de estações de trabalho (e até de usuários). E esse crescimento se refletiu no tamanho, no número de atualizações e transferências do antigo HOSTS.TXT.

Na busca por um sistema de nomes distribuído, foram analisados na época três sistemas já existentes: DARPA Internet IEN116, Xerox Grapevine e Clearinghouse System. O primeiro era, a princípio, muito limitado e era extremamente dependente de hardware; assim não apresentava benefícios suficientes que justificassem os custos de migração para este. O segundo era o sistema de nomes mais sofisticado de serviço de nomes; contudo, não estava claro se o seu grande uso de replicação e pouco uso de caching e número fixo de níveis de hierarquia eram apropriados à heterogeneidade da DARPA Internet. E por último e mais importante, o uso deste sistema implicaria na adoção de alguns elementos específicos dos seus protocolos.

Assim foi dada a necessidade um novo design para o DNS, cujas primeiras especificações foram dados no RFC 882 e RFC 883.

Arquitetura do DNS

Os princípios básicos para o novo sistema era:

• Fornecer pelo menos as mesmas informações que o antigo sistema.
• Que o banco de dados de ip’s fosse distribuído.
• Não ter nenhuma limitação simplista dos dados.
• Ser interoperável entre a DARPA Internet e tantos outros sistemas quanto possível.
• Ter uma boa performance.
• Custo de implementação que justificasse o desenvolvimento.
• Ser universalmente compatível quanto a arquitetura de hardware e software.

O DNS tem 2 componentes principais: o servidor de nomes e o resolver; o primeiro é um repositório de dados e o segundo faz a interface com os programas clientes e é a parte que contem todo o algoritmo para encontrar o servidor de nomes que tem os dados que o cliente está procurando.

Espaço de Nomes

É uma variável de profundidade onde cada nó na hierarquia tem um nome associado a ele. Exemplo o hostname en.wikipedia.org. A RFC 920 definiu que os DNS mais altos corresponderiam a países (BR, UK, etc) ou organizações de fins definidos EDU para educação, MIL para militar, etc.

Distribuição do Banco de Dados

A forma como o DNS repassa os dados do DNS mais alto até o cliente usam duas técnicas em especial: caching e zonas. As zonas são partes da hierarquia do DNS que são controladas por uma organização; e esta se torna responsável por manter copias desta em vários servidores. E o cachê é usado para armazenar resultados de um cliente em que foi necessário consultar servidores externos; dessa forma aproveita-se o resultado em futuras consultas.

Berkeley

O suporte ao UNIX foi desenvolvido pela Universidade Berkeley, na Califórnia, em parte como uma pesquisa em sistemas distribuídos e por outro lado numa necessidade da própria instituição em aumentar a rede do campus. O resultado dessa pesquisa foi o BIND (Berkeley Internet Name Domain, e mais tarde Berkeley Internet Name Daemon). Com o BIND, Berkeley foi a primeira organização a colocar todas as suas máquinas totalmente dependentes do novo sistema DNS (isso em 1985).

Surpresas

Semântica

O problema aqui foi ter o DNS apenas como um repositório para informação e assim assumiu-se que os dados estavam bem definidos neste; mas sabia-se que uma máquina poderia ter mais de um IP; mas como esses endereços deveriam ser ordenados?

Performance

Na prática a performance do sistema foi muito pior do que se previa. O crescimento das redes acabou gerando problemas nos gateways o que gerou caminhos inválidos e caminhos unidirecionais. Estes problemas foram percebidos principalmente nos servidores raiz, onde haviam, nos logs, muitas instâncias de mesmas querys do mesmo cliente. Para se ter uma idéia do problema, consultas da ARPANET a domínios delegados levavam de 3 a 10 segundos na primeira consulta, e 30 a 60 segundos nas consultas seguintes, no pior caso. Mas ainda assim a mudança para o novo sistema se justificava só pela flexibilidade administrativa que proporcionava.

Cache Negativo

O DNS retorna dois casos de resposta negativa: um diz que o nome não existe, o outro diz que apesar de o nome existir, o dado requisitado não. O primeiro é esperado quando ocorre um erro de digitação, e o segundo quando se consulta o tipo de host de uma caixa de e-mail. Estes casos falsos eram esperados para serem raros, mas o monitoramento inicial do sistema mostrou uma porcentagem de 20% a 60% destas respostas. Os logs mostraram, contudo que a maioria destas consultas eram geradas por aplicativos que ainda usavam o sistema antigo de hostname. Este caso foi deixado inicialmente como um recurso opcional a ser desenvolvido posteriormente.

O DNS Hoje

O DNS desde então sofreu muitas melhorias, principalmente no que diz respeito a tolerância a falhas e segurança. Abaixo segue a lista das RFC's (Request for Comments, do inglês) pelas quais o DNS passou ao longo do tempo até hoje:

• RFC 882 Concepts and Facilities (Deprecated by RFC 1034)
• RFC 883 Domain Names: Implementation specification (Deprecated by RFC 1035)
• RFC 1032 Domain administrators guide
• RFC 1033 Domain administrators operations guide
• RFC 1034 Domain Names - Concepts and Facilities
• RFC 1035 Domain Names - Implementation and Specification
• RFC 1101 DNS Encodings of Network Names and Other Types
• RFC 1123 Requirements for Internet Hosts -- Application and Support
• RFC 1183 New DNS RR Definitions
• RFC 1706 DNS NSAP Resource Records
• RFC 1876 Location Information in the DNS (LOC)
• RFC 1886 DNS Extensions to support IP version 6
• RFC 1912 Common DNS Operational and Configuration Errors
• RFC 1995 Incremental Zone Transfer in DNS
• RFC 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
• RFC 2136 Dynamic Updates in the domain name system (DNS UPDATE)
• RFC 2181 Clarifications to the DNS Specification
• RFC 2182 Selection and Operation of Secondary DNS Servers
• RFC 2308 Negative Caching of DNS Queries (DNS NCACHE)
• RFC 2317 Classless IN-ADDR.ARPA delegation
• RFC 2671 Extension Mechanisms for DNS (EDNS0)
• RFC 2672 Non-Terminal DNS Name Redirection (DNAME record)
• RFC 2782 A DNS RR for specifying the location of services (DNS SRV)
• RFC 2845 Secret Key Transaction Authentication for DNS (TSIG)
• RFC 2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering
• RFC 3403 Dynamic Delegation Discovery System (DDDS) (NAPTR records)
• RFC 3696 Application Techniques for Checking and Transformation of Names
• RFC 4398 Storing Certificates in the Domain Name System
• RFC 4408 Sender Policy Framework (SPF) (SPF records)

Como funciona

Teoria

O espaço de nomes do domínio consiste em uma árvore de nomes. Cada nó tem um ou mais registros de recursos, que tem informações sobre o domínio. A árvore é subdividida em zonas, sendo esta um conjunto de nós que são servidos por um DNS superior. Quando um administrador quer delegar parte de seu domínio a outro administrador, ele usa este recurso de zonas para tal. O resolver procura as informações associadas aos nós; este sabe como se comunicar com os servidores (requisições DNS). Esse processo se trata de iterar consultas através de vários servidores de nomes até conseguir toda a informação desejada. Exemplo: ii.ufrgs.br; BR é o domínio raiz, ii.ufrgs.br é um hostname (tem um ou mais endereços IP associados).

Hierarquia no DNS.

Sistema de Resolução de Nomes

Para consultas, o sistema olha parte a parte do hostname (da direita pra esquerda). A cada passo o programa pergunta ao servidor DNS correspondente àquele nível para ter o endereço do próximo DNS a ser consultado.

Resolução do endereço www.wikipedia.org.

• O sistema local é pré-configurado com os endereço dos servidores raiz num arquivo de “roo-hints”, o qual precisa ser atualizado com alguma freqüência pelo administrador local para manter o sistema funcional caso tenham havido mudanças na árvore.
• Consulta um dos servidores raiz para descobrir o caminho para o servidor do nível abaixo.
• Consultando o segundo servidor pelo endereço do DNS com todos os dados do domínio seguinte.
• E o passo anterior é repetido até que ao invés de se obter o endereço do DNS seguinte, se obtenha o endereço final da máquina procurada.

Mundo Real

A cada consulta que uma aplicação faz, ela não executa todos os passos mencionados no item anterior.

Resolução no mundo real.

Por causa do enorme tráfego gerado por sistema como o DNS, principalmente nos servidores mais altos na hierarquia foi usado um sistema de cache. Assim, por um período de tempo (gerenciado pelo administrador) as respostas do DNS ficam armazenadas como válidas. Dessa forma antes de consultar um servidor DNS máquina irá buscar no cachê da máquina se já não existe um registro para esta busca ou pelo menos para parte dela. Usuários não se comunicam diretamente com o DNS resolver. A resolução de nomes se dá de forma transparente nas aplicações. Quando numa requisição se faz necessário consultar um DNS, a aplicação requisita o DNS resolver local do Sistema Operacional. O sistema DNS usa TCP e UDP na porta 53 para servir requisições. Quase todas as requisições DNS consitem em um pacote UDP, e é respondida ao cliente também através de outro pacote UDP. TCP só é usado quando a resposta excede 512 bytes, ou para tarefas específicas como transferências de zonas.