Qual TTL usar nos registros DNS

Todo registro DNS tem um campo pequeno que costuma ficar no valor que o painel sugeriu: o TTL. Ele decide quanto tempo uma mudança leva para chegar aos visitantes, quantas consultas o seu provedor de DNS recebe e se o seu site continua acessível quando algo dá errado.

Não existe um valor único certo, e sim o valor certo para cada registro e para cada momento. A escolha fica simples quando você sabe o que o TTL controla e quanto custa errar para cima ou para baixo.

O que o TTL controla?#

TTL (time to live) é o número de segundos que um resolvedor pode guardar a resposta de um registro em cache antes de perguntar de novo ao servidor autoritativo. A RFC 1035 define o campo, e a RFC 2181 fixa o máximo em 2147483647 segundos. Resolvedores podem impor um teto menor: a RFC 8767 recomenda limitar a 7 dias (604800 segundos).

É uma troca direta, que a documentação de TTL da Cloudflare resume assim: TTL longo aumenta a chance de a resposta estar em cache e acelera as consultas, mas faz as mudanças demorarem mais para valer. No pior caso, uma mudança demora o TTL antigo inteiro para chegar a todos, como explica o artigo sobre propagação de DNS.

Quais critérios definem o TTL certo?#

Antes de escolher um número, responda cinco perguntas:

1. Com que frequência esse registro muda? Um MX que não muda há anos aguenta TTL longo. O registro A de um servidor que você pode trocar no mês que vem, não.
2. Você precisa trocar o destino rapidamente numa emergência? Se o plano de contingência é apontar o domínio para outro servidor, o TTL é o tempo mínimo de recuperação para quem já tem cache.
3. Quantas consultas o domínio recebe? Alguns provedores de DNS cobram por consulta. A documentação do Route 53 lembra que um TTL maior reduz as chamadas dos resolvedores, a latência e a fatura.
4. O que acontece se o DNS autoritativo ficar fora do ar? Com TTL longo, os resolvedores continuam respondendo do cache por mais tempo.
5. O registro está atrás de um proxy ou CDN? Nesse caso, o IP que o visitante recebe é o da borda, e o provedor costuma fixar o TTL.

Quais são os valores comuns e seus prós e contras?#

Valores abaixo de 60 segundos raramente compensam. Muitos provedores nem permitem: cada um define um mínimo e um máximo, às vezes diferentes por plano, como mostra a documentação de TTL da Cloudflare.

Qual TTL usar em cada tipo de registro?#

Os tipos estão explicados em o que são registros DNS. Esta é a recomendação para cada um:

• A e AAAA (IP do site ou da API): 3600 se o servidor é estável; 300 se você ainda pode trocar de hospedagem ou de IP. Se a sua hospedagem pede um CNAME no lugar do A, siga essa orientação, como mostra A vs CNAME.
• CNAME: 3600 na maioria dos casos. O destino do CNAME tem o próprio TTL, controlado por quem opera esse nome, e o resolvedor respeita os dois.
• MX (e-mail): 3600 ou mais. E-mail tolera bem mudanças lentas, porque servidores de envio tentam de novo.
• TXT (SPF, DKIM, verificação de domínio): 3600. Ao configurar uma verificação nova, 300 ajuda a corrigir um erro de digitação sem esperar.
• NS: 86400 ou o valor que o seu provedor de DNS definir. A delegação na zona pai (como .com ou .br) tem TTL próprio, definido por quem opera o TLD, e você não controla esse valor.
• Registros com health check e failover: 60 segundos ou menos. É a recomendação da documentação de failover do Route 53, para que os clientes reajam rápido a mudanças de saúde.

Há também o cache de respostas negativas. Se alguém consulta um nome antes de você criá-lo, o resolvedor guarda o "não existe" pelo menor valor entre o TTL do SOA e o campo MINIMUM do SOA, conforme a RFC 2308. Se você cria subdomínios com frequência, um MINIMUM de 300 a 3600 evita esperas longas.

Qual TTL usar antes de uma migração?#

O TTL que vale numa troca é o do registro antigo, não o do novo. Por isso a redução precisa vir antes:

1. Anote o TTL atual. Se for 86400, você precisa de 1 dia de antecedência.
2. Reduza o TTL para 300 (ou 60, se cada minuto conta).
3. Espere o TTL antigo inteiro passar.
4. Troque o valor do registro e confirme que tudo funciona.
5. Suba o TTL de volta para 3600 ou mais.

É o mesmo roteiro que a documentação do Route 53 recomenda: começar com um valor curto, como 300 segundos, e aumentar depois de confirmar que a configuração nova está certa. Para o passo a passo de apontar o domínio, veja como apontar um domínio para sua hospedagem.

TTL muito baixo tem desvantagens?#

Tem, e por isso não vale deixar 60 segundos em tudo "por garantia":

• Mais consultas. Cada resolvedor volta ao autoritativo a cada minuto. Em provedores que cobram por consulta, isso aparece na fatura.
• Primeira visita mais lenta. Quanto menos tempo a resposta fica em cache, mais visitantes pagam a ida completa até o autoritativo.
• Menos resistência a falhas. Se o provedor de DNS sofre um ataque ou fica fora do ar, um TTL longo mantém o domínio respondendo pelo cache. A RFC 8767 descreve resolvedores que servem respostas expiradas nesse caso, mas nem todos fazem isso.

O equilíbrio para a maioria dos projetos é 300 durante mudanças e 3600 no dia a dia.

Como conferir o TTL de um registro?#

Use dig. Primeiro, descubra os servidores autoritativos do domínio:

dig NS exemplo.com +short

Se você consultar um deles diretamente, vê o TTL configurado. Se consultar um resolvedor público, vê quanto falta para aquele cache expirar:

dig @ns1.provedor-dns.example exemplo.com A +noall +answer
dig @8.8.8.8 exemplo.com A +noall +answer

Na resposta, o número entre o nome e IN é o TTL em segundos. Rode a consulta ao resolvedor duas vezes: o número diminui até o cache expirar.

Para ver o valor usado no cache negativo, consulte o SOA. O último número da resposta é o campo MINIMUM:

dig exemplo.com SOA +short

Como fazer isso na Square Cloud#

Na Square Cloud, o domínio personalizado está disponível a partir do plano Standard. O painel mostra os registros DNS necessários, e você os cria no seu registrador ou provedor de DNS. Como a zona continua com você, é lá que você define o TTL, com os critérios acima.

O painel mostra o status de validação em tempo real, emite o TLS automaticamente e aceita domínios com acento (Punycode). Se você está trazendo um domínio que já aponta para outro lugar, reduza o TTL antes de trocar os registros e acompanhe a validação pelo painel.

Enquanto isso, toda aplicação web continua acessível pelo subdomínio *.squareweb.app com HTTPS, em todo plano. Veja como configurar na página de domínios.