Visão geral de terminologias, componentes e conceitos de DNS

DNS (Domain Name System) é um dos componentes cruciais que impulsionam a internet. Ter uma compreensão adequada de como o DNS funciona pode ajudar a diagnosticar problemas com a configuração do site e ampliar sua compreensão do que está acontecendo nos bastidores.

Neste guia, falaremos sobre alguns conceitos fundamentais de DNS para fornecer uma base sólida ao trabalhar com sua configuração de DNS. Este guia também ajudará a configurar seu próprio nome de domínio ou servidor DNS.

Vamos começar!

Terminologias de Domínio

Primeiro, precisamos estabelecer uma compreensão dos termos que vamos usar. Você já deve estar familiarizado com alguns deles em outros contextos. No entanto, existem muitos termos específicos ao falar sobre nomes de domínio e DNS que não são muito discutidos em outras áreas da computação.

• Sistema de Nomes de Domínio

O sistema de nomes de domínio (DNS, de forma abreviada) é um sistema de rede em vigor que traduz nomes de domínio amigáveis para humanos em endereços IP exclusivos.

• Nome de Domínio

Um nome de domínio refere-se ao nome amigável para humanos usado para se associar a um recurso da internet. Por exemplo, “cloudsigma.com” é um nome de domínio. Alguns podem argumentar que apenas a parte “cloudsigma” é o nome de domínio, mas geralmente refere-se ao todo.

A URL “cloudsigma.com” está associada aos servidores de propriedade da CloudSigma. Ao inserir a URL no navegador web, ela se comunica com o DNS para se conectar ao endereço IP do servidor de destino.

• Endereço IP

Um endereço IP age como um endereço de rede para um dispositivo conectado à rede. Cada endereço IP deve ser exclusivo dentro da rede. In no contexto de sites, a rede é, na maioria das vezes, toda a internet.

Existem dois tipos de endereços IP:

• • IPv4: Esta é a forma mais comum de endereço IP. É escrito como um conjunto de quatro números, cada conjunto tendo até 3 dígitos. Cada conjunto é separado por um ponto. O intervalo do IPv4 é de 0.0.0.0 a 255.255.255.255.

  • IPv6: É um padrão mais moderno que foi desenvolvido para resolver o problema de esgotamento de endereços IPv4. O IPv4 suporta até 232 endereços exclusivos, enquanto o IPv6 suporta até 2128 endereços. Qualquer endereço IPv6 é escrito em dígitos hexadecimais. Ele pode conter até 32 dígitos, divididos em 8 seções (4 dígitos em cada seção). Cada seção é separada por dois-pontos (:).

Domínio de Nível Superior

Um domínio de nível superior (TLD, de forma abreviada) é a parte mais geral do domínio. Refere-se à parte mais à direita (separada por um ponto). Alguns dos domínios de nível superior comuns incluem:

• “com”

• “net”

• “org”

• “edu”

• “io”

• “gov”

Em termos de nomes de domínio, esses domínios estão no topo da hierarquia. A ICANN (Internet Corporation for Assigned Names and Numbers) pode emitir uma permissão para o controle de certas partes sobre domínios de nível superior. Com a permissão, essas partes podem distribuir nomes de domínio sob o TLD (geralmente por meio de um registrador de domínios).

• Hosts

No domínio, o proprietário pode especificar hosts individuais, referindo-se a máquinas/serviços separados acessíveis por meio de um domínio. Por exemplo, é uma prática comum tornar os servidores web acessíveis através do domínio raiz ( example.com) e a definição de “host” “www  ( www.example.com).

É possível ter hosts adicionais sob o domínio geral, por exemplo, acesso à API através do host “api” ( api.example.com), acesso FTP através do host “ftp” ou “files” ( ftp.example.com ou files.example.com).

Observe que os nomes de domínio podem ser arbitrários, desde que sejam exclusivos dentro do domínio.

• Subdomínio

Um subdomínio é um assunto relacionado a hosts. O DNS funciona em uma hierarquia. Um TLD pode ter muitos domínios sob ele. Por exemplo, “ example.com”, “ cloudsigma.com”, etc. estão todos sob o TLD “com”. Nesse sentido, um subdomínio é uma referência a qualquer domínio que faça parte do domínio de destino. Assim, podemos dizer que “example.com” é um subdomínio de “com”. Geralmente, a parte “example” é referida como um SLD (domínio de segundo nível).

Da mesma forma, um domínio pode controlar todos os “subdomínios” localizados sob ele. Geralmente é a isso que o termo “subdomínio” se refere. Por exemplo, “ history.example.com” é um subdomínio de “ example.com”.

