DNS: Domain Name System DHCP: Dynamic Host Configuration Protocol

Transcrição

1 DNS: Domain Name System DHCP: Dynamic Host Configuration Protocol 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

2 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 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

3 Á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, 3

4 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

5 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 beta.pucpr.br. IN A dns IN CNAME alpha IN A smpt1 IN A smpt1 IN A 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 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 primário (preferência 10) e secundário (preferência 20). 5

6 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 A primeira informação adicional é o endereço de do administrador do servidor primário (com 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

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

8 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

9 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 pucpr IN NS dns.pucpr.br. IN NS beta.pupcr.br. ufpr IN NS dns.pucpr.br. dns.pucpr IN A beta.pucpr IN A dns.ufpr IN A pucpr.br. IN SOA dns.pucpr.br IN NS dns.pucpr.br IN NS beta.pucpr.br dns IN A beta IN A IN A ppgia IN A ufpr.br. IN SOA dns.ufpr.br IN NS dns.ufpr.br dns.ufpr.br. IN A IN A 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

10 Consulta Recursiva recursivo.pucpr.br? A 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

11 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 { ; ; options { directory /var/named/ ; forwarders { ; 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

12 Cache e Respotas de Autorização não recursivo br dns pucpr ufpr.pucpr.br? A Autoritative dns dns.ufpr.br? A 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

13 Zonas Reversa $TTL IN SOA dns.pucpr.br. jamhour.pucpr.br ( 2 ; serial ; refresh (s) 7200 ; retry (s) ; expire (s) ) ; 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 /24 é necessário definir uma zona com o seguinte nome: 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 é 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 Dessa forma, todas as vezes que se desejar referenciar ao nome da zona, pode-se utilizar apenas o 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 , ele faz uma consulta reversa para determinar se o endereço IP de origem do pacote recebido realmente corresponde ao servidor de do domínio do usuário que enviou o . Em muitos casos, se não houver zona reversa, o é simplesmente descartado. 13

14 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 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 A B.ROOT-SERVERS.NET A 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

15 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

16 DHCP - Dynamic Host Configuration Protocol Subrede 2 BOOTP SERVIDOR DHCP Subrede 2 CLIENTES DHCP BOOTP O DHCP (Dynamic Host Configuration Protocol) é um padrão industrial aberto, definido por vários documentos do IETF: RFC 1533, 1534, 1541 e O DHCP permite a criação de um mecanismo centralizado para automatizar a administração e a configuração de parâmetros TCP/IP numa rede. O DHCP segue a arquitetura cliente-servidor. Os clientes de DHCP em sua inicialização solicitam parâmetros de rede para o servidor de DHCP. O servidor atribui para cada cliente um endereço IP e a configuração de outros parâmetros (como roteador padrão, servidor DNS, servidor NetBIOS, etc). O protocolo utilizado pelo DHCP é denominado BOOTP, e é construído sobre o protocolo UDP. Para solicitar a configuração de parâmetros de rede, um cliente DHCP tenta localizar um servidor utilizando uma mensagem em broadcast. Qualquer servidor DHCP que seja alcançável por uma mensagem broadcast poderá atender ao cliente. Esta estratégia permite que o cliente seja configurado sem conhecer nenhum parâmetro específico de rede. Um único servidor DHCP pode configurar várias subredes, normalmente, uma subrede em cada uma de suas interfaces. Por ser um serviço simples, e associado as interfaces de rede, o serviço de DHCP é comumente implementado por roteadores. Mesmo equipamentos de pequeno porte, como Access Point (AP) WiFi e roteadores ADSL tem capacidade de distribuir endereços via DHCP. 16

17 Configuração do DHCP subnet netmask { range ; default-lease-time 86400; option routers ; option ip-forwarding off; option broadcast-address ; option subnet-mask ; option domain-name-servers ; option nntp-server ; option netbios-name-servers ; host laser-printer { hardware ethernet 08:00:2b:4c:59:23; fixed-address ; } } Um servidor DHCP permite configurar vários parâmetros de rede no cliente. De acordo com a padronização do serviço de DHCP pelo IETF, esses parâmetros são denominados opções. O exemplo da figura ilustra uma parte do arquivo de configuração do servidor DHCP no Linux (arquivo dhcpd.conf). Cada sub-rede atendida pelo servidor DHCP terá uma estrutura similar ao indicado na figura. O exemplo define os seguintes parâmetros: range: faixa de IPs que será distribuída default-lease-time: tempo em segundos que o computador poderá ficar com o endereço IP sem solicitar renovação. option routers: indica o gateway padrão do rede. option ip-forwanding: define se o cliente terá ou não roteamento habilitado. option broadcast-address: define o endereço de broadcast para subrede. option subnet-mask: indica a máscara de subrede que será utilizada pelo cliente. option domain-name-servers: indica a máscara de subrede que será utilizada pelo cliente. option nntp-server: indica o servidor nntp (relógio) da rede. option netbios-name-servers: indica o servidor de nomes NetBIOS (WINS) da rede. A princípio, a distribuição de endereços IP para os clientes é dinâmica. É possível, contudo, fixar o endereço IP para um dado cliente baseado no seu endereço MAC. Isso é feito através da diretiva host, conforme indicado no exemplo. 17

18 Processo de Atribuição: Novo IP Cliente DHCP Dhcpdiscover Dhcpoffer Dhcprequest subrede horas Dhcpack Todas as mensagens são enviadas em broadcast... Dhcprelease Servidor DHCP O protocolo BOOTP define um conjunto de mensagens padronizadas trocadas entre o cliente e o servidor de DHCP. O processo de atribuição dos parâmetros IP é dividido em duas etapas: a obtenção de um novo endereço IP e o processo de renovação de um IP já obtido. O processo de obtenção de um novo IP só acontece quando o cliente DHCP não possui nenhum IP obtido anteriormente. Nesse caso, o conjunto de mensagens trocadas é o seguinte: 1) O cliente envia a mensagem Dhcpdiscover em broadcast. O endereço IP de origem do pacote é pois o cliente ainda não tem um endereço IP. 2) Quando o servidor recebe o pacote, ele seleciona um endereço IP disponível na sua lista e oferece ao cliente. O servidor responde ao cliente com a mensagem Dhcpoffer 3) Quando o cliente recebe a oferta ele pode: aceitar enviando a mensagem Dhcprequest (incluindo o IP) em broadcast recusar enviando a mensagem Dhcpdecline em broadcast 4) Quando o servidor recebe o Dhcprequest ele pode: confirmar para o cliente com a mensagem Dhcpack recusar, se o endereço foi usado por outro, com a mensagem Dhcpnack 5) O cliente pode liberar um endereço com a mensagem Dhcprelease. Um cliente DHCP aceita a primeira oferta que receber. Se houver mais de um servidor DHCP distribuindo endereços IP, não haverá como selecionar apenas um deles. Se o cliente não receber a oferta do servidor ele repete o pedido Dhcpdiscover em intervalos de 2, 4, 8, 16 segundos. Se as 4 tentativas fracassarem, ele tenta novamente em intervalos de 5 minutos. 18

