You are on page 1of 15

DNS: Domain Name System

Edgard Jamhour

O objetivo desta unidade apresentar o funcionamento de dois importantes servios de rede: o DNS e o DHCP. O DNS (Domain Name System) o servio de nomes usado na Internet. Esse mecanismo, permite que servidores da Internet sejam localizados utilizando nomes (denominados FQDN Fully Qualified Domain Names) ao invs de endereos IP. O DHCP (Dynamic Host Configuration Protocol) o servio de atribuio automtica de endereos e outras configuraes essenciais para o funcionamento das redes IP. Os exemplos dessa unidade so baseados na implementao desses servios para o ambiente Linux, e devem ser usados como referncia na execuo das atividades prticas.

Servio DNS: Domain Name System


nome - ip

nome - ip Nome?

IP

nome - ip

nome - ip
Edgard Jamhour

Um servio de nomes mecanismo que permite mapear nomes amigveis a endereos para facilitar a identificao dos computadores em redes IP. Existem basicamente dois modelos para servios de nomes: nomes planos e nomes hierrquicos. Um modelo de nomes planos muito difundido o padro de nomes NetBIOS. Os nomes NetBIOS so muito comuns nas redes Microsoft. Eles correspondem ao nome do computador fornecido na instalao 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, no possvel dizer a qual empresa ou a qual pas ele pertence. Como os nomes planos podem ser escolhidos livremente, muito difcil evitar nomes duplicados. Isso torna o seu uso em redes grandes e de administrao decentralizada como a Internet totalmente proibitivo. O modelo de nomes hierrquicos mais apropriado para redes de grande porte. Dois exemplos de modelos hierrquicos so o X500 e o DNS (Domain Name System). Nesse modelos, o nome formado por mltiplas partes, que alm do nome do computador propriamente dito, identificam a localizao e a empresa ao qual o computador pertence. O X500 um modelo mais genrico que o DNS, pois permite associar nomes a qualquer tipo de objeto, e no apenas endereos IP. O DNS especfico para endereos. Os modelos de nomes hierrquicos podem ser implementados de forma distribuda. Como ilustrado na figura, os nomes podem ser armazenados em mltiplos servidores, cada um contendo apenas uma parte do banco de dados que mapeia nomes em endereos. 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 padro aberto especificado em vrios documentos do IETF, como as RFCs 1033, 1034, 1034, 1101, 1123, 1183 e 1536. Sua implementao original, contudo, foi desenvolvida na Berkley University para a verso 4.3 SD Unix. Por isso, at hoje, nos sistemas Unix, a implementa do DNS denominada BIND (Berkeley Internet Name Domain)

rvore de nomes
RAIZ

br br pucpr
ufpr

Pucpr
www

Ufpr
ppgia www

www FOLHA

eureka

www
Edgard Jamhour

Os nomes hierrquicos utilizados pelo DNS so chamados FQDN: Fully Qualified Domain Name. Um FQDN formado por vrias nomes separados por pontos. Cada um desses nomes pode ser um nome de host ou um nome de domnio. Um domnio representa uma coleo de hosts ou uma coleo de outros domnios. Um nome de host identifica um computador apenas dentro de um domnio especfico. O FQDN identifica um computador de forma nica em toda a Internet. Por exemplo, www.pucpr.br um FQDN. Seus componentes so definidos seguinte forma: www: nome do host, pucpr: nome de domnio e br: nome de domnio. O domnio br uma coleo de todos os domnios que esto no Brasil, e inclui o domnio pucpr. O domnio pucpr uma coleo de todos os hosts que esto na PUCPR, e inclui o host www. Os nomes hierrquicos so comumente representos como uma rvore, conforme mostrado na figura. Nessas rvore os nomes de host correspondem sempre as folhas, e so os nicos elementos mapeados a endereos IP. Observe no desenho, que o nome de host no identifica um computador de forma global. Por exemplo, podemos ter o host www no domnio ufpr ou no domnio pucpr. Todavia, o FQDN garante que o nome seja nico. Esse mecanismo permite a administrao descentralizada dos nomes na Internet, pois a nica preocupao do administrador evitar que um nome seja duplicado em seu domnio mais prximo. Observao: O FQDN pode ser combinado com outras informaes 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.

