Introdução ao DNS by Novatec Editora

Allan Liska Geoffrey Stowe

Novatec

Copyright © 2016 Elsevier Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek permission, further information about the Publisher’s permissions policies and our arrangement with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions. This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein). This edition of DNS Security: Defending the domain name system - 9780128033067 by Allan Liska and Geoffrey Stowe is published by arrangement with ELSEVIER INC., a Delaware corporation having its principal place of business at 360 Park Avenue South, New York, NY 10010, USA. Nenhuma parte desta publicação pode ser reproduzida ou transmitida de qualquer forma ou por qualquer meio, eletrônico ou mecânico, incluindo fotocópia, gravação ou qualquer armazenamento de informação e sistema de recuperação, sem permissão por escrito da editora. Detalhes sobre como pedir permissão, mais informações sobre as permissões de políticas da editora e o acordo com organizações como o Copyright Clearance Center e da Copyright Licensing Agency, podem ser encontradas no site: www.elsevier.com/permissions. Este livro e as contribuições individuais contidas nele são protegidos pelo Copyright da Editora (além de outros que poderão ser aqui encontrados). Esta edição do livro DNS Security: Defending the domain name system - 9780128033067 de Allan Liska e Geoffrey Stowe é publicada por acordo com a Elsevier Inc., uma corporação de Delaware estabelecida no endereço 360 Park Avenue South, New York, NY 10010, EUA. © Novatec Editora Ltda. 2016. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia autorização, por escrito, do autor e da Editora. Editor: Rubens Prates Tradução: Lúcia A. Kinoshita Revisão gramatical: Priscila A. Yoshimatsu Editoração eletrônica: Carolina Kuwabata ISBN: 978-85-7522-533-2 Histórico de impressões: Novembro/2016

Primeira edição

Novatec Editora Ltda. Rua Luís Antônio dos Santos 110 02460-000 – São Paulo, SP – Brasil Tel.: +55 11 2959-6529 E-mail: novatec@novatec.com.br Site: www.novatec.com.br Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec

capítulo 1

Compreendendo o DNS

Informações contidas neste capítulo • • • • •

História do DNS A raiz Serviços recursivos e autoritativos Arquivos de zona Registros de recursos

Introdução Antes de discutir maneiras de garantir a segurança da infraestrutura de DNS, é importante compreender o que é DNS e o que deve ser protegido. O DNS tradicionalmente tem sido algo em que muitas organizações pensam a posteriori. Com frequência, a inicialização e a manutenção da infraestrutura de DNS de uma organização são atribuídas às pessoas responsáveis pela configuração e correção dos servidores web ou àquelas que configuram e administram os dispositivos de rede. Muitas vezes, essas pessoas não são treinadas para lidar com a complexidade do DNS e confiam em informações obtidas de várias fontes na web, algumas das quais são ótimas, enquanto outras, bem, nem tanto. Do ponto de vista da segurança, isso pode ser extremamente problemático. Como podemos esperar que uma pessoa garanta eficientemente a segurança de uma solução que ela não compreende? Falando de modo 16

Capítulo 1 ■ Compreendendo o DNS

simples, ela não pode; sem uma compreensão sólida dos princípios, não podemos esperar que um administrador compreenda as nuances associadas à proteção do sistema, muito menos que se mantenha atualizado e perceba os riscos impostos pelo volume de vulnerabilidades publicadas somente sobre esse assunto anualmente. Considerando a grande quantidade de vulnerabilidades de DNS publicada todos os anos e o número de maneiras pelas quais um administrador pode expor uma infraestrutura de DNS a um ataque, é mandatório que aqueles que administram as instalações de DNS compreendam os princípios por trás dele para que sejam capazes de garantir adequadamente a segurança dessas instalações. O melhor lugar para começar é definindo o que é DNS. O acrônimo DNS significa Domain Name System (Sistema de Nomes de Domínio), embora algumas pessoas usem DNS para se referir a Domain Name Servers (Servidores de Nomes de Domínio). O DNS é um banco de dados redundante, hierárquico e distribuído, usado para passar informações sobre nomes de domínio. A divergência quanto ao acrônimo mostra a dificuldade que qualquer pessoa teria para documentar o DNS. Se elas não são capazes de sequer concordar em relação ao significado do acrônimo, como poderiam concordar em tudo o mais? À medida que progredir neste livro, você perceberá que os administradores de DNS raramente concordam com tudo. Na maioria das vezes, a metáfora usada para descrever o DNS é a de uma árvore. O DNS tem uma raiz, e os vários TLDs (Top Level Domains, ou Domínios de Nível Superior) são semelhantes aos galhos que saem da raiz. Cada galho tem galhos menores, que são os Second Level Domains (Domínios de Segundo Nível), e as folhas são os FQDNs (Fully Qualified Domain Names, ou Nomes de Domínio Totalmente Qualificados), às vezes chamados de nomes de host (hostnames). Não pense que essa árvore é uma palmeira tranquila ou um carvalho robusto. É uma árvore monstruosa, plantada no cimento, com raízes que se enroscam umas nas outras e galhos que se estendem para todas as direções; com frequência, a impressão que temos é que ela se mantém unida mais pela força de vontade do que por qualquer outro motivo. Se o DNS é uma árvore, ela se assemelha mais à Árvore de Banyan, em Lahaina, no Maui. A Banyan tinha cerca de 2,4 metros de altura quando foi plantada em 1873; atualmente, ela tem mais de 18,3 metros de altura e se espalha por mais de

Segurança de DNS

2.700 m2. De modo muito semelhante ao DNS, a Árvore de Banyan cresceu dessa maneira lançando novas raízes a partir de seus galhos; essas raízes passaram a ser novos troncos da Árvore de Banyan. O fluxo completo de uma consulta de DNS, de uma estação de trabalho até a resposta, está representado na Figura 1.1. Autoritativo O servidor autoritativo informa ao servidor recursivo o endereço IP de www.dns-book.net

Raiz do TLD .net A raiz do TLD .net diz ao servidor recursivo para perguntar ao servidor autoritativo por dbs-book.net

Raiz O servidor-raiz diz ao servidor recursivo para perguntar à raiz do TLD .net Servidor recursivo local

Usuário

O servidor recursivo verifica o seu cache e, então, acessa os servidores-raiz e fornece a resposta

O usuário acessa www.dns-book.net

Figura 1.1 – Uma versão estilizada do fluxo de tráfego de uma consulta de DNS.

O DNS é importante não só para a funcionalidade da internet, mas também para a funcionalidade de praticamente qualquer organização de tamanho razoável. Um servidor DNS configurado de forma precária pode causar impactos em toda a organização, e um servidor DNS ou

Capítulo 1 ■ Compreendendo o DNS

domínio cuja segurança seja precária oferece a um invasor uma porta de entrada fácil para a rede da empresa. Mesmo que uma organização esteja devidamente protegida, o DNS ainda pode ser usado como um vetor de ataque contra uma organização. Este capítulo aborda o básico sobre DNS – foi concebido para apresentar uma visão geral do processo de DNS e não se preocupa em fornecer muitos detalhes. Começaremos com o surgimento do DNS e, em seguida, passaremos para o sistema de raiz, veremos detalhes dos diferentes tipos de servidores DNS, como eles conversam uns com os outros e que tipo de informações são transmitidas entre eles.

