O que é DNS? Guia para donos de servidores

O que é DNS e porque o seu domínio ainda não chega ao seu VPS

O DNS (sistema de nomes de domínio) converte um nome como example.com num endereço IP (protocolo de Internet) como 203.0.113.10. Um navegador não consegue ligar-se a um nome. Liga-se a um endereço, por isso cada carregamento de página começa com uma pergunta DNS e uma resposta. Se acabou de comprar um domínio e um VPS seu, e nada carrega, uma de duas situações é verdadeira: ainda não existe nenhum registo que associe o nome ao endereço do seu servidor, ou existe um registo, mas algo no caminho continua a fornecer uma resposta antiga.

As duas situações são normais e nenhuma significa que exista uma avaria. As secções abaixo seguem as partes pela ordem em que as encontrará, começando pela que mais tempo desperdiça: qual é o painel de controlo que efetivamente contém os seus registos.

Todas as verificações aqui utilizam dig, que não está instalado por predefinição numa máquina Ubuntu ou Debian acabada de instalar.

sudo apt update && sudo apt install -y bind9-dnsutils

Registrar, nameservers e host DNS: qual deles deve editar

Estes três termos descrevem funções diferentes. Confundi-los é a razão mais comum para uma alteração não produzir efeito.

• O registrar é a empresa onde comprou o domínio. A sua função crítica é a delegação: informa o registry que gere o seu TLD (domínio de nível superior, a parte .com) sobre quais nameservers são autoritativos para o seu domínio.
• Os nameservers autoritativos contêm os registos reais da sua zona. Uma zona é o seu domínio e os nomes que existem abaixo dele.
• O host DNS é quem opera esses nameservers. Pode ser o registrar, um fornecedor separado ou bind9 em execução num servidor que lhe pertence.

Compra o domínio no registrar. Edita os registos no host DNS. Se transferiu o domínio para os nameservers de outro fornecedor, o painel DNS do próprio registrar continua a mostrar uma zona, continua a guardar as suas alterações e ninguém na Internet consulta essa zona. Os registos são reais. Simplesmente nunca são consultados.

Descubra onde o mundo está a consultar:

dig example.com NS +short
dig +trace example.com

O primeiro comando mostra os nameservers que respondem atualmente pelo domínio. O segundo percorre a cadeia a partir dos root servers e mostra a delegação que os servidores do TLD fornecem. Essa é a delegação controlada pelo seu registrar. Se esses nomes pertencerem a um fornecedor que não reconhece, é nesse fornecedor que encontrará o painel que precisa de utilizar.

Como uma única consulta percorre a hierarquia

Quatro partes estão envolvidas, e cada uma mantém uma cópia do que aprende.

1. O stub resolver na sua máquina. Não faz pesquisas. Consulta um servidor configurado e aceita a resposta. No Ubuntu, /etc/resolv.conf normalmente é um link simbólico para /run/systemd/resolve/stub-resolv.conf e identifica 127.0.0.53, que é o systemd-resolved executado localmente com a sua própria cache.
2. O resolvedor recursivo. É o resolvedor executado pelo seu ISP (fornecedor de serviços de Internet), por um serviço público como 1.1.1.1 ou por si. Faz o trabalho efetivo de encontrar a resposta.
3. Os servidores raiz e TLD. O resolvedor recursivo consulta um servidor raiz. Este não conhece o seu endereço, mas responde com uma referência aos servidores .com. Estes respondem com uma referência aos seus servidores de nomes.
4. O servidor de nomes autoritativo. Não consulta nenhum outro servidor. Responde a partir da sua zona e marca a resposta como autoritativa.

dig +trace example.com mostra este processo, porque começa na própria raiz e apresenta cada referência em vez de consultar uma cache. Esta é a forma mais rápida de verificar se a delegação e a zona estão de acordo.

Os registos DNS importantes quando executa um servidor