ZONAS DNS

ZONA .br

br

RAIZ

servidor A.dns.br
ZONA ufpr.br

ZONA pucpr.br

pucpr
ppgia

ufpr
servidor ns.ufpr.br

servidor alpha.pucpr.br

www

www

www
Edgard Jamhour

Uma rvore de nomes DNS dividida em zonas. Essa diviso permite que os nomes sejam armazenados em vrios servidores DNS, segundo o conceito de banco de dados distribudos. Uma zona DNS uma poro da rvore de nomes que est armazenada em um servidor especfico. O exemplo da figura mostra uma parte da rvore de nomes global da Internet. Apenas para efeito de ilustrao, vamos assumir que esta poro da rvore est dividida em trs zonas: pucpr.br, ufpr.br e br. A zona pucpr.br contm os nomes correspondentes aos computadores da PUCPR. Observe que os conceitos de zona e domnio so distintos. Uma zona corresponde sempre a um domnio, mas o contrrio nem sempre verdade. Uma zona pode conter uma hierarquia de domnios, e seu nome corresponde apenas ao domnio de nvel mais elevado. Por exemplo, ppgia um domnio dentro da pucpr, mas no corresponde a uma zona. Isto significa que as informaes sobre os computadores pertencentes ao domnio pucpr e ao domnio ppgia esto armazenados na mesma zona. Observe que o domnio br contm os domnios pucpr e ufpr, mas sua zona no armazena os nomes dos computadores dessas zonas. Como veremos, o domnio br contm apenas ponteiros para os servidores de DNS das zonas que esto hierarquicamente abaixo de seu domnio. 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 domnio br. O mesmo acontece quando criado um ponteiro para o servidor de nomes da UFPR. O formato desses ponteiros ser discutido a seguir.

Arquivo de ZONA
ZONA pucpr.br
$TTL pucpr.br. 1D IN SOA IN NS IN NS IN MX IN MX alpha beta.pucpr.br. dns www smpt1 smpt1 IN A IN A IN CNAME IN A IN A IN A alpha.pucpr.br. [ ....] alpha.pucpr.br. beta.pupcr.br. 10 smtp.pucpr.br. 20 smtp2.pupcr.br. 200.17.99.2 200.17.99.3 alpha 200.192.112.141 200.192.112.20 200.192.112.21

Edgard Jamhour

Na implementao do BIND para UNIX, as zonas so representados na forma de arquivos. Um arquivo de zona contm uma coleo 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 domnio, um FQDN ou at mesmo um endereo IP (no caso de zonas reversas, discutidas na seqncia). O TTL (Time to Live) especifica o tempo mximo que a informao pode ficar na cache de um cliente. O campo opcional, podendo ser um valor global especificado no incio do arquivo, ao invs de individual para cada registro. O campo IN significa endereo de Internet (o DNS pode suportar outros tipos de endereo). Os tipos de registro e seus respectivos valores so discutidos abaixo: SOA (Start of Zone Authority): indica o servidor DNS que a autoridade para uma zona, isto , aquele que contm a cpia master com as informaes mais confiveis e atualizadas. O registro SOA tem outras informaes omitidas no exemplo acima, mas que sero discutidos na seqncia. NS (Authoritative Name Server): indica uma lista de servidores que so autoridade para um certo domnio. Os registros declarados aps um registro de domnio (SOA), podem ter o nome de domnio omitido (eles assumem o domnio do SOA). A (Address): efetua o mapeamento entre um FQDN e um endereo 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 prprio nome da zona. CNAME (Canonical Name): permite definir um alias para um FQDN MX (Mail Exchange): define o servidor de e-mail padro para um domnio. Para enviar um email para usuario@pucpr.br, o servidor SMTP precisa determinar o endereo IP do servidor onde a caixa postal de usuario est armazenada. O nome pucpr.br no define uma mquina, mas apenas um domnio. Quando um servidor SMTP externo consulta o DNS da PUCPR, ele recebe como resposta um registro MX especificado os servidores de e-mail primrio (preferncia 10) e secundrio (preferncia 20). 5