História do DNS Quando a maioria das pessoas pensa nos grandes nomes da Internet, Bill Gates, Steve Jobs, Marc Andreessen e Mark Zuckerberg vêm à mente. Sem dúvida, essas pessoas fizeram grandes contribuições para o progresso da Internet (ou para a sua queda, dependendo da pessoa a quem você perguntar), mas há todo um grupo de pessoas cujo impacto foi muito mais profundo. Essas contribuições não necessariamente resultaram em IPOs (Initial Public Offerings, ou Ofertas Públicas Iniciais) de muitos milhões de dólares, mas sem elas a Internet não seria o que é hoje.

Arquivo hosts.txt A Internet às vezes é comparada a um organismo. Como qualquer organismo, ela evolui com o tempo e, deixa traços de sua existência anterior. Nesse caso, um remanescente do precursor do DNS – o arquivo hosts.txt – ainda pode ser encontrado em muitos sistemas. Para compreender por que o DNS se tornou necessário, dê uma olhada no arquivo /etc/hosts em sistemas UNIX, em %systemroot%\system32\drivers\ etc\hosts.txt no Windows ou no arquivo hosts.txt em dispositivos Android. O formato de todos esses arquivos é o mesmo: Endereço IP Nome do Computador Comentário

Segurança de DNS

Esses arquivos são usados para mapear endereços IP a nomes de host; em outras palavras, eles têm a mesma função do DNS e foram o seu precursor. Antes da introdução do DNS, o arquivo de hosts era usado como o principal método para compartilhar dados sobre nomes de host. Dois eventos contribuíram para o surgimento do arquivo de hosts. Em dezembro de 1973, e em conjunto com uma descrição na RFC 592, uma convenção “oficial” para nomenclatura de hosts foi definida. Números, letras e traços eram os únicos caracteres permitidos nos nomes de host; parênteses eram permitidos como parte dos nomes de rede. Depois que a lista de nomes de host (todos os 81!) foi reunida, o próximo passo veio com as RFCs 606 e 608. Essas RFCs descrevem a criação de um novo arquivo centralizado chamado HOSTS.TXT, que poderia ser baixado por meio de FTP para que todos os administradores conectados à Arpanet tivessem os mesmos dados referentes aos nomes de host. É interessante observar que, embora essa ideia fizesse bastante sentido pensando retrospectivamente, o autor da RFC 606, L. Peter Deutsch, sentiu-se no dever de acrescentar o seguinte texto de aviso: Percebo que há uma armadilha de longa data associada às sugestões como esta apresentada aqui: ela representa uma solução específica para um problema específico e, desse modo, pode não ser compatível nem constituir uma base razoável para soluções mais genéricas para problemas mais genéricos. No entanto, (1) esse problema em particular tem preocupado, a mim e a outras pessoas com quem conversei, por bem mais de um ano, e é realmente absurdo que ele tenha permanecido sem solução por tanto tempo assim; (2) ninguém parece estar particularmente interessado em resolver qualquer problema mais genérico.

O primeiro arquivo hosts.txt foi disponibilizado online em 25 de março de 1974 e foi anunciado pela RFC 627. Antes do lançamento do primeiro arquivo hosts.txt, outra instituição do DNS foi introduzida. As RFCs 623 e 625 discutiram colocar o arquivo hosts.txt em um servidor adicional. Se o servidor principal OFFICE-1 estivesse indisponível, um host poderia recuperar o arquivo do servidor secundário. Novamente, isso era muito semelhante ao modo como o DNS funciona atualmente.

Capítulo 1 ■ Compreendendo o DNS

Problemas com correio eletrônico A Arpanet continuou funcionando dessa maneira durante mais de uma década. À medida que mais organizações se conectavam a essa Internet, tornou-se claro que havia alguns problemas com o sistema, particularmente no que dizia respeito à aplicação mais comumente usada: o correio eletrônico (computer mail). O problema com o correio eletrônico era o fato de haver pessoas demais usando o sistema, de modo que se tornou difícil para os postmasters administrarem as mensagens de correio. O formato dos endereços de correspondência era baseado nos endereços no arquivo de hosts. Assim, se alguém quisesse enviar uma mensagem para Allan Liska na Example Corp., o formato seria algo do tipo liska@example ou aliska@example. Isso não era um problema, desde que houvesse apenas um computador ao qual os usuários da empresa originadora estivessem conectados. Porém, a popularidade da Arpanet estava aumentando, e os usuários de computadores não estavam isolados em um departamento e nem mesmo em um campus. Havia usuários da Arpanet espalhados em diversas organizações e em vários lugares. À medida que a popularidade da Arpanet aumentava, os postmasters precisavam adicionar servidores de correio eletrônico em vários lugares. Cada um devia receber um nome de host único, que deveria então ser acrescentado ao arquivo hosts.txt. Se Allan Liska estivesse no escritório da Example Corp. na Virgínia, um nome de host para esse escritório deveria ser criado. Em vez de enviar um email para liska@example, ela deveria ser enviada para liska@exampleva. Por outro lado, se Bruce Liska estivesse no escritório da Example Corp. na Califórnia, a correspondência eletrônica deveria ser enviada para liska@exampleca. Isso geraria uma tremenda confusão – se o remetente não tivesse certeza do escritório em que uma pessoa estava localizada ou desconhecesse as diversas convenções de nomenclatura, era muito fácil enviar a correspondência para um endereço incorreto. Esse cenário criou um problema com o qual os postmasters deveriam lidar. Afinal de contas, depois que uma pessoa tivesse sido exposta ao correio eletrônico, ela não poderia se ver privada desse recurso. Em 11 de janeiro de 1982, houve uma reunião para discutir esse problema de correio

Segurança de DNS

eletrônico, entre outros, e desenvolver uma solução. Algumas das pessoas que participaram da reunião incluíam Vint Cerf, Bill Joy, Dave Crocker, Paul Mockapetris, David Mills e, é claro, Jon Postel. Os resultados da reunião foram publicados na forma da RFC 805, “Computer Mail Meeting Notes” (Notas da reunião sobre correio eletrônico). O título banal mascara a importância que esse documento teve para o DNS. A solução proposta durante a reunião foi uma combinação de um acréscimo ao formato do correio eletrônico na época e a incorporação de “Internet Domain Names” (Nomes de Domínio da Internet), proposta por David L. Mills na RFC 799. Segundo a proposta básica, o formato do sistema de endereços de correio eletrônico deveria ser expandido por meio do acréscimo de dois níveis, chamados nós, ao esquema de endereço em vigor. Além do “endereço” arroba “host”, a proposta acrescentava os nós para organização e domínio ao endereço. No exemplo anterior, se você quisesse enviar uma correspondência para Allan Liska na Example Corp., o formato passaria a ser “endereço” arroba “nome do host” separador de nós “empresa” separador de nós “domínio” – por exemplo, allan@mailserver.example.in (.in para um Internet Address, ou Endereço de Internet). Esse sistema facilitaria bastante a administração da correspondência eletrônica para os usuários de organizações geograficamente dispersas. Os endereços poderiam ser separados do ponto de vista geográfico. Se alguém quisesse enviar uma correspondência para Allan Liska no escritório da Example Corp. na Virgínia, o endereço poderia ser allan@va.example.in; por outro lado, Bruce Liska no escritório da Califórnia teria um endereço como bruce@ca.example.in. Obviamente, isso daria muito mais liberdade às organizações e facilitaria a vida dos administradores de correio eletrônico. É claro que essa mudança também significou ter de reescrever os programas de correio eletrônico para que eles pudessem lidar com vários nós. Em março de 1982, o primeiro servidor HOSTNAMES foi disponibilizado online. Esse servidor não tinha suporte para consultas a domínios. Era usado principalmente para compartilhar informações sobre redes, gateways e hosts, mas utilizava o mesmo formato que, futuramente, seria seguido pelas consultas de domínio.

