--- id: "dnssec" kind: "glossary-term" title: "DNSSEC" language: "pt-BR" category: "DNS e fundamentos técnicos" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/pt/glossario/dnssec/" translations: en: "https://tldlog.com/glossary/dnssec/" es: "https://tldlog.com/es/glosario/dnssec/" de: "https://tldlog.com/de/glossar/dnssec/" fr: "https://tldlog.com/fr/glossaire/dnssec/" it: "https://tldlog.com/it/glossario/dnssec/" ru: "https://tldlog.com/ru/glossariy/dnssec/" zh-Hans: "https://tldlog.com/zh/cihui/dnssec/" --- # DNSSEC extensões de segurança do DNS Extensões do DNS que acrescentam assinaturas digitais às respostas DNS. As assinaturas permitem que um resolvedor (o servidor que busca os nomes para os usuários) verifique se uma resposta é autêntica e não foi alterada no caminho. Os titulares o ativam pelo provedor de DNS e pelo registrador. O DNSSEC acrescenta assinaturas digitais às respostas do sistema de nomes de domínio (DNS), para que um computador possa verificar se uma resposta vem do titular de um domínio e não foi alterada no caminho. Ele não oculta nada e não impede todos os ataques. Ativá-lo exige que o provedor de DNS, o registrador e o registro trabalhem juntos. ## Contra o que o DNSSEC protege, em palavras simples Quando alguém visita example.com, um resolvedor consulta o endereço do site. Sem DNSSEC, um atacante que entregue ao resolvedor uma resposta falsificada pode mandar os visitantes para o servidor errado. Com DNSSEC, um resolvedor que valida verifica a assinatura e rejeita a falsificação. A RFC 4033 (março de 2005) define o que o DNSSEC oferece: prova de origem e de integridade dos dados do DNS. Ele não oferece confidencialidade, por isso as respostas continuam legíveis, nem proteção contra ataques de negação de serviço. Cobre apenas as respostas do DNS, não o phishing nem a tomada de uma conta no registrador. A RFC 9364 (fevereiro de 2023) chama o DNSSEC de melhor prática atual para autenticar dados do DNS; usá-lo ou não em um domínio é uma decisão do titular. ## Como funciona a cadeia de confiança, da raiz até o seu domínio Um resolvedor que valida parte de uma chave em que já confia: a âncora de confiança, que é a Key Signing Key da zona raiz, publicada pela IANA. A partir dela, segue uma cadeia: 1. A zona raiz contém um registro DS assinado para o .com. 2. Esse registro DS corresponde a uma chave da zona .com, o que permite ao resolvedor verificar os registros do .com, incluindo o registro DS de example.com. 3. Esse registro DS corresponde à chave de example.com, que verifica os registros do próprio domínio. Uma zona assinada cuja zona pai não tem registro DS é uma “ilha de segurança”: não pode ser validada a partir da raiz. Uma resposta é segura quando todas as assinaturas conferem, insegura quando uma prova assinada mostra que a zona pai não tem registro DS para a zona, e inválida (bogus) quando as assinaturas esperadas estão ausentes, expiradas ou inutilizáveis (RFC 4033). Para uma resposta inválida, o resolvedor normalmente retorna um erro, SERVFAIL (RFC 4035). ## Chaves e registros: KSK, ZSK, DNSKEY, DS e RRSIG - Os registros **DNSKEY** publicam as chaves públicas de uma zona. - Os registros **RRSIG** contêm as assinaturas, cada uma válida apenas entre uma data de início e uma data de expiração. - Os registros **DS** ficam na zona pai e contêm um key tag, um número de algoritmo e um resumo (digest) da chave da zona filha. - A **KSK** assina apenas o conjunto de chaves da zona, e o registro DS da zona pai aponta para ela. A **ZSK** assina todo o resto. A RFC 6781 (dezembro de 2012) observa que os validadores tratam os dois tipos de chave da mesma forma: a divisão é operacional, e algumas zonas usam uma única chave para as duas funções. Provar que um nome não existe exige registros próprios. O NSEC indica o próximo nome existente, o que permite a qualquer pessoa listar a zona inteira (“zone walking”). O NSEC3 (RFC 5155) aplica antes uma função de hash aos nomes, embora ainda revele detalhes como o tamanho da zona. ## Como ativar o DNSSEC: o papel do registrador, do registro e do provedor de DNS 1. O provedor de DNS assina a zona e publica os registros DNSKEY e RRSIG. 2. Os dados do DS, ou os dados da chave, vão para o registrador. 3. O registrador os envia ao registro pelo EPP com a extensão secDNS (RFC 5910, maio de 2010), seja como dados de DS, seja como dados de chave a partir dos quais o operador de registro monta o registro DS. 4. O operador de registro publica o registro DS na zona do TLD. Quando o registrador também é o provedor de DNS, os passos 1 a 3 costumam ser uma única configuração. Nos gTLDs, o Contrato de Credenciamento de Registradores de 2013 exige que os registradores repassem pedidos para acrescentar, remover ou alterar material de chaves aos registros que aceitam DNSSEC, usando a RFC 5910. O Contrato de Registro base (aprovado em 21 de janeiro de 2024 e em vigor em outubro de 2026) exige que os registros de gTLD assinem suas zonas e aceitem material de chaves dos domínios abaixo deles. As regras dos ccTLDs são diferentes: consulte o registrador ou o registro. Há também um caminho automatizado: o provedor de DNS publica registros CDS e CDNSKEY que indicam como deve ser o registro DS, e alguns registros e registradores fazem buscas periódicas por eles. A RFC 8078 (março de 2017) acrescentou um sinal para desativar o DNSSEC; a RFC 9615 (julho de 2024) permite que a zona pai verifique esses registros criptograficamente antes de ativar o DNSSEC. ## O que pode dar errado: assinaturas expiradas, trocas de chave e mudança de provedor de DNS - **Assinaturas expiradas.** Registros RRSIG não renovados a tempo tornam as respostas inválidas. - **Um registro DS sem chave correspondente.** A RFC 6781 chama isso de “security lameness”: o domínio falha para todos os resolvedores que validam, e a correção leva tempo para se espalhar. Por isso, uma troca de KSK exige que o novo registro DS esteja na zona pai antes de a chave antiga ser removida. - **Mudança de provedor de DNS.** O operador antigo controla as chaves. O melhor método é uma troca de chaves coordenada. Se o operador antigo não colaborar, o registro DS é removido, os servidores de nomes são trocados e, depois que essa mudança se espalhar, o novo registro DS é acrescentado. Nesse intervalo o domínio fica sem assinatura, o que a RFC 8078 prefere a falhas de validação. TTLs curtos ajudam. As falhas aparecem como SERVFAIL para os usuários de resolvedores que validam, enquanto o domínio pode continuar funcionando para todos os demais. Na raiz, em 9 de outubro de 2026, a ICANN prevê substituir a KSK da raiz em 11 de outubro de 2026: a KSK-2024 (key tag 38696) assume o lugar da KSK-2017 (key tag 20326), que deve ser revogada em 11 de janeiro de 2027 e removida em 22 de março de 2027. Isso diz respeito aos operadores de resolvedores que validam, que precisam da nova âncora de confiança, não aos titulares de domínios. ## DNSSEC e DNS criptografado: como se diferenciam O DNSSEC assina os dados para que qualquer resolvedor possa verificá-los, mas tudo continua legível. O DNS sobre TLS (DoT) e o DNS sobre HTTPS (DoH) criptografam a ligação entre o dispositivo do usuário e o resolvedor, o que protege a privacidade, mas não provam que os dados vieram do titular da zona. Os dois se complementam. ## Fontes - [RFC 4033: DNS Security Introduction and Requirements](https://www.rfc-editor.org/rfc/rfc4033.txt) - [RFC 6781: DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781.txt) - [RFC 5910: Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)](https://www.rfc-editor.org/rfc/rfc5910.txt) - [DNSSEC Trust Anchors and Rollovers](https://www.iana.org/dnssec/files) - [ICANN Announces Next Major Internet Security Update](https://www.icann.org/resources/press-material/release-2026-05-20-en) ## termos relacionados - [registro DS](https://tldlog.com/pt/glossario/registro-ds/) - [registro DNSKEY](https://tldlog.com/pt/glossario/registro-dnskey/) - [resolvedor](https://tldlog.com/pt/glossario/resolvedor/) - [DNS](https://tldlog.com/pt/glossario/dns/)