Modo de funcionamento do DNS
Apresentaremos, agora, uma visão panorâmica do modo de funcionamento do DNS. Nossa discussão focalizará o serviço de tradução de nome de hospedeiro para endereço IP.
Suponha que uma certa aplicação (como um browser Web ou um leitor de correio), que executa na máquina de um usuário, precise traduzir um nome de hospedeiro para um endereço IP. A aplicação chamará o lado cliente do DNS, especificando o nome de hospedeiro que precisa ser traduzido. (Em muitas máquinas UNIX, gethostbyname( ) é a chamada de função que uma aplicação invoca para realizar a tradução. Na Seção 2.7, mostraremos como uma aplicação Java pode chamar o DNS). A partir daí, o DNS do hospedeiro do usuário assume o controle, enviando uma mensagem de consulta para dentro da rede. Todas as mensagens de consulta e de resposta do DNS são enviadas dentro de datagramas UDP à porta 53. Após um atraso na faixa de milissegundos a segundos, o DNS no hospedeiro do usuário recebe uma mensagem de resposta DNS fornecendo o mapeamento desejado, que é, então, passado para a aplicação que está interessada. Portanto, do ponto de vista dessa aplicação, que está na máquina do cliente, o DNS é uma caixa-preta que provê um serviço de tradução simples e direto. Mas, na realidade, a caixa-preta que implementa o serviço é complexa, consistindo em um grande número de servidores de nomes distribuídos ao redor do mundo, bem como em um protocolo de camada de aplicação que especifica como se comunicam os servidores de nomes e os hospedeiros que fazem a consulta.
Um arranjo simples para DNS seria ter um servidor de nomes contendo todos os mapeamentos. Nesse projeto centralizado, os clientes simplesmente dirigiriam todas as consultas a esse único servidor de nomes, que responderia diretamente aos clientes que estão fazendo a consulta. Embora a simplicidade desse arranjo seja atraente, ele não é adequado para a Internet de hoje com seu vasto (e crescente) número de hospedeiros. Dentre os problemas de um arranjo centralizado, estão:
Um único ponto de falha. Se o servidor de nomes quebrar, a Internet inteira quebrará!
Volume de tráfego. Um único servidor de nomes teria de manipular todas as consultas DNS (para todas as requisições HTTP e mensagens de e-mail geradas por centenas de milhões de hospedeiros).
Banco de dados centralizado distante. Um único servidor de nomes nunca poderia estar ‘próximo’ de todos os clientes que fazem consultas. Se colocarmos o único servidor de nomes na cidade de Nova York, todas as buscas provenientes da Austrália terão de viajar até o outro lado do globo, talvez por linhas lentas e congestionadas, o que pode resultar em atrasos significativos.
Manutenção. O único servidor de nomes teria de manter registros de todos os hospedeiros da Internet. Esse banco de dados não somente seria enorme, mas também teria de ser atualizado frequentemente para atender a todos os novos hospedeiros.
Em resumo, um banco de dados centralizado em um único servidor DNS simplesmente não é escalável. Consequentemente, o DNS é distribuído por conceito de projeto. Na verdade, ele é um ótimo exemplo de como um banco de dados distribuído pode ser implementado na Internet.
Um banco de dados distribuído, hierárquico
Para tratar da questão da escala, o DNS usa um grande número de servidores, organizados de maneira hierárquica e distribuídos por todo o mundo. Nenhum servidor de nomes isolado tem todos os mapeamentos para todos os hospedeiros da Internet. Em vez disso, os mapeamentos são distribuídos pelos servidores de nomes. Como uma primeira aproximação, há três classes de servidores de nomes: servidores de nomes raiz, servidores DNS de domínio de alto nível (top-level domain — TLD) e servidores DNS com autoridade — organizados em uma hierarquia, como mostra a Figura 2.19
Para entender como essas três classes de servidores interagem, suponha que um cliente DNS queira determinar o endereço IP para o nome de hospedeiro www.amazon.com. Como uma primeira aproximação, ocorrerão os seguintes eventos. Em primeiro lugar, o cliente contatará um dos servidores raiz, que retornará endereços IP dos servidores TLD para o domínio de alto nível com. Então, o cliente contatará um desses servidores TLD, que retornará o endereço IP de um servidor com autoridade para amazon.com. Finalmente, o cliente contatará um dos servidores com autoridade para amazon.com, que retornará o endereço IP para o nome de hospedeiro www.amazon.com. Mais adiante, analisaremos mais detalhadamente esse processo de consulta DNS. Mas, em primeiro lugar, vamos examinar mais de perto as três classes de servidores DNS.
Servidores de nomes raiz. Na Internet há 13 servidores de nomes raiz (denominados de A a M) e a maior parte deles está localizada na América do Norte. Um mapa de servidores de nomes raiz de outubro de 2006 é mostrado na Figura 2.20; uma lista dos servidores de nomes raiz existentes hoje está disponível em [Root-servers, 2009]. Embora tenhamos nos referido a cada um dos 13 servidores de nomes raiz como se fossem um servidor único, na realidade, cada um é um conglomerado de servidores replicados, para fins de segurança e confiabilidade.
Servidores de nomes de Domínio de Alto Nível (TLD). Esses servidores são responsáveis por domínios de alto nível como com, org, net, edu e gov, e por todos os domínios de alto nível de países, tais como uk, fr, ca e jp. A empresa Network Solutions mantinha os servidores TLD para o domínio de alto nível com e a empresa Educause mantinha os servidores para o domínio de alto nível edu.
Servidores de nomes com autoridade. Toda organização que tiver hospedeiros que possam ser acessados publicamente na Internet (como servidores Web e servidores de correio) deve fornecer registros DNS também acessíveis publicamente que mapeiem os nomes desses hospedeiros para endereços IP. Um servidor DNS com autoridade de uma organização abriga esses registros. Uma organização pode preferir implementar seu próprio servidor DNS com autoridade para abrigar esses registros ou, como alternativa, pode pagar para armazená-los em um servidor DNS com autoridade de algum provedor de serviço. A maioria das universidades e empresas de grande porte implementam e mantêm seus próprios servidores DNS primário e secundário (backup) com autoridade.
Os servidores de nomes raiz, TLD e com autoridade pertencem à hierarquia de servidores DNS, como mostra a Figura 2.19. Há um outro tipo importante de DNS, denominado servidor DNS local, que não pertence, estritamente, à hierarquia de servidores, mas, mesmo assim, é central para a arquitetura DNS.
Cada ISP — como o de uma universidade, de um departamento acadêmico, de uma empresa ou de uma residência — tem um servidor de nomes local (também denominado servidor de nomes default). Quando um hospedeiro se conecta com um ISP, o ISP fornece ao hospedeiro os endereços IP de um ou mais de seus servidores de nomes locais (normalmente por DHCP, que será discutido no Capítulo 4). Determinar o endereço IP do seu servidor de nomes local é fácil: basta acessar as janelas de estado da rede no Windows ou UNIX. O servidor de nomes local de um hospedeiro normalmente está ‘próximo’ dele. No caso de um ISP institucional, pode estar na mesma LAN do hospedeiro; já no caso de um ISP residencial, em geral o servidor de nomes está separado do hospedeiro por não mais do que alguns roteadores. Quando um hospedeiro faz uma consulta ao DNS, ela é enviada ao servidor de nomes local, que age como proxy e a retransmite para a hierarquia do servidor DNS, como discutiremos mais detalhadamente a seguir.
Vamos examinar um exemplo simples. Suponha que o hospedeiro cis.poly.edu deseje o endereço IP de gaia.cs.umass.edu. Suponha também que o servidor de nomes local da Polytechnic seja denominado dns.poly. edu e que um servidor de nomes com autoridade para gaia.cs.umass.edu seja denominado dns.umass.edu. Como mostra a Figura 2.21, o hospedeiro cis.poly.edu primeiramente envia uma mensagem de consulta DNS a seu servidor de nomes local dns.poly.edu. Essa mensagem contém o nome de hospedeiro a ser traduzido, isto é, gaia.cs.umass.edu. O servidor de nomes local transmite a mensagem de consulta a um servidor de nomes raiz, que percebe o sufixo edu e retorna ao servidor de nomes local uma lista de endereços IP contendo servidores TLD responsáveis por edu. Então, o servidor de nomes local retransmite a mensagem de consulta a um desses servidores TLD que, por sua vez, percebe o sufixo umass.edu e responde com o endereço IP do servidor de nomes com autoridade para a University of Massachusetts, a saber, dns.umass.edu. Finalmente, o servidor de nomes local reenvia a mensagem de consulta diretamente a dns.umass.edu, que responde com o endereço IP de gaia.cs.umass.edu. Note que, nesse exemplo, para poder obter o mapeamento para um único nome de hospedeiro, foram enviadas oito mensagens DNS: quatro mensagens de consulta e quatro mensagens de resposta! Em breve veremos como o cache de DNS reduz esse tráfego de consultas.
Nosso exemplo anterior afirmou que o servidor TLD conhece o servidor de nomes com autoridade para o nome de hospedeiro, o que nem sempre é verdade. Ele pode conhecer apenas um servidor de nomes intermediário que, por sua vez, conhece o servidor de nomes com autoridade para o nome de hospedeiro. Por exemplo, suponha novamente que a Universidade de Massachusetts tenha um servidor de nomes para a universidade denominado dns.umass.edu. Imagine também que cada um dos departamentos da universidade tenha seu próprio servidor de nomes e que cada servidor de nomes departamental seja um servidor de nomes com autoridade para todos os hospedeiros do departamento. Nesse caso, quando o servidor de nomes intermediário dns.umass.edu receber uma consulta para um hospedeiro cujo nome termina com cs.umass.edu, ele retornará a dns.poly.edu o endereço IP de dns.cs.umass.edu, que tem autoridade para todos os nomes de hospedeiro que terminam com cs.umass.edu. Então, o servidor de nomes local dns.poly.edu enviará a consulta ao servidor de nomes com autoridade, que retornará o mapeamento desejado para o servidor de nomes local e que, por sua vez, o repassará ao hospedeiro requisitante. Nesse caso, serão enviadas dez mensagens DNS no total!
O exemplo mostrado na Figura 2.21 usa consultas recursivas e consultas iterativas. A consulta enviada de cis.poly.edu para dns.poly.edu é recursiva, visto que pede a dns.poly.edu que obtenha o mapeamento em seu nome. Mas as três consultas subsequentes são iterativas, visto que todas as respostas são retornadas diretamente a dns.poly.edu. Teoricamente, qualquer consulta DNS pode ser iterativa ou recursiva. Por exemplo, a Figura 2.22 mostra uma cadeia de consultas DNS na qual todas elas são recursivas. Na prática, as consultas normalmente seguem o padrão mostrado na Figura 2.21: a consulta do hospedeiro requisitante ao servidor de nomes local é recursiva e todas as outras são iterativas.
Cache DNS
Até aqui, nossa discussão ignorou o cache DNS, uma característica muito importante do sistema DNS. Na realidade, o DNS explora extensivamente o cache para melhorar o desempenho quanto ao atraso e reduzir o número de mensagens DNS que ricocheteia pela Internet. A ideia que está por trás do cache DNS é muito simples. Em uma cadeia de consultas, quando um servidor de nomes recebe uma resposta DNS (contendo, por exemplo, o mapeamento de um nome de hospedeiro para um endereço IP), ele pode fazer cache das informações da resposta em sua memória local. Por exemplo, na Figura 2.21, toda vez que o servidor de nomes local dns.poly.edu recebe uma resposta de algum servidor DNS, pode fazer cache de qualquer informação contida na resposta. Se um par nome de hospedeiro/endereço IP estiver no cache de um servidor DNS e outra consulta chegar ao mesmo servidor para o mesmo nome de máquina, o servidor de nomes poderá fornecer o endereço IP desejado, mesmo que não tenha autoridade para esse nome. Como hospedeiros e mapeamentos entre hospedeiros e endereços IP não são, de modo algum, permanentes, após um período de tempo (frequentemente dois dias), os servidores DNS descartam as informações armazenadas em seus caches.
Comentários
Postar um comentário