Navegação
OBJETIVO
O objetivo deste artigo é passar o conhecimento básico necessário envolvendo o serviço DNS para avançar nos estudos das provas de certificação em cloud. Não tenho a intenção de ser exaustivo ou entrar em detalhes profundos do funcionamento de DNS. Tentei manter a nomenclatura mais simples possível e desconsiderar os aspectos que não são importantes para os estudos de certificação de nível intermediário.
DNS
O DNS é um sistema cliente-servidor, com os clientes fazendo requisições aos servidores DNS para que eles recuperem informações deste banco de dados distribuído. Como o banco é distribuído, os servidores DNS muitas vezes não tem os dados que foram solicitados e precisam consultar outros servidores DNS para encontrar a informação que está sendo requisitada pelo cliente. Os clientes são chamados resolvers e os servidores DNS são chamados name servers.
A estrutura do banco de dados DNS tem a forma de uma árvore invertida como na figura abaixo e cada nó tem um rótulo (nome), sendo o nó mais acima da árvore chamado de root e seu rótulo é vazio. Esta árvore toda é conhecida como namespace.
Cada nó precisa ter um identificador único que o diferencie dos demais nós no namespace. Este identificador é o nome do domínio (domain name). O nome de um domínio é formado pela lista dos rótulos que estão no caminho entre este nó e o nó root do namespace (toda a árvore). Este caminho é percorrido de baixo para cima e tem os rótulos separados por pontos.
Por exemplo, na figura a seguir o nó destacado tem o nome de domínio www.arquitetocloud.com.br.
DOMÍNIOS
Um outro ponto da teoria do DNS é que um grupo de nós em uma subárvore do namespace é chamado de domínio (domain). Um agrupamento de nós (domínio) é identificado pelo nó que está no topo do agrupamento e este nó também tem o seu identificador que – conforme falamos anteriormente – é chamado de nome do domínio. Em outras palavras, o identificador do domínio é o identificador do nó que está no topo, que nada mais é do que o nome do domínio (domain name). A figura abaixo mostra o domínio arquitetocloud.com.br, com o nó arquitetocloud.com.br no topo.
Como arquitetocloud.com.br pode se referir tanto ao nó quanto ao domínio, é importante especificar o contexto – o nó arquitetocloud.com.br ou o domínio arquitetocloud.com.br.
DELEGAÇÃO E ZONAS
Na prática, domínios são administrados por organizações privadas, por exemplo, o Google administra o domínio google.com e a Amazon administra o domínio amazon.com. Administrar um domínio significa que ter a capacidade de adicionar nós ao domínio.
Em um caso hipotético, a Universidade de São Paulo (USP) – que administra o domínio usp.br – pode decidir delegar ao Instituto de Matemática e Estatística (IME) o subdomínio ime.usp.br. Neste caso, o IME ficará responsável por administrar os nós do seu subdomínio. Assim, teremos um conjunto de nós administrados pela TI da USP e outro conjunto de nós administrados pela TI do IME. Ao conjunto de nós administrados pela USP damos o nome de Zona (zone). Uma zona é um domínio sem os subdomínios que foram delegados para outros. Se um domínio não delegar nenhum subdomínio, então, a zona e o domínio terão os mesmos nós.
No exemplo acima, a zona ime.usp.br também pode delegar um conjunto de seus nós para o Centro Acadêmico (CA) e assim criar uma zona chamada ca.ime.usp.br.
RESOURCE RECORDS
Se o DNS é um banco de dados distribuído, os resource records são os dados deste banco. Eles podem ser de diversos tipos, mas os mais comuns são:
A – Mapeia um nome de domínio para um endereço IPv4.
AAAA – Mapeia um nome de domínio para um endereço IPv6.
CNAME – Mapeia um nome de domínio para outro nome de domínio.
NS – Nomeia um servidor DNS para uma zona.
SOA – Fornece parâmetros para uma zona.
Cada tipo de resource record requer um conjunto de dados específicos, por exemplo, o tipo A requer um endereço IPv4 de 32 bits, já o tipo AAAA requer um endereço IPv6 de 128 bits. Mais tarde entraremos em detalhes sobre os resource registers.
SERVIDORES DNS E AUTORIDADE
Servidores DNS tem duas responsabilidades: responder às consultas de clientes sobre nomes de domínio e consultar outros servidores DNS sobre nomes de domínios.
Um servidor DNS primário é aquele que tem todas as informações de uma zona, isto é, conhece todos os registros associados a um nome de domínio naquela zona. O servidor primário recebe as informações sobre a zona a partir de um arquivo chamado master file.
Um servidor DNS secundário para uma zona também tem todas as informações sobre uma zona, mas os dados sobre a zona são “carregados” no servidor secundário por outro servidor DNS (servidor DNS master) e não do master file.
Ambos os servidores – primário e secundário – são ditos ter autoridade sobre uma zona. Isto significa que eles podem responder a uma consulta por um nome de domínio dentro da zona de forma definitiva, isto é, sem repassar a consulta para outros servidores.
Um único servidor DNS pode ter autoridade em mais de uma zona ao mesmo tempo e ser o servidor primário em algumas e secundário em outras.
RESOLVERS
Resolvers são os clientes DNS. Geralmente são embutidos nos sistemas operacionais e têm a função de “pegar” uma requisição da aplicação para resolver um nome de domínio e transformar esta requisição em uma consulta DNS. Quando o resolver recebe a resposta do servidor DNS ele converte a resposta em uma estrutura que a aplicação possa entender. Os resolvers são importantes pois tiram a obrigação das aplicações de conhecerem o protocolo DNS para fazer uma consulta.
RESOLUÇÃO E RECURSIVIDADE
Resolução é o processo pelo qual os resolvers e servidores DNS interagem para encontrar os resources records (dados) no banco de dados distribuído do DNS.
Algumas vezes a resolução é simples: um resolver envia uma consulta para um servidor DNS que é responsável por uma zona e este responde diretamente para o resolver. Outras vezes a consulta pode ser mais complicada: um resolver envia uma consulta para um servidor DNS que não tem autoridade sobre uma zona, então, novas consultas devem ser feitas para tentar encontrar quem pode responder pelo nome de domínio solicitado.
Por padrão, o processo de resolução de nomes começa no topo no namespace (root) e vai em direção aos nós mais baixos. Desta forma, quando uma consulta é requisitada pela aplicação, o resolver envia a solicitação para um servidor DNS. Este primeiro servidor DNS tem registros do tipo NS que “apontam” para os servidores DNS que tem autoridade no domínio root. O servidor DNS root provavelmente não irá ter autoridade sobre o domínio que está sendo procurado, mas ele conhece os servidores DNS do próximo nível e responde à solicitação com uma lista de servidores que tem autoridade sobre as zonas top-level (.com, .net, .br etc). A resposta do servidor DNS root é uma referência e contém registros do tipo NS para os servidores da zona top-level.
O servidor DNS que está fazendo a consulta continua seguindo as referências dadas pelos outros servidores DNS no caminho até chegar a um servidor DNS que tenha autoridade na zona e possa responder pelo nome de domínio solicitado.
O processo de começar com os servidores DNS root e seguir as referências até chegar no servidor DNS que tem autoridade na zona é chamado recursividade.
Uma observação é que, na maioria dos casos, os outros servidores DNS que são consultados no caminho apenas respondem com a informação que eles têm sobre o próximo nível e não ficam responsáveis por eles mesmos fazerem consultas aos outros servidores DNS.
A imagem a seguir ilustra as etapas na resolução de nome para o nome ww.arquitetocloud.com
CACHING
Se todas as resoluções de nomes de domínio tivessem que iniciar pelo servidor DNS root elas seriam muito demoradas. Na prática, a maioria dos servidores DNS que fazem consultas recursivas não precisam consultar os servidores root porque fazem cache dos registros que foram retornados em consultas anteriores. Por exemplo, um servidor DNS que fez recentemente uma consulta ao nome de domínio google.com, se quiser fazer uma nova consulta à maps.google.com não precisa consultar novamente o servidor DNS root e depois o servidor DNS da zona “com”, neste caso, ele irá buscar no cache e pode ir diretamente consultar o servidor que tem autoridade sobre o domínio google.com.
RESOURCE RECORDS
Um servidor DNS que responde às solicitações dos clientes (Resolvers) para tradução de nomes tem um arquivo de configuração onde os administradores da zona podem decidir quais os nomes de domínio aquele servidor DNS pode responder e como esta resposta será dada. Este arquivo de configuração é o Zone Data File (arquivo de dados da zona) ou Master File. O zone data file contém uma descrição completa da zona pelo qual o servidor é responsável. Esta descrição é feita através de registros (resource records) que estão associados a todos os nomes de domínio na zona, isto é, a todos os nós. Assim, a configuração essencial de um servidor DNS são os resource records e por isso daremos mais ênfase neles a partir de agora.
FORMATO DE RESOURCE RECORDS
Os registros dentro de um master file tem o seguinte formato geral:
[NAME] [TTL] [CLASS] TYPE RDATA
NAME
É o campo que contém o nome de domínio para o qual o resource record está associado. O valor de NAME pode ser um FQDN terminado com ponto (.) ou o nome relativo de domínio, que não termina com um ponto (.). Isto é útil porque se você estiver escrevendo um data file para arquitetocloud.com.br, não será necessário escrever “arquitetocloud.com.br.” no final de cada nome.
O caractere @ pode ser usado para se referir a própria zona (arquitetocloud.com.br).
O campo NAME é opcional e se for omitido o registro será associado ao último nome de domínio especificado no data file.
O exemplo a seguir mostra o uso do campo NAME em um data file de arquitetocloud.com.br.
@ 60 IN A 10.0.0.1 # Associado à arquitetocloud.com.br
arquitetocloud.com.br. 60 IN A 10.0.0.2 # Associado à arquitetocloud.com.br
www 60 IN A 10.0.0.3 # Associado à www.arquitetocloud.com.br
60 IN A 10.0.0.4 # Associado à www.arquitetocloud.com.br
TTL (time-to-live)
O campo TTL determina quanto tempo um servidor DNS recursivo deve manter o resource record em cache.
O campo TTL é opcional e se for omitido, o registro irá ter o mesmo TTL do último registro que foi especificado.
O exemplo a seguir mostra o campo TTL para o data file do arquitetocloud.com.br.
@ 60 IN A 10.0.0.1 # TTL de 60 segundos
3600 IN A 10.0.0.1 # TTL de 1 hora
IN A 10.0.0.3 # TTL do registro anterior (1 hora)
CLASS
Existem outras classes, mas a única que nos importa é a classe IN (internet).
Os campos TYPE e RDATA serão discutidos na sequência.
TIPOS DE RESOURCE RECORD
Cada tipo (TYPE) de resource record precisa de uma sintaxe específica chamada RDATA, que pode ser diferente dependendo do tipo do resource record. A seguir estão os tipos mais comuns e seus RDATA.
Tipo A
O tipo A mapeia um nome de domínio para um endereço IPv4. Para mapear múltiplos IPs basta adicionar múltiplos endereços IPv4 ao mesmo domínio.
Exemplo:
www.arquitetocloud.com.br 300 IN A 10.0.0.1
IN A 10.0.1.1
Tipo AAAA
O mesmo que o tipo A, mas mapeando nomes de domínios para endereços IPv6.
www.arquitetocloud.com.br 300 IN AAAA 2001:db4:84:1:1
IN AAAA 2001:db4:84:2:1
Tipo CNAME
O tipo CNAME aponta um nome de domínio para outro. O CNAME é associado à um nome de domínio conhecido como “alias” e o RDATA é o nome de domínio para o qual o alias aponta, chamado canonical name (CNAME).
O tipo CNAME tem algumas regras:
- O nome de domínio que é o alias não pode ter outros tipos de resource registers associados a ele.
- O nome de domínio de uma zona não pode ter um CNAME. Por exemplo, o nome de domínio arquitetocloud.com.br não pode ter um CNAME associado a ele se ele for o nó no ápice da zona.
- O tipo CNAME pode apontar um alias para outro alias, mas tem que se ter o cuidado de não criar um loop do tipo A aponta para B, e B aponta para A.
Exemplo:
api.arquitetocloud.com.br 300 IN CNAME apiserver01.arquitetocloud.com.br
O tipo MX
O tipo MX (mail exchanger) diz para onde direcionar e-mails que são direcionados para um determinado nome de domínio. Por exemplo, o registro abaixo diz que um e-mail direcionado para contato@arquitetocloud.com.br dever ser encaminhado para mail01.teste.exemplo e caso não tenha sucesso pode encaminhar para mail.isp.net.
O tipo MX tem um valor de preferência que indica para qual servidor de e-mail a mensagem deveria ser enviado primeiro. Quanto menor o valor, maior a preferência.
@ 300 IN MX 0 mail01.teste.exemplo. # Envie e-mails para este servidor
300 IN MX 10 mail.isp.net. # Se o 1º falhar envie para este
O tipo NS
O tipo NS é parecido com o tipo MX, mas ao invés de apontar para um serviço de e-mail, aponta para o nome de domínio de um servidor DNS que tenha autoridade em uma determinada zona.
Exemplo:
arquitetocloud.com.br 300 IN NS ns550.hostgator.com.br
Diferente de outros resource records, o tipo NS geralmente aparece em duas zonas: a zona com um determinado nome de domínio e a zona “pai”. Por exemplo, haverá um registro do tipo NS associado à zona arquitetocloud.com.br, mas também haverá um registro NS na zona ns550.hostgator.com.br, que é a zona “pai” do nome de domínio arquitetocloud.com.br.
Em uma eventual consulta de um cliente ao nome de domínio arquitetocloud.com.br, este registro NS informa: “se você está interessado no nome de domínio arquitetocloud.com.br você deveria falar com o servidor ns550.hostgator.com.br”.
O tipo SRV
Assim como o tipo MX oferece uma camada de abstração entre o nome de domínio usado em um e-mail e os servidores de e-mail que recebem os e-mails de um domínio, o tipo de registro SRV oferece uma camada de abstração entre o nome de domínio e os servidores que irão atender requisições de um determinado serviço.
Então, por exemplo, se a intenção é publicar um serviço de APIs que seja atendido pelos servidores com nomes de domínio api01.arquiteto.com.br, api02.arquiteto.com.br e api03.arquiteto.com.br, o seguinte registro SRV poderia ser criado.
api.arquiteto.com.br 300 IN SRV 10 200 5678 api01.aquiteto.com.br
300 IN SRV 10 100 5678 api02.aquiteto.com.br
300 IN SRV 20 100 5678 api02.aquiteto.com.br
Os valores do RDATA do exemplo acima são:
Prioridade (10 e 20) – Diz o seguinte: “primeiro tente se conectar aos servidores que tem a prioridade de menor valor (api01 e api02). Se não conseguir, se conecte com o servidor com a prioridade 20 (api03).”
Peso (100 e 200) – Diz o seguinte: “se conecte 2/3 das vezes no servidor api01, 1/3 das vezes no servidor api02 e 1/3 das vezes no servidor api03.”
Porta (5678) – A porta onde as requisições de APIs são atendidas.
Destino – Especifica o nome de domínio do servidor que irá atender as conexões.
O tipo SOA
Um registro SOA fornece informações de “resumo” de uma zona. O RDATA de um registro SOA tem 7 campos:
- MNAME – É o nome de domínio do servidor DNS primário de uma zona.
- RNAME – É o e-mail da pessoa responsável pela zona.
- Serial Number da zona.
- Intervalo de refresh.
- Intervalo de recuperação.
- Intervalo de expiração.
- TTL de cache.
O detalhamento de cada um dos campos não influi no estudo do Route 53.
Em outro artigo irei entrar no funcionamento do Route 53 que é o serviço de DNS da AWS.
Imagem de Firmbee.com no Unsplash.