19 Processo de Atribuição: Renovação Cliente DHCP Dhcprequest Dhcpack OU Dhcpnack subrede horas Todas as mensagens são enviadas em broadcast Dhcpdiscover Servidor DHCP O direito do cliente de usar o endereço IP recebido pelo servidor DHCP é temporário. Quando o prazo de validade do IP expira, o servidor pode atribuí-lo a outra estação na rede. Para evitar que isso aconteça, o cliente precisa renovar o seu direito de utilizar o endereço IP antes desse prazo. O cliente inicia o processo de renovação quando metade do seu período de empréstimo tiver sido atingido. Por exemplo, se o período de empréstimo for de 72 horas, o cliente irá tentar a renovação a partir de 36 horas. O cliente também tenta a renovação todas as vezes que é reinicializado. A princípio um cliente DHCP pode manter o seu IP indefinidamente. Ele só irá perder o seu IP se ficar desligado por um longo período. Nesse caso, ele poderá ter seu endereço IP atribuído para outro computador. Se desejar, o cliente pode liberar seu endereço IP antecipadamente com a mensagem Dhcprelease. O processo de renovação do endereço IP é bastante simples. Primeiro ele envia uma mensagem em Dhcprequest com o endereço IP antigo ao invés do Dhcpdiscover. Se o pedido for negado, então o cliente envia um Dhcpdiscover, e tenta conseguir um novo endereço seguindo o procedimento descrito anteriormente. O período de 72 horas é o padrão de leasing de muitas implementações de DHCP. Todavia, recomenda-se um leasing bem mais curto para computadores que se ligam temporariamente na rede (notebooks via rede wireless, por exemplo). 19

20 Agente Relay DHCP/BOOTP DhcpDiscover subrede 3 endereço pertence a subrede 3 Agente Relay 2 eth0 eth1 DhcpDiscover DhcpDiscover eth0 1 eth1 subrede 2 Roteador com servidor DHCP configurado com três subredes Em redes não segmentadas, um único servidor DHCP pode atender uma quantidade arbitrariamente grande de clientes. Contudo, como o DHCP funciona em broadcast, um cliente não consegue localizar um servidor DHCP que esteja do outro lado de um roteador. Considere o exemplo da figura. O roteador 1 exerce o papel de servidor DHCP. Quando ele recebe um DhcpDiscover em broadcast pela sua interface eth1, ele oferece aos clientes a configuração referente a subrede 1. Quando ele recebe um DhcpDiscove em broadcast pela sua interface eth0, ele oferece aos clientes a configuração referente a subrede 2. Contudo, não é possível para os clientes da subrede 3 localizar o servidor DHCP, pois suas mensagens em broadcast serão bloqueadas pelo roteador 2. Para permitir o funcionamento do DHCP em redes segmentas, foi definido um mecanismo complementar denominado agente relay (RFC1542). O agente relay é um software que roda em um roteador ou computador (existe implementações do agente relay para sistemas operacionais, como o Linux). O agente relay é configurado para escutar mensagens BOOTP em broadcast e propagá-las em unicast para um roteador DHCP especifico. No exemplo da figura, o roteador 2 possui o agente relay habilitado. Quando ele recebe uma mensagem DhcpDiscover em broadcast pela sua interface eth0, ele repassa a mensagem em unicast para a interface eth0 do roteador 1. A mensagem contém o endereço IP do agente relay (correspondente a um endereço da subrede 3). Dessa forma, o servidor DHCP sabe que deve selecionar uma configuração da subrede 3 e responder a essa mensagem também em unicast par ao roteador 2. 20

21 Conclusão DHCP - Dynamic Host Configuration Protocol O DHCP é um serviço de configuração automática de parâmetros IP. Além de atribuir endereços IP, o mecanismo permite configurar diversos parâmetros como roteador default, servidor de DNS, servidor WINS, opções de roteamento, etc. Um problema com esse mecanismo é a utilização de mensagens em broadcast. Isso traz duas conseqüências. A primeira, é que o funcionamento do DHCP em redes segmentadas (LANs distintas ou VLANs) pode ser trabalhosa, pois necessita do uso de mecanismos adicionais como o agente relay. A segunda, são aspectos de segurança, pois inicialmente, o cliente DHCP não tem como filtrar de quais servidores DHCP ele vai receber ofertas de IP, o que torna o uso desse serviço potencialmente inseguro. 21