A principal diferença entre um hostname e um subdomínio é que um host define um computador/recurso, enquanto um subdomínio estende o domínio pai. Sempre que estivermos falando de subdomínios ou hosts, você pode ter certeza disso olhando para a parte mais à esquerda de um domínio, pois ela é a mais específica. É assim que o DNS funciona: do mais específico (lado mais à esquerda) para o menos específico (lado mais à direita).

• Nome de Domínio Totalmente Qualificado

Um nome de domínio totalmente qualificado (FQDN, na sigla em inglês) refere-se a um nome de domínio absoluto. No sistema DNS, os domínios podem ser fornecidos de forma relativa uns aos outros. Isso pode levar a alguma ambiguidade. Um FQDN, no entanto, é um nome absoluto que se refere à raiz absoluta do sistema de nomes de domínio.

Isso significa que o FQDN especifica cada domínio pai, incluindo o TLD. Um exemplo adequado seria “ mail.google.com”. Em casos específicos, o FQDN pode não terminar com um ponto, mas deve ter um ponto final (exigido pelos padrões da ICANN).

• Servidor de nomes

Um servidor de nomes é um computador dedicado para traduzir nomes de domínio em endereços IP. Os servidores de nomes suportam a maior parte da carga no sistema DNS. Como o número total de solicitações de tradução de domínio é alto demais para ser tratado por um único servidor, as solicitações são frequentemente redirecionadas para outros servidores de nomes para aliviar a pressão.

Um servidor de nomes pode ser “autoritativo”, o que significa que ele apenas fornece respostas para consultas sobre domínios sob seu controle. Esses servidores podem retransmitir a solicitação para outros servidores de nomes ou fornecer uma cópia em cache dos dados de outros servidores de nomes.

• Arquivo de Zona

Um arquivo de zona é um arquivo de texto que contém os mapeamentos entre nomes de domínio e endereços IP. Ele serve como o banco de dados do sistema DNS. Este é o catálogo que o DNS usa para encontrar qual endereço IP contatar ao concluir uma solicitação de usuário para um determinado nome de domínio.

Geralmente, os servidores de nomes hospedam os arquivos de zona e definem os recursos disponíveis sob um único domínio. Ele também pode conter informações sobre onde ir para obter essas informações.

• Registros

Um arquivo de zona compreende inúmeros registros. Aqui, um registro é definido como um único mapeamento entre um recurso e um nome. Os registros podem ser um mapeamento de nome de domínio para um endereço IP, recursos disponíveis sob um domínio específico ou referências a locais para obter as informações.

DNS em Ação

Até agora, nos familiarizamos com algumas terminologias comuns envolvidas com o DNS. No entanto, como o sistema realmente funciona? O sistema pode parecer muito simples em uma visão de alto nível. No entanto, aprofundar-se nos detalhes revelará sua verdadeira complexidade. No geral, o sistema DNS é importante para a ampla adoção da internet.

• Servidores Raiz

O DNS, em sua essência, funciona em uma hierarquia. No topo do sistema residem os “servidores raiz”. Esses servidores estão sob o controle de várias organizações. A autoridade desses servidores é delegada pela ICANN (Internet Corporation for Assigned Names and Numbers).

Até o momento, existem cerca de 13 servidores raiz em operação. Devido à carga, no entanto, cada um desses servidores é espelhado. É importante notar que todos os servidores espelho compartilham o mesmo endereço IP do servidor raiz. Sempre que qualquer solicitação é feita ao servidor raiz, a solicitação é redirecionada para o espelho mais próximo desse servidor.

Quais são as funções dos servidores raiz? Eles fornecem informações sobre domínios de nível superior. Sempre que um servidor de nomes de nível inferior falha em resolver uma solicitação, ela é redirecionada para o servidor raiz do domínio.

No entanto, o servidor raiz não sabe realmente a localização do domínio. Ele apenas redireciona a requisição que lidará com o domínio de nível superior especificamente solicitado. Por exemplo, se for feita uma requisição para “ blog.cloudsigma.com”, o servidor raiz não o terá em seus registros. Ele pesquisará em seus arquivos de zona, mas não haverá nenhum registro para ele. Em vez disso, ele reconhecerá o TLD “com” e redirecionará a entidade solicitante para o servidor de nomes que lida com endereços “com”.

• Servidores TLD

Continuando a partir do nosso exemplo anterior, a entidade solicitante agora enviará a requisição para o endereço IP (fornecido pelo servidor raiz). No caso de “ blog.cloudsigma.com”, o servidor de nomes “com” pesquisará seus registros em seus arquivos de zona.

