Quanto tempo leva para a propagação dos registros DNS?

Esta é uma pergunta canônica sobre a propagação de DNS

Quanto tempo leva para que os vários tipos de registros sejam propagados?
Alguns se propagam mais rápido que outros?
Por que demora a propagação dos registros DNS e como funciona?

"Propagação de DNS" não é um fenômeno real, por si só. Pelo contrário, é o efeito manifesto da funcionalidade de armazenamento em cache especificada no protocolo DNS. Dizer que as alterações "se propagam" entre servidores DNS é uma falsidade conveniente que é, sem dúvida, mais fácil de explicar para usuários não técnicos do que descrever todos os detalhes do protocolo DNS. Não é realmente como o protocolo funciona, no entanto.

Servidores DNS recursivos fazem consultas em nome dos clientes. Servidores DNS recursivos, geralmente executados por ISPs ou departamentos de TI, são usados ​​pelos computadores clientes para resolver nomes de recursos da Internet. Os servidores DNS recursivos armazenam em cache os resultados das consultas que eles fazem para melhorar a eficiência. As consultas para informações já armazenadas em cache podem ser respondidas sem fazer nenhuma consulta adicional. A duração, em segundos, que um resultado é armazenado em cache deve basear-se em um valor configurável chamado Time To Live (TTL). Este valor é especificado pelo servidor DNS autoritativo para o registro consultado.

Não há uma resposta para todas as perguntas feitas porque o DNS é um protocolo distribuído. O comportamento do DNS depende da configuração do servidor DNS autoritativo para um determinado registro, da configuração de servidores DNS recursivos que fazem consultas em nome dos computadores clientes e da funcionalidade de cache do DNS incorporada aos sistemas operacionais dos computadores clientes.

É uma boa prática especificar um valor TTL curto o suficiente para acomodar alterações diárias necessárias nos registros DNS, mas longo o suficiente para criar uma "vitória" no cache (ou seja, não tão curto que o tempo de espera do cache seja muito rápido para fornecer qualquer melhoria de eficiência). Empregar uma estratégia equilibrada com valores TTL resulta em uma "vitória" para todos. Reduz a utilização de carga e largura de banda para os servidores DNS autoritativos de um determinado domínio, os servidores raiz e os servidores de TLD. Reduz a utilização da largura de banda upstream para o operador do servidor DNS recursivo. Isso resulta em respostas de consulta mais rápidas para computadores clientes.

Como o TTL de um registro DNS é definido, a carga menor e a utilização da largura de banda nos servidores DNS autoritativos aumentarão porque os servidores DNS recursivos não poderão armazenar em cache o resultado por um longo período. Como o TTL de um registro é maior, as alterações nos registros não parecerão "ter efeito" rapidamente, porque os computadores clientes continuarão a receber resultados armazenados em cache armazenados em seus servidores DNS recursivos. Definir o TTL ideal se resume a um ato de equilíbrio entre utilização e capacidade de alterar registros rapidamente e ver essas alterações refletidas nos clientes.

Vale ressaltar que alguns ISPs são abusivos e ignoram os valores TTL especificados pelos servidores DNS autoritativos (substituindo sua própria substituição administrativa, que é uma violação do RFC). Não há nada a ser feito sobre isso, de uma perspectiva técnica. Se os operadores de servidores DNS abusivos puderem ser localizados, as queixas dos administradores de sistemas podem resultar na implementação de práticas recomendadas (sem dúvida o que equivale ao senso comum de qualquer engenheiro de rede familiarizado com o DNS). Esse tipo específico de abuso não é um problema técnico.

Se todos "cumprirem as regras", as alterações nos registros DNS poderão "entrar em vigor" muito rapidamente. No caso de alterar o endereço IP atribuído a um registro "A", por exemplo, seria realizado um backoff exponencial do valor TTL, levando ao momento em que a alteração será feita. O TTL pode começar em 1 dia, por exemplo, e ser reduzido para 12 horas por um período de 24 horas, depois 6 horas por um período de 12 horas, 3 horas por um período de 6 horas, etc., até um intervalo adequadamente pequeno. Após o backup do TTL, o registro pode ser alterado e o TTL retornado ao valor desejado para as operações do dia-a-dia. (Não é necessário usar um backoff exponencial, no entanto, essa estratégia minimiza o tempo em que o registro terá um TTL baixo e diminui a carga no servidor DNS autoritário.)

Depois de fazer um registro DNS, os logs de alteração devem ser monitorados quanto a tentativas de acesso, como resultado do registro DNS antigo. No exemplo de alteração de um registro "A" para se referir a um novo endereço IP, um servidor deve permanecer presente no endereço IP antigo para lidar com tentativas de acesso resultantes de computadores clientes que ainda usam o registro "A" antigo. Quando as tentativas de acesso baseadas no registro antigo atingirem um nível aceitável baixo, o endereço IP antigo poderá ser desativado. Se as solicitações relacionadas a um registro antigo não estiverem diminuindo rapidamente, é possível que (como descrito acima) um servidor DNS recursivo esteja ignorando o TTL autoritativo. Conhecer o endereço IP de origem de uma tentativa de acesso, no entanto, não fornece informações diretas sobre o servidor DNS recursivo responsável por fornecer um registro antigo.

Pessoalmente, vi mudanças "entrarem em vigor" imediatamente, em algumas horas e, em alguns casos, com um ISP danificado pelo cérebro, após vários dias. Fazer um backoff do seu TTL e estar ciente de como o processo funciona aumentará suas alterações para o sucesso, mas você nunca pode ter certeza do que algum idiota bem-intencionado pode estar fazendo com seus servidores DNS recursivos.