Aula 5: Sistema de nomes de domínios (DNS)

Prévia do material em texto

Serviços de rede em sistemas Windows e Linux
Aula 5: Sistema de nomes de domínios (DNS)
Apresentação
Sempre que lemos sobre comunicação de dados, somos levados ao entendimento aplicado na primeira aula, na qual
tratamos de con�gurações de redes. Nela, vimos os endereçamentos lógicos, sua associação com os endereços físicos e
a estrutura de roteamento, além do Serviço de Nomes de Domínios (DNS).
Porém, no dia a dia, pouco usamos endereços lógicos já que nos referimos aos nomes para chamadas de sites, sistemas
e serviços de redes. Durante esta aula, percorreremos os conceitos e aplicações do DNS demonstrando sua importância e
fragilidades.
Objetivos
Descrever a história do DNS, sua relação com a ARPANET, o princípio do serviço de resolução de nomes e os
conceitos do DNS;
Explicar o serviço DNS;
Analisar o processo de busca DNS.
Traduzindo nomes em endereços
Imagine se, para acessarmos os serviços de nossos bancos, webmail ou outro tipo qualquer de serviço na internet,
precisássemos usar os endereços lógicos ao invés dos nomes como fazemos normalmente.
Você consegue imaginar tal cenário? Seria bem complicado, não acha? Então, você já deve ter percebido a grande importância
de um sistema que possa traduzir nomes em endereços.
De forma bem simples e direta, o objetivo do Sistema de Nomes de Domínios (DNS) está relacionado diretamente à
possibilidade de dar nomes que serão usados em diferentes recursos ─ como hosts, redes, protocolos, organizações e na
própria internet − criando um grande banco de informações sobre domínios e dando ao usuário capacidade de solicitar
endereços de determinados hosts ou serviços através de um nome único, que o identi�ca mundialmente.
Para entendermos como tudo isso surgiu, vamos dar uma rápida passada pela história e conhecer um pouco dos desa�os e
limitações que tornaram o DNS uma ferramenta tão importante nos dias de hoje.
Anos 1970
Lá pelos anos 1970, existia uma tal rede chamada Advanced Research Projects Agency Network – ARPANET (Você já deve ter
escutado falar dela), na qual existiam algumas centenas de hosts.
Para possibilitar a comunicação entre os hosts dessa tal ARPANET, existia um arquivo, com uma lista com os nomes e os
endereços Internet Protocol (IP) de cada host, chamado de hosts.txt.
Esse arquivo era mantido por uma equipe e atualizado uma ou duas vezes por semana. Era consultado sempre que um host
necessitava se comunicar com outro host e, por ser centralizado, requeria um tráfego de rede e uso de recursos
computacionais que eram bem limitados naquele momento.
Atenção
Lembre-se que estamos falando da década de 1970.
Com o tempo, a rede ARPANET foi crescendo e isso trouxe problemas para manter a gestão do arquivo hosts.txt, dentre os
quais podemos destacar:
1 Alto volume de tráfego e processamento.
2 Colisões de nomes (apesar dos esforços, era comum encontrar hosts com entradas distintasno arquivo, provocando con�itos).
3
Baixa capacidade de consistência (você deve imaginar como era trabalhoso manter a
consistência do arquivo; isso tornou-se inviável com tantos con�itos de nomes e mudanças
constantes com retiradas e inserções de hosts em uma rede em crescimento).
Motivados por tais problemas e em busca de uma solução para esse
cenário aparentemente caótico, os administradores da ARPANET
pensaram em um sistema que fosse capaz de ser administrado de
forma descentralizada, permitindo que um administrador local
pudesse publicar os dados mundialmente, reduzisse o tráfego de rede
e fosse capaz de resolver os nomes em endereços, exatamente como
o arquivo hosts.txt fazia.
A administração local se demonstrava uma solução interessante, já que traria maior simplicidade e efetividade para a
administração do arquivo e reduziria consideravelmente o tráfego na rede.
Contudo, o esquema de con�guração deveria usar nomes em uma estrutura hierárquica como forma de garantir a
exclusividade dos nomes e isso eliminaria os con�itos iminentes.
Atenção
Observe que falamos de hosts e não de sub-redes, falamos de nomes e não de endereços lógicos e, também, falamos de
hierarquia. A razão de termos usado esses conceitos faz parte do princípio do DNS, já que ele tem por objetivo principal
traduzir um nomes de domínio em um endereço de host que deve ser único em sua árvore hierárquica. Grave isso!
Anos 1980
Por volta de 1984, sob o comando de Paul Mockapetris, nasce a arquitetura do sistema de nomes e é lançada as Request For
Comments (RFCs) 882 e 883, que depois foram substituídas pelas RFCs 1034 e 1035, as quais trazem, respectivamente, os
conceitos, facilidades, especi�cações e implementações.
 (Fonte: Good_Stock / Shutterstock)