• A: associa um nome a um endereço IPv4. example.com. A 203.0.113.10. Este é o registo que aponta o seu domínio para o seu VPS.
• AAAA: associa um nome a um endereço IPv6, como 2001:db8::10. Publique-o apenas quando o seu serviço escutar efetivamente nesse endereço. Os clientes em redes IPv6 tentam primeiro a resposta AAAA, por isso um endereço que não tenha nenhum serviço a responder acrescenta uma espera a cada visita.
• CNAME: um alias de um nome para outro nome. www.example.com. CNAME example.com. envia os visitantes de www para o destino resolvido pelo domínio base. Um CNAME não pode existir no apex (o example.com sem subdomínio), porque o apex tem de conter os seus próprios registos SOA (start of authority) e NS, e um CNAME não pode partilhar um nome com qualquer outro registo. Os fornecedores disponibilizam alternativas com nomes como ALIAS, ANAME ou CNAME flattening.
• MX: indica para onde é entregue o correio do domínio. Contém um hostname e um número de preferência; o número mais baixo é tentado primeiro. Um MX tem de apontar para um nome que tenha um registo de endereço. Apontá-lo para um CNAME é inválido, e alguns servidores de envio irão rejeitá-lo.
• TXT: texto livre, usado para validação e políticas. Os registos de autenticação de correio (SPF, DKIM, DMARC) ficam aqui, tal como o token ACME (automatic certificate management environment) que emite um certificado wildcard.
• NS: indica quais os nameservers que servem a zona. A cópia que define onde o mundo faz as consultas fica na zona-pai e resulta da delegação do seu registrar, não da cópia dentro da sua própria zona.

Dois detalhes causam mais confusão do que os próprios tipos de registo. Um nome terminado por um ponto é absoluto, por isso www.example.com. significa exatamente isso e nada mais. A maioria dos painéis espera um nome relativo e acrescenta o domínio automaticamente. Assim, introduzir www.example.com no campo do nome produz www.example.com.example.com, que não resolve para ninguém. O outro detalhe é @, que em quase todos os painéis significa o apex: o domínio por si só, sem subdomínio.

Aponte um registo A para o seu VPS

Primeiro, obtenha o endereço que a Internet vê para o seu servidor:

curl -4 https://ifconfig.me
ip -brief -4 address show

Depois, crie um registo no seu fornecedor de DNS: tipo A, nome @, valor igual a esse endereço e TTL (tempo de vida) 300. Adicione um segundo registo para www, usando outro A com o mesmo endereço ou um CNAME a apontar para o domínio raiz.

Agora confirme se a resolução funciona, de preferência a partir do seu portátil e não do próprio servidor:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

O primeiro comando usa o caminho normal da sua máquina, incluindo as caches. O segundo ignora a cache local e consulta um resolvedor recursivo público. O terceiro consulta diretamente o seu servidor de nomes autoritativo. Por isso, a resposta representa o estado atual, sem qualquer cache no caminho. Quando o terceiro comando devolve o seu endereço e o primeiro não, o DNS está configurado corretamente e ainda está a aguardar a atualização de uma cópia em cache da resposta antiga.

A resolução de nomes não funciona

A resolução de nomes confirma que o DNS funciona. Não confirma nada sobre o seu servidor web. Depois de dig devolver o endereço correto, teste a ligação:

curl -I http://example.com

curl: (6) Could not resolve host: example.com é um problema de DNS. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused não é um problema de DNS: o nome foi resolvido e o pacote chegou, portanto o problema é que não havia nada a escutar nessa porta. Um pedido que fica pendente e depois excede o tempo limite normalmente indica que uma firewall descartou o pacote silenciosamente, em vez de o rejeitar. É neste ponto que o DNS deixa de ser o assunto, e as portas e os sockets em escuta e as regras da firewall ufw no seu VPS passam a ser relevantes. Depois de a ligação ser estabelecida, o restante carregamento da página é o HTTP a processar o pedido.

Por que o navegador ainda mostra o host antigo

Nada é propagado. Nenhum servidor envia a sua alteração para outras pessoas. O nameserver autoritativo mantém o novo valor assim que o guarda, e cada cópia em cache da resposta anterior continua válida até o temporizador próprio expirar. Esse temporizador é o TTL, em segundos, que o registo tinha quando foi entregue.

As cópias existem em mais locais do que se imagina: a cache curta do próprio navegador, o stub resolver da máquina, o resolver recursivo utilizado por essa rede e qualquer resolver que uma VPN tenha instalado no cliente. Cada um mantém a sua cópia durante, no máximo, o TTL recebido. Duas pessoas em duas redes podem ver respostas diferentes durante horas, e ambas as máquinas estão a funcionar corretamente.

Observe a contagem decrescente num resolver com cache:

dig @1.1.1.1 example.com +noall +answer

Execute o comando duas vezes, com alguns segundos de intervalo. O TTL da resposta diminui. Quando chega a zero, o resolver descarta o registo e consulta novamente o seu nameserver.

