Felipe de Andrade Gallois. Uma Avaliação de Desempenho do DNSSEC

Felipe de Andrade Gallois Uma Avaliação de Desempenho do DNSSEC Joinville 2010

Felipe de Andrade Gallois Uma Avaliação de Desempenho do DNSSEC Relatório Final de Trabalho de Conclusão de Curso (TCC) apresentado ao Curso de Graduação em Ciência da Computação, da Universidade do Estado de Santa Catarina (UDESC), como requisito parcial da disciplina de Trabalho de Conclusão de Curso. Orientador: Prof o Rafael Rodrigues Obelheiro Joinville 2010

Felipe de Andrade Gallois Uma Avaliação de Desempenho do DNSSEC Relatório Final de Trabalho de Conclusão de Curso (TCC) apresentado ao Curso de Ciência da Computação da UDESC, como requisito parcial para a obtenção do grau de BACHAREL em Ciência da Computação. Aprovado em 29 de Novembro de 2010 BANCA EXAMINADORA Prof o Rafael Rodrigues Obelheiro Prof o Maurício Aronne Pillon Prof o Fabiano Baldo

Agradecimentos Agradeço aos meus familiares minha mãe e minha irmã pela força e paciência. À Juliana, por me ajudar a ter mais calma e por toda a diversão. Aos meus amigos Augusto, Daniel, Esdras, Henry, Júlio, Marina e Pedro pelas longas e divertidas conversas. Aos muitos colegas de faculdade por várias ideias e orientações. Aos professores da UDESC principalmente ao meu orientador Rafael Obelheiro pela paciência, consideração e iluminação que nos incentivam a buscar sempre mais: Pillon, Cláudio... À toda a comunidade do software livre, principalmente ao grupo Colmeia, pela filosofia de vida e maneira de encarar o conhecimento. À Internet, pela quase infinita fonte de informação. Ao café, por me manter acordado. À música, por ajudar a criar uma barreira de isolamento com o resto do mundo, quantas vezes necessária. Aos finais de semana, por servirem como horário de trabalho.

Resumo O Domain Name System (DNS) é um dos pilares da Internet atual. Apesar dessa importância, o protocolo DNS apresenta vulnerabilidades de segurança. Para tratar essas vulnerabilidades, algumas extensões ao protocolo têm sido propostas. Do ponto de vista operacional, uma preocupação que envolve tais propostas diz respeito ao impacto delas sobre o desempenho do DNS. Atualmente, a alternativa de segurança mais amplamente adotada é o DNSSEC. O presente trabalho apresenta uma análise de desempenho do DNSSEC comparado ao DNS sem nenhuma extensão de segurança e o impacto que este representa para ambientes de produção. Palavras-chave: DNS, segurança de redes, análise de desempenho

Abstract The Domain Name System (DNS) is one of the pillars of current Internet. In spite of this importance, the DNS protocol shows security vulnerabilities. In order to treat those vulnerabilities, some extensions have been proposed to the protocol. From an operational point of view, there is a concern about the performance impact of those proposals. In the present time, the most widely deployed security alternative is the DNSSEC. This work presents a performance analysis of the DNSSEC compared to the DNS without security extensions and the impact it can present to production environments. Keywords: DNS, network security, performace analysis

Conteúdo 1 Introdução 10 1.1 Contextualização................................. 10 1.2 Motivação..................................... 10 1.3 Objetivos..................................... 11 1.4 Organização do trabalho............................. 11 2 DNS - Domain Name System 12 2.1 História do Domain Name System........................ 12 2.2 Características do DNS.............................. 13 2.2.1 O Espaço de nomes............................ 13 2.2.2 Configuração de Zonas.......................... 22 2.2.3 Registros................................. 22 2.3 Funcionamento.................................. 23 2.3.1 O Protocolo DNS............................. 24 2.3.2 Consulta DNS.............................. 27 2.3.3 Cache................................... 31 2.4 Considerações do Capítulo............................ 32 3 Problemas de Segurança no DNS 33 3.1 Definição do problema.............................. 33 3.2 DNSSEC..................................... 37 3.2.1 Características do DNSSEC....................... 37 3.2.2 Funcionamento.............................. 41