Capítulo 1 ■ Compreendendo o DNS

RFCs 819 e 920 A RFC 819 marca um salto enorme na evolução dos domínios; ela descreve a estrutura de domínios e definiu as bases para uma infraestrutura de DNS. Jon Postel e Zaw-Sing Su escreveram a RFC 819, cujo título é “The Domain Naming Convention for Internet User Applications” (A convenção de nomenclatura de domínios para aplicações de usuários da Internet), e ela foi publicada em agosto de 1982. A RFC é, na verdade, um framework para uma infraestrutura de DNS. Seu foco não está nas especificidades, permitindo que elas sejam definidas por outras pessoas. Esse é um dos bons aspectos relacionados ao protocolo de DNS: ele sempre foi menos rígido que outros protocolos, tornando-o bastante adaptável a mudanças. Essa flexibilidade também faz do DNS um alvo para aqueles que desenvolvem padrões. Com frequência, eles querem criar novas extensões no DNS ou tentam usar o protocolo de maneiras para as quais ele jamais foi projetado. Aparentemente, o ano seguinte foi tranquilo no que concerne ao DNS – o framework definido na RFC 819 estava sendo refinado e moldado. Em 1983, três RFCs foram publicadas em rápida sucessão. As RFCs 881, 882 e 883 organizaram o framework para a infraestrutura atual de DNS. Três RFCs moldaram o modo como o DNS funciona atualmente. As RFCs 882 e 883, escritas por Paul Mockapetris, foram especialmente importantes, pois discutiram o modo como as pesquisas de DNS seriam feitas, além de apresentarem uma visão geral sobre delegação, que é a marca registrada do DNS e um dos motivos pelos quais ele tem sido tão bem-sucedido. Depois que a discussão sobre o design do DNS foi concluída – o que demorou quase um ano a mais –, a RFC 920 foi lançada. Essa RFC, publicada em outubro de 1984, definiu os requisitos para realmente implementar o DNS em toda a Arpanet e os passos que deveriam ser executados. A RFC 920 também concluiu a lista inicial de TLDs: Arpanet (que deveria ser um TLD temporário), .GOV, .MIL, .EDU, .COM, .ORG e os domínios de códigos de países com duas letras. As pessoas envolvidas na criação inicial do DNS queriam que ele fosse implantado rapidamente, e a RFC 920 definiu um ritmo acelerado. A partir do lançamento da RFC 920, tudo estava pronto para ser iniciado e novos domínios foram registrados em seis meses. De fato, o primeiro

Segurança de DNS

domínio não TLD registrado foi o NORDU.NET em 1 de janeiro de 19851. A Defense Information Systems Agency (Agência de Sistemas de Informação de Defesa), que então controlava a Arpanet, concedeu a manutenção da infraestrutura de raiz ao Stanford Research Institute (Instituto de Pesquisas de Stanford), e a moderna infraestrutura de DNS nasceu.

Rumo à comercialização O DNS prosseguiu praticamente sem mudanças nos anos seguintes. Em outubro de 1992, o NSF (National Science Foundation, ou Fundação Nacional de Ciência) – ou, mais especificamente, a NSFNet, que havia assumido a responsabilidade pela Arpanet em 1986 – concedeu um contrato de serviços de administração à Network Solutions Inc. Foi uma mudança enorme, pois passou o controle do DNS, em sua maior parte nas mãos da comunidade acadêmica, para o setor privado. Até 1995, qualquer um que quisesse um nome de domínio podia registrar um. À medida que mais pessoas perceberam o valor comercial da Internet, alguns começaram a registrar centenas de domínios, achando que eles poderiam ser valiosos no futuro. Para acabar com a disseminação dessa prática e recuperar parte dos custos de manutenção da infraestrutura de DNS, a Network Solutions, com a aprovação da NSF, começou a cobrar uma taxa para registrar nomes de domínio. A taxa inicial era de cem dólares por dois anos, com uma parcela de trinta dólares desse total sendo aplicada no suporte à infraestrutura da Internet. Isso estava alinhado às ideias do governo norte-americano na época, que tinha como incumbência privatizar e aumentar a concorrência na Internet. O Departamento de Comércio estava particularmente interessado no DNS e havia solicitado comentários do público sobre maneiras de ajudar a cumprir a incumbência do presidente Clinton. Em 1998, o governo publicou um artigo que descrevia a passagem do controle do DNS do domínio exclusivo da Network Solutions para uma organização independente que incentivasse a concorrência e estimulasse novos usos da Internet. A partir desse artigo, surgiu posteriormente a Icann (Internet Corporation for Assigned Names and Numbers, ou Corporação da Internet para Atribuição de Nomes e Números).

Capítulo 1 ■ Compreendendo o DNS

A Icann assumiu a administração dos servidores de nomes raiz em 1999 e deu início ao processo de registros. Empresas que atendam a um conjunto de requisitos podem registrar domínios em nome do público em geral. Esses domínios são inseridos nos vários bancos de dados de TLD e todos os agentes de registro (registrars) aprovados pela Icann podem registrar os TLDs genéricos.

Raiz (root) O coração do DNS é a raiz (root) ou, de modo mais apropriado, as várias raízes. Os sistemas-raiz mantêm dados autoritativos (ou de autoridade) sobre os domínios e ajudam a direcionar as requisições aos servidores apropriados. Há dois tipos de servidores-raiz usados em DNS: os servidores-raiz e as raízes de TLD. Em geral, quando as pessoas falam de servidores-raiz, elas se referem aos servidores-raiz consultados pelos servidores de nomes recursivos (discutidos na próxima seção). Os treze servidores de nomes raiz estão dispersos pelo mundo, são mantidos por organizações diferentes e estão em redes distintas. Além dos servidores de nomes raiz, cada TLD também tem o seu próprio servidor ou servidores-raiz. Esse servidor-raiz é autoritativo para informações sobre o TLD específico; o servidor-raiz de um domínio é o nó de nível mais alto da árvore de domínios e é representado por um “.” no final do nome do domínio. O “.” no final geralmente não é exibido fora da esfera do DNS, mas é importante lembrar-se de que ele está presente. Assim, o domínio example.com é devidamente apresentado como: example.com.

Os servidores TLD raiz não são consultados diretamente. Em vez disso, os servidores-raiz direcionam as consultas a esses servidores à medida que elas são processadas. Obviamente, isso faz com que o funcionamento dos servidores de nomes raiz seja crucial para a operação contínua da internet. Se os servidores de nomes raiz ficassem offline, a comunicação típica da internet seria interrompida em algum momento. Isso não significa que toda a comunicação na internet pararia; o roteamento e outros

Segurança de DNS

serviços que não dependem de DNS continuariam funcionando conforme esperado. Entretanto, serviços como email, FTP e HTTP rapidamente se tornariam inutilizáveis, pois dependem muito de DNS.

Ataques nos servidores de nomes raiz No final de outubro de 2002, o que na época havia sido o maior ataque DDoS (Distributed Denial of Service, ou Negação de Serviço Distribuído) jamais registrado foi lançado contra os servidores de nomes raiz, em uma tentativa de inutilizar a internet. Felizmente, a maioria dos usuários não tomou conhecimento desse distúrbio – um sinal de que o DNS é tão resiliente quanto se proclama que seja. Em fevereiro de 2007, outro grande ataque DDoS foi lançado contra os servidores DNS raiz; enquanto dois dos servidores sofreram danos temporariamente, os outros servidores-raiz continuaram a responder às consultas. O grupo Anonymous ameaçou tirar do ar os servidores DNS raiz em 31 de março de 2012. O ataque foi um fracasso total.

