Artigo original: Why a domain’s root can’t be a CNAME — and other tidbits about the DNS

Este artigo usará a pergunta acima para explorar DNS, dig, registros A, registros CNAME e registros ALIAS/ANAME da perspectiva de um iniciante. Vamos começar.

Primeiro, alguns conceitos

  • Domain Name System (DNS): o sistema geral para converter um nome de domínio inteligível para humanos (como "example.com") em um endereço IP (93.184.216.34). O endereço IP é de um servidor (geralmente, um servidor da web) onde são armazenados os arquivos necessários para exibir uma página da web.
  • Servidor DNS (também conhecido como servidor de nomes): usa o software do DNS para armazenar informações sobre endereços de domínio. Existem vários níveis — aqueles pertencentes a cada provedor de serviços de internet, root (13 no total em todo o mundo), domínios de primeiro nível (em inglês, "TLD" – por exemplo, ".com") e servidores DNS de nível de domínio.
  • Nome de domínio: o domínio (example) combinado com o TLD (.com). O termo 'domínio' é frequentemente usado como sinônimo do nome de domínio, embora sejam diferentes. Quando você compra um "domínio" de uma empresa de registro ou revendedor, você compra os direitos de um nome de domínio específico (como "example.com") e quaisquer subdomínios que desejar criar (meu-site.example.com, mail.example.com etc.).

Fluxo de consulta de alto nível

O fluxo de alto nível do que acontece quando você digita "example.com" em seu navegador pode ser simplificado para remover os saltos para os servidores ISP, root e DNS de TLDs, conforme vemos abaixo:

-Yu9MR65z19xx2TDl-6phT7soy3g3KNgjArX
Simplificação do fluxo de uma requisição DNS. Mais detalhes podem ser consultados aqui (texto em inglês).

Um domínio normalmente tem dois ou mais servidores de nome, contendo registros relacionados ao nome de domínio (como "example.com").

Muitos tipos de registros podem ser armazenados, a maioria dos quais pode ter várias entradas por tipo:

  • A: Registros de endereço que mapeiam o nome de domínio para um endereço IP
  • CNAME: Registro de Nome Canônico. Usado para apelidar um nome de domínio (ou nome de subdomínio) para outro. Veremos isso em mais detalhes posteriormente.
  • MX: registros do Mail eXchange que informam aos agentes de entrega de e-mail onde eles devem entregar seu e-mail
  • TXT: registros de texto flexíveis, para armazenar strings para uma variedade de usos
  • SOA: Registro Singular de Início de Autoridade mantido no nível superior do domínio. Contém informações específicas necessárias sobre o domínio, como por exemplo, seu servidor de nomes principal

Quando seu dispositivo envia uma consulta que chega a um servidor de nomes, o servidor procura no nó de registro do domínio um registro A e o endereço IP armazenado associado (example.com: 93.184.216.34). Esse endereço é, então, retornado ao dispositivo para ser usado para enviar uma solicitação ao servidor da web correto para recuperar a página da web ou o recurso solicitado.

Usando o 'dig'

dig (explorador de informações de domínio – do inglês Domain Information Groper) é uma ferramenta de linha de comando para consultar servidores DNS. Esse comando geralmente é usado para solução de problemas ou, como agora, para entender mais sobre a configuração de um sistema.

$ dig example.com resulta em uma resposta longa impressa no terminal, cuja saída padrão é detalhada aqui (texto em inglês). Dela, temos interesse apenas em ver a SEÇÃO DE RESPOSTAS(do inglês, ANSWER SECTION).

;; ANSWER SECTION:
example.com.       72703      IN     A       93.184.216.34

Podemos ver que example.com retorna um registro A de 93.184.216.34. Às vezes, os domínios terão mais de um registro A, se mais de um servidor da web puder fornecer as informações necessárias.

Tem mais! Se tentarmos alguns outros exemplos, logo veremos que outro registro comum aparece: CNAME.

$ dig www.skyscanner.net:

;; ANSWER SECTION:
www.skyscanner.net. 169 IN CNAME www.skyscanner.net.edgekey.net.
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

Usar o sinalizador +short nos permite ver claramente o caminho formado:

$ dig www.skyscanner.net +short

www.skyscanner.net.edgekey.net.
e11316.a.akamaiedge.net.
23.217.6.192

CNAME

Um registro CNAME permite que um nome de domínio seja usado como um apelido para outro domínio canônico (verdadeiro).

Quando o servidor DNS retorna um registro CNAME, ele não o retorna ao client. Em vez disso, ele procurará novamente o nome de domínio retornado e, por sua vez, retornará o endereço IP do registro A. Essa cadeia pode continuar com muitos níveis de CNAME profundos, mas sofre pequenos impactos de desempenho de várias pesquisas antes do armazenamento em cache.

Um exemplo simples disso pode ser se você tiver um servidor onde guarda todas as suas fotos. Você pode acessá-lo normalmente através de photos.example.com. No entanto, você também pode querer permitir o acesso via photographs.example.com. Uma maneira de tornar isso possível é adicionar um registro CNAME que aponte photographs para photos. Isso significa que, quando alguém visitar photographs.example.com, receberá o mesmo conteúdo que photos.example.com.

Usando a consulta $ dig photography.example.com, veríamos:

photographs.example.com    IN   CNAME photos.example.com
photos.example.com         IN   A     xx.xxx.x.xxx

É importante observar que o CNAME é aquela parte do lado direito. O lado esquerdo é o nome do apelido ou rótulo.

Outro uso comum é para o subdomínio www. Depois de comprar example.com, você provavelmente também desejará que os usuários que digitem www.example.com vejam o mesmo conteúdo.

Vale a pena notar aqui que example.com pode ser chamado de ápice, raiz ou nome de domínio puro.

Uma opção seria configurar outro registro A, apontando para o mesmo endereço IP de example.com. Isso é totalmente válido e é o que o site real example.com faz, mas não escala bem. O que acontece se você precisar atualizar o endereço IP para o qual example.com aponta? Você também precisaria atualizá-lo para o subdomínio www e qualquer outro que possa usar.

Se um registro CNAME foi usado como apelido para www.example.com para apontar para example.com, apenas o domínio raiz teria que ser atualizado, já que todos os outros nós apontam para ele.

Limitações do CNAME

Na época em que os padrões de DNS foram escritos, algumas regras foram estabelecidas para reger seu uso. RFC 1912 e RFC 2181 estabelecem que:

  • Os registros SOA e NS são obrigatórios no domínio raiz
  • Os registros CNAME só podem existir como registros únicos e não podem ser combinados com nenhum outro registro de recurso (com exceção dos registros DNSSEC SIG, NXT e KEY RR)

Isso exclui um CNAME de ser usado no domínio raiz, pois isso faria com que as duas regras se contradissessem.

O importante aqui é que se trata de uma limitação contratual, não técnica. É possível usar um CNAME na raiz, mas pode resultar em erros inesperados, pois está quebrando o contrato de comportamento esperado.

Um exemplo disso é relatado pela Cloudflare, descrevendo problemas que eles encontraram com os servidores de e-mail do Microsoft Exchange depois de usar um CNAME em seu domínio raiz:

Os domínios geralmente designam os servidores que lidam com seus e-mails por meio do que é conhecido como registro MX. O problema era que os servidores Exchange… podiam pegar o CNAME no registro raiz e não respeitar adequadamente o CNAME definido no registro MX. Você não pode realmente culpar o Exchange. Eles estavam operando sob as suposições estabelecidas pela especificação do DNS.

Aqui, você vê a desvantagem que pode aparecer em vários softwares de servidor ou bibliotecas. Como existe um padrão para que um CNAME seja o único registro em um nó, nenhum outro registro é procurado. Todos os outros registros serão ignorados silenciosamente, sem aviso ou mensagens de erro. Mesmo que um registro MX tenha sido definido para receber e-mail, o MX será ignorado como se não existisse porque o CNAME é avaliado primeiro. O mesmo é verdadeiro se houvesse um registro A: o CNAME teria precedência e o registro A não seria lido.