3.3 Limitações do DNSSEC............................. 47 3.3.1 Desempenho............................... 47 3.3.2 Negação de Serviço............................ 47 3.3.3 Segurança................................. 48 3.3.4 Falta de segurança no canal de comunicação............... 48 3.4 Considerações do Capítulo............................ 48 4 Avaliação de Desempenho 49 4.1 Descrição dos Experimentos........................... 49 4.1.1 Ambiente Computacional........................ 49 4.1.2 Ferramentas................................ 49 4.1.3 Métricas adotadas e testes realizados................... 50 4.2 Tempo de validação de cadeia DNSSEC..................... 51 4.2.1 Tempo de validação de cadeia DNSSEC................. 52 4.2.2 Tempo de validação de cadeia DNSSEC em cache........... 53 4.2.3 Tempo de consulta de nomes sem DNSSEC............... 54 4.2.4 Comparação entre os tempos de resposta................ 54 4.3 Tempo para assinatura de zonas......................... 57 4.3.1 Procedimento de criação das chaves................... 57 4.3.2 Procedimento de assinatura de zonas................... 58 4.3.3 Avaliação dos resultados......................... 59 4.4 Throughput.................................... 61 4.4.1 Testes de throughput........................... 61 4.5 Avaliação de DNSSEC em portais Web..................... 63 4.5.1 Procedimento de avaliação dos portais.................. 63 4.5.2 Resultados................................ 64 4.6 Considerações do Capítulo............................ 67

5 Considerações Finais 68 Referências 69

Lista de Figuras 2.1 Exemplo de um namespace............................ 14 2.2 Caminhos absolutos e relativos em namespaces................. 15 2.3 Exemplo de domínio 1.............................. 16 2.4 Dois nós podem ter o mesmo nome a menos que sejam irmãos......... 17 2.5 Exemplo de domínio 2.............................. 17 2.6 Exemplo de zona 1................................ 19 2.7 Exemplo de zona 2................................ 20 2.8 Cabeçalho de um pacote DNS.......................... 27 2.9 Seção de consulta de um pacote DNS...................... 27 2.10 Seção de resposta de um pacote DNS....................... 28 2.11 Exemplo de consulta DNS iterativa........................ 29 2.12 Exemplo de consulta DNS recursiva....................... 30 3.1 Passos de uma consulta DNS para www.gallois.com.br............. 34 3.2 Ilhas de segurança................................. 39 3.3 Ilhas de segurança 2................................ 40 3.4 Ilhas de segurança 3................................ 42 3.5 Formato do DNSKEY............................... 43 3.6 Formato do RRSIG................................ 44 3.7 Formato do DS.................................. 45 3.8 Formato do NSEC................................. 45 4.1 Tempo de validação de cadeias DNSSEC sem cache............... 55 4.2 Tempo de validação de cadeias DNSSEC com cache.............. 55

4.3 Tempo de consultas DNS sem cache....................... 56 4.4 Tempo de geração de chaves criptográficas.................... 60 4.5 Tempo de resposta de consultas (eixo y em escala logarítmica)......... 62

Lista de Tabelas 2.1 Exemplos de cctlds e gtlds. (fonte: IANA)................. 18 2.2 RRs mais comuns no DNS............................ 22 2.3 Cabeçalho DNS.................................. 24 2.4 Consulta DNS................................... 26 2.5 Resposta DNS................................... 28 3.1 Estados de respostas DNSSEC.......................... 41 4.1 Tempo de validação de cadeia DNSSEC (sem cache).............. 52 4.2 Tempo de validação de cadeia DNSSEC (com cache).............. 53 4.3 Tempo de consulta DNS sem cache....................... 54 4.4 Tempo de geração de chaves criptográficas (s).................. 60 4.5 Total de assinaturas de zonas por segundo.................... 61 4.6 Porcentagem de consultas mais rápidas que 10ms e throughput......... 62 4.7 Tempo de resposta de consultas.......................... 63 4.8 globo.com..................................... 65 4.9 terra.com.br.................................... 65 4.10 msn.com.br.................................... 65 4.11 yahoo.com.br................................... 66 4.12 uol.com.br..................................... 66