Existe uma segunda cache que quase ninguém considera: as respostas negativas. Quando um resolver recebe a informação de que um nome não existe, também coloca esse NXDOMAIN em cache, durante o período definido pelo último campo do registo SOA da sua zona.

dig example.com SOA +short

O último número dessa linha é o TTL negativo, frequentemente 3600. Por isso, consultar staging.example.com antes de o criar pode ocultar o registo durante uma hora completa depois da criação. Crie primeiro o registo e só depois consulte-o.

Alterar os nameservers é mais lento do que alterar um registo, e o motivo é mecânico. Os registos de delegação na zona .com são servidos com um TTL de 172800 segundos, ou seja, dois dias. Por isso, um resolver que tenha colocado em cache os nameservers antigos pode continuar a consultá-los durante esse período. É daí que vem a recomendação de "aguardar até 48 horas". Essa recomendação aplica-se a alterações de nameservers, não a edições de registos comuns.

Planeie uma migração em função do TTL, em vez de tentar contorná-lo:

1. Reduza o TTL do registo para 300 e guarde-o.
2. Aguarde mais tempo do que o TTL antigo, para que todas as cópias em cache que contêm o valor antigo tenham expirado.
3. Altere o endereço.
4. Depois de o tráfego ter sido transferido, aumente novamente o TTL para 3600 ou mais, porque um TTL baixo faz com que cada resolver consulte os seus nameservers com muito mais frequência.

Para limpar o que a sua própria máquina mantém:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics apresenta uma secção de cache com contadores de acertos e falhas. Assim, logo depois da limpeza, a consulta seguinte aparece como uma falha. Os navegadores mantêm uma cache separada, o que significa que o Chrome ainda pode utilizar uma resposta antiga depois de a cache do sistema estar vazia. Limpe essa cache em chrome://net-internals/#dns. Verifique também /etc/hosts, porque uma linha antiga nesse ficheiro tem precedência sobre o DNS nessa máquina, e apenas nessa máquina. getent hosts example.com mostra a resposta que o sistema realmente utilizará, incluindo /etc/hosts.

Os certificados wildcard são comprovados com um registo TXT

Uma CA (autoridade de certificação) verifica o controlo sobre um nome antes de emitir um certificado. O desafio HTTP-01 disponibiliza um ficheiro na porta 80 desse nome de host exato, o que funciona bem para um único nome. Um certificado wildcard abrange *.example.com, um conjunto aberto de nomes de host do qual a CA não pode obter um ficheiro. Por isso, a Let's Encrypt emite certificados wildcard apenas através do desafio DNS-01. Publique um registo TXT em _acme-challenge.example.com com um token fornecido pela CA. O controlo da zona é a prova.

Isto torna o seu fornecedor de DNS parte da renovação do certificado. O Certbot tem de criar e eliminar esse registo TXT em cada renovação, sem intervenção manual. Para isso, precisa de uma API e de um plugin compatível com o seu fornecedor. Quando a validação falha, a mensagem habitual é DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com. Isto significa que a CA consultou o DNS antes de o registo estar visível. O registo pode nunca ter sido guardado ou uma resposta negativa pode ainda estar em cache. O procedimento completo está no guia sobre certificados wildcard com o desafio DNS-01.

Quando uma VPN assume o controlo do resolvedor

Um cliente VPN (rede privada virtual) normalmente substitui o resolvedor do sistema enquanto está ligado, porque enviar as consultas para a rede local revelaria a essa rede o nome de todos os sites que visita. Esse é o comportamento correto, mas pode falhar de duas formas.

Se o túnel é estabelecido e os nomes deixam de ser resolvidos enquanto os endereços continuam a funcionar, o resolvedor instalado pelo cliente não está acessível a partir do túnel. ping 1.1.1.1 é concluído com sucesso e curl https://example.com retorna curl: (6) Could not resolve host: example.com. Se, em vez disso, o túnel é estabelecido e as consultas continuam a ser enviadas para a rede à qual está ligado, o tráfego passa pelo túnel enquanto o resolvedor local continua a ver todos os nomes que consulta.

resolvectl status

Esse comando mostra o resolvedor utilizado em cada ligação. Assim, pode verificar qual resolvedor o túnel instalou e se é o que pretendia. Um túnel WireGuard define este valor a partir da linha DNS = na configuração do cliente. O artigo corrigir o DNS quando o WireGuard assume o controlo do resolvedor aborda em detalhe os casos de systemd-resolved e resolvconf.

Os códigos de resposta e o que cada um indica

