DNS: Domain Name System

DNS: Domain Name System O objetivo desta unidade é apresentar o funcionamento de dois importantes serviços de rede: o DNS e o DHCP. O DNS (Domain Name System) é o serviço de nomes usado na Internet. Esse mecanismo, permite que servidores da Internet sejam localizados utilizando nomes (denominados FQDN - Fully Qualified Domain Names) ao invés de endereços IP. O DHCP (Dynamic Host Configuration Protocol) é o serviço de atribuição automática de endereços e outras configurações essenciais para o funcionamento das redes IP. Os exemplos dessa unidade são baseados na implementação desses serviços para o ambiente Linux, e devem ser usados como referência na execução das atividades práticas. 1

Serviço DNS: Domain Name System nome - ip nome - ip Nome? IP nome - ip nome - ip Um serviço de nomes é mecanismo que permite mapear nomes amigáveis a endereços para facilitar a identificação dos computadores em redes IP. Existem basicamente dois modelos para serviços de nomes: nomes planos e nomes hierárquicos. Um modelo de nomes planos muito difundido é o padrão de nomes NetBIOS. Os nomes NetBIOS são muito comuns nas redes Microsoft. Eles correspondem ao nome do computador fornecido na instalação do sistema operacional, e visualizados no ambiente de rede do Windows Explorer. Esse modelo é dito plano pois cada nome tem um significado independente. Por exemplo, olhando o nome NetBIOS de um computador, não é possível dizer a qual empresa ou a qual país ele pertence. Como os nomes planos podem ser escolhidos livremente, é muito difícil evitar nomes duplicados. Isso torna o seu uso em redes grandes e de administração decentralizada como a Internet totalmente proibitivo. O modelo de nomes hierárquicos é mais apropriado para redes de grande porte. Dois exemplos de modelos hierárquicos são o X500 e o DNS (Domain Name System). Nesse modelos, o nome é formado por múltiplas partes, que além do nome do computador propriamente dito, identificam a localização e a empresa ao qual o computador pertence. O X500 é um modelo mais genérico que o DNS, pois permite associar nomes a qualquer tipo de objeto, e não apenas endereços IP. O DNS é específico para endereços. Os modelos de nomes hierárquicos podem ser implementados de forma distribuída. Como ilustrado na figura, os nomes podem ser armazenados em múltiplos servidores, cada um contendo apenas uma parte do banco de dados que mapeia nomes em endereços. Nesses sistemas, um cliente pode consultar qualquer servidor de nomes da rede, e ter acesso aos nomes armazenados em todos os servidores. É justamente esse mecanismo que provê o desempenho suficiente para o DNS ser implantado na Internet. O DNS é um padrão aberto especificado em vários documentos do IETF, como as RFCs 1033, 1034, 1034, 1101, 1123, 1183 e 1536. Sua implementação original, contudo, foi desenvolvida na Berkley University para a versão 4.3 SD Unix. Por isso, até hoje, nos sistemas Unix, a implementaçã do DNS é denominada BIND (Berkeley Internet Name Domain) 2

Árvore de nomes br RAIZ br pucpr ufpr Pucpr Ufpr ppgia eureka FOLHA Os nomes hierárquicos utilizados pelo DNS são chamados FQDN: Fully Qualified Domain Name. Um FQDN é formado por várias nomes separados por pontos. Cada um desses nomes pode ser um nome de host ou um nome de domínio. Um domínio representa uma coleção de hosts ou uma coleção de outros domínios. Um nome de host identifica um computador apenas dentro de um domínio específico. O FQDN identifica um computador de forma única em toda a Internet. Por exemplo,.pucpr.br é um FQDN. Seus componentes são definidos seguinte forma: : nome do host, pucpr: nome de domínio e br: nome de domínio. O domínio br é uma coleção de todos os domínios que estão no Brasil, e inclui o domínio pucpr. O domínio pucpr é uma coleção de todos os hosts que estão na PUCPR, e inclui o host. Os nomes hierárquicos são comumente representos como uma árvore, conforme mostrado na figura. Nessas árvore os nomes de host correspondem sempre as folhas, e são os únicos elementos mapeados a endereços IP. Observe no desenho, que o nome de host não identifica um computador de forma global. Por exemplo, podemos ter o host no domínio ufpr ou no domínio pucpr. Todavia, o FQDN garante que o nome seja único. Esse mecanismo permite a administração descentralizada dos nomes na Internet, pois a única preocupação do administrador é evitar que um nome seja duplicado em seu domínio mais próximo. Observação: O FQDN pode ser combinado com outras informações para criar outro tipo de nome denominado Localizador Universal de Recursos ou URL (Universal Resource Locator). O formato geral de uma URL é protocolo:://fqdn/nome_arquivo. Por exemplo, http://espec.ppgia.pucpr.br/cronograma_pos.pdf. 3