10 1 Introdução 1.1 Contextualização O Domain Name System (DNS) foi criado com o propósito de servir como um sistema distribuído e hierárquico de mapeamento entre nomes/endereços para os computadores na Internet (TANENBAUM, 2003), que em sua estrutura baseia-se em uma hierarquia de protocolos (SCHUBA, 1993). Uma grande parte das aplicações da Internet e, consequentemente os usuários, dependem da corretude da informação do DNS. O uso de métodos para aprimorar a segurança do protocolo tornou-se alvo de preocupação quando, durante a década de 90, o conhecimento sobre vulnerabilidades do DNS tornou-se mais disseminado (BELLOVIN, 1995; VIXIE, 1995). Atualmente a solução mais tangível é o DNSSEC (ARENDS et al., 2005a), por contar com implementação finalizada e estar disponível para uso em servidores de produção. Para garantir a segurança o DNSSEC utiliza mecanismos criptográficos, o que pode representar uma queda no desempenho do sistema, tanto para os servidores quanto para os clientes. Apesar disso, poucos estudos (AGER; DREGER; FELDMANN, 2006) visam clarificar a viabilidade da implementação desse modelo em larga escala, avaliando o impacto em seu desempenho. 1.2 Motivação O simples fato do protocolo DNS possuir falhas conceituais (AGER, 2005) já representa um motivo importante para o estudo das deficiências em si. Embora elas já tenham sido extensivamente estudadas e detalhadas (MOCKAPETRIS, 1987b; BELLOVIN, 1995; VIXIE, 1995; ATKINS, 2004; ARENDS et al., 2005a), o mesmo não pode ser dito sobre a questão da avaliação de desempenho na aplicação de mecanismos de segurança para o DNS. Como o uso do Domain Name System é bastante comum na Internet, requisitado em plano de fundo por diversas aplicações, uma análise detalhada sobre o impacto de implantação de alterações que ofereçam mais segurança ao serviço é vista como uma maneira importante de embasar a sua operacionalização.

1.3 Objetivos 11 O objetivo geral deste trabalho é avaliar o impacto no desempenho da implementação do DNSSEC como proposta de segurança para o DNS. Para alcançar o objetivo geral são definidos os seguintes objetivos específicos: Apresentar as falhas de segurança intrínsecas ao protocolo. Avaliar o DNSSEC, alternativa de segurança para o DNS. Realizar a avaliação de desempenho entre o DNS e o DNSSEC, comparando o resultado obtido para que seja possível analisar a viabilidade da implementação do DNSSEC em ambientes de produção. 1.4 Organização do trabalho O trabalho é dividido em cinco capítulos sendo a introdução o primeiro. O segundo capítulo discute o protocolo DNS, seu funcionamento e as deficiências que levaram à necessidade de se criar alternativas de segurança para o mesmo. O terceiro capítulo apresenta o DNSSEC, alternativa ao DNS escolhida pelo fato de ser o único com implementação disponível ao público e portanto passível de experimentação. Sobre o mesmo serão apresentadas suas características básicas de funcionamento e informações conceituais. O quarto capítulo apresenta as métricas para avaliação de desempenho e a implementação deste processo. Ao final deste são avaliados os resultados obtidos e comparados com o DNS para analisar se o custo computacional representa algum impacto significativo no desempenho. O quinto capítulo apresenta as considerações finais, avaliando de modo geral os resultados obtidos e oferecendo sugestões para futuras implementações.

12 2 DNS - Domain Name System Neste capítulo serão apresentados conceitos fundamentais do DNS, descrevendo sua história, características principais, seu funcionamento, sua importância na Internet atual e suas deficiências. As informações apresentadas neste capítulo serão utilizadas no decorrer deste trabalho. 2.1 História do Domain Name System As origens do DNS remontam à ARPAnet(Advanced Research Projects Agency Network) onde centenas de computadores conectados em centros de pesquisa comunicavamse para trocar informações (ALBITZ; LIU, 2006). O uso de endereços de baixo nível para a comunicação entre essas estações mostrava-se muito pouco conveniente do ponto de vista prático. Por este motivo foi criado um sistema de nomes para as estações, visando mapear os endereços das máquinas para nomes compreensíveis a seres humanos (AGER, 2005; AITCHISON, 2005). Essa solução consistia, inicialmente, em coletar e organizar em um único arquivo todos os mapeamentos entre endereços e nomes. Ela foi de fato adotada na Internet em seus primórdios, quando o arquivo HOSTS.TXT continha os dados citados para todos os computadores conectados (SCHUBA, 1993). O sistema operacional GNU/Linux ainda apresenta um arquivo com formato e propósito semelhante em /etc/hosts e as versões do Windows baseadas no NT em %SystemRoot%\system32\drivers\etc\hosts (AGER, 2005), embora não sejam os únicos sistemas a possuir tal arquivo. Esse arquivo era mantido de maneira centralizada, um servidor o disponibilizava para download e era responsabilidade dos administradores atualizá-lo em suas redes locais. O sistema funcionava razoavelmente bem para uma quantidade de computadores que não passava de uma centena (TANENBAUM, 2003). O advento do TCP/IP e da Internet comercial propiciaram um grande aumento do número de máquinas e mostraram que realmente o sistema se tornaria impossível de administrar com milhares ou milhões de computadores ou PCs conectados. Além da dificuldade de manter