Não haverá um registro correspondente à requisição. No entanto, ele encontrará um registro listando o endereço IP do servidor de nomes responsável por “ cloudsigma.com”.

• Servidor de Nomes de Nível de Domínio

Agora, a entidade solicitante tem o endereço IP do servidor de nomes que realmente hospeda as informações sobre “ blog.cloudsigma.com”. Ela agora enviará uma nova requisição ao servidor, solicitando a resolução de “www.cloudsigma.com”.

Assim como antes, o servidor de nomes verificará seus arquivos de zona e encontrará aquele associado a “ cloudsigma.com”. Dentro deste arquivo residirá uma entrada para o host “www”. Este registro descreve onde o host está localizado. A resposta final é então retransmitida para a entidade solicitante.

• Servidor de Resolução de Nomes

No exemplo, mencionamos uma entidade solicitante. O que é isso? Na maioria dos casos, o solicitante será um “servidor de resolução de nomes”. É um servidor configurado para fazer perguntas a outros servidores. Ele age como um servidor intermediário para os usuários. Ele armazena os resultados em cache para melhorar a velocidade.

Qualquer usuário geralmente terá alguns servidores de resolução de nomes configurados em seu sistema. Geralmente, os servidores de resolução de nomes são oferecidos pelo ISP ou por outras organizações. Por exemplo, Google oferece servidores DNS de resolução públicos para consulta. Você pode configurá-lo manualmente em seu sistema.

Ao inserir uma URL no navegador web, ele procura a localização do recurso. Primeiro, a busca é realizada localmente. Isso inclui o arquivo “hosts” (e alguns outros locais). Se não for encontrado, a requisição é enviada para o servidor de resolução de nomes. Após receber a requisição, o servidor de resolução de nomes busca a resposta em seu cache. Se não for encontrada, ele segue as etapas mencionadas anteriormente.

Os servidores de resolução de nomes simplificam o processo de requisição para o usuário final. O cliente só precisa perguntar aos servidores de resolução de nomes pela localização de um recurso. O servidor de nomes investigará e retornará a resposta final.

• Arquivos de Zona

Nós já discutimos os conceitos de “arquivos de zona” e “registros”. Bem, como eles operam?

Os arquivos de zona agem como o banco de dados para os servidores de nomes, armazenando as informações sobre os domínios que eles conhecem. Todos os domínios que um servidor de nomes conhece serão armazenados em seu arquivo de zona. No entanto, a maioria das requisições que chegam a um servidor de nomes não são resolvidas pelo arquivo de zona. Se a configuração do servidor for para lidar com consultas recursivas (servidores de resolução de nomes, por exemplo), ele retornará a resposta. Caso contrário, ele redirecionará a parte solicitante para um local diferente para procurar a seguir.

Quanto mais arquivos de zona um servidor de nomes hospedar, mais autoritativas serão suas respostas. Os arquivos de zona descrevem uma “zona” DNS (um subconjunto de todo o sistema de nomenclatura DNS). Geralmente, un arquivo de zona contém os dados de configuração de apenas um único domínio. Ele pode ter inúmeros registros definindo a localização dos recursos do domínio em questão.

O parâmetro $ORIGIN de uma zona é igual ao nível mais alto de autoridade da zona. Por exemplo, um arquivo de zona para “ cloudsigma.com” terá seu $ORIGIN como “ cloudsigma.com”. O valor do parâmetro pode ser armazenado no início do arquivo de zona ou na configuração do servidor DNS. De qualquer forma, o parâmetro descreve para qual zona o arquivo é autoritativo.

O $TTL define as informações de “tempo de vida” do resultado fornecido. Ele pode ser descrito como um temporizador que um servidor de cache pode usar para acompanhar a validade das respostas armazenadas em cache. Se o valor de TTL expirar, a resposta não será mais válida e será descartada.

• Tipos de Registro

Os arquivos de zona consistem em vários registros. Agora, existem diferentes tipos de registros. A seguir, abordaremos alguns dos tipos de registros mais comuns (e obrigatórios):

Registros SOA

O registro Start of Authority (SOA, abreviado) é obrigatório em todos os arquivos de zona. Ele deve ser o primeiro registro real no arquivo. No entanto, entradas como $ORIGIN ou $TTL têm permissão para aparecer antes.

O registro SOA é um dos tipos de registros mais complexos. A estrutura dele se parece com isso:

Vamos detalhar:

• • example.com: Esta parte define a raiz da zona. Neste exemplo, o arquivo de zona é para o domínio “ example.com’. Às vezes, o valor pode ser substituído por @ (um marcador para substituir o valor de $ORIGIN).

  • IN SOA: O termo “IN” significa “internet”. Você o encontrará em muitos registros. O termo “SOA” indica que é um registro SOA.

  • ns1.example.com: Este valor contém o servidor de nomes primário para o domínio “ example.com’. Os servidores de nomes podem ser primários ou secundários. Se tiver sido configurado com DNS dinâmico, será necessário um servidor “primário”. Se nenhum DNS dinâmico tiver sido configurado, ele será um dos servidores de nomes primários.

  • admin.example.com: O endereço de e-mail do administrador da zona vai aqui. Observe que o @ é substituído por . aqui. Se o endereço de e-mail original contiver um ponto, ele será substituído por um \. Por exemplo, “ my.domain@example.com’ se tornaria “ my\domain.example.com”.

  • 12083: É o número de série do arquivo de zona. Toda vez que o arquivo de zona é editado, o número deve ser atualizado para que o arquivo se propague corretamente. Os servidores secundários usam esse número de série para acompanhar se seus próprios arquivos de zona estão atualizados.

  • 3h: Representa o intervalo de atualização da zona. Os servidores secundários aguardarão esse período antes de verificar se há atualizações no arquivo de zona.

  • 30m: Este valor representa o intervalo de tentativa da zona. Se um servidor secundário não conseguir se conectar ao servidor primário após o término do período de atualização, ele aguardará esse período antes de consultar o primário novamente.

  • 3w: Este valor representa o período de expiração. Se um servidor secundário não conseguir se conectar ao servidor primário por esse período, ele deixará de retornar respostas como “autoritativo”.

  • 1h: Este valor representa a quantidade de tempo que o servidor de nomes armazenará em cache um erro de nome se ele não for encontrado em seu arquivo de zona.

Registros A e AAAA

Esses registros estabelecem um mapeamento entre um host e um endereço IP. Aqui, o registro “A” significa o mapeamento IPv4 para o host e o AAAA o mapeamento IPv6.

Esta é a estrutura fundamental dos registros A e AAAA:

No exemplo de registro SOA, chamamos o servidor de nomes de “ ns1.exampel.com’. O servidor de nomes pertence ao domínio “ example.com’. Veja como seria o seu registro A:

Observe que não precisamos fornecer o nome completo. Apenas com o hostname (sem o FQDN), o servidor DNS pode preencher o restante com o valor de $ORIGIN. No entanto, ainda podemos usar o FQDN:

Aqui está como definir o servidor web como “www”:

Também devemos incluir o mapeamento para o domínio base. A entrada ficaria assim:

Alternativamente, podemos usar o @ símbolo para denotar o domínio base (em vez de seu nome completo):

É uma boa prática incluir uma entrada curinga que permite a opção de resolver qualquer coisa sob este domínio que não tenha sido definida explicitamente:

A mesma estrutura se aplica aos registros AAAA. A única diferença são os endereços IPv6.

Registros CNAME

Os registros CNAME agem como um apelido para o nome canônico do servidor (definido por um registro A ou AAAA). Dê uma olhada no seguinte exemplo:

Aqui, usamos “server1” como um apelido para definir o nome “www”. Note que tais atalhos trazem custos de desempenho, pois o servidor precisa executar consultas adicionais para obter a resposta final. Dependendo do número de camadas de apelidos, isso pode facilmente causar um grande custo de desempenho. No entanto, há um caso específico que se beneficia do apelidamento CNAME, por exemplo, fornecer um recurso fora da zona atual.

Registros MX

Os registros MX definem os servidores de correio eletrônico para o domínio. Eles ajudam o e-mail a chegar corretamente ao servidor. Ao contrário de outros registros, os registros MX não mapeiam um host para algo, pois são aplicáveis a toda a zona. É por isso que os registros MX se parecem com isto:

Observe que não há hostname no início da entrada. Você também notará que há um valor adicional na linha. É o número de preferência que ajuda a decidir para qual servidor enviar o e-mail (se houver vários servidores de e-mail definidos). Quanto menor o número, maior a prioridade.

Um registro MX deve apontar para um host definido por um registro A ou AAAA (não por CNAME). Tendo isso em mente, se houver dois servidores de e-mail configurados, os registros ficariam assim:

Neste exemplo, a julgar pelo número de preferência, “mail1” é o servidor preferível em relação ao “mail2”. Podemos encurtar ainda mais o código omitindo o nome de domínio completo:

Registros NS

Estes registros definem os servidores de nomes para a zona específica. Agora, a pergunta óbvia é: se o arquivo de zona reside dentro do servidor de nomes, por que ele requer uma referência a si mesmo? Uma resposta para a pergunta são os múltiplos mecanismos de cache do sistema DNS. O arquivo de zona pode, na verdade, ser uma cópia em cache em outros servidores.