A internet moderna

Então, por que isso é um problema? Por que você desejaria usar um CNAME para seu domínio raiz? Certamente, esse é o fim do caminho ao procurar o endereço IP do servidor da web que hospeda seu conteúdo?

No cenário moderno da internet, esse não é mais o caso. O mundo é muito diferente de quando os padrões de DNS foram escritos.

Você pode optar por usar um provedor de plataforma como serviço (do inglês, PaaS), como o Heroku, e armazenar conteúdo em seus servidores da web. Você controla o conteúdo, mas não a infraestrutura. O provedor de PaaS faz o trabalho pesado da manutenção da rede. Eles normalmente fornecem um URL (`my-app.herokuapp.com`) que é um subdomínio de seu domínio raiz. Você pode visualizar os endereços IP dos servidores da web em que seu conteúdo está. Eles, no entanto, estão totalmente sob o controle do provedor de PaaS e serão alterados sem aviso prévio.

A escala e a frequência das alterações de back-end feitas pelo provedor de PaaS podem dificultar a manutenção do registro A do domínio raiz apontando para um único endereço IP. Idealmente, você gostaria de fazer isso:

example.com      IN   CNAME    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.example.com      IN   CNAME    my-app.herokuapp.com.
www.example.com  IN   CNAME    my-app.herokuapp.com.

para permitir que o Heroku (ou seu provedor de host escolhido) gerencie a atualização do registro A para a qual o CNAME aponta sem nenhuma alteração feita por você. No entanto, como sabemos agora, isso quebra a especificação do DNS e, portanto, é uma péssima ideia.

É possível simplesmente implementar um redirecionamento 301/302 de example.com para www.example.com. Porém, essa instrução ocorre no servidor da web (portanto, ainda tem o problema de precisar usar um registro A fixo no DNS para apontar para esse servidor da web) ou um redirecionamento de provedor de DNS personalizado (que sofre complicações com HTTPS).

Isso também tem o efeito colateral de alterar o domínio que você vê na barra de URL, o que você pode não querer. Este método destina-se a quando seu site foi movido permanentemente ou quando você está tentando preservar as classificações de SEO, em vez de resolver o problema de apontar para um back-end de mudança complexo de maneira escalável.

A solução

Vários provedores de DNS já desenvolveram soluções personalizadas para contornar esse problema, incluindo:

  • ALIAS em DNSimple
  • ANAME em DNS Made Easy
  • ANAME em easyDNS
  • CNAME (virtual) em CloudFlare

Esses são todos os tipos de registro virtual que fornecem comportamento semelhante ao CNAME, sem nenhuma das desvantagens. A implementação exata pode diferir, mas, em um alto nível, quando o servidor DNS vê um desses tipos de registro virtual, ele age como um resolvedor de DNS. Ele segue a cadeia criada pelo apelido até resolver em um registro (ou registros) A e retornar esses registros A ao servidor DNS. Isso "achata" a cadeia CNAME nos registros A retornados e é indistinguível da consulta enviada. A consulta vê apenas um registro A puro, que não quebra a especificação do DNS e não apresenta nenhuma das desvantagens de um CNAME.

Esses registros virtuais podem ficar ao lado de outros registros na raiz, sem medo de comportamentos não intencionais. Dependendo do método de resolução de DNS do provedor ao seguir a cadeia CNAME, eles também podem ter benefícios de desempenho ao armazenar em cache pesquisas anteriores.

Para uma configuração simples de DNS, configuraríamos conforme abaixo. Essa solução tem todas as vantagens da técnica de apelidar ou rotular um nome de domínio e nenhum dos riscos de usá-lo no nível raiz.

example.com      IN   ALIAS    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.

Obrigado por ler este artigo!

Como sempre, estou aberto a quaisquer correções ou tópicos adicionais.

Referências (todas em inglês)