13 o arquivo atualizado em todas as estações, uma vez que este se tornaria muito grande para ser copiado para cada computador individualmente, a centralização da manutenção seria custosa demais. A descentralização era uma preocupação no que diz respeito à colisão de nomes (AGER, 2005). Esta ocorreria no caso do mesmo nome ser atribuído em um mapeamento para dois endereços diferentes. Tal situação tornaria um dos endereços indisponíveis caso não houvesse um tratamento. 2.2 Características do DNS Em resumo, o DNS é uma base de dados distribuída e hierárquica que é responsável pelo mapeamento entre nomes e endereços IP e vice-versa (ALBITZ; LIU, 2006). A sua principal função é o mapeamento de nomes de estações e domínios de endereços de email em endereços IP, embora outros usos também sejam possíveis como, por exemplo, a resolução reversa, que será vista posteriormente. O fato de ser distribuído oferece uma grande vantagem em termos de escalabilidade. O sistema hierárquico faz com que a administração distribuída ocorra sem riscos de colisões de nomes, já que podem ser delegadas sub-hierarquias do sistema (AGER, 2005). Os detalhes conceituais do Domain Name System estão descritos em (STAHL, 1987), (LOTTOR, 1987), (MOCKAPETRIS, 1987a) e (MOCKAPETRIS, 1987b) e serão apresentados brevemente abaixo. 2.2.1 O Espaço de nomes A estrutura hierárquica do DNS sugere que deve haver uma maneira de organizá-lo de modo em que seja possível atribuir regiões de maior controle sobre outras. Uma estrutura adequada para essa representação é a de árvore (FULTON, 2006) e o que ela representa é chamado de espaço de nomes, ou namespace. Como analogia é possível citar o sistema de endereçamento postal, onde um destinatário responde por um endereço como: Prof. Avelino Marcante s/n - Bairro Bom Retiro - Joinville-SC - Brasil. A leitura é feita de maneira inversa (da direita para a esquerda), de modo que temos a rua pertencendo ao bairro, o bairro à cidade, a cidade ao estado e este por sua vez ao país.

14 Da mesma maneira, o espaço de nomes do Domain Name System precisa se organizar para viabilizar a administração distribuída. A figura 2.1 representa uma árvore com um espaço de nomes. Figura 2.1: Exemplo de um namespace O nó raiz tem nome., ele representa o nível mais alto da hierarquia que é o domínio raiz (root domain). Ele é também o único rótulo vazio em todo o namespace, isto se dá pelo fato de ele poder ser omitido, uma vez que é comum para todos os endereços. Fazendo novamente o uso de analogias, o domínio raiz seria equivalente a um diretório raiz do UNIX (/). Como dito anteriormente, todos os nós da árvore têm necessariamente um nome. O nome, que é o nome de domínio, pode ser relativo, considerando um determinado nó (i.e. o com em com.br.) ou absoluto (www.joinville.udesc.br.) este que é comumente chamado de FQDN (Fully Qualified Domain Name, ou Nome de Domínio Completamente Expressado). Pelo FQDN podemos saber em que nível na hierarquia do DNS o domínio se encontra. O nome absoluto de um nó da árvore é feita escrevendo o rótulo do nó mais a descrição do seu predecessor, conforme visto na figura 2.2. A descrição do predecessor de cada nó pode ser notada em destaque. Algumas observações merecem destaque: 1) O nome do nó raiz pode ser deixado