Servidores Primrios e Secundrios


beta.pucpr.br zona pucpr.br slave zona pucpr.br master alpha.pucpr.br gama.pucpr.br zona pucpr.br slave

Edgard Jamhour

O padro DNS permite definir servidores primrios e secundrios. Um servidor primrio armazena a cpia master (original) para uma dada zona. A fim de prover tolerncia a falhas e melhorar a disponibilidade do servio, outros servidores ditos secundrios podem armazenar cpias slave (escravas). As alteraes podem ser feitas apenas na cpia master. Os servidores secundrios precisam verificar periodicamente se sua cpia est atualizada, e atualiz-la caso haja uma nova verso. Um registro SOA traz vrias informaes 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 informao adicional o endereo de e-mail do administrador do servidor primrio (com o @ substitudo por um .). serial: indica qual a verso da zona master. Se houver uma alterao, este valor deve ser incrementado. refresh: tempo de atualizao para os servidores secundrios. Aps expirar este tempo, os servidores secundrios devem verificar se o primrio tem um serial mais atualizado. Se tiver, precisam atualizar a sua cpia da zona. retry: tempo que o servidor secundrio dever aguardar antes de uma nova tentativa, caso a tentativa de refresh falhe (por indisponibilidade do primrio). expire: tempo mximo que o secundrio ir considerar sua informao vlida, caso no consiga atualizar sua cpia aps inmeras tentativas. Aps esse perodo, o DNS secundrio pra de responder a consultas. ttl: tempo mximo que o registro SOA pode ficar na cache do cliente. Existem implementaes de servidores DNS que no armazenam o registros da ZONA em arquivos texto, usando como alternativa um banco de dados relacional ou similar. Contudo, como os tipos de registros so padronizados em RFCs, mesmo os sistemas que usam um banco de dados so capazes de importar e exportar as informaes da ZONA na forma de um arquivo texto que segue o formato do BIND. 6

Arquivos de Configurao (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 primrio

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; }; };

named.conf secundrio

Edgard Jamhour

O arquivo de zonas no contm todas as informaes necessrias para o funcionamento do servidor DNS. Um outro arquivo de configurao necessrio a fim de informar ao servidor DNS quais zonas ele representa e quais arquivos ele deve carregar em memria durante sua inicializao. No caso da implementao do BIND, este arquivo se chama named.conf. A estrutura geral do arquivo de configurao mostrada na figura. Um arquivo named.conf possui dois tipos de estruturas principais: options e zone. A estrutura options define parmetros globais vlidos para todas as zonas. Por exemplo, o diretrio onde os arquivos de zona ficaro armazenados no servidor DNS. A estrutura zone define parmetros especficos para uma zona. Os parmetros mudam de acordo com o tipo de zona. Por exemplo, numa zona tipo master basta especificar o nome do arquivo que contm a zona. Numa zona do tipo slave necessrio ainda informar o endereo IP do servidor (ou servidores) master de onde o arquivo ser copiado. Observe que o nome do arquivo da zona concatenado com a opo global directory a fim de definir um caminho absoluto. Uma boa prtica consiste em criar sub-diretrios diferentes para as zonas master e slave. A figura mostra como ficariam os arquivos de configurao dos servidores DNS primrio e secundrio para a zona pucpr.br. Observe que o servidor primrio localiza o arquivo de zona na pasta /var/named/master/ e o servidor secundrio localiza sua cpia na pasta /var/named/slave.

Delegao de SubDominios
ZONA .br

br
ZONA pucpr.br

RAIZ

NS

NS

ZONA ufpr.br

pucpr ppgia

ufpr

www

www

www
Edgard Jamhour