• NXDOMAIN: um servidor autoritativo informa que o nome não existe. Verifique a ortografia, confirme se não duplicou o sufixo do domínio e confirme se editou a zona para a qual a sua delegação aponta.
• NOERROR com um ANSWER SECTION vazio: o nome existe, mas não tem nenhum registo do tipo solicitado. Consultar AAAA quando só existe um A produz exatamente este resultado.
• SERVFAIL: o resolver tentou responder, mas não conseguiu produzir uma resposta. As duas causas habituais são servidores autoritativos que nunca respondem e uma falha na validação de DNSSEC (domain name system security extensions). Teste com dig @1.1.1.1 example.com A +cd, que desativa a validação. Uma resposta com +cd e SERVFAIL sem essa opção significa que o problema está nas assinaturas. Isto acontece depois da mudança de um nameserver, quando o servidor pai ainda publica o registo DS (delegation signer) antigo.
• REFUSED: o servidor consultado não responde a essa pergunta, normalmente porque apontou dig para um servidor autoritativo de um domínio que ele não serve.
• ;; connection timed out; no servers could be reached: o dig nunca chegou a um resolver. Trata-se de um problema de rede ou do resolver no seu lado. Portanto, o domínio não é a causa.

ping: example.com: Temporary failure in name resolution é a mesma classe de falha reportada pelo glibc, e não pelo dig.

Você deve executar servidores DNS no seu próprio VPS?

Pode. bind9, knot ou nsd servirão a sua zona a partir do servidor, e isso ensina mais sobre DNS do que qualquer painel. As objeções são práticas. Um domínio deve ter pelo menos dois servidores DNS em redes separadas. Por isso, um único VPS torna-se um ponto único de falha para todos os serviços do domínio, incluindo o e-mail. Os servidores DNS cujo nome está dentro do domínio que servem precisam de registros glue no registrador. Esse registro contém o endereço de ns1.example.com armazenado na zona pai. Sem ele, a resolução não tem como começar. Quando um resolvedor não consegue alcançar o seu servidor DNS, ele não recorre ao seu site. O domínio inteiro deixa de estar disponível para esse utilizador. O DNS hospedado com uma API é a opção de menor risco para a maioria das pessoas. Executar um resolvedor de cache no seu VPS para as suas próprias máquinas é uma tarefa diferente e um compromisso muito menor.

FAQ

Por que a minha alteração de DNS ainda não foi propagada?

Nada é propagado. Os seus servidores de nomes autoritativos mantêm o novo valor assim que o guarda, e cada resolver que já fez uma consulta mantém a cópia em cache até expirar o TTL recebido. Consulte diretamente o servidor autoritativo com dig @ns1.your-dns-host.net example.com A +short. Se devolver o novo endereço, a alteração está ativa e o que resta é apenas a cache. Se alterou os servidores de nomes em vez dos registos, espere muito mais tempo, porque as delegações dos TLD são distribuídas com um TTL de dois dias.

Como descubro quais servidores de nomes o meu domínio utiliza efetivamente?

dig example.com NS +short apresenta os servidores de nomes que respondem atualmente pelo domínio, e dig +trace example.com mostra a cadeia de referências desde a raiz, incluindo a delegação que os servidores do TLD distribuem. Se esses nomes não corresponderem ao fornecedor cujo painel editou, esse é o problema. Edite os registos no fornecedor indicado na delegação ou altere a delegação no seu registrar para que aponte para o local pretendido.

O meu domínio resolve, mas o site continua sem carregar. E agora?

O DNS está concluído assim que dig example.com A +short devolver o endereço do seu servidor. A partir daí, o problema está na ligação. Se curl -I http://example.com devolver Connection refused, não há nada a escutar nessa porta. Um pedido que fica pendente até atingir o tempo limite indica que uma firewall descartou o pacote. Confirme se o seu servidor Web está em execução e associado ao endereço público. Depois, verifique a firewall do servidor e a firewall de rede separada no painel de controlo do seu fornecedor.

Por que não posso colocar um CNAME no meu domínio raiz?

Um CNAME indica que um nome é um alias de outro nome, e um nome que tenha um CNAME não pode conter qualquer outro registo. O seu domínio raiz tem de conter registos SOA e NS para existir como uma zona, por isso não pode também ser um CNAME. Utilize um registo A que contenha o endereço na raiz ou utilize a funcionalidade do fornecedor comercializada como ALIAS, ANAME ou CNAME flattening. Essa funcionalidade armazena um nome e responde às consultas com o endereço para o qual esse nome resolve atualmente.