15 Figura 2.2: Caminhos absolutos e relativos em namespaces em branco, por conveniência; 2) O espaço de nomes DNS é case insensitive, isto é, não diferencia letras maiúsculas de minúsculas; 3) O rótulo de um domínio não pode ter mais do que 63 caracteres, e; 4) O FQDN não pode ter mais que 255 caracteres. Para organizar a hierarquia do DNS e permitir que o sistema seja administrado de maneira distribuída, evitando colisões de nomes, são usadas delegações de espaços de nomes. Essas delegações passam porções de um determinado domínio para uma administração separada, obedecendo a certas normas que previnem, por exemplo, que uma porção delegada adicione entradas em locais onde ela não tem esse tipo de permissão. Dessa maneira é possível descentralizar o sistema de nomes enquanto é mantida a hierarquia. Essa divisão gera dois conceitos importantes dentro do escopo do DNS, domínios e zonas, que serão vistos a seguir. Domínios Domínios representam toda a estrutura hierárquica de um nó, incluindo o próprio nó. A figura 2.3 ilustra um exemplo de domínio. Os nomes de domínios são usados para identificar entidades administrativas independentes ou mesmo máquinas individuais do DNS. Como dito anteriormente, os nós das árvores podem representar estações isoladas. Novamente no caso da figura 2.3, todos os nós representados pelos rótulos www, com exceção do www.gallois.com.br. são máquinas que per-

16 br net domínio udesc.br com org udesc gallois joinville faed www www moodle www Figura 2.3: Exemplo de domínio tencem ao domínio udesc.br. No caso, todos os nós que pertencem a uma subárvore fazem parte do domínio representado pela mesma. O domínio é responsável por delimitar as fronteiras administrativas do DNS. Embora o nome de cada nó possa ser definido pelo administrador responsável pelo domínio, não se pode utilizar o mesmo rótulo para dois nós que sejam filhos diretamente do mesmo pai, pois isso acarretaria em colisão de nomes (ALBITZ; LIU, 2006). Essa restrição, entretanto, não aplica-se a todos os nós da árvore, especificamente os que não são irmãos, conforme pode ser visto na figura 2.4. Em resumo, um domínio é uma subárvore pertencente ao namespace de um outro domínio. Uma vez que informações sobre nomes de domínios são apenas índices na base de dados do DNS, a identificação de um domínio com diversas máquinas ou uma estação é apenas uma questão de interpretação do arquivo de configuração do servidor de nomes. Em geral, os nós folha de uma árvore que representa um domínio são estações e os interiores representam uma estação e apontam para outras informações, embora não seja regra. Um exemplo é mostrado na Figura 2.5. Uma técnica para descobrir se duas estações ou domínios fazem parte de um outro domínio é usar o seu FQDN. Se o final de seu nome for igual ao do que se deseja comparar, então eles são parte do mesmo subdomínio. Por exemplo, joinville.udesc.br. e faed.udesc.br. fazem parte do mesmo subdomínio, uma vez que ambos terminam com udesc.br.. De maneira semelhante, tanto joinville.udesc.br. como faed.udesc.br. e udesc.br. fazem parte de.br. e assim

17 br com udesc gallois joinville www www www www Figura 2.4: Dois nós podem ter o mesmo nome a menos que sejam irmãos endereço IP de udesc.br br udesc joinville faed esag Figura 2.5: Exemplo de domínio com registro apontando para uma estação e outras informações

18 por diante (ALBITZ; LIU, 2006). Um grupo particularmente interessante de domínios é o dos TLDs (Top Level Domains ou domínio de primeiro nível DPN). Eles estão no primeiro nível na estrutura do DNS, isto é, são descendentes diretos do root domain. Em todos os domínios utilizados, eles representam a última parte do nome de domínio. A IANA (Internet Assigned Numbers Authority) é responsável pela manutenção da zona de root do DNS e consequentemente da delegação dos TLDs (IANA, 2009). Atualmente, a IANA distingue dois tipos de Top Level Domains, que têm alguns exemplos mostrados na Tabela 2.1: cctld (country-code Top Level Domains) Domínios com duas letras, representam países e territórios gtld (generic Top Level Domains) Domínios com três ou mais caracteres Tabela 2.1: Exemplos de cctlds e gtlds. (fonte: IANA) cctld País gtld Entidade.au Austrália.biz Negócios.br Brasil.com Comércio.ca Canadá.edu Instituições de ensino.de Alemanha.gov Agências e entidades governamentais.fr França.jobs Publicação de vagas de emprego.gr Grécia.mil Organizações militares.hk Hong Kong.mobi Para sites voltados a dispositivos móveis.jp Japão.name Para nomes de pessoas.uk Reino Unido.org Organizações não governamentais A responsabilidade de administração do TLD delegado ao Brasil, o.br, é atualmente do Núcleo de Informação e Coordenação do Ponto BR (NIC.BR, 2009). Através do registro.br é possível cadastrar domínios dentro do TLD.br. Esses são chamados de SLDs (Second Level Domains ou Domínios de Segundo Nível).