ZONAS DNS ZONA.br br RAIZ servidor A.dns.br ZONA pucpr.br ZONA ufpr.br pucpr ufpr servidor alpha.pucpr.br ppgia servidor ns.ufpr.br Uma árvore de nomes DNS é dividida em zonas. Essa divisão permite que os nomes sejam armazenados em vários servidores DNS, segundo o conceito de banco de dados distribuídos. Uma zona DNS é uma porção da árvore de nomes que está armazenada em um servidor específico. O exemplo da figura mostra uma parte da árvore de nomes global da Internet. Apenas para efeito de ilustração, vamos assumir que esta porção da árvore está dividida em três zonas: pucpr.br, ufpr.br e br. A zona pucpr.br contém os nomes correspondentes aos computadores da PUCPR. Observe que os conceitos de zona e domínio são distintos. Uma zona corresponde sempre a um domínio, mas o contrário nem sempre é verdade. Uma zona pode conter uma hierarquia de domínios, e seu nome corresponde apenas ao domínio de nível mais elevado. Por exemplo, ppgia é um domínio dentro da pucpr, mas não corresponde a uma zona. Isto significa que as informações sobre os computadores pertencentes ao domínio pucpr e ao domínio ppgia estão armazenados na mesma zona. Observe que o domínio br contém os domínios pucpr e ufpr, mas sua zona não armazena os nomes dos computadores dessas zonas. Como veremos, o domínio br contém apenas ponteiros para os servidores de DNS das zonas que estão hierarquicamente abaixo de seu domínio. Quando o administrador da zona br cria um ponteiro para o servidor de nomes da PUCPR, ele está delegando o direito da PUCPR criar qualquer nome que termine com pucpr.br. Assim, o administrador da PUCPR pode criar nomes em seu servidor, sem consultar o administrador do domínio br. O mesmo acontece quando é criado um ponteiro para o servidor de nomes da UFPR. O formato desses ponteiros será discutido a seguir. 4

Arquivo de ZONA ZONA pucpr.br $TTL 1D pucpr.br. IN SOA alpha.pucpr.br. [...] IN NS alpha.pucpr.br. IN NS beta.pupcr.br. IN MX 10 smtp.pucpr.br. IN MX 20 smtp2.pupcr.br. alpha IN A 200.17.99.2 beta.pucpr.br. IN A 200.17.99.3 dns IN CNAME alpha IN A 200.192.112.141 smpt1 IN A 200.192.112.20 smpt1 IN A 200.192.112.21 Na implementação do BIND para UNIX, as zonas são representados na forma de arquivos. Um arquivo de zona contém uma coleção de registros (records) que seguem a seguinte sintaxe: nome do registro [TTL] IN tipo do registro valor O nome do registro pode ser um nome de domínio, um FQDN ou até mesmo um endereço IP (no caso de zonas reversas, discutidas na seqüência). O TTL (Time to Live) especifica o tempo máximo que a informação pode ficar na cache de um cliente. O campo é opcional, podendo ser um valor global especificado no início do arquivo, ao invés de individual para cada registro. O campo IN significa endereço de Internet (o DNS pode suportar outros tipos de endereço). Os tipos de registro e seus respectivos valores são discutidos abaixo: SOA (Start of Zone Authority): indica o servidor DNS que é a autoridade para uma zona, isto é, aquele que contém a cópia master com as informações mais confiáveis e atualizadas. O registro SOA tem outras informações omitidas no exemplo acima, mas que serão discutidos na seqüência. NS (Authoritative Name Server): indica uma lista de servidores que são autoridade para um certo domínio. Os registros declarados após um registro de domínio (SOA), podem ter o nome de domínio omitido (eles assumem o domínio do SOA). A (Address): efetua o mapeamento entre um FQDN e um endereço IPv4. Observe que os nomes do arquivo de zona podem ser absolutos (terminados por. ) ou relativos (sem. ). O FQDN dos nomes relativos é formado concatenado-se o nome do registro com o próprio nome da zona. CNAME (Canonical Name): permite definir um alias para um FQDN MX (Mail Exchange): define o servidor de e-mail padrão para um domínio. Para enviar um e- mail para usuario@pucpr.br, o servidor SMTP precisa determinar o endereço IP do servidor onde a caixa postal de usuario está armazenada. O nome pucpr.br não define uma máquina, mas apenas um domínio. Quando um servidor SMTP externo consulta o DNS da PUCPR, ele recebe como resposta um registro MX especificado os servidores de e-mail primário (preferência 10) e secundário (preferência 20). 5

