Tempo de vida: O que é o TTL e por que é importante para a configuração do DNS?

07/11/2022

Se vocês souberem alguma coisa sobre o DNS, provavelmente já ouviram falar do “tempo de vida” (em inglês, Time to Live, abreviado TTL). No entanto, cometer erros ao configurar os TTL é mais comum do que se imagina. Neste artigo, analisamos as peculiaridades dos conjuntos de registros do DNS, os domínios pai/filho e como evitar os problemas com o TTL.

Por Lars-Johan Liman, Especialista Sênior em Sistemas na Netnod. Originalmente publicado aqui

Bem-vindo ao The Quirks of the DNS, uma série de postagens no blog nas que destaco algumas das peculiaridades do sistema de nomes de domínio (DNS), o banco de dados universal de todas as coisas relativas à Internet. Vamos estudar algumas situações interessantes que podem ocorrer com o DNS e daremos algumas dicas sobre como evitar problemas.

Neste trabalho, analisaremos o valor do “tempo de vida” (TTL), um campo de cada registro do DNS que informa aos clientes DS por quanto tempo as informações nesse registro são válidas e, portanto, por quanto tempo podem ser armazenadas no cache do cliente DNS. O TTL seria como a data de validade em uma caixa de leite. Passada essa data, o cache sabe que deve jogar fora esse leite e procurar um novo.

O TTL e os registros do DNS pai/filho

No DNS, a “transferência” de um servidor que serve um nome mais curto (se.) para um que serve um nome mais longo (netnod.se.) é expresso por registros do tipo “servidor de nomes”. (em inglês, nameserver, abreviado NS). Um cliente que solicite ao servidor se. um nome que termine em netnod.se. receberá apenas registros NS informando-lhe que deve procurar em outro lugar, quer dizer, nos servidores que contêm as informações do netnod.se.

Os registros que entrega no servidor se. (o “pai”) serão visualizados assim:

netnod.se.                            86400     IN            NS           nna.netnod.se.

netnod.se.                            86400     IN            NS           nnb.netnod.se.

netnod.se.                            86400     IN            NS           nnp.netnod.se.

netnod.se.                            86400     IN            NS           nnu.netnod.se.

A sequência netnod.se. da esquerda (chamada “nome do proprietário”) mostra qual subdomínio (“filho”) é delegado; IN (a “classe”) mostra que estamos lidando com informações relacionadas à Internet; NS (o “tipo de registro”) mostra que a resposta que estamos recebendo é a informação do servidor de nomes para o filho, e os nomes à direita (os “dados de registro”) nos informam os nomes dos servidores que contêm informações do DNS sobre o netnod. se. e os nomes que estão “abaixo” deste.

O último campo —o número 86400— é conhecido como tempo de vida (TTL). Este campo informa ao destinatário dos dados que pode confiar nos dados recebidos (neste caso) durante 86.400 segundos (= 24 horas) sem precisar perguntar novamente. Os dados podem ser armazenados localmente no cache do cliente durante este período de tempo.

PECULIARIDADE n.º 1: Todos os TTL de um conjunto de registros devem ter o mesmo valor

Um “conjunto de registros” (RRSET) é o conjunto completo de todos os registros que possuem o mesmo nome de proprietário, a mesma classe e o mesmo tipo. No exemplo acima, há um conjunto de registros para a combinação [netnod.se., IN, NS] que é composto de quatro registros. O DNS trata os conjuntos de registros como se estivessem “colados” e sempre devem ser transferidos e interpretados como um grupo. Se o pool de registros pudesse ser dividido, os diferentes “atores” do mundo do DNS teriam visões diferentes dos dados do DNS, e o banco de dados não seria mais coerente e consistente.

O requisito de que as exibições de banco de dados devem ser consistentes leva ao requisito de que o valor do TTL deve ser o mesmo para todos os membros de um conjunto de registros. Há dois motivos para isso:

1. Os clientes recebem o RRSET e o armazenam em seus caches. Todos os valores do TTL de todos os registros no cache são reduzidos de forma contínua, e quando o TTL de um registro chega a 0, esse registro é removido do cache. Se os membros de um RRSET tiverem TTL diferentes, estes serão excluídos em momentos diferentes, “forçando” o sistema de cache a dividir o conjunto de registros e o requisito de consistência não será mais atendido. O cache apenas irá conter algumas das partes. A imagem do banco de dados já não será correta. Portanto, é importante que todos os registros de um RRSET sejam removidos do cache ao mesmo tempo. A ausência de registros no cache forçará o cliente a solicitar que a fonte lhe envie um RRSET “novo”, e o cache voltará a conter dados consistentes.
    
2. Isso é ainda mais importante quando forem adicionadas as extensões de segurança ao DNS (habilitando o DNSSEC). No DNSSEC, as assinaturas criptográficas são usadas como uma ferramenta para o cliente validar que os dados do DNS recebidos não foram adulterados durante seu trânsito pela rede. O DNSSEC assina conjuntos de registros, não registros individuais. Uma parte importante da assinatura é “o TTL original” (quer dizer, o valor inicial do TTL, antes do cache começar a diminui-lo). Esse TTL original é um valor único que abrange todo o RRSET. Se os registros do conjunto originalmente tinham valores diferentes, a assinatura não seria correta e não seria possível validar os dados.

RECOMENDAÇÃO: Certifique-se de que todos os registros de um conjunto tenham o mesmo TTL.

PECULIARIDADE n.º 2: Os registros NS para pais e filhos devem estar sincronizados

Os registros NS devem estar presentes tanto no pai (que “dá autoridade”) quanto no filho (que “recebe autoridade”). Os registros parecem exatamente os mesmos em ambas as localizações, mas não são mantidos sincronizados automaticamente (a menos que sejam usadas adições muito recentes ao protocolo DNS). Isso deve ser feito de forma manual. Como todos sabemos, nós humanos não somos muito bons em manter as coisas em sincronia, então isso cria uma grande oportunidade para os sistemas divergirem. Duas coisas costumam acontecer:

1. Os administradores dos dados filhos alteram o conjunto de servidores de nomes e se esquecem de informar o pai sobre seu desejo de fazê-lo. Se os administradores filhos alterarem todos os servidores, as coisas vão parar de funcionar. Se apenas alterarem alguns, as coisas poderiam continuar a funcionar de forma degradada.
    
2. Os registros do pai têm um TTL diferente ao do filho. Isso é um problema menor, mas pode causar um tráfego do DNS desnecessário se os TTL dos registros no banco de dados filho tiverem um TTL menor do que os do banco de dados pai. Uma vez que os registros NS no banco de dados filho são considerados “autoritários” (isto é, têm uma “prioridade” mais alta do que os do pai), o filho pode “brincar” com o TTL sem o conhecimento ou consentimento do pai. Se o pai projetar seus sistemas DNS para um determinado padrão de tráfego que é o resultado esperado da configuração do TTL para seus filhos para um valor específico, podem se surpreender se os filhos definirem o TTL para os registros NS com um valor completamente diferente.

RECOMENDAÇÃO: Como gerenciador de dados filho, mantenha seus valores de TTL para os registros NS alinhados com aqueles que aparecem no banco de dados do seu pai. Espero que este artigo tenha sido útil para vocês. Fiquem atentos, pois postaremos outras notas na medida em que aprofundemos nas peculiaridades do DNS. Enquanto isso, se vocês tiverem alguma dúvida sobre a configuração do DNS ou sobre como o serviço de DNS anycast de Netnod pode ajudá-los, clique  aqui para entrar em contato conosco.