Atualiza os registos DNS de um domínio, guarda a alteração e espera que o novo site ou serviço de correio funcione imediatamente. Mas um colega ainda vê o site antigo, um verificador online mostra um endereço diferente ou a entrega de correio eletrónico comporta-se de forma inconsistente. Este atraso é comumente chamado propagação de DNS.
A frase pode dar a impressão de que uma única atualização está a viajar através de um sistema central da Internet. No entanto, o DNS é distribuído. As informações de domínio são armazenadas e cacheadas em servidores de nomes autoritativos, resolvers recursivos, routers, sistemas operativos e aplicações. Cada sistema pode atualizar as suas informações em momentos diferentes.
A maioria das alterações DNS torna-se visível à medida que as caches expiram e os resolvedores recuperam registos atualizados. O tempo necessário para isso depende do Time to Live (TTL) anterior do registo, do comportamento dos resolvedores e se a configuração DNS autoritativa está correta. Não existe um período universal que garanta que todos os utilizadores vejam a nova resposta.
Este guia explica o que as pessoas querem dizer com propagação de DNS, por que é que as alterações ao DNS aparecem em momentos diferentes, como verificar as respostas atuais de um domínio e o que fazer quando uma atualização ainda parece incompleta.
O que significa a propagação do DNS?
A propagação do DNS é o termo comum para o período durante o qual diferentes utilizadores ou resolvers de DNS podem receber respostas diferentes após a alteração dos registos de DNS. Um utilizador numa rede pode já ver o novo endereço IP, enquanto o resolver de outro utilizador continua a devolver um endereço mais antigo em cache.
A alteração subjacente do DNS é efetuada nos servidores de nomes autoritativos para o domínio. Os resolvers recursivos, em seguida, recuperam e armazenam em cache os registos para os seus utilizadores. Esses resolvers não necessariamente consultam novamente os servidores autoritativos sempre que alguém visita o domínio. Podem reutilizar uma resposta armazenada em cache enquanto esta permanecer válida.
É por isso que a “propagação” é melhor compreendida como expiração e atualização do cache. Não existe uma cópia central que tenha de ser atualizada em todos os dispositivos ligados à Internet ao mesmo tempo. O registo autoritativo pode já estar correto, mesmo enquanto alguns resolvedores continuam a servir dados mais antigos em cache.
Como funciona o armazenamento em cache do DNS
Quando um navegador precisa encontrar o endereço IP de um domínio, solicita ao sistema operativo que resolva o nome. O sistema operativo pode ter uma resposta em cache. Se não tiver, pergunta a um resolvedor recursivo configurado, como aquele operado por um fornecedor de Internet, uma empresa ou um serviço DNS público.
O resolvedor recursivo também pode ter uma resposta em cache. Se essa resposta ainda estiver dentro do seu tempo de vida no cache, pode devolvê-la sem contactar os servidores de nomes autoritativos. Quando o registo em cache expira, o resolvedor pode consultar o sistema DNS autoritativo e armazenar a resposta atualizada.
O cache reduz o tempo de pesquisa e a carga na infraestrutura DNS. Isto significa também que as alterações aos registos não são necessariamente visíveis para todos os resolvedres ao mesmo tempo. A resposta antiga continua a ser utilizável por um resolvedor até que o seu cache expire ou que o resolvedor a atualize de outra forma.
Diferentes utilizadores podem utilizar diferentes resolutores recursivos. Mesmo pessoas na mesma casa podem ver respostas diferentes se os seus dispositivos utilizarem serviços DNS, VPNs, redes móveis ou caches locais distintos.
O que é TTL no DNS?
TTL significa Tempo de Vida Útil Tempo de Vida. É um valor, geralmente medido em segundos, que indica aos resolvedores recursivos durante quanto tempo podem armazenar em cache um registo DNS antes de verificar uma resposta atualizada.
Por exemplo, um TTL de 3600 significa uma hora. Se um resolvedor recuperar um registo com esse TTL, pode geralmente continuar a usar a resposta durante até uma hora antes de precisar de a atualizar. Um TTL de 300 significa cinco minutos.
O TTL que importa após uma alteração é geralmente o TTL do registo antigo que os resolvers já tinham em cache. Reduzir o TTL imediatamente antes de alterar um registo pode não encurtar o tempo de espera para os resolvers que armazenaram em cache o TTL anterior, mais elevado. Esses resolvers podem continuar a utilizar a resposta antiga até expirar o período original de cache.
Para migrações planeadas, os administradores frequentemente reduzem o TTL antecipadamente, aguardam tempo suficiente para que o TTL anterior expire e, em seguida, efetuam a alteração no DNS. Após a estabilidade da alteração, podem aumentar novamente o TTL para reduzir as consultas repetidas. Os valores adequados dependem do serviço e do processo de alteração do operador.
Por que as alterações de DNS levam tempos diferentes?
A razão mais comum é que os resolvedores têm cópias em cache diferentes. Alguns podem já ter atualizado o registo, enquanto outros ainda estão a utilizar uma resposta não expirada. Um resolvedor também pode aplicar o seu próprio comportamento de atualização ou armazenar em cache respostas negativas, que são respostas que indicam que um registo não existe.
O cache local pode adicionar outra camada. Um computador, um router, um navegador ou uma aplicação de segurança podem reter temporariamente as informações DNS. Reiniciar um navegador ou limpar o cache DNS do sistema operativo pode ajudar em alguns casos, mas não alterará o que um resolvedor recursivo ainda tem em cache.
As alterações do fornecedor de DNS podem introduzir fatores adicionais de tempo. Se alterar os servidores de nomes autoritativos do domínio no registrador, os resolvedores podem precisar atualizar as informações de delegação, bem como os registros servidos por esses servidores de nomes. Esta é uma alteração diferente da edição de um registo A ou AAAA dentro do mesmo serviço de alojamento DNS.
Finalmente, uma atualização pode não estar correta na fonte autoritativa. Se o registo errado foi editado, a alteração não foi guardada, o domínio utiliza servidores de nomes autoritativos diferentes ou o registo contém um erro de sintaxe, esperar não resolverá a configuração subjacente.
Propagação de DNS vs Atualizações de DNS Autoritativo
Um servidor DNS autoritativo fornece os registos oficiais para um domínio ou zona. Quando edita um registo no painel de controlo do seu fornecedor de DNS, o fornecedor deve atualizar os dados autoritativos que serve.
Um resolvedor recursivo fornece respostas DNS aos dispositivos cliente. Pode ter dados em cache anteriores à alteração. Portanto, o servidor autoritativo pode devolver o novo endereço enquanto um resolvedor recursivo continua a devolver um mais antigo.
Esta distinção é útil na resolução de problemas. Comece por verificar o que os servidores de nomes autoritativos devolvem. Se já tiverem o registo esperado, a alteração foi publicada na origem e as diferenças remanescentes devem-se provavelmente à cache ou ao comportamento do resolvedor. Se os servidores autoritativos ainda devolverem o valor antigo ou nenhum valor, investigue a configuração do fornecedor de DNS e os próprios registos.
A alteração dos servidores de nomes adiciona outra camada. A zona DNS pai deve apontar para os servidores de nomes autoritativos pretendidos, e esses servidores devem servir a zona correta. Um registo correto num fornecedor de DNS não é útil se o domínio estiver delegado nos servidores de nomes de um fornecedor diferente.
Alterações comuns de DNS e os seus efeitos
Alterando um Um recorde changes the IPv4 address returned for a hostname. Changing an Registo AAAA altera o seu endereço IPv6. Se ambos estiverem presentes, os clientes podem utilizar qualquer uma das famílias de endereços, dependendo da sua rede e comportamento de ligação.
Alterar um Registo CNAME altera o nome de host para o qual um alias aponta. Os resolvers podem então precisar de procurar o nome do destino e o seu endereço. Uma alteração nos registos do destino pode afetar o resultado final, mesmo que o CNAME permaneça inalterado.
Alterando um Registo MX afeta quais servidores de correio recebem e-mails para um domínio. Os sistemas de correio podem armazenar em cache estes registos, e o roteamento de e-mails pode demorar a refletir as atualizações. Ao alterar os fornecedores de correio, os administradores devem verificar os registos MX e quaisquer registos relacionados de autenticação de correio, como SPF, DKIM ou DMARC, separadamente.
A mudar nameservers alterações que tornam um fornecedor de DNS o responsável pelo domínio. Isto requer uma delegação correta no registo e uma configuração adequada da zona no novo fornecedor. Uma migração de servidores de nomes deve ser planeada cuidadosamente, pois a ausência de registos no novo fornecedor pode tornar os sites, correio eletrónico ou outros serviços indisponíveis.
Como verificar se uma alteração no DNS foi aplicada
Comece por consultar o domínio a partir do computador que está a utilizar. No Windows, macOS e Linux, nslookup é comumente disponível:
nslookup example.comPara verificar um registo de endereço IPv4, utilize:
nslookup -type=A example.comPara IPv6:
nslookup -type=AAAA example.comPara registos de servidor de correio:
nslookup -type=MX example.comNo macOS e no Linux, dig fornece uma saída mais detalhada:
dig example.com AMostrar apenas a secção de respostas:
dig example.com A +noall +answerPode consultar um resolvedor recursivo específico para comparar respostas. Por exemplo:
dig @1.1.1.1 example.com ANo Windows, pode especificar um servidor DNS com:
nslookup example.com 1.1.1.1Substituir example.com com o seu domínio. O endereço do resolvedor nestes exemplos é apenas um possível resolvedor público; também pode consultar o serviço DNS utilizado pela sua organização ou fornecedor.
Registe o resolvedor que consultou, a resposta e o tempo. Comparar os resultados de vários resolvedores ajuda a determinar se a diferença é local a um resolvedor ou se aparece mais amplamente.
Como consultar um servidor de nomes autoritativo
Para encontrar os servidores de nomes autoritativos de um domínio, utilize:
dig example.com NSEm seguida, consulte um desses servidores de nomes diretamente para obter o registo que alterou:
dig @ns1.example-dns.com example.com ASubstituir ns1.example-dns.com com um servidor autoritativo listado para o seu domínio. Se a consulta direta retornar o endereço esperado, mas um resolvedor recursivo retornar o antigo, os dados autoritativos foram atualizados e o resolvedor pode ainda estar a utilizar uma resposta em cache.
Também pode perguntar dig para rastrear o processo de delegação:
dig +trace example.comIsto segue a hierarquia DNS desde a raiz até aos servidores autoritativos do domínio. Pode ajudar a identificar problemas de delegação, embora a sua saída seja mais detalhada do que a maioria das verificações básicas requerem.
Se estiver a utilizar o painel de controlo de um fornecedor de DNS, confirme que o domínio está realmente delegado nos servidores de nomes indicados. Um registo pode estar correto no painel de um fornecedor, enquanto o domínio público aponta para outro fornecedor.
E se alguns utilizadores virem o site antigo?
Primeiro, confirme que o registo A ou AAAA autoritativo tem o valor pretendido. Em seguida, consulte vários resolvers recursivos e verifique se devolvem a mesma resposta. Se os dados autoritativos estiverem corretos, mas alguns resolvers devolverem um endereço mais antigo, o cache é uma explicação provável.
De seguida, verifique a configuração local do utilizador. Uma VPN, um resolvedor DNS da empresa, um produto de segurança, o cache do navegador ou o ficheiro hosts local podem afetar o endereço que é devolvido. Compare o resultado obtido numa outra rede, como uma ligação móvel, para verificar se o comportamento muda.
Considere também se os servidores antigos e novos respondem. Uma migração pode parecer inconsistente se o servidor antigo ainda servir uma cópia em cache ou redirecionar de forma diferente. O registo DNS pode estar correto enquanto o servidor antigo permanecer acessível para utilizadores cujos resolvedores não foram atualizados.
Se o problema afetar apenas IPv4 ou apenas IPv6, compare os registos A e AAAA separadamente. Um dispositivo pode ligar-se através de IPv6 enquanto outro utiliza IPv4. Uma família de endereços pode apontar para o novo servidor enquanto a outra ainda aponta para o antigo.
E se um site ficar indisponível após uma alteração de DNS?
Verifique se os servidores de nomes autoritativos do domínio estão corretos e acessíveis. Em seguida, confirme que os registos relevantes existem nesses servidores. Se tiver alterado recentemente os servidores de nomes, certifique-se de que o novo fornecedor de DNS tem todos os registos necessários, incluindo os de website, correio eletrónico, verificação e serviços.
Confirme que o servidor de destino está pronto para aceitar ligações para o domínio. A atualização do DNS apenas altera para onde os clientes são direcionados. Não configura o servidor web, instala um certificado, abre uma porta no firewall ou copia ficheiros do site.
Se o DNS retornar o endereço IP esperado, mas o site ainda falhar, teste o servidor e a aplicação separadamente. O problema pode estar no servidor web, firewall, certificado TLS, configuração de alojamento ou na aplicação. Uma pesquisa DNS confirma a resolução de nomes; não confirma que o serviço está saudável.
Para uma verificação geral do caminho entre o seu dispositivo e um destino, consulte o nosso guia para usando o traceroute para diagnosticar problemas de conexão de redeO Traceroute e as consultas DNS testam diferentes partes da ligação, pelo que são úteis em conjunto ao tentar identificar um problema.
Cacheamento negativo e resultados de “Registro não encontrado”
Os resolvers podem armazenar em cache o facto de um registo não existir. Isto é chamado de cache negativo. Se um resolver tiver consultado um nome antes do registo ser criado, pode continuar temporariamente a devolver uma resposta “não encontrado” mesmo depois do registo ter sido adicionado.
O cache negativo também possui um TTL, baseado nas informações do registro SOA da zona e nas regras do resolver. O comportamento exato pode variar. Se um subdomínio recém-criado não for resolvido imediatamente, verifique primeiro o servidor de nomes autoritativo. Se ele retornar o novo registro, aguarde a expiração dos caches negativos e compare com outros resolvers.
Uma resposta "registo não encontrado" também pode indicar que o registo foi adicionado à zona errada, o nome de host foi introduzido incorretamente ou o domínio utiliza servidores de nomes autoritativos diferentes. Confirme o nome de host completo, o tipo de registo e o fornecedor de DNS antes de assumir que o problema é apenas um atraso na propagação.
Como Planejar uma Migração de DNS
Antes de alterar os registos para um serviço de produção, liste todos os nomes de host e os registos dos quais o serviço depende. Um site pode utilizar registos A e AAAA, enquanto o correio eletrónico depende de registos MX, SPF, DKIM e DMARC. As aplicações também podem depender de registos de verificação ou de descoberta de serviços.
Se a alteração for planeada, reduza o TTL relevante antecipadamente e aguarde pelo menos o período do TTL anterior antes de alterar o destino. Prepare o novo servidor ou fornecedor antes de atualizar o DNS. Teste diretamente, sempre que possível, e confirme que os certificados, as regras de firewall, as definições da aplicação e os serviços de correio estão prontos.
Após a alteração, verifique as respostas autoritativas e vários resolvers recursivos. Monitore a disponibilidade do site, a entrega de e-mails e os erros da aplicação. Mantenha o serviço antigo disponível durante a transição, quando possível, porque alguns utilizadores podem continuar a aceder-lhe enquanto expiram as respostas em cache.
Assim que a nova configuração estiver estável, restaure um TTL adequado. Manter um TTL muito baixo de forma indefinida pode aumentar o volume de consultas DNS sem proporcionar benefícios significativos para um serviço que raramente é alterado.
Mal-entendidos Comuns sobre a Propagação de DNS
Um equívoco comum é acreditar que cada alteração no DNS demora exatamente 24 ou 48 horas. Não existe uma duração universal fixa. O atraso efetivo depende dos valores anteriores de TTL, do cache dos resolvedores, das alterações de delegação e da correção da configuração autoritativa.
Outro mal-entendido é que limpar o cache do navegador atualiza o DNS em todos os lugares. Pode limpar as informações armazenadas nesse dispositivo, mas não pode limpar o cache de um resolvedor recursivo remoto. Da mesma forma, reiniciar um roteador pode limpar seu cache local, mas não altera os registros autoritativos.
Um terceiro mal-entendido é a ideia de que um verificador de DNS que mostra respostas diferentes prova que o domínio está avariado. Respostas diferentes podem ocorrer durante uma migração planeada, especialmente quando os resolvers têm dados em cache em momentos diferentes. A questão importante é se os registos autoritativos estão corretos e se as diferenças restantes são consistentes com o TTL anterior.
Finalmente, a propagação do DNS não configura o serviço de destino. Um endereço IP correto ainda pode resultar num website indisponível se o servidor, firewall, certificado TLS ou aplicação não estiverem prontos.
Perguntas Frequentes Sobre a Propagação do DNS
Quanto tempo demora a propagação do DNS?
Não existe uma duração garantida única. Algumas alterações aparecem rapidamente, enquanto outras permanecem inconsistentes até que os registos em cache expirem. O TTL anterior, o comportamento do resolver e se os servidores de nomes mudaram afetam todos o tempo de propagação.
A redução do TTL torna a alteração instantânea?
Não. Reduzir um TTL afeta o cache futuro após os resolvers obterem o novo TTL. Os resolvers que já tinham em cache o registo antigo podem continuar a utilizá-lo até que o seu TTL anterior expire.
Por que é que os verificadores de DNS mostram resultados diferentes?
Podem consultar diferentes resolvers recursivos a partir de localizações distintas. Esses resolvers podem ter respostas em cache diferentes, atualizar-se em momentos diferentes ou receber respostas diferentes devido a políticas de DNS geográficas.
Devo limpar o cache DNS do meu computador?
Pode ajudar quando o seu próprio dispositivo tem armazenada em cache uma resposta antiga. Não limpa os caches mantidos pelo seu fornecedor de Internet, pelo resolvedor da empresa ou por um serviço DNS público.
Porque é que o meu website resolve mas ainda assim falha ao carregar?
O DNS pode estar a devolver o endereço correto, enquanto o servidor ou aplicação de destino apresenta um problema. Verifique o servidor web, a firewall, o certificado TLS e a configuração de alojamento separadamente.
As alterações de nameserver podem demorar mais do que as alterações de registos?
Podem envolver informações de delegação adicionais no registo e na zona DNS pai. O novo fornecedor também deve servir uma zona completa e correta. Verifique tanto a delegação como os registos nos servidores autoritativos novos.
As alterações de DNS podem aparecer em momentos diferentes porque os servidores de nomes autoritativos e os resolvers recursivos têm papéis distintos, e os resolvers armazenam em cache as respostas de acordo com os valores de TTL. Um utilizador pode ver um endereço antigo enquanto outro já recebe o novo.
Para investigar, verifique primeiro os servidores de nomes autoritativos e, em seguida, compare as respostas de vários resolvers recursivos. Confirme o tipo de registo, o nome do anfitrião, o TTL e a delegação dos servidores de nomes. Se o DNS retornar o endereço esperado, mas o serviço continuar indisponível, verifique o servidor de destino e a aplicação como partes separadas do problema.
Compreender o cache facilita o planeamento e a resolução de problemas das alterações ao DNS. Para mais fundamentos de redes, continue com os nossos guias para Endereços IP, portas de entrada padrão, e traceroute.