Servidores Primários e Secundários zona pucpr.br slave beta.pucpr.br zona pucpr.br master alpha.pucpr.br gama.pucpr.br zona pucpr.br slave O padrão DNS permite definir servidores primários e secundários. Um servidor primário armazena a cópia master (original) para uma dada zona. A fim de prover tolerância a falhas e melhorar a disponibilidade do serviço, outros servidores ditos secundários podem armazenar cópias slave (escravas). As alterações podem ser feitas apenas na cópia master. Os servidores secundários precisam verificar periodicamente se sua cópia está atualizada, e atualizá-la caso haja uma nova versão. Um registro SOA traz várias informações adicionais relativas a esse processo, como no exemplo abaixo: pucpr.br. IN SOA alpha.pucpr.br. jamhour.ppgia.pucpr.br ( 1 ; serial 8H ; refresh 2H ; retry 1W ; expire 1D ) ; ttl e-mail: A primeira informação adicional é o endereço de e-mail do administrador do servidor primário (com o @ substituído por um. ). serial: indica qual a versão da zona master. Se houver uma alteração, este valor deve ser incrementado. refresh: tempo de atualização para os servidores secundários. Após expirar este tempo, os servidores secundários devem verificar se o primário tem um serial mais atualizado. Se tiver, precisam atualizar a sua cópia da zona. retry: tempo que o servidor secundário deverá aguardar antes de uma nova tentativa, caso a tentativa de refresh falhe (por indisponibilidade do primário). expire: tempo máximo que o secundário irá considerar sua informação válida, caso não consiga atualizar sua cópia após inúmeras tentativas. Após esse período, o DNS secundário pára de responder a consultas. ttl: tempo máximo que o registro SOA pode ficar na cache do cliente. Existem implementações de servidores DNS que não armazenam o registros da ZONA em arquivos texto, usando como alternativa um banco de dados relacional ou similar. Contudo, como os tipos de registros são padronizados em RFCs, mesmo os sistemas que usam um banco de dados são capazes de importar e exportar as informações da ZONA na forma de um arquivo texto que segue o formato do BIND. 6