19 Zonas Para entender as zonas é necessário antes definir uma delegação. A delegação é usada para alcançar a descentralização no DNS. Com ela, uma determinada porção do namespace (um subdomínio) tem sua responsabilidade administrativa transferida. A essas porções denominam-se zonas. Com as delegações, o responsável pela manutenção de um determinado domínio divide essa tarefa com outros, precisando apenas manter registros que apontem para as outras zonas de modo que as consultas DNS sejam redirecionadas corretamente. A diferença entre domínios e zonas é sutil. Os domínios podem se tornar muito complexos para serem administrados pela grande quantidade de subdomínios existentes como, por exemplo, um TLD ou um domínio de uma corporação, como a apple.com. Como já vimos anteriormente, é feita a delegação de partes do domínio para que sejam criadas unidades menores e mais fáceis de administrar (ALBITZ; LIU, 2006). Dessa forma percebe-se que um domínio é formado por uma ou mais zonas. Essa estrutura é lógica de um ponto de vista organizacional uma vez que faz mais sentido que a UDESC administre o seu subdomínio do que os responsáveis pelo.br. Seguindo essa linha, o subdomínio udesc.br também pode ser repartido em outras zonas de delegação, uma para cada campus conforme o exemplo hipotético da Figura 2.6. Figura 2.6: Exemplo de zona 1

20 É importante notar que a divisão de zonas é muito mais lógica e organizacional do que geográfica. Podem haver computadores em diversas localidades geográficas pertencendo a uma mesma zona. Um exemplo disso são os root servers que contam com 191 servidores atualmente. Uma lista de todos eles pode ser encontrada na Internet 1. Há ainda a situação onde um determinado domínio não faz a delegação de administração de um subdomínio e o faz para outros (LANGFELDT, 2000). Isso torna mais clara a distinção entre domínios e zonas. Na Figura 2.7 podemos observar que os subdomínios virtual.udesc.br e esag.udesc.br estão sob administração de udesc.br e os outros subdomínios foram delegados. Figura 2.7: Exemplo de zona 2 Servidor de nomes Os nameservers (servidores de nomes) são os programas de computador responsáveis por armazenar e distribuir informações sobre o espaço de nomes de uma determinada zona. Existem dois tipos básicos de servidores de nomes, determinados por suas funções, que são chamados de mestres e escravos. Quando os nomes são obtidos da máquina local, o servidor de nomes é dito mestre. Caso a resolução precise ser feita contatando um outro servidor, o nameserver é escravo. 1 http://root-servers.org/

21 A redundância de servidores é uma prática comum para evitar indisponibilidades e garantir a escalabilidade, inclusive sendo frequente a utilização de um servidor de nomes para a zona em uma rede separada. Isto é feito pois caso seja impossível alcançar aquela zona por algum motivo, ainda será possível acessar os mapeamentos através de um outro servidor de nomes. A diferenciação entre servidores de nomes mestres e escravos é visível unicamente no que diz respeito à administração interna da zona, sendo completamente transparente para o usuário final. Tendo em vista o cenário mostrado na Figura 2.7 fica evidenciado o porquê de um servidor de nomes carregar um arquivo contendo informações sobre zonas e não domínios. As informações de um domínio inteiro podem exceder em muito o necessário, contendo dados que foram delegados a outros nameservers. Como as zonas são limitadas pela delegação, elas são a unidade mínima administrativa de um nameserver. Por esse motivo, os servidores de nomes devem carregar informações de zonas e não domínios, pois caso o contrário eles teriam dados que já foram delegados a outros servidores, sendo então inúteis para o seu propósito (ALBITZ; LIU, 2006). Para facilitar o entendimento, basta imaginar a quantidade de registros presentes em um servidor da zona raiz. Este volume provavelmente seria suficiente para implicar em danos consideráveis ao desempenho do servidor, além de ser desnecessário. A delegação de zonas consiste, na prática, em especificar no seu nameserver qual é o servidor de nomes responsável por responder a uma consulta de uma máquina que está no seu subdomínio mas não na sua zona. Como essa distribuição será feita, no que diz respeito aos limites de cada zona, cabe ao administrador decidir (TANENBAUM, 2003). No caso de um servidor de nomes receber a consulta por um determinado domínio que faz parte de uma zona que está sendo delegada por um nameserver, este só necessita encaminhar a consulta para o servidor de nomes da zona (ALBITZ; LIU, 2006). Zonas Reversas Na comunicação entre computadores, o protocolo IP fornece apenas o endereço da estação de origem. O DNS fornece um meio para que sejam consultados nomes a partir do endereço IP, chamado de consulta reversa. Os detalhes das consultas, tanto diretas quanto reversas serão tratadas mais detalhadamente na seção 2.3.