Um conceito importante da rvore de nomes do DNS a delegao de subdomnios. Delegar um subdomnio 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 autoritrio para zona .br o detentor dos direitos de todos os nomes que terminam com .br. Ao invs de todos os nomes de servidores registrados no Brasil serem definidos na zona .br, mltiplos subdomnios podem ser delegados, para que cada instituio possa criar seus nomes de servidores sem precisar de alteraes na zona .br. A delegao de subdomnios feita atravs da criao de registros do tipo NS (Authoritative Name Server). Quando um servidor de alto nvel consultado sobre um endereo armazenado em um subdomnio que foi delegado, ele pode responder de duas formas distintas. A primeira dar uma resposta no recursiva, isto , simplesmente retornar um ponteiro para o servidor que realmente possui a informao de mapeamento entre nome e IP desejado. A segunda dar uma resposta recursiva, onde o prprio servidor de alto nvel faz a consulta ao servidor de baixo nvel e retorna uma resposta final (um registro do tipo A - Address) para o computador que fez a consulta. No caso de servidores pblicos como o do domnio .br, o comportamento sempre no recursivo. No exemplo, a zona .br delegou dois subdomnios: 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 responsvel 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 responsvel por responder a essa consulta o servidor da UFPR.

Zonas com Delegao de Sub-Domnios


br.

ZONA br

dns pucpr ufpr dns.pucpr beta.pucpr dns.ufpr

IN SOA IN NS IN A IN NS IN NS IN NS IN A IN A IN A IN SOA IN NS IN NS IN A IN A IN A IN A IN SOA IN NS IN A IN A

dns.br dns.br 200.1.2.3 dns.pucpr.br. beta.pupcr.br. dns.ufpr.br. 200.17.99.2 200.17.99.3 200.101.0.12 dns.pucpr.br dns.pucpr.br beta.pucpr.br 200.17.99.2 200.17.99.3 200.17.99.3 200.17.98.174 dns.ufpr.br dns.ufpr.br 200.101.0.12 200.101.0.15
Edgard Jamhour

ZONA pucpr.br

pucpr.br.

dns beta www www.ppgia

ZONA ufpr.br

ufpr.br. dns.ufpr.br. www

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 subdomnios 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. Alm dos ponteiros NS o arquivo da zona br precisa conhecer os endereos dos servidores DNS dos subdomnios delegados. No exemplo, o subdomnio pucpr.br possui um servidor primrio (dns.pucpr.br.) e um secundrio (beta.ufpr.br), e o subdomnio ufpr.br apenas um servidor primrio (dns.ufpr.br). No arquivo da zona pucpr.br esto efetivamente registrados os nomes dos computadores pertencentes ao seu subdomnio. O servidor dns.pucpr.br o SOA para o domnio pucpr.br, pois ele o detentor da cpia master do arquivo de zona. Observe como o registro www.ppgia foi definido (ltima linha do arquivo da zona pucpr.br). Nesse caso, o domnio ppgia um subdomnio em relao a pucpr.br, mas no houve delegao. Dessa forma, os registros do domnio ppgia so efetivamente registrados na zona pucpr, adicionando-se o nome do subdomnio 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 domnio ufpr.br. Em todos os exemplos, o TTL e os parmetros adicionais do registro SOA foram omitidos, mas devem constar nos arquivos de zona reais.

Consulta Recursiva
www.pucpr.br?
recursivo

A 200.17.99.3 www.pucpr.br?

br

no recursivo

dns

NS dns.pucpr.br
pucpr ufpr

www

dns

www

dns

Edgard Jamhour

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. Trs situaes diferentes podem ocorrer: situao 1: o nome pertence a zona, e um registro do tipo A pode ser localizado localmente. (e.g. dns.br) situao 2: o nome pertence a um subdominio que foi delegado a outro servidor dns (e.g., www.pucpr.br) situao 3: o nome no pertence a zona (e.g, www.google.com) A maneira como o servidor ir responder a situao 1 obvia, ele vai localizar o registro do tipo A e devolver o endereo IP correspondente para o solicitante. A maneira como ele responder as situaes 2 e 3, contudo, depende se ele foi configurado ou no para responder a consultas recursivas. Se o servidor no 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 endereo dos servidores DNS (primrio e secundrio) que respondem pelo domnio pucpr.br. No caso de uma situao do tipo 3, ele simplesmente no responderia. O cliente que fez a consulta s perceber o erro aps um temporizador de espera mxima expirar. Se o modo recursivo estiver habilitado, ento o servidor DNS tentar ele mesmo consultar outro servidor, e devolver uma resposta definitiva (registro do tipo A) para o solicitante.