Arquivos de Configuração (named.conf) options { directory pasta de zonas ; zone nome da zona { type master; file master/arquivo de zona ; zone nome da zona { type slave; file slave/arquivo de zona ; masters { ipmaster1; ipmaster2; } named.conf primário named.conf secundário options { directory /var/named/ ; zone pucpr.br { type master; file pucpr.br ; options { directory /var/named/ ; zone pucpr.br { type slave; file slave/pucpr.br ; masters { 200.17.99.2; O arquivo de zonas não contém todas as informações necessárias para o funcionamento do servidor DNS. Um outro arquivo de configuração é necessário a fim de informar ao servidor DNS quais zonas ele representa e quais arquivos ele deve carregar em memória durante sua inicialização. No caso da implementação do BIND, este arquivo se chama named.conf. A estrutura geral do arquivo de configuração é mostrada na figura. Um arquivo named.conf possui dois tipos de estruturas principais: options e zone. A estrutura options define parâmetros globais válidos para todas as zonas. Por exemplo, o diretório onde os arquivos de zona ficarão armazenados no servidor DNS. A estrutura zone define parâmetros específicos para uma zona. Os parâmetros mudam de acordo com o tipo de zona. Por exemplo, numa zona tipo master basta especificar o nome do arquivo que contém a zona. Numa zona do tipo slave é necessário ainda informar o endereço IP do servidor (ou servidores) master de onde o arquivo será copiado. Observe que o nome do arquivo da zona é concatenado com a opção global directory a fim de definir um caminho absoluto. Uma boa prática consiste em criar sub-diretórios diferentes para as zonas master e slave. A figura mostra como ficariam os arquivos de configuração dos servidores DNS primário e secundário para a zona pucpr.br. Observe que o servidor primário localiza o arquivo de zona na pasta /var/named/master/ e o servidor secundário localiza sua cópia na pasta /var/named/slave. 7

Delegação de SubDominios ZONA.br br RAIZ ZONA pucpr.br NS NS ZONA ufpr.br pucpr ufpr ppgia Um conceito importante da árvore de nomes do DNS é a delegação de subdomínios. Delegar um subdomínio significa criar um ponteiro para que um outro servidor DNS administre uma parte da árvore de nomes. A figure ilustra este conceito. O servidor DNS autoritário para zona.br é o detentor dos direitos de todos os nomes que terminam com.br. Ao invés de todos os nomes de servidores registrados no Brasil serem definidos na zona.br, múltiplos subdomínios podem ser delegados, para que cada instituição possa criar seus nomes de servidores sem precisar de alterações na zona.br. A delegação de subdomínios é feita através da criação de registros do tipo NS (Authoritative Name Server). Quando um servidor de alto nível é consultado sobre um endereço armazenado em um subdomínio que foi delegado, ele pode responder de duas formas distintas. A primeira é dar uma resposta não recursiva, isto é, simplesmente retornar um ponteiro para o servidor que realmente possui a informação de mapeamento entre nome e IP desejado. A segunda é dar uma resposta recursiva, onde o próprio servidor de alto nível faz a consulta ao servidor de baixo nível e retorna uma resposta final (um registro do tipo A - Address) para o computador que fez a consulta. No caso de servidores públicos como o do domínio.br, o comportamento é sempre não recursivo. No exemplo, a zona.br delegou dois subdomínios: pucpr.br e ufpr.br. Isso significa que quando uma consulta for feita ao servidor.br sobre algum FQDN que termina com pucpr.br, o servidor retornará como resposta que o responsável por responder a essa consulta é o servidor DNS da PUCPR. Similarmente, se alguma consulta sobre nomes que terminam com ufpr.br for feita, o servidor DNS da zona.br irá retornar como resposta que o responsável por responder a essa consulta é o servidor da UFPR. 8

Zonas com Delegação de Sub-Domínios ZONA br ZONA pucpr.br ZONA ufpr.br br. IN SOA dns.br IN NS dns.br dns IN A 200.1.2.3 pucpr IN NS dns.pucpr.br. IN NS beta.pupcr.br. ufpr IN NS dns.ufpr.br. dns.pucpr IN A 200.17.99.2 beta.pucpr IN A 200.17.99.3 dns.ufpr IN A 200.101.0.12 pucpr.br. IN SOA dns.pucpr.br IN NS dns.pucpr.br IN NS beta.pucpr.br dns IN A 200.17.99.2 beta IN A 200.17.99.3 IN A 200.17.99.3.ppgia IN A 200.17.98.174 ufpr.br. IN SOA dns.ufpr.br IN NS dns.ufpr.br dns.ufpr.br. IN A 200.101.0.12 IN A 200.101.0.15 A figura mostra como ficariam os arquivos de zonas para árvore de nomes do exemplo anterior. O arquivo da zona br tem um registro do tipo NS para os subdomínios pucpr.br e ufpr.br (linhas 3 e 4). Observe que os nomes foram escritos de forma relativa, isto é, sem ponto no final. O nome da zona é concatenado automaticamente aos nomes relativos, de forma que os nomes pucpr e ufpr significam pucpr.br. e ufpr.br. Além dos ponteiros NS o arquivo da zona br precisa conhecer os endereços dos servidores DNS dos subdomínios delegados. No exemplo, o subdomínio pucpr.br possui um servidor primário (dns.pucpr.br.) e um secundário (beta.ufpr.br), e o subdomínio ufpr.br apenas um servidor primário (dns.ufpr.br). No arquivo da zona pucpr.br estão efetivamente registrados os nomes dos computadores pertencentes ao seu subdomínio. O servidor dns.pucpr.br é o SOA para o domínio pucpr.br, pois ele é o detentor da cópia master do arquivo de zona. Observe como o registro.ppgia foi definido (última linha do arquivo da zona pucpr.br). Nesse caso, o domínio ppgia é um subdomínio em relação a pucpr.br, mas não houve delegação. Dessa forma, os registros do domínio ppgia são efetivamente registrados na zona pucpr, adicionando-se o nome do subdomínio ao nome do computador, conforme indicado no exemplo. Similarmente, o arquivo da zona ufpr.br indica que o servidor dns.ufpr.br é SOA para o domínio ufpr.br. Em todos os exemplos, o TTL e os parâmetros adicionais do registro SOA foram omitidos, mas devem constar nos arquivos de zona reais. 9

Consulta Recursiva recursivo.pucpr.br? A 200.17.99.3 br não recursivo.pucpr.br? NS dns.pucpr.br dns pucpr ufpr dns dns Quando um servidor DNS recebe uma consulta, ele primeiro verifica se o nome consultado pertence a uma de suas zonas. Por exemplo, considere que uma consulta foi feita ao servidor DNS da zona br. Três situações diferentes podem ocorrer: situação 1: o nome pertence a zona, e um registro do tipo A pode ser localizado localmente. (e.g. dns.br) situação 2: o nome pertence a um subdominio que foi delegado a outro servidor dns (e.g.,.pucpr.br) situação 3: o nome não pertence a zona (e.g,.google.com) A maneira como o servidor irá responder a situação 1 é obvia, ele vai localizar o registro do tipo A e devolver o endereço IP correspondente para o solicitante. A maneira como ele responderá as situações 2 e 3, contudo, depende se ele foi configurado ou não para responder a consultas recursivas. Se o servidor não foi configurado para consultas recursivas, ele trabalhará no modo interativo. Nesse modo ele responde com registros do tipo NS, indicando para qual servidor o cliente deverá refazer sua consulta. Por exemplo, no caso do tipo 2, ele responderia informado o nome e endereço dos servidores DNS (primário e secundário) que respondem pelo domínio pucpr.br. No caso de uma situação do tipo 3, ele simplesmente não responderia. O cliente que fez a consulta só perceberá o erro após um temporizador de espera máxima expirar. Se o modo recursivo estiver habilitado, então o servidor DNS tentará ele mesmo consultar outro servidor, e devolver uma resposta definitiva (registro do tipo A) para o solicitante. 10

Opções de Redirecionamento options { directory pasta de zonas ; forwarders { forwarder 1; forwarder 2; } recursion yes no; allow-recursion { subrede 1; subrede 2; } zone nome da zona { type forward; forwarders { forwarder 1; forwarder 2; } forward only; named.conf superior (br) named.conf inferior (pucpr.br) options { directory /var/named/ ; recursion yes; zone pucpr.br { type forward; forward { 200.17.99.2; 200.17.99.3; options { directory /var/named/ ; forwarders { 200.1.2.3; zone ppgia.pucpr.br { type master; file master/pucpr.br ; O controle de consultas recursivas ou não recursivas é feito através de opções do arquivo de configuração do DNS (resolv.conf). Por default, o servidor DNS está configurado para responder a consultas recursivas. É possível controlar esse comportamento através da opção recursion. Caso o modo recursivo seja habilitado, então é possível restringir a partir de quais subredes as consultas recursivas serão atendidas através da opção allow-recursion. Por default, todas as subredes são aceitas. Quando um servidor DNS que está operando em modo recursivo recebe uma consulta de um registro que não está armazenado localmente, ele redireciona a consulta para um outro servidor DNS denominado forwarder. Existem dois tipos de fowarder. Os forwarders globais (definido na seção options) e os forwarders de subdomínios delegados (definidos na em uma zona especial, do tipo forward). Os forwarders globais são utilizados quando a consulta recebida não pertencer a nenhuma zona conhecida (local ou subdomínio delegado). Por exemplo, a figura mostra como ficariam os arquivos de configuração do servidores de DNS da zona superior br e da zona delegada pucpr.br. Observe que a zona br possui uma zona forward indicando o redirecionamento para o servidores de dns primário e secundários da pucpr.br. A zona pucpr.br, por sua vez, traz o endereço do DNS br na seção global. O servidor da pucpr.br redirecionará para o servidor br qualquer consulta que não termine com o domínio pucpr.br. Convém ressaltar que o exemplo da figura não é realista. O servidor do domínio br não responde a consultas recursivas, pois isso geraria uma carga de trabalho excessivo. Ele trabalha sempre no modo interativo. Normalmente, o único servidor que aceita consultas recursivas é o servidor mais próximo dos clientes (o servidor DNS do seu provedor ou o servidor DNS da sua empresa). E mesmo nesse caso, as consultas recursivas são restritas as subredes conhecidas. 11

Cache e Respotas de Autorização não recursivo br dns pucpr ufpr.pucpr.br? A 200.17.99.3 Autoritative dns dns.ufpr.br? A 200.3.3.3 Não Autoritative recursivo para usuários pucpr recursivo para usuários ufpr Os servidores DNS armazenam em cache as respostas obtidas de outros servidores. Por exemplo, suponha que um cliente do servidor DNS da pucpr deseja conhecer o endereço.ufpr.br. Quando o servidor da pucpr recebe a consulta, ele determinar que precisa redirecioná-la para o forwarder global (o servidor br). O servidor br não aceita consultas recursivas, e por isso responde com um registro NS, indicando o servidor de DNS da ufpr. O servidor da pucpr então refaz a consulta para o servidor da ufpr, obtendo finalmente um registro do tipo A. Essa resposta é armazenada em cache e retornada para o cliente. O registro armazenado na cache tem um tempo de vida (o TTL definido no arquivo de zona). No caso, como a resposta veio diretamente do servidor que é o SOA para o domínio ufpr.br, ela é dita de autorização (ou autoritativa, em algumas traduções). Todavia, quando um segundo cliente fizer a consulta ao mesmo nome, o servidor da pucpr irá utilizar o registro da cache (se não tiver expirado). Nesse caso, a resposta não é de autorização. A razão de informar ao cliente se a resposta veio da cache ou não, é que a informação vinda da cache é menos confiável (ela pode estar desatualizada). O protocolo DNS, contudo, permite ao cliente especificar se ele deseja ou não uma resposta de autorização. Isso pode ser feito através de ferramentas de teste de DNS, como o dig do Linux ou o nslookup do Windows. Essas ferramentas permitem ao cliente especificar também se deseja uma resposta recursiva ou não. Por default, os clientes de DNS sempre tentam consultas recursivas e aceitam respostas não autoritárias. O mecanismo de cache é bastante eficiente pois reduz bastante o tempo de resposta das consultas DNS dos clientes (por exemplo, dificilmente uma consulta ao.google.com não virá da cache). De fato, é possível criar servidores que funcionam apenas como cache (ditos Caching-Only). Esses servidores não possuem zona própria, apenas forwarders para outros servidores DNS. 12

Zonas Reversa $TTL 1D @ORIGIN 1.2.200.in-addr.arpa.zone @ IN SOA dns.pucpr.br. jamhour.pucpr.br ( 2 ; serial 28800 ; refresh (s) 7200 ; retry (s) 604800 ; expire (s) 86400 ) ; ttl (s) IN NS dns.pucpr.br. 1 IN PTR dns.pucpr.br. 2 IN PTR.pucpr.br. No DNS é possível fazer consultas reversas, isto é, fornecer um endereço IP e obter como resposta o FQDN. Para suportar consultas reversas, é necessário criar uma zona reversa no servidor DNS. As zonas reversas devem ser criadas para cada subrede e seguem uma notação bastante especial. Por exemplo, para criar uma zona reversa para subrede 200.2.1.0/24 é necessário definir uma zona com o seguinte nome: 1.2.200.in-addr.arpa.zone Observe que a parte fixa do endereço IP foi escrita no sentido contrário. Os registros reversos são do tipo PTR, e permitem mapear um endereço IP a um nome. Por exemplo: 1 PTR.pucpr.br O registro acima define que o endereço do servidor.pucpr.br é 200.2.1.1. O exemplo da figura ilustra como uma zona reversa seria estruturada. Nós aproveitamos esse exemplo para introduzir alguns opções de configuração de zona que foram omitidos nos exemplos anteriores. É possível indicar o nome da zona através da opção @ORIGIN. Dessa forma, todas as vezes que se desejar referenciar ao nome da zona, pode-se utilizar apenas o símbolo @. Essa opção é útil quando se deseja definir múltiplas subredes em uma única zona. A definição da zona reversa é muito importante em diversos casos. Por exemplo, quando um servidor SMTP recebe um email, ele faz uma consulta reversa para determinar se o endereço IP de origem do pacote recebido realmente corresponde ao servidor de email do domínio do usuário que enviou o email. Em muitos casos, se não houver zona reversa, o email é simplesmente descartado. 13

Os servidores DNS Raiz (Root Servers) A M zona root.zone... root-servers hints-file.com.org.edu.com.pucpr Segundo a nomenclatura adotada na Internet, o Domain Name Space é dividido em três áreas principais: Organization Domains: (.com - comercial), (.edu - educacional), (.gov - governo), (.org - instituições sem fins lucrativos), (.net - empresas de telecom), etc. Geographical Domains: (.br - brasil), (.us - estados unidos), (.uk - reino unido), (.fr - frança), etc. Reverse domain: domínios usados para mapear endereços IP em nomes. Geralmente, os domínios organizacionais são associados a nomes de país como.com.br,.gov.br, etc. Mas também existem os domínios organizacionais globais sem determinação de país, como.com,.gov, etc. Nos exemplos anteriores, nós sempre consideramos o DNS br como root. Contudo, existe servidores em um nível superior, que delegam ao DNS br o direito de gerenciar os nomes que terminam com.br. Esses servidores são ditos (Root Servers). Eles possuem os ponteiros (NS) para os servidores autoritários de nível mais alto da árvore DNS. O arquivo dos root-servers é dito root-zone, e tem entradas do tipo: BR. NS A.DNS.BR. A.DNS.BR. A 200.160.0.10 Ao invés de utilizar um forward único, os servidores DNS podem obter uma cópia do arquivo root-zone e redirecionar as consultas fora de seus domínios diretamente para os servidor raiz de cada domínio. Por questões de escalabilidade, existem 13 root-servers com cópias idênticas de suas bases espalhados por vários continentes. Esses servidores tem nomes forma letra.root-servers.net (onde a letra varia de A até M). Essa lista de servidores é denominada hints file (arquivo named.root) e pode ser obtida junto a página da IANA (.iana.org). O hints file possui entradas no seguinte formato: A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201 etc. Para o servidor utilizar o hints file, é necessário criar a seguinte zona especial no named.conf: zone "." in{ type hint; file "root.servers"; Essa diretiva instrui o servidor DNS, na sua inicialização, a buscar o arquivo de zona raiz root.zone em um dos servidores root. 14

Conclusão DNS - Domain Name System Nessa unidade nós vimos o DNS (Domain Name System). Esse serviço implementa um mecanismo de nomes hierárquico. Isto facilita a organização dos nomes em redes de grande porte. O banco de dados que armazena os nomes DNS da Internet está distribuído em inúmeros servidore DNS. Cada servidor DNS contém informações de zonas específicas, e pode ser administrado separadamente. O serviço DNS implementa mecanismos de cache que torna a resolução de nomes um processo muito rápido. O DNS é um dos sistemas mais rápidos e escaláveis da Internet. Como as mensagens DNS são muito pequenas, o protocolo DNS é implementado sobre UDP. Existem algumas extensões do DNS, para oferecer melhores opções de segurança (DNSsec) e também atualizar o arquivo de zonas automaticamente (DNSdinâmico). Essa opções seriam úteis para o caso de utilizar o DNS para atribuir nomes também a computadores clientes, e não apenas a servidores. Todavia, como as redes locais são largamente dominadas pelos Nomes NetBIOS, a utilização do DNS dinâmico e do DNSsec ainda não está muito difundida. 15