Um dos principais objetivos da configuração e manutenção dos servidores-raiz é a disponibilidade. O DNS deve ser redundante e altamente disponível, portanto os servidores-raiz devem ter alta disponibilidade. Para isso, eles estão dispersos pelo mundo, instalados em backbones diferentes e são mantidos por organizações distintas. Todos os servidores-raiz compartilham a mesma convenção de nomenclatura: a letra designada para eles, seguida do domínio root-servers.org. O primeiro é a.root-servers.org, o segundo é b.root-servers.org, e assim sucessivamente. Esses servidores estão entre os mais ocupados da internet. O servidor f.root-servers.org – sem dúvida, o mais ocupado – trata mais de 270 milhões de consultas por dia, embora tenha sido desenvolvido para tratar um número significativamente maior. Uma concepção equivocada persistente é que um servidor-raiz A é mais importante para a infraestrutura de DNS que os demais servidores-raiz. Isso não é verdade; todos os servidores de nomes raiz compartilham a carga igualmente, e todos os servidores-raiz contêm as mesmas informações sobre as raízes TLD.

Capítulo 1 ■ Compreendendo o DNS ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . <file>" ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC ; under anonymous FTP as ; file /domain/named.cache ; on server FTP.INTERNIC.NET ; -ORRS.INTERNIC.NET ; ; last update: November 05, 2014 ; related version of root zone: 2014110501 ; ; formerly NS.INTERNIC.NET ; . 3600000 NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:ba3e::2:30 ; ; FORMERLY NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201 B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:84::b ; ; FORMERLY C.PSI.NET ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 C.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2::c ; ; FORMERLY TERP.UMD.EDU ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 199.7.91.13

Seguranรงa de DNS D.ROOT-SERVERS.NET. 3600000 ; ; FORMERLY NS.NASA.GOV ; . 3600000 E.ROOT-SERVERS.NET. 3600000 ; ; FORMERLY NS.ISC.ORG ; . 3600000 F.ROOT-SERVERS.NET. 3600000 F.ROOT-SERVERS.NET. 3600000 ; ; FORMERLY NS.NIC.DDN.MIL ; . 3600000 G.ROOT-SERVERS.NET. 3600000 ; ; FORMERLY AOS.ARL.ARMY.MIL ; . 3600000 H.ROOT-SERVERS.NET. 3600000 H.ROOT-SERVERS.NET. 3600000 ; ; FORMERLY NIC.NORDU.NET ; . 3600000 I.ROOT-SERVERS.NET. 3600000 I.ROOT-SERVERS.NET. 3600000 ; ; OPERATED BY VERISIGN, INC. ; . 3600000 J.ROOT-SERVERS.NET. 3600000 J.ROOT-SERVERS.NET. 3600000 ;

AAAA 2001:500:2d::d

NS A

E.ROOT-SERVERS.NET. 192.203.230.10

NS F.ROOT-SERVERS.NET. A 192.5.5.241 AAAA 2001:500:2f::f

NS A

G.ROOT-SERVERS.NET. 192.112.36.4

NS H.ROOT-SERVERS.NET. A 128.63.2.53 AAAA 2001:500:1::803f:235

NS I.ROOT-SERVERS.NET. A 192.36.148.17 AAAA 2001:7fe::53

NS J.ROOT-SERVERS.NET. A 192.58.128.30 AAAA 2001:503:c27::2:30

Capítulo 1 ■ Compreendendo o DNS ; OPERATED BY RIPE NCC ; . K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. ; ; OPERATED BY ICANN ; . L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. ; ; OPERATED BY WIDE ; . M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. ; End of file

3600000 3600000 3600000

NS K.ROOT-SERVERS.NET. A 193.0.14.129 AAAA 2001:7fd::1

3600000 3600000 3600000

NS L.ROOT-SERVERS.NET. A 199.7.83.42 AAAA 2001:500:3::42

3600000 3600000 3600000

NS M.ROOT-SERVERS.NET. A 202.12.27.33 AAAA 2001:dc3::35

Os servidores-raiz não contêm informações sobre todos os TLDs disponíveis; eles apenas compartilham dados dos TLDs aprovados pela Icann. Esses incluem os TLDs genéricos, assim como os TLDs específicos de países. Há outros servidores TLD raiz que aceitam raízes “alternativas”. Eles são menos populares que os TLDs aprovados pela Icann e, por não haver dados sobre eles nos servidores-raiz, são inacessíveis pela maior parte da internet. Quando é aprovado pela Icann, um novo TLD será um domínio patrocinado ou não (a menos que seja um TLD de código de país, como .us ou .ca). Domínios patrocinados são aqueles TLDs usados para um mercado específico, como .aero (transporte aéreo) ou .museum (museus). A maioria dos TLDs não é patrocinada e, desse modo, está no controle da Icann e obedece às regras desenvolvidas por ela. A Icann não administra diretamente os TLDs; em vez disso, ela terceiriza a sua manutenção para várias organizações por um período de tempo contratado. Diferentes organizações operam TLDs distintos de acordo com os seus próprios conjuntos de regras, porém na esfera das regras especificadas

Segurança de DNS

pela Icann. Assim, a Icann, com o feedback da comunidade da internet, cria um novo TLD e terceiriza a sua manutenção para outra organização. Essa organização administra o servidor-raiz para o TLD específico e atualiza a Icann à medida que as informações sobre o TLD mudarem. Os ccTLDs (country code TLDs, ou TLDs de códigos de países) são tratados de modo um pouco diferente. Os ccTLDs têm como base os dois caracteres atribuídos a um país pela ISO (International Organization for Standardization, ou Organização Internacional para Padronização). A ISO mantém um documento – ISO 3166-1 – que lista os países junto com seus códigos de dois caracteres. A Iana (Internet Assigned Numbers Authority, ou Autoridade para Atribuição de Números na Internet) utiliza essa lista para determinar qual será o ccTLD de cada país. Afora a atribuição do ccTLD para cada país, a Iana não tem nada a ver com a operação cotidiana dos ccTLDs. Cada país é responsável por decidir como o seu ccTLD será implementado, ou mesmo se o será. Como cada país cria as suas próprias regras sobre o seu ccTLD, as regras para registrar e usar domínios ccTLD variam bastante.

Uma lista de todos os ccTLDs Uma lista completa dos ccTLDs, assim como as suas organizações patrocinadoras e outras informações importantes, podem ser encontradas no site da Iana em http://www.iana.org/domains/root/db.

Os ccTLDs interagem com os servidores-raiz do mesmo modo que os TLDs genéricos. A organização que mantém o ccTLD compartilha as mudanças em seu banco de dados com os servidores-raiz, e esses servidores direcionam as requisições à raiz de ccTLD conforme for apropriado. Embora seja importante compreender o que são os servidores-raiz e como eles funcionam, a verdade é que os vários servidores-raiz causarão bem pouco impacto nas operações cotidianas da maioria dos administradores de DNS. Os servidores de nomes raiz e os servidores TLD raiz são operados com um nível bem elevado de segurança e de disponibilidade. Mesmo que não o fossem, haveria muito pouco que um indivíduo ou uma empresa pudessem fazer a respeito.