2.2.2 Configuração de Zonas 22 A configuração de uma zona é feita através de um arquivo de zona, ou zone file. Esses arquivos carregam informações sobre a zona em questão, como quais são os hosts presentes na mesma, quais os endereços de servidores, de emails, subdomínios e nameservers de zonas delegadas, traduzindo-os para uma linguagem conhecida pelo protocolo DNS (AITCHISON, 2005). Ainda dentro desses arquivos existem informações sobre quanto tempo as informações serão armazenadas nos servidores locais quando fazem consultas a outro nameserver. Essa característica é importante do ponto de vista de segurança e será tratada em maiores detalhes no capítulo 3. 2.2.3 Registros Um arquivo de configuração de zona é composto por diversos registros (RR ou Resource Records). Esses registros são responsáveis por definir os mapeamentos de nomes entre nomes e endereços e vice-versa. A Tabela 2.2 mostra alguns tipos comuns de RRs (MAZIERO, 2010). Tabela 2.2: RRs mais comuns no DNS RR SOA NS MX A AAAA CNAME PTR Função Indica o responsável pela zona (servidor primário) Indica um servidor de nomes para a zona Indica um servidor de emails para a zona Indica o endereço IP de um nome de domínio Idem ao anterior, utilizado em IPv6 Indica um alias (atalho) para um nome de domínio Indica o nome de domínio para um dado endereço IP Além dos registros descritos acima, existem mais dois tipos de entradas em um arquivo de configuração de zona. Tudo que estiver escrito após um ; (ponto-e-vírgula) é um comentário, isto é, o que estiver depois será descartado pelo nameserver. Além disso, linhas iniciadas por $ (cifrão) são diretivas e servem para controlar o processamento de arquivos de

23 zona (AITCHISON, 2005). Esses dois tipos, juntamente com os RRs, representam todas as alternativas válidas a serem escritas em um arquivo de configuração de zona. Entre as diretivas que podem ser utilizadas, destacam-se: $INCLUDE Recebe como parâmetro um outro arquivo de configuração de zona que será incluído no mesmo; $ORIGIN Recebe como parâmetro um domínio que será adicionado ao final de todos os domínios de registros que não terminarem com. ; $TTL Recebe como parâmetro um tempo para o caching nos servidores. Caso algum registro não tenha um tempo TTL especificado, o valor utilizado na diretiva prevalecerá. As colunas existentes em um arquivo de configuração de zonas são as seguintes: domain_name time_to_live class type value domain name Especifica a qual domínio o registro se aplica. A ordem em que esses registros são apresentados não tem importância; time to live Determina quanto tempo um determinado registro deve perdurar no cache. Um valor alto significa uma entrada estável, com pouca chance de mudanças. Um valor baixo indica que o registro é bastante volátil e tende a mudar bastante; class Informa o tipo de classe da informação, para a Internet usa-se IN. Na prática é o valor mais encontrado (TANENBAUM, 2003); type Um dos tipos descrito na Tabela 2.2; value Valor do registro, pode ser tanto um número, quanto um domínio ou uma string ASCII, dependendo do tipo do registro. 2.3 Funcionamento Esta seção descreve os princípios de funcionamento do DNS. Como existem falhas de segurança que são intrínsecas ao protocolo (AGER, 2005), este merece atenção especial. A especificação original do protocolo DNS pode ser encontrada nas RFCs 1033, 1034 e 1035 (LOTTOR, 1987; MOCKAPETRIS, 1987a; MOCKAPETRIS, 1987b).