Semelhante aos registros MX, os registros NS se aplicam a toda a zona. Portanto, eles não têm nenhum host específico por padrão. As entradas de registro NS se parecerão com isto:

Recomenda-se ter dois servidores de nomes definidos caso um servidor falhe em operar corretamente. Além disso, a maioria dos servidores DNS rejeitará um arquivo de zona se ele contiver apenas um único servidor de nomes.

Você também deve incluir o mapeamento dos hosts com registros A ou AAAA:

Registros PTR

Os registros PTR são o inverso de um registro A ou AAAA clássico. Esses registros são usados para definir um nome associado a um endereço IP. Esses registros têm uma propriedade única, pois começam no .arpa root e representam o proprietário do endereço IP. São os RIRs (Regional Internet Registries) que distribuem endereços IP para organizações e provedores de serviços. Os RIRs incluem APNIC, AFRINIC, LACNIC, RIPE NCC e ARIN.

Por exemplo, um registro PTR para 111.222.333.444 seria parecido com isto:

No próximo exemplo de registro PTR, dê uma olhada no servidor DNS IPv6 do Google 2001:4860:4860::8888:

Podemos usar a ferramenta dig com a flag -x para buscar o nome DNS reverso de um endereço IP. Por exemplo, confira o endereço IP DNS reverso de 8.8.4.4:

Os servidores de Internet usam registros PTR para rastrear nomes de domínio em entradas de log, tomar decisões informadas sobre o tratamento de spam e exibir informações fáceis de ler sobre outros dispositivos.

Os servidores de e-mail comumente usados buscarão o registro PTR do endereço IP de onde o e-mail foi enviado. Se o registro PTR estiver em branco, há uma grande chance de o e-mail ser spam (portanto, rejeitado). Observe que ter uma correspondência entre o FQDN e o nome de domínio do registro PTR não é a preocupação. O fator importante é se um registro PTR válido está associado a um registro A direto correspondente.

Geralmente, os roteadores de rede na internet possuem registros PTR correspondentes à sua localização física. Por exemplo, “NYC” ou “CHI” são referências válidas para roteadores localizados em Nova York e Chicago. Essa técnica é benéfica ao realizar um traceroute ou MTR e revisar o caminho que os pacotes estão fazendo.

Registros CAA

Esses registros especificam as CAs (Autoridades de Certificação) que podem emitir certificação SSL/TLS para o seu domínio. Desde 8 de setembro de 2017, todas as CAs são obrigadas a verificar os registros CAA antes de emitir um certificado. Se nenhum registro de CA existir, qualquer CA poderá emitir um certificado. Caso contrário, apenas CAs específicas têm permissão para emitir certificados. Os registros CAA podem ser aplicados a hosts individuais ou a um domínio inteiro.

Aqui está um exemplo de um registro CAA:

A parte específica do CAA na entrada é 0 issue "letsencrypt.org". Há três partes envolvidas nesta porção:

• Flags: É um valor inteiro que indica como uma CA deve lidar com tags que não entende. Se o valor da flag estiver definido como 0, então o registro será ignorado. Se o valor for 1, então a CA deve se recusar a emitir o certificado.
• Tags: Estas são strings que indicam o propósito de um registro CAA. Atualmente, os valores válidos incluem issue (autorizando uma CA a emitir certificados para um domínio específico), issuewild (autorizando certificados wildcard) e iodef definindo uma URL onde as CAs relatam violações de política).
• Valores: Estas são strings associadas à tag do registro. Se a tag for issue ou issuewild, o valor geralmente será o domínio da CA para a qual você está concedendo a permissão. Se a tag for iodef, será uma URL de um formulário de contato ou um link mailto: para feedback por e-mail.

Podemos usar a ferramenta dig para buscar os registros CAA:

Para informações mais detalhadas sobre registros CAA, confira RFC 6844.

Considerações Finais

Este guia descreve várias terminologias relacionadas ao DNS. Também descreve como todos os componentes se integram. Com esta visão geral detalhada em mente, você deve ter uma boa compreensão do funcionamento do sistema DNS. Embora a ideia geral seja simples e fácil de entender, os detalhes tornam-se complexos muito rapidamente. Para administradores inexperientes, pode ser difícil aplicar esses conceitos e estratégias.

Você é um cliente da CloudSigma? Então confira o gerenciamento e a atualização de registros DNS reverso/PTR para a sua infraestrutura CloudSigma.

Boa computação!