--- id: "dns-propagation" kind: "glossary-term" title: "propagação de DNS" language: "pt-BR" category: "DNS e fundamentos técnicos" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/pt/glossario/propagacao-dns/" translations: en: "https://tldlog.com/glossary/dns-propagation/" es: "https://tldlog.com/es/glosario/propagacion-dns/" de: "https://tldlog.com/de/glossar/dns-propagation/" fr: "https://tldlog.com/fr/glossaire/propagation-dns/" it: "https://tldlog.com/it/glossario/propagazione-dns/" ru: "https://tldlog.com/ru/glossariy/rasprostranenie-dns/" zh-Hans: "https://tldlog.com/zh/cihui/dns-chuanbo/" --- # propagação de DNS O nome informal do atraso até que uma mudança no DNS seja vista por todos. Na verdade, nada se espalha pela internet: os resolvedores simplesmente mantêm as respostas antigas até que suas cópias guardadas expirem. A espera depende do TTL dos registros e, nas mudanças de servidores de nomes, das configurações do próprio TLD. Quando as configurações de DNS de um domínio mudam, por exemplo para mudar um site de lugar ou passar a usar novos servidores de nomes, nem todos os usuários veem a mudança ao mesmo tempo. Durante algum tempo, algumas pessoas chegam à configuração antiga e outras à nova. Essa espera é o que se costuma chamar de propagação de DNS. ## O que se entende por propagação de DNS “Propagação” é uma palavra informal. Ela sugere uma mudança que se espalha pela internet, mas nada é enviado a lugar nenhum. Os resolvedores, os servidores que consultam os nomes para os usuários, guardam cópias das respostas que já receberam e as reutilizam até que expirem. Só então perguntam de novo. A RFC 9499, o documento de terminologia do DNS do IETF, não tem nenhum verbete para “propagation”. O termo costuma abranger dois tipos de mudança: - Uma mudança em um registro da própria zona do domínio, como um novo registro A que aponta o nome para um novo servidor web. - Uma troca de servidores de nomes. Ela é feita no registrador, que a repassa ao registro; o registro então publica a nova delegação na zona do TLD. ## Por que as mudanças não são instantâneas: cache e TTL Os principais caches são os resolvedores recursivos operados por provedores de internet, empresas e serviços públicos. O resolvedor stub de um celular ou computador normalmente depende de um deles. Todo registro DNS tem um TTL: um número de segundos, definido por quem opera a zona, que diz por quanto tempo uma cópia pode ser guardada. Uma cópia em cache faz uma contagem regressiva e, ao chegar a zero, é descartada, e a consulta seguinte busca o registro de novo. Um TTL de 0 significa que o registro não pode ser guardado em cache. O TTL é um máximo, não uma garantia. Os resolvedores podem limitar TTLs muito longos (a RFC 8767 recomenda um limite de sete dias), e muitos guardam as respostas por pelo menos algumas dezenas de segundos mesmo quando o TTL é menor. Acima de tudo, ninguém consegue apagar uma cópia em cache no resolvedor de outra pessoa. Esse é o verdadeiro motivo da espera. ## Quanto tempo leva de fato, e como encurtar a espera antes de uma mudança Não existe um número único e universal: depende dos TTLs envolvidos. Na mudança de um registro, a resposta antiga pode sobreviver em um resolvedor por até o TTL antigo do registro, contado a partir da última vez que esse resolvedor o buscou. Com um TTL de 3.600, um resolvedor pode dar a resposta antiga por até uma hora depois da mudança. Na troca de servidores de nomes, três atrasos se somam: 1. O registrador envia a mudança ao registro. 2. O registro a publica na zona do TLD. Para os gTLDs sob o Contrato de Registro base da ICANN (versão de 21 de janeiro de 2024), o nível de serviço é de 60 minutos para pelo menos 95% das sondas de teste da ICANN, em outubro de 2026. Esse número não vale para gTLDs antigos como o .com, que têm contratos próprios, nem para os ccTLDs. 3. Os registros NS em cache expiram. A zona do TLD guarda sua própria cópia dos registros NS do domínio, com um TTL que o titular do domínio não pode alterar. A forma padrão de encurtar a espera, descrita na RFC 1034 em 1987, é baixar o TTL com antecedência, pelo menos um período completo do TTL antigo antes da mudança, fazer a mudança e depois subir o TTL de novo. Para zonas .es, a Red.es recomenda um TTL e um Minimum do SOA normais de 3.600 segundos, e valores temporários de até 900 segundos (15 minutos) antes de grandes mudanças (em outubro de 2026). Baixar os próprios TTLs não encurta a cópia dos registros NS mantida pelo TLD. ## Cache negativo: por que um nome novo pode continuar “inexistente” Os resolvedores também se lembram de que algo não existe. Se alguém consulta um nome antes de seus registros serem criados, o resolvedor pode guardar em cache uma resposta NXDOMAIN (o nome não existe) ou NODATA (o nome existe, mas não tem registro daquele tipo). Uma resposta negativa é guardada pelo menor de dois valores do registro SOA da zona: seu próprio TTL e seu campo Minimum. Com os valores normais da Red.es, de 3.600 e 3.600 (em outubro de 2026), isso significa até uma hora. A RFC 2308 sugere que, por padrão, os resolvedores limitem o cache negativo a um intervalo de uma a três horas. A lição prática: crie os registros antes de testar ou anunciar um nome novo. Um teste antecipado pode fazer o nome parecer inexistente durante todo o tempo do cache negativo. ## Como verificar se uma mudança está visível - Consulte diretamente os servidores autoritativos do domínio. Eles respondem a partir da zona, não de um cache. - Depois, consulte um ou mais resolvedores recursivos. Se eles ainda devolverem dados antigos, o TTL que mostram é o tempo que falta até perguntarem de novo. - Na troca de servidores de nomes, verifique se os servidores do TLD devolvem os novos registros NS. É esse o ponto que o tempo de atualização da ICANN mede. ## Planejar uma migração sem interrupção 1. Configure primeiro a nova hospedagem ou os novos servidores de nomes e verifique se os novos servidores já respondem de forma correta e autoritativa pelo domínio. A Red.es recomenda isso para o .es. 2. Baixe os TTLs com antecedência, como descrito acima. 3. Faça a mudança: edite os registros ou troque os servidores de nomes pelo registrador. No .es, as mudanças de delegação são solicitadas à Red.es pelo procedimento estabelecido. 4. Mantenha os servidores ou a hospedagem antigos funcionando com dados corretos por pelo menos o maior valor entre o TTL do TLD e o TTL do próprio domínio. 5. Verifique e depois suba os TTLs de novo. Um exemplo prático, com valores apenas ilustrativos: example.com tem um registro A com TTL de 86.400 segundos (um dia). Dois dias antes de mudar o site de lugar, o titular baixa o TTL para 900. Quando o TTL antigo de um dia já passou, o titular altera o registro A e, em cerca de 15 minutos, os resolvedores que respeitam o TTL recebem o novo endereço. ## Fontes - [Domain names - concepts and facilities (RFC 1034)](https://www.rfc-editor.org/rfc/rfc1034.txt) - [Negative Caching of DNS Queries (DNS NCACHE) (RFC 2308)](https://www.rfc-editor.org/rfc/rfc2308.txt) - [Considerations for Large Authoritative DNS Server Operators (RFC 9199)](https://www.rfc-editor.org/rfc/rfc9199.txt) - [Registry Agreement (ICANN base gTLD Registry Agreement, version of 21 January 2024), Specification 10](https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-21-01-2024-en.html) - [Guía informativa DNS, Versión 1.1 (dominios.es, Red.es)](https://www.dominios.es/sites/dominios/files/2026-02/dns-guia-informativa-y-requisitos-de-configuracion.pdf) ## termos relacionados - [cache de DNS](https://tldlog.com/pt/glossario/cache-dns/) - [TTL](https://tldlog.com/pt/glossario/ttl/) - [resolvedor](https://tldlog.com/pt/glossario/resolvedor/) - [registro NS](https://tldlog.com/pt/glossario/registro-ns/) - [cache negativo](https://tldlog.com/pt/glossario/cache-negativo/)