Como funciona a estrutura distribuída e hierárquica que
chamamos de DNS?
O primeiro ponto é entendermos de forma clara que o DNS tem por objetivo:
1. Fornecer um espaço de nomes que será usado para identi�car ou referenciar recursos, sendo que os nomes não precisam
conter rotas, identi�cadores de redes e endereços como parte do nome. Precisamos de um nome, apenas um nome;
2. Se o objetivo é melhorar a performance e reduzir os custos, além da complexidade, o “banco de dados” com os nomes
deve ser mantido de maneira distribuída e um cache local deve ser estabelecido. Temos aqui mais um ponto importante,
temos um CACHE que é um tipo de “memória do que já foi usado” localmente;
3. Seu uso não está restrito a uma única implementação. Ele pode ser usado para nomes de hosts, correio eletrônico, sites,
serviços de redes, nomes de impressoras, dentre outras aplicações;
4. Como você viu, a aplicação deve ter a capacidade de conversar com diversos protocolos e endereços; assim, deve ser
capaz de ter grande interoperabilidade (capacidade de conversar com sistemas diversos tipos e características);
5. Uma das características que mais chama a atenção, e está relacionada com a interoperabilidade, é a independência do
sistema de comunicação que está usando o serviço, já que, em alguns casos, serão usados apenas datagramas para as
consultas e respostas e, em outros, circuitos virtuais para garantir a con�abilidade, como acontece em transações longas
ou que exijam a garantia da entrega.
 Exemplo
 Clique no botão acima.
Exemplo
Para o atendimento dos objetivos descritos anteriormente, foi pensada uma estrutura simples, composta por três
elementos simples:
1. Domain Name Space ou Resource Records - estruturação ou especi�cação de uma estrutura em árvore,
contendo os dados associados aos nomes, de�nindo um espaço de nome estruturado;
2. Name Server - serviço de rede (um programa) que contém as informações e a estrutura de árvore do domínio,
sendo considerado a autoridade (autoritativo) para o espaço ao qual se refere;
3. Resolver - responsável por coletar as respostas dos servidores de nomes, após uma solicitação de cliente.
O sistema de nome de domínio é uma forma de traduzir um nome de domínio para um endereço IP da máquina que
está hospedando um servidor ou serviço de redes. Dessa forma, é criada uma “base de dados” ou um banco de
consultas distribuído, permitindo um controle mais efetivo, já que a administração se torna local, com possibilidade de
consulta mundial, conforme vimos anteriormente.
Conforme demonstrado na Figura 1 abaixo, a estrutura de nomes é muito parecida com a que encontramos na
ordenação de diretórios em sistemas operacionais. Assim, a estrutura parte de um ponto principal, chamado de ROOT
level domain, e segue para as camadas inferiores, chamadas de Level Domain.
Outra forma analisar a imagem é tratá-la como uma árvore, com seus nós e galhos e assim por diante.
Vamos usar este cenário para entendermos a imagem:
Cada nó da árvore representa uma parte desse grande banco de dados. Em um sistema operacional, chamaríamos
esses nós de diretórios; no DNS, chamamos de domínio.
Esses domínios podem ser divididos em parte menores, que chamaremos de subdomínios. Logo, um subdomínio é
um �lho de um domínio, ok?
 Figura 1: Hierarquia DNS. (Fonte: Ntchosting)
javascript:void(0);
É importante entendermosessa relação, pois todo domínio tem um nome que o relaciona ao seu domínio
pai. Podemos dizer, então, que um nome de domínio é uma lista de rótulos que nos levará do nó até a raiz
da árvore e deve ser lido da esquerda para a direita, dando o entendimento do caminho absoluto entre o
local de destino ou mais baixo nível da árvore até a sua “localização espacial” ou mais alto nível, que estará
mais próximo da raiz. 
 
Outro detalhe importante é que, por convenção, os nomes não diferenciam a questão da escrita em
maiúscula ou minúscula. 
 