Capítulo 1 ■ Compreendendo o DNS

Servidores recursivos e autoritativos Passando do quadro geral para o específico, esta seção descreve como as organizações descobrem informações sobre nomes de domínio e compartilham informações sobre os seus próprios nomes de domínio. Dois tipos de servidores são usados para essas tarefas: servidores recursivos, que monitoram informações sobre domínios, e servidores autoritativos (ou servidores com autoridade), que contêm informações sobre determinados domínios. Os servidores recursivos e autoritativos podem ser programas separados ou partes do mesmo programa; também podem ser executados no mesmo servidor ou em servidores distintos. Esta seção apresenta uma visão geral dos serviços.

Servidores de nomes recursivos Servidores de nomes recursivos são como um quadro branco. Eles não sabem nada sobre nomes de domínio; tudo que sabem é fazer perguntas. Sua tarefa é bem simples: alguém pergunta ao servidor de nomes recursivo sobre um domínio; ele se vira e pergunta para outro servidor, obtém a resposta e a devolve para a pessoa que originalmente fez a pergunta. Servidores de nomes recursivos estão na rede local ou na rede de um Internet Service Provider (Provedor de Serviços de Internet). Eles podem ser atribuídos manualmente a cada desktop, ou dinamicamente por meio do Dynamic Host Configuration Protocol (Protocolo de Configuração Dinâmica de Hosts) ou de um protocolo semelhante. Quando alguém usa uma aplicação que exija DNS, seu computador envia uma mensagem aos servidores recursivos configurados localmente; esses servidores consultam os servidores-raiz em busca de informações sobre o domínio e os servidores-raiz direcionam o servidor recursivo para dois ou mais servidores de nomes autoritativos. Esse processo está representado na Figura 1.2. O processo é incrivelmente simples, mas essa simplicidade esconde a complexidade do serviço por trás dele. Como em tudo o mais em DNS, a disponibilidade é importante e a maioria dos administradores de rede atribui pelo menos dois servidores DNS recursivos para cada estação de trabalho.

Segurança de DNS

O servidor-raiz direciona o servidor recursivo para o servidor TLD apropriado

O usuário quer acessar o site www.example.com

O servidor recursivo verifica se há alguma informação sobre esse domínio; se não houver, ele consulta os servidores de nomes raiz.

Figura 1.2 – O processo do servidor recursivo.

Um usuário que queira acessar www.example.com inicialmente fará uma consulta ao servidor de nomes recursivo na estação de trabalho, que terá um aspecto semelhante a este: Domain Name System (query) Transaction ID: 0x003e Flags: 0x0100 (Standard query) 0... .... .... .... = Response: Message is a query .000 0... .... .... = Opcode: Standard query (0) .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries www.example.com: type A, class inet Name: www.example.com Type: Host address Class: inet

Capítulo 1 ■ Compreendendo o DNS

Não se preocupe muito com os códigos: eles serão explicados em breve. As consultas de DNS são enviadas pela porta 53 usando UDP (User Datagram Protocol, ou Protocolo de Datagrama de Usuário). A estação de trabalho envia uma consulta, pedindo essencialmente o seguinte: “Gostaria de saber o máximo possível sobre example.com, mas estou particularmente interessado em um registro A para www.example.com”. O servidor recursivo responde com as informações a seguir: Domain Name System (response) Transaction ID: 0x003e Flags: 0x8580 (Standard query response, No error) 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .1.. .... .... = Authoritative: Server is an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... 1... .... = Recursion available: Server can do recursive queries .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... .... 0000 = Reply code: No error (0) Questions: 1 Answer RRs: 1 Authority RRs: 2 Additional RRs: 2 Queries www.example.com: type A, class inet Name: www.example.com Type: Host address Class: inet Answers www.example.com: type A, class inet, addr 192.0.34.166 Name: www.example.com Type: Host address Class: inet Time to live: 2 days Data length: 4 Addr: 192.0.34.166

Segurança de DNS

Com base na resposta, www.example.com é resolvido para o endereço IP 192.0.34.166. Após ter traduzido com sucesso o domínio para um endereço IP utilizável, a estação de trabalho faz uma requisição HTTP para www.example.com. Tudo isso ocorre sem qualquer interferência ou conhecimento do usuário da estação de trabalho. Como o servidor recursivo faz a sua consulta? Novamente, é um processo bem simples. O servidor de nomes recursivo executa um software de resolução, como o BIND, e utiliza esse software para consultar os servidores de nomes raiz. O software de resolução tem um arquivo de pistas, semelhante ao antigo arquivo hosts.txt, que contém uma lista dos servidores-raiz. Quando uma consulta chega ao servidor recursivo, ele guarda a requisição e consulta um dos servidores-raiz. O arquivo de pistas está disponível por meio de FTP no servidor de FTP InterNIC, e o seu nome default é named.root (embora diferentes sistemas operacionais e diferentes resolvers tenham convenções de nomenclatura distintas). O arquivo named.root tem um formato bem simples; ele contém uma lista dos servidores-raiz junto com seus endereços IP correspondentes. Quando uma consulta chega ao servidor recursivo, ele verifica se já sabe algo sobre o domínio; se não souber, ele consultará os servidores de nomes raiz.

Como saber qual servidor deverá ser consultado Como um servidor recursivo sabe qual servidor de nomes deve ser consultado? Um servidor de nomes recursivo calcula o RTT (Round Trip Time, ou Tempo de Ida e Volta) para consultas em cada servidor de nomes. O RTT é, essencialmente, uma corrida que mede o tempo – em milissegundos – que demora para obter o arquivo de zona. Quando um servidor recursivo inicia uma consulta, ele define o RTT para todos os servidores de nomes autoritativos com 0. O servidor recursivo então consulta todos os servidores de nomes aleatoriamente; aquele com o menor RTT após todos eles terem sido consultados será o servidor de nomes favorito. Depois de cada consulta, o RTT de todos os servidores, exceto do servidor de nomes anteriormente registrado como o “mais rápido”, é decrementado. Isso é feito de modo que os demais servidores de nomes, em algum momento, passarão a ser o primeiro a ser consultado, o que ajuda a distribuir a carga entre todos os servidores de nomes. Depois que o TTL inicial expirar, o processo de RTT começará novamente.

Capítulo 1 ■ Compreendendo o DNS

Servidores de nomes autoritativos A última parada no processo de consulta de DNS é o servidor de nomes autoritativo. Como o nome implica, servidores de nomes autoritativos contêm informações sobre um nome de domínio. Servidores recursivos consultam os servidores de nomes autoritativos para encontrar respostas específicas (por ex., qual é o endereço IP de www.example.com). Essas respostas são compartilhadas com outros computadores que consultam o servidor de nomes recursivo. Servidores de nomes autoritativos são hosts registrados junto à(s) autoridade(s) de TLD, nos quais o administrador do servidor de nomes pretende hospedar nomes de domínio. Depois que o host tiver sido registrado, ele poderá hospedar tantos domínios quantos o servidor puder tratar2. O processo funciona assim: uma organização inicialmente registra um domínio usando o seu agente de registro (registrar) predileto. A organização decide que vai administrar o DNS internamente; assim, ela cria um registro de host, por exemplo, ns1.example.com. Esse registro é criado por meio de seu agente de registro e é um mapa do nome do host para um endereço IP, armazenado nos servidores TLD raiz. Agora, não só ns1.example.com pode ter informações autoritativas para example.com, como também pode hospedar informações autoritativas de outros domínios. Quando um domínio é registrado, a organização simplesmente informa ao agente de registro para usar ns1.example.com como um dos servidores autoritativos. De modo alternativo, www.example.com pode ser registrado usando servidores autoritativos de terceiros, como neste exemplo: Domain Name: EXAMPLE.COM Registrar: RESERVED-INTERNET ASSIGNED NUMBERS AUTHORITY Whois Server: whois.iana.org Referral URL: http://res-dom.iana.org Name Server: A.IANA-SERVERS.NET Name Server: B.IANA-SERVERS.NET Status: clientDeleteProhibited Status: clientTransferProhibited Status: clientUpdateProhibited Updated Date: 14-aug-2015 Creation Date: 14-aug-1995 Expiration Date: 13-aug-2016

Segurança de DNS

Como as informações sobre servidores de nomes autoritativos são mantidas nos servidores TLD raiz, espera-se que elas sejam razoavelmente permanentes. Não é aconselhável registrar um nome de host que mude o seu endereço IP com frequência, especialmente pelo fato de poder demorar até três dias para que as mudanças no servidor de nomes autoritativo tenham efeito. Uma consulta aos servidores .COM raiz devolve os dois servidores de nomes autoritativos para o domínio example.com. O servidor de nomes recursivo então inicia uma corrida entre os dois servidores de nomes autoritativos para ver qual deles é mais rápido para responder. Dos dois servidores autoritativos, a.iana-servers.net responde mais rápido e devolve as informações solicitadas. Esse processo também está representado na Figura 1.3. O servidor TLD raiz direciona o servidor recursivo para o servidor de nomes autoritativo apropriado.

O servidor recursivo consulta o servidor TLD raiz.

Servidor recursivo

Figura 1.3 – O servidor TLD raiz direciona o servidor recursivo para o servidor autoritativo apropriado.

Na verdade, há dois tipos de servidores de nomes autoritativos: mestre (master) e escravo (slave) – também conhecidos como primário e secundário, embora esses termos sejam depreciados. O servidor de nomes mestre mantém informações autoritativas sobre um domínio e o(s) servidor(es) de nomes escravo extrai(em) informações do mestre usando um processo conhecido como transferência de zona. O relacionamento mestre-escravo é conveniente, pois significa que apenas um documento precisa ser mantido. Informações autoritativas sobre um domínio são automaticamente replicadas dos servidores de nomes mestre para os escravos. Ao automatizar o processo o máximo possível, há menos chances de erros humanos.

Capítulo 1 ■ Compreendendo o DNS

Conforme descrito na seção anterior, o servidor recursivo armazena as informações fornecidas pelo servidor autoritativo e oferece uma resposta ao solicitante original. O incrível é que tudo isso acontece em questão de milissegundos – na verdade, se essa transação demorar mais de um segundo, ela será considerada problemática.

Arquivos de zona O arquivo de zona é um arquivo-texto simples que contém informações autoritativas sobre um domínio. O arquivo original é armazenado no servidor de nomes mestre; o servidor de nomes escravo obtém uma cópia do arquivo de zona e o armazena localmente. Servidores recursivos solicitam informações do arquivo, mas não armazenam cópias locais; o servidor recursivo simplesmente reúne tantas informações quantas forem compartilhadas pelos servidores de nomes autoritativos. Um arquivo de zona às vezes será semelhante a isto: 1 $ttl 43200 2 example.com. IN SOA ns1.example.com. dns.example.com. ( 3 2003040401 4 10800 5 3600 6 432000 7 43200) 8 example.com. IN NS ns1.example.com. 9 ; Servidores 10 www IN CNAME example.com. 11 ftp IN A example.com. 12 mail 60 IN A 10.100.0.10 13 example.com. IN A 10.100.0.12 14 ; Servidores de nomes 15 example.com. IN NS ns1.foo.com. 16 example.com. IN NS ns2.example.com. 17 ; Servidores de email 18 example.com. IN MX 10 mail.example.com. 19 example.com. IN MX 50 mail.foo.com.

Segurança de DNS

Esse é um arquivo de zona bem básico e inclui os serviços mais comuns: Web, Mail e FTP. Um arquivo de zona mais extenso pode incluir uma lista das estações de trabalho ou de servidores adicionais; na verdade, alguns arquivos de zona podem ter milhares de linhas. A primeira linha no arquivo de zona define o TTL (Time to Live, ou Tempo de Vida) default – em segundos – para a zona; esse é o TTL que será usado para todas as entradas no arquivo de zona, a menos que outro TTL seja especificado. A linha 1 define o TTL default para essa zona com 12 horas. A linha 2 é, na verdade, o coração de um arquivo de zona e é a ferramenta que permite que diferentes servidores de nomes conversem uns com os outros; é o registro SOA (Start of Authority, ou Início de Autoridade). O SOA informa aos servidores de nomes recursivos quanto tempo um registro deve permanecer em cache e facilita a comunicação entre os servidores de nomes mestre e escravo. A linha 2 conterá a mesma informação para todos os domínios: Nome do domínio Classe Registro de recurso Origem Contato

O primeiro campo da linha é o próprio domínio, o segundo campo é a classe, que é sempre IN (abreviatura de Internet), e o terceiro campo é o RR (Resource Record, ou Registro de Recurso), que é sempre SOA. O próximo campo é o Servidor de Origem, que é o servidor mestre para esse domínio – o servidor a partir do qual as informações são extraídas. A informação nesse campo é a mesma nos servidores mestre e escravo e deve referenciar um nome canônico, não um CNAME ou um endereço IP. O último campo contém o contato de administrador para o nome do domínio. Deve conter a pessoa ou o grupo responsável pela manutenção do nome do domínio e do arquivo de zona. Observe o formato da informação de contato: todos os três campos estão separados por pontos e o primeiro ponto deve ser substituído por “@”, de modo que o campo seja realmente lido como dns@example.com.

Convenção para contatos Segundo a convenção-padrão para o campo de contato, o primeiro ponto deve ser substituído por “@” para que o endereço seja mantido da forma mais simples possível. Usar um endereço como dns.admin@example.com seria traduzido para dns.admin.example.com e poderia confundir alguém que estivesse tentando entrar em contato com o administrador desse domínio.

Capítulo 1 ■ Compreendendo o DNS

As linhas de 3 a 6 foram projetadas para serem usadas pelos servidores escravos. A linha 3 contém o número serial; esse campo deve ser atualizado sempre que uma mudança for feita no arquivo de zona do mestre. O formato-padrão é AAAAMMDDNN, mas qualquer formato pode ser usado, desde que sempre que uma mudança for feita, o número seja maior. A linha 4 é o intervalo de atualização. Expresso em segundos, esse campo informa aos servidores escravos a frequência com que eles devem fazer verificações junto ao servidor de nomes mestre para ver se houve alguma atualização. Quando o tempo expirar, os escravos consultarão o servidor mestre e verão se o número serial aumentou. Se ele não foi incrementado, o servidor escravo não fará nada; se o número foi incrementado, o servidor escravo iniciará uma transferência do arquivo de zona do mestre. Em geral, o campo de frequência de atualização tem um valor baixo para que os servidores mestre e escravo tenham as mesmas informações pelo máximo de tempo possível. A linha 5 é o campo de retentativas. É a quantidade de tempo – novamente, em segundos – que os servidores escravos esperarão após terem solicitado uma zona e não a terem recebido, até pedirem novamente. Lembre-se de que o protocolo de transporte default de DNS é o UDP. O UDP é um protocolo não orientado à conexão; os servidores escravos enviam a requisição e não sabem se o mestre a recebeu, e o mestre não sabe se os servidores escravos realmente obtiveram as informações enviadas a eles. O campo de retentativas compensa essa falta de comunicação com estados, forçando uma retentativa caso a ação desejada não seja recebida. A linha 6 é o campo de prazo de vencimento, que é o tempo em segundos que um escravo deve se ater aos seus dados quando o mestre não responder às consultas. Depois que esse tempo expirar, o servidor escravo descartará todas as informações que tiver sobre o nome do domínio. O propósito do prazo de vencimento é ajudar a evitar uma variedade de servidores órfãos mantendo informações imprecisas sobre os domínios. Não é incomum que um administrador transfira um domínio de um servidor para outro e se esqueça de apagar o arquivo de zona do servidor antigo – certamente, isso não é recomendável, mas acontece com mais frequência do que devia. A linha 7 serve especificamente para os servidores recursivos e contém o TTL default. Ela deve ter o mesmo valor que o TTL listado na linha 1.

Segurança de DNS

O restante do arquivo de zona é constituído de uma série de RRs, que serão discutidos em detalhes na próxima seção.

Registros de recursos Este capítulo progrediu do geral para o específico; esta seção é a mais específica e é também o coração do DNS. A principal função do DNS é compartilhar informações de modo a facilitar – e automatizar – o processo de acesso ao site www.example.com ou de envio de um email para user@example.com por alguém. Os RRs são as entradas em um arquivo de zona e fornecem as informações que os usuários estão procurando. Toda a disponibilidade embutida no DNS está presente somente para que as informações contidas nos RRs possam ser transferidas de um servidor autoritativo para um servidor recursivo e as pessoas possam acessar alegremente os sites, compartilhar arquivos etc. Um RR é uma entrada no arquivo de zona de um domínio, com uma função específica. Há muitos tipos de RRs, mas na verdade existem apenas cerca de dez que são mais comumente usados. Um dos RRs comuns, que já vimos, é o SOA. O SOA é excepcional no sentido de que é o único RR comum que não segue o formato-padrão. O formato-padrão de um RR é composto de cinco campos, cada um contendo informações específicas sobre o RR: Nome TTL Classe Tipo Dados

Na prática, o formato em geral se parece com isto: mail.example.com.

3600

10.10.100.102

É nesse caso que a importância do ponto no final se torna evidente. Se não houver um ponto no final de um domínio, o software de DNS geralmente interpretará isso como uma indicação de nome de host e o software anexará o domínio. No exemplo anterior, se não houvesse o ponto no final de mail.example.com, o software pensaria que o RR estaria se referindo a mail.example.com.example.com.

Capítulo 1 ■ Compreendendo o DNS

O campo Nome é o nome do host ou o endereço IP, conforme o registro; é o objeto que é o dono desse RR em particular. O TTL é usado somente se um TTL diferente daquele definido no SLA for exigido para um RR em particular. Se nenhum TTL for especificado, o TTL default da zona será usado. A Classe é sempre IN (Internet), que atualmente é a única classe aceita pelo DNS. O Tipo define o propósito do RR; no exemplo anterior, um registro “A” é um registro de endereço – outros registros serão discutidos a seguir. O campo Dados varia conforme o tipo de RR; os dados são as informações que o servidor de nomes está tentando compartilhar sobre esse RR em particular.

Registros de endereço O tipo mais comum de RR é o registro de endereço, ou A. Um registro A mapeia um FQDN para um endereço IP, como no exemplo anterior. Cada endereço de host em um domínio deve ter um registro A (hosts no arquivo de zona, mas que não façam parte do domínio, não exigem registros A nesse arquivo de zona) ou um registro de Nome Canônico (Canonical Name Record): mail.example.com. 3600 IN A 10.10.100.102

Lembre-se de que o campo TTL é opcional; se o RR puder usar o TTL default da zona, então não é necessário incluí-lo no RR. O registro A é o mais básico dos RRs e, sem dúvida, é o registro usado com mais frequência. Até mesmo um arquivo de zona simples geralmente terá de cinco a seis registros A. Se um FQDN apontar para vários endereços IP, o servidor de nomes os devolverá segundo o algoritmo round-robin. O primeiro servidor que solicitar o registro A obterá o primeiro registro, o segundo servidor obterá o segundo, o terceiro servidor obterá o terceiro etc. Depois que o servidor de nomes tiver devolvido todos os registros A, ele retornará novamente ao início. Há também um registro A projetado especificamente para endereços IPv6. Esse registro é conhecido como registro AAAA e segue o mesmo formato de um registro A, porém com um endereço IPv6: ipv6.example.com. 3600 IN AAAA

2001:468:504:1:210:5aff:fe1a:11e

Segurança de DNS

Registros de nomes canônicos Registros CNAME (Canonical Name, ou Nome Canônico) são aliases (apelidos) que mapeiam um FQDN para outro. Em vez de mapear um FQDN diretamente para um endereço IP, muitas vezes é mais fácil mapeá-lo para outro host. Isso é especialmente conveniente se houver muitos FQDNs que apontem para o mesmo endereço IP; quando uma mudança for feita no endereço principal, os demais endereços serão atualizados automaticamente. Um CNAME é semelhante a isto: www.example.com. 3600 IN CNAME mail.example.com. 3600 IN A

mail.example.com. 10.10.100.102

Para que o CNAME funcione, ele deve apontar para um FQDN com um registro A válido. Um CNAME não precisa apontar para um FQDN no mesmo arquivo de zona; ele pode apontar para outros FQDNs. www.example.com

3600 IN CNAME

www.foo.com.

Novamente, www.foo.com deve ter um registro A válido para esse CNAME funcionar. Outro aspecto importante sobre registros CNAME é que eles não podem ser usados por outros RRs. Nem o registro MX nem o NS podem apontar para registros CNAME.

Registros de servidor de mensagens O registro MX (Mail Exchanger, ou Servidor de Mensagens) é usado para definir os hosts para os quais os emails de um domínio devem ser enviados. Como no caso dos registros CNAME, os registros MX não precisam apontar para FQDNs no domínio; eles podem apontar para qualquer host, dentro ou fora do domínio – desde que esse host esteja configurado para receber emails desse domínio. Os registros MX devem apontar para FQDNs representados por registros A, não por registros CNAME. A maioria dos MTAs (Mail Transport Agents, ou Agentes de Transporte de Emails) modernos compreende registros CNAME e pode encaminhar emails para eles, mas alguns ainda não são capazes de fazê-lo. Isso também vai contra a RFC, portanto não faça isso.

Capítulo 1 ■ Compreendendo o DNS

Um registro MX terá um aspecto semelhante a isto: example.com. 3600 IN MX 10 mail.example.com. example.com. 3600 IN MX 20 mail.foo.com.

Há um campo que é exclusivo dos registros MX, chamado de peso do registro. O peso é usado para determinar as preferências para vários registros MX. Quanto menor o peso de um registro, maior será a preferência atribuída a esse registro. No exemplo anterior, mail.example.com é preferível a mail.foo.com. Um MTA tentando enviar emails para user@example.com tentará mail.example.com antes, e somente tentará mail.foo.com se ocorrer um timeout para mail.example.com ou o email for devolvido.

Registros de servidores de nomes Além de serem registrados como hosts, os servidores de nomes também devem ser definidos em um arquivo de zona como registros NS (Name Server, ou Servidores de Nome). Como o nome implica, os registros NS são usados para listar os servidores de nomes autoritativos para um domínio. Esses registros, em geral, são os primeiros RRs após o SOA e são formatados da seguinte maneira: example.com. example.com. example.com.

IN IN IN

NS NS NS

ns1.example.com. ns1.foo.com. ns2.example.com.

Como ocorre com os registros MX e CNAME, os registros NS não precisam apontar para um FQDN existente no arquivo de hosts; ele pode apontar para qualquer host que tenha informações autoritativas sobre o domínio. Um registro NS deve ser um FQDN; ele não pode ser um endereço IP. Além disso, ele deve apontar para um FQDN que seja um registro A, não um CNAME. Os registros NS também atendem a outro propósito. Para daemons DNS com capacidade para isso, o servidor de nomes mestre enviará atualizações do arquivo de zona para os servidores de nomes listados nesse arquivo de zona. Isso, é claro, é extremamente dependente da infraestrutura de DNS instalada.

Segurança de DNS

Registros de ponteiros Os registros PTR (Pointer, ou Ponteiro) são o oposto dos registros A. Os registros PTR mapeiam endereços IP para nomes de domínios. Esses registros são armazenados em arquivos de zona especiais chamados arquivos de zona in-addr.arpa. Informações sobre dados de blocos de endereços IP são distribuídas pelos NCCs (Network Coordination Centers, ou Centros de Coordenação de Rede) regionais. Atualmente, há cinco NCCs: o American Registry for Internet Numbers trata informações para a América do Norte; o Latin American and Caribbean Internet Addresses Registry cuida do espaço IP para a América Latina e o Caribe; o Réseaux IP Européens administra o espaço de endereços IP da Europa; o African Network Information Center é o registry de Internet para o continente africano e o Asia-Pacific Network Information Center é responsável pelo espaço de endereços IP da região da Ásia do Pacífico. Informações sobre a alocação de endereços IP são tratadas praticamente da mesma maneira que as informações de nomes de domínio, e a estrutura de DNS é idêntica. A diferença é que os administradores trabalham com blocos de endereços IP, não com nomes de domínio, e os arquivos de zona são diferentes quanto a isso. Os arquivos de zona in-addr.arpa são nomeados com o bloco IP em ordem inversa, seguido de in-addr.arpa. Se uma organização tiver o bloco IP 10.100.50.0/24 alocado (um bloco de rede classe “C”), o arquivo de zona com informações sobre esse bloco de rede teria o seguinte nome: 50.100.10.IN-ADDR.ARPA

Os arquivos de zona geralmente contêm apenas três tipos de RRs: registros SOA, NS e PTR, e os registros PTR são os de maior interesse. Esses registros seguem o mesmo formato geral dos arquivos de zona diretos, mas o nome de host está no campo de dados: 102 3600 IN PTR

mail.example.com.

Esse registro informa que o endereço IP 10.10.100.102 está mapeado para mail.example.com. De modo diferente dos registros A, em que um nome de host pode ser mapeado para vários endereços IP, um endereço IP pode ser mapeado somente para um único nome de host.

Capítulo 1 ■ Compreendendo o DNS

As informações de um registro PTR com frequência são usadas para autenticação. Alguns administradores de email rejeitam emails que não tenham sido originados de um servidor com um registro reverso, e alguns servidores de FTP rejeitam logins de usuários que não tenham registros reversos mapeados aos seus nomes de host. Aconselhar esse tipo de medida de segurança é discutível, mas isso existe e é algo do qual você deve estar ciente.

Registros de informações de host Registros HINFO (Host Info, ou Informações de Host) não são usados com muita frequência atualmente, mas continuam aparecendo ocasionalmente. O HINFO oferece informações do sistema operacional e do hardware de um host. O formato é o mesmo de outros RRs, mas o campo de dados contém dados não estruturados de host: mail.example.com. 3600 IN HINFO "Dell 1650" "Redhat 9.1"

A RFC 1035 recomenda um formato para o campo de dados de HINFO, embora ele não seja rigorosamente seguido, e outras informações podem ser usadas como substitutas.

Registros de servidores Os registros SRV (Server, ou Servidor) foram inicialmente definidos na RFC 2052. São uma maneira diferente de consultar servidores de nomes para obter informações sobre um nome de host. Normalmente, quando alguém quiser acessar um serviço de um domínio, o nome de host apropriado deve ser conhecido. Por exemplo, se uma pessoa estiver tentando acessar o site da Example Corp., ela deverá saber que o nome de host www.example.com aceita serviços HTTP. Infelizmente, nem sempre é possível saber quais serviços são aceitos pelos hosts em um domínio. Em vez de dar palpites ao acaso, usar um SRV ajuda o solicitante a obter o serviço desejado sem conhecer as informações do servidor. O formato do RR SRV é este: Serviço.Proto.Nome TTL Classe SRV Prioridade Peso Porta Alvo

Segurança de DNS

Assim como os registros MX, os registros SRV permitem aos administradores de DNS atribuir pesos diferentes aos diversos registros SRV. Um exemplo do mundo real seria usar registros SRV para distribuição de tráfego entre servidores web: http.tcp.www.example.com. IN SRV 10 10 80 host1.example.com. http.tcp.www.example.com. IN SRV 10 10 80 host2.example.com.

No exemplo anterior, o administrador de DNS está distribuindo a carga dos serviços HTTP entre dois serviços. Evidentemente, deve haver registros A tanto para host1.example.com quanto para host2.example.com. Nesse caso, como o administrador quer dividir a carga uniformemente entre os dois servidores, tanto o peso quanto a prioridade são definidos com os mesmos valores. Se um dos servidores precisasse assumir uma carga maior, seu peso seria definido com um valor menor. De modo semelhante, se um servidor fosse o servidor principal e o outro fosse simplesmente um servidor failover, a prioridade do servidor principal seria definida com um valor menor do que o valor usado para o servidor failover. Os registros SRV não são tão comuns assim; eles são usados principalmente por serviços de intranet, como o Active Directory da Microsoft.

Registros de texto Os registros TXT (Text, ou Texto) são outro tipo de RR que não é comumente usado. Esses registros têm texto em formato livre e são usados para fornecer informações legíveis aos seres humanos sobre uma entrada ou um domínio de modo geral; são configurados de modo semelhante a isto: allan

TXT "Hello World!"

Uma área em que os registros TXT continuam sendo muito utilizados é na esfera dos malwares baseados em DNS. Em particular, nos malwares que usam DNS como o caminho para roubar informações, dados e comandos muitas vezes são incluídos nas consultas de DNS como registros TXT.

Capítulo 1 ■ Compreendendo o DNS

Conclusões O DNS é um assunto complexo, que não pode ser totalmente explicado em um único capítulo. Este capítulo teve como propósito apresentar uma boa visão geral do DNS e de algumas de suas complexidades. Muitos recursos estão disponíveis, tanto online quanto impressos, oferecendo mais informações detalhadas sobre o DNS e suas complexidades. No entanto, as informações deste capítulo constituem uma boa base; são informações com as quais os administradores de DNS devem ter familiaridade.

Notas 1. Algumas pessoas dirão que o primeiro domínio registrado foi Symbolics.com ou Think.com; você pode lhes informar que esses domínios foram registrados em março e em maio de 1985, respectivamente, pelo menos três meses após o NORDU.NET ter sido registrado. 2. Isso, é claro, supondo que o domínio associado ao host também esteja registrado.