10

Opes 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; }; 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; };
Edgard Jamhour

named.conf superior (br)

named.conf inferior (pucpr.br)

O controle de consultas recursivas ou no recursivas feito atravs de opes do arquivo de configurao do DNS (resolv.conf). Por default, o servidor DNS est configurado para responder a consultas recursivas. possvel controlar esse comportamento atravs da opo recursion. Caso o modo recursivo seja habilitado, ento possvel restringir a partir de quais subredes as consultas recursivas sero atendidas atravs da opo allow-recursion. Por default, todas as subredes so aceitas. Quando um servidor DNS que est operando em modo recursivo recebe uma consulta de um registro que no est armazenado localmente, ele redireciona a consulta para um outro servidor DNS denominado forwarder. Existem dois tipos de fowarder. Os forwarders globais (definido na seo options) e os forwarders de subdomnios delegados (definidos na em uma zona especial, do tipo forward). Os forwarders globais so utilizados quando a consulta recebida no pertencer a nenhuma zona conhecida (local ou subdomnio delegado). Por exemplo, a figura mostra como ficariam os arquivos de configurao 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 primrio e secundrios da pucpr.br. A zona pucpr.br, por sua vez, traz o endereo do DNS br na seo global. O servidor da pucpr.br redirecionar para o servidor br qualquer consulta que no termine com o domnio pucpr.br. Convm ressaltar que o exemplo da figura no realista. O servidor do domnio br no 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 prximo dos clientes (o servidor DNS do seu provedor ou o servidor DNS da sua empresa). E mesmo nesse caso, as consultas recursivas so restritas as subredes conhecidas.

11

Cache e Respotas de Autorizao


br

no recursivo

dns

pucpr

ufpr

www.pucpr.br? A 200.17.99.3 Autoritative www.ufpr.br? A 200.3.3.3 No Autoritative


www dns www dns

recursivo para usurios pucpr

recursivo para usurios ufpr


Edgard Jamhour

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 endereo www.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 no aceita consultas recursivas, e por isso responde com um registro NS, indicando o servidor de DNS da ufpr. O servidor da pucpr ento 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 domnio ufpr.br, ela dita de autorizao (ou autoritativa, em algumas tradues). Todavia, quando um segundo cliente fizer a consulta ao mesmo nome, o servidor da pucpr ir utilizar o registro da cache (se no tiver expirado). Nesse caso, a resposta no de autorizao. A razo de informar ao cliente se a resposta veio da cache ou no, que a informao vinda da cache menos confivel (ela pode estar desatualizada). O protocolo DNS, contudo, permite ao cliente especificar se ele deseja ou no uma resposta de autorizao. Isso pode ser feito atravs de ferramentas de teste de DNS, como o dig do Linux ou o nslookup do Windows. Essas ferramentas permitem ao cliente especificar tambm se deseja uma resposta recursiva ou no. Por default, os clientes de DNS sempre tentam consultas recursivas e aceitam respostas no autoritrias. O mecanismo de cache bastante eficiente pois reduz bastante o tempo de resposta das consultas DNS dos clientes (por exemplo, dificilmente uma consulta ao www.google.com no vir da cache). De fato, possvel criar servidores que funcionam apenas como cache (ditos Caching-Only). Esses servidores no possuem zona prpria, 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) dns.pucpr.br. IN NS 1 IN PTR dns.pucpr.br. www.pucpr.br. 2 IN PTR

Edgard Jamhour

No DNS possvel fazer consultas reversas, isto , fornecer um endereo IP e obter como resposta o FQDN. Para suportar consultas reversas, necessrio criar uma zona reversa no servidor DNS. As zonas reversas devem ser criadas para cada subrede e seguem uma notao bastante especial. Por exemplo, para criar uma zona reversa para subrede 200.2.1.0/24 necessrio definir uma zona com o seguinte nome: 1.2.200.in-addr.arpa.zone Observe que a parte fixa do endereo IP foi escrita no sentido contrrio. Os registros reversos so do tipo PTR, e permitem mapear um endereo IP a um nome. Por exemplo: 1 PTR www.pucpr.br O registro acima define que o endereo do servidor www.pucpr.br 200.2.1.1. O exemplo da figura ilustra como uma zona reversa seria estruturada. Ns aproveitamos esse exemplo para introduzir alguns opes de configurao de zona que foram omitidos nos exemplos anteriores. possvel indicar o nome da zona atravs da opo @ORIGIN. Dessa forma, todas as vezes que se desejar referenciar ao nome da zona, pode-se utilizar apenas o smbolo @. Essa opo til quando se deseja definir mltiplas subredes em uma nica zona. A definio 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 endereo IP de origem do pacote recebido realmente corresponde ao servidor de email do domnio do usurio que enviou o email. Em muitos casos, se no houver zona reversa, o email simplesmente descartado.

13

Os servidores DNS Raiz (Root Servers)


A
zona root.zone

M ...
root-servers hints-file

.com

.org

.edu

.com .pucpr
Edgard Jamhour

Segundo a nomenclatura adotada na Internet, o Domain Name Space dividido em trs reas principais: Organization Domains: (.com - comercial), (.edu - educacional), (.gov - governo), (.org - instituies sem fins lucrativos), (.net - empresas de telecom), etc. Geographical Domains: (.br - brasil), (.us - estados unidos), (.uk - reino unido), (.fr - frana), etc. Reverse domain: domnios usados para mapear endereos IP em nomes. Geralmente, os domnios organizacionais so associados a nomes de pas como .com.br, .gov.br, etc. Mas tambm existem os domnios organizacionais globais sem determinao de pas, como .com, .gov, etc. Nos exemplos anteriores, ns sempre consideramos o DNS br como root. Contudo, existe servidores em um nvel superior, que delegam ao DNS br o direito de gerenciar os nomes que terminam com .br. Esses servidores so ditos (Root Servers). Eles possuem os ponteiros (NS) para os servidores autoritrios de nvel 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 invs de utilizar um forward nico, os servidores DNS podem obter uma cpia do arquivo root-zone e redirecionar as consultas fora de seus domnios diretamente para os servidor raiz de cada domnio. Por questes de escalabilidade, existem 13 root-servers com cpias idnticas de suas bases espalhados por vrios 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 pgina da IANA (www.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, necessrio criar a seguinte zona especial no named.conf: zone "." in{ type hint; file "root.servers"; }; Essa diretiva instrui o servidor DNS, na sua inicializao, a buscar o arquivo de zona raiz root.zone em um dos servidores root.

14

Concluso
DNS - Domain Name System

Edgard Jamhour

Nessa unidade ns vimos o DNS (Domain Name System). Esse servio implementa um mecanismo de nomes hierrquico. Isto facilita a organizao dos nomes em redes de grande porte. O banco de dados que armazena os nomes DNS da Internet est distribudo em inmeros servidore DNS. Cada servidor DNS contm informaes de zonas especficas, e pode ser administrado separadamente. O servio DNS implementa mecanismos de cache que torna a resoluo de nomes um processo muito rpido. O DNS um dos sistemas mais rpidos e escalveis da Internet. Como as mensagens DNS so muito pequenas, o protocolo DNS implementado sobre UDP. Existem algumas extenses do DNS, para oferecer melhores opes de segurana (DNSsec) e tambm atualizar o arquivo de zonas automaticamente (DNSdinmico). Essa opes seriam teis para o caso de utilizar o DNS para atribuir nomes tambm a computadores clientes, e no apenas a servidores. Todavia, como as redes locais so largamente dominadas pelos Nomes NetBIOS, a utilizao do DNS dinmico e do DNSsec ainda no est muito difundida.

15

You might also like