Dessa forma, o nome estacio.br e ESTACIO.BR são interpretados pelos programas da mesma forma, faça
o teste no seu navegador.
Mas onde �ca o tal Domain Name Espace nisso tudo?
Ao observar a Figura 2 acima, você será capaz de entender o conceito de Domain Name Space e a relação dos nós
para formar o que conhecemos como nome de domínios ou subdomínios.
Lembre-se de que o Domain Name Space é a estruturação ou especi�cação de uma estrutura em árvore,
contendo os dados associados aos nomes, conforme demonstrado.
Quando um usuário usar o endereço absoluto, ele passará ao sistema um conjunto de caracteres que demonstram a
composição do nome completo do domínio, geralmente terminado com o “.” (servidor.estacio.br.), notação chamada
de Fully Quali�ed Domain Name (FQDN), que nada mais é do que o nome de domínio completamente quali�cado e
pelo qual você é capaz de identi�car a posição exata na hierarquia do DNS.
 Figura 2: Domain name space. (Fonte: Cisco)
javascript:void(0);
Isso é possível por ele ser capaz de demonstrar todos os níveis do domínio e certamente terminará com o “.” (lembra
do topo da árvore, o ROOT?). Dessa forma, sempre que pensar em um endereço FQDN, lembre-se do endereço
absoluto de um arquivo em um sistema operacional. Isso ajudará a entender o conceito.
Como consequência, o FQDN proporciona uma interpretação única do endereço, acabando com a ambiguidade. Um
host (Macapá) que faz parte do domínio (cidade.com), por exemplo, terá seu FQDN macapa.cidade.com.
Todo endereço de domínio é constituído por mais de um rótulo/etiqueta separadas por um ponto
(tabajara.com.br) e deve contar, no máximo, 63 caracteres, ok?
Porém, quando tratamos do FQDN de um determinado endereço de host, ele poderá ter 255 caracteres contando com
o “.” e a descrição do domínio é lida da direita para a esquerda, sendo o rótulo/etiqueta da direita o nível mais alto ou
superior do domínio (Top Domain Level – TDL).
No exemplo, macapa.cidade.com, ”com” é o TDL do domínio.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Atividade
1. Observe novamente a Figura 2. Você seria capaz de identi�car os TDLs dos domínios www.tpwd.state.tx.us,
jabber.oarc.isc.org, estacio.br, dmiconsulting.com.br?
 Figura 2: Domain name space. (Fonte: Cisco)
Conceitos e terminologias importantes
Entendido um pouco dos princípios, vamos estudar alguns conceitos e terminologias importantes para compreender como
funciona o serviço, facilitando muito a compreensão das requisições e do funcionamento geral. Para isso, observe a Tabela 1.
javascript:void(0);
Conceito De�nição
Resolvedor (Resolver)
Um cliente (não confunda com usuário) DNS que envia mensagens DNS para obter informações
sobre o espaço de nome de domínio solicitado.
Recursão (Recursion)
A ação executada quando um servidor DNS é solicitado a consultar em nome de um resolvedor
de DNS.
Servidor Autoritativo (Authoritative
Name Server)
Um servidor DNS que responde a mensagens de consulta com informações armazenadas em
Registros de Recursos (RRs) para um espaço de nome de domínio armazenado no servidor.
Resolvedor Recursivo Um servidor DNS que consulta recursivamente as informações solicitadas na consulta DNS.
FQDN
Um nome de domínio totalmente quali�cado é o nome absoluto de um dispositivo no banco de
dados DNS distribuído.
RR (Resource Records)
Um Registro de Recurso é um formato usado em mensagens DNS composto pelos seguintes
campos: NOME, TIPO, CLASSE, TTL, RDLENGTH e RDATA.
Zona (Zone)
Um banco de dados que contém informações sobre o espaço de nome de domínio armazenado
em um servidor autoritativo.
 Tabela 1: De�nições principais do DNS.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Limites do DNS
Dentro da estrutura do DNS, temos uma série de objetos, parâmetros, usados nas de�nições e con�gurações do serviço. Tais
recursos possuem limitações de tamanho.
Conheça essas limitações na Tabela 2 a seguir.
Rótulos / Etiqueta <= 63 octetos ou menos
Nomes (FQDN) <= 255 octetos ou menos
TTL (Tempo de intervalo da consulta de uma
informação armazenada em cache. Esse tempo
determina o período de armazenamento de cache de
uma referência, antes de uma nova pesquisa) Um
número positivo de 32 bits.
Um número positivo de 32 bits.
Mensagem UDP <= 512 octetos
 Tabela 2: Limites do DNS.
Formato de RR
Agora, vamos entender as de�nições e os tipos de um Registro de Recurso (RR) descritos na Tabela 3.
Formato Descrição
Nome Nome do nó (proprietário) ao qual o registro de recursos pertence.
Tipo De�nição do tipo de RR (RR Type), especi�cado em formato de dois octetos.
CLASS Especi�cação de código de classe através de dois octetos.
TTL
Especi�cação do tempo em que o registro de recurso pode ser armazenado em cache antes que
a origem da informação seja novamente consultada. 
 
Caso seja especi�cado o valor zero, o RR só pode ser usado para a transação em andamento e
não deve ser armazenado em cache.
RDLENGTH Especi�ca o comprimento em octetos do campo RDATA.
RRDATA
É uma cadeia de octetos de comprimento variável que descreve o recurso, vaiando de acordo
com o TIPO e a CLASSE do registro de recurso.
 Tabela 3: Formato de RR.
Tipos de classe
Entendidos os formatos, vamos entender os tipos de classes que são usadas no registo do recurso. A Tabela 4 demonstra
cada tipo e especi�ca a sua função.
Tipo Signi�cado
A (hostname) Endereço de um host (IPV4)
AAAA Endereço de um host (IPV6)
Name Server - NS Indicação de um servidor de nome autoritativo para o domínio ou subdomínio.
Canonical NAME - CNAME
Um apelido dado a um hostname. Normalmente usado em caso de redirecionamento de
serviços, como o WWW.
Start Of Authority - SOA
Indica o início da zona de autoridade do servidor. Ele indica o responsável pelo domínio, ou seja,
aquele que responderá a consultas autoritativas.
PTR
Um ponteiro de nome de domínio. Trocando em miúdos... Em caso de busca reversa, na qual é
usado endereço lógico, o PTR aponta o domínio reverso para o referido IP.
TeXT - TXT
Uma sequência de texto que permite incluir uma informação curta em um hostname. Um
exemplo de uso são as chaves públicas usadas nos Mail Exchange.
Mail exchanger – MX Endereço ou apontamento do servidor de e-mail do domínio.
 Tabela 4: Tipos de classes.
Formatos DNS
Por �m, vamos entender os formatos do SOA RDATA e destacar o uso o tipo IN, que determina endereço na Internet. De forma
complementar, temos:
Tipo Descrição
SERIAL
Um valor usado para transferência de zona. Durante a transferência de zonas, este número é
preservado e será comparado para veri�cação.
REFRESH Determina o intervalo para atualização da zona.
RETRY
Determina o tempo de espera para nova tentativa de transferência, em caso de erro na
transferência de zona.
EXPIRE
Indica o tempo limite de espera dos servidores secundários antes da desistência de tentativa de
sincronização com o servidor primário. Depois do tempo de�nido, as informações do domínio
param de responder consultas sobre ele dos servidores secundários.
Minimum TTL
Estabelece o “tempo de vida” do cache. Ele estabelece quanto tempo o registro de uma zona
deverá permanecer no cache de um servidor DNS antes que seja feito um Refresh.
 Tabela 5: Formatos DNS.
Pesquisa de nslookup
Agora que vimos tudo que precisamos para entender as informações básicas de um DNS, podemos colocar em prática o que
foi apresentado através do resultado de uma pesquisa pública de um domínio qualquer.
Como exemplo prático, faremos umapesquisa de nslookup, comando usado para consulta de informações de DNS do
domínio estacio.br.
Nele, são apresentadas todas as informações referentes ao domínio e que estão con�guradas no servidor autoritativo.
As informações são públicas e podem ser consultadas por qualquer sistema a qualquer momento. Por isso, faz-se a solicitação
das informações com a ferramenta https://centralops.net/co/.
Existem várias ferramentas que podem ser usadas, mas usaremos
uma on-line apenas por não estarmos usando nenhuma na nossa
máquina.
javascript:void(0);
 Figura 3: Pesquisa NSLOOKUP.
Atividade
2. Descreva o que você foi capaz de entender com o resultado da pesquisa apresentada na Figura 3: Pesquisa NSLOOKUP.
Como o serviço efetivamente funciona?
Passado o primeiro momento de entendimento da origem, princípios, conceitos e fundamentos, vamos entender como o
serviço efetivamente funciona e os aspectos técnicos por trás dele.
O primeiro passo será desvendar como é atendida uma requisição de um usuário. Para isso, vamos analisar a Figura 4.
 Figura 4: Modo simples de pesquisa por nome. (Fonte: Tools)
javascript:void(0);
Um usuário, por meio de um sistema operacional, interage com um resolvedor (resolver) como forma de acesso ao Domain
Name Space, conforme demonstrado na Figura 2, para consulta de um determinado domínio.
Após a solicitação do usuário, o resolvedor fará as consultas por meio de um cache mantido por ele após consultas anteriores
e através de consultas a servidores “estrangeiros” (servidores que estão fora da área de atuação do resolvedor).
Atenção
Haverá a consulta do cache do resolvedor e várias consultas para servidores de nomes estrangeiros com o objetivo de
responder à solicitação especí�ca de usuário.
Isso demonstra algo interessante: uma consulta de um usuário pode envolver vários acessos de rede em uma quantidade
arbitrária. Feito todo esse processo, o resolvedor, então, fará a entrega da solicitação e adicionará em seu cache o resultado
para consultas posteriores.
Não se esqueça de que estamos falando de endereços de máquinas, endereços especí�cos que estão endereçadas em um
domínio. Lembre-se bem disso pois fará todo o sentido quando formos analisar o cenário de aplicação do DNS integrado aos
diversos serviços de redes.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Fluxo de pesquisa DNS
Se olharmos com mais detalhes, veremos que o serviço do DNS é um tanto mais complexo e dependente de uma cadeia de
con�gurações em cascata.
Veja a Figura 5:
 Figura 5: Fluxo de pesquisa DNS. (Fonte: D1 Awsstatic)
javascript:void(0);
 Como uma solicitação de um cliente é atendida?
 Clique no botão acima.
Como uma solicitação de um cliente é atendida?
Vamos entender agora em detalhes como uma solicitação de um cliente é atendida.
Tudo se inicia quando uma aplicação do cliente faz uma solicitação de acesso a um endereço (www.exemplo.com).
A solicitação será recebida pelo resolver con�gurado no cliente durante a con�guração do dispositivo de redes,
conforme demonstrado na Figura 3.
Sem que seja feita esta con�guração, os aplicativos do cliente não serão capazes de resolver os nome de serviços ou
de qualquer recurso.
Mesmo que sua interface esteja con�gurada com a opção de con�guração automática, usando o Dynamic Host
con�guration Protocol (DHCP), assim como está na imagem, é necessário que um endereço de resolução de nomes
seja con�gurado no cliente para possibilitar o acesso ao Domain Name Space.
Agora você sabe como localizar o seu Resolver na con�guração de seu sistema Windows. No Linux, o
princípio é o mesmo, então entendido um, entendido todos.
Após a solicitação ao Resolver, o servidor Resolver fará uma consulta em seu cache para veri�car se já existe alguma
entrada do nome requerido. Caso não haja uma entrada, o servidor fará o questionamento ao ROOT name server do
name espace ao qual o Resolver faz parte.
O Servidor ROOT encaminhará ao TDL que trata do .com, já que este é o próximo nível do domínio.
Ao receber a requisição vinda do TLD superior, o servidor responsável pelo .com encaminhará a solicitação ao host
responsável pelo nome exemplo que entregará o endereço do servidor responsável pelo www, que provavelmente será
uma entrada de CNAME, apontando para o servidor web onde está o serviço http rodando.
Assim, o DNS Resolver fará o registro em cache do domínio em questão e entregará ao cliente o endereço para que ele
�nalmente tenha acesso à página web.
 Figura 3: Con�guração de DNS cliente.
Atividade
3. Qual a função primária do servidor DNS?
4. Em caso de perda de um DNS, você acredita que haverá grandes impactos institucionais? Justi�que.
5. Qual o papel do resolver para as requisições do DNS?
6. Você pode ter em um mesmo Domain Name Space duas referências com o mesmo nome?
7. Em caso de uma segunda busca por um mesmo nome, o servidor resolver fará uma nova busca recursiva?
Referências
MOCKAPETRIS, P. Request for Comments: 1034. 1987. Disponível em: https://tools.ietf.org/html/rfc1034. Acesso em: 06 set.
2019.
MOCKAPETRIS, P. Request for Comments: 1035. 1987. Disponível em: https://tools.ietf.org/html/rfc1035. Acesso em: 06 set.
2019.
Próxima aula
Instalação e con�guração do serviço DNS em sistema Windows e Linux.
Explore mais
Acesse os seguintes materiais:
Request for Comments: 1034;
Request for Comments: 1035;
BIND 9;
Sistema de nome de domínio (DNS).
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);