DNSSEC

DNSSEC resolve um problema específico: o DNS clássico não autentica criptograficamente a origem dos dados. Um operador assina cada RRset relevante com uma chave privada e publica a assinatura em registros RRSIG. A chave pública aparece em DNSKEY. A delegação para uma zona filha é ligada por um registro DS na zona pai, que contém um digest da chave da filha. O resolvedor começa em uma trust anchor, normalmente a chave da zona raiz, valida o DS, o DNSKEY e as assinaturas até chegar ao nome consultado. Essa cadeia é hierárquica. Uma zona `casa.example` só é validável se a zona pai publicar o DS correto e a filha mantiver chaves e assinaturas válidas. A ausência intencional de um nome também precisa ser autenticada; NSEC e NSEC3 fornecem prova de inexistência. NSEC enumera intervalos de nomes e pode facilitar zone walking. NSEC3 usa hashes e salt para reduzir a enumeração direta, embora não elimine todos os ataques de dicionário. O resultado de validação pode ser Secure, Insecure, Bogus ou Indeterminate, conforme implementação. Insecure não significa adulterado; significa que a cadeia não está assinada. Bogus indica falha de validação. Um resolvedor não deve transformar Bogus em resposta normal apenas para “fazer funcionar”. O administrador precisa diagnosticar horário, DS, chave, assinatura expirada ou algoritmo. A validação depende de relógio correto porque RRSIG tem início e expiração. NTP é requisito operacional.

A segurança depende menos do algoritmo isolado e mais da operação. Zonas tradicionalmente distinguem Key Signing Key, KSK, e Zone Signing Key, ZSK, embora modelos modernos possam usar uma única Combined Signing Key. A KSK assina o conjunto DNSKEY; a ZSK assina os demais RRsets. A separação reduz a frequência de interação com a zona pai, mas aumenta procedimentos. Rollover exige publicar a nova chave, aguardar propagação, assinar, atualizar DS quando necessário e retirar a antiga somente depois dos TTLs e janelas. A RFC 6781 descreve práticas operacionais. A automação do registrador e do provedor DNS reduz erro. Muitos serviços, como Cloudflare DNS, Amazon Route 53, Google Cloud DNS e provedores de registro, oferecem DNSSEC gerenciado. Mesmo assim, o proprietário deve confirmar que o DS está publicado no registrador. Assinar a zona sem DS deixa uma ilha sem cadeia. Publicar DS errado torna a zona Bogus para validadores e pode derrubar acesso a APIs, hubs e serviços. Chaves privadas precisam de proteção; HSM pode ser usado em provedores. O algoritmo deve seguir registros e recomendações atuais. RSA/SHA-256 e ECDSA são comuns; algoritmos obsoletos precisam de migração. A escolha considera suporte de resolvers e tamanho de resposta. Ed25519 possui suporte em DNSSEC por RFC específica, mas a interoperabilidade da base instalada deve ser verificada. A zona precisa resignar antes da expiração. Monitoramento verifica RRSIG, DS, DNSKEY, tempo restante e validação externa. Um certificado TLS válido não compensa DNSSEC quebrado; são camadas diferentes.

A proteção chega ao usuário quando algum componente valida. Um resolvedor recursivo como Unbound, BIND, Knot Resolver, PowerDNS Recursor, Quad9, Cloudflare 1.1.1.1 ou Google Public DNS pode validar. A resposta ao stub resolver traz o bit AD quando a validação foi feita e a cadeia é segura, mas confiar nesse bit exige um canal confiável até o resolvedor. Em uma LAN, o roteador pode oferecer um resolvedor local e encaminhar por DoT/DoH a um upstream validador. Se um atacante consegue alterar a resposta entre o resolvedor e o dispositivo, DNSSEC validado apenas no upstream não protege esse trecho. O próprio dispositivo pode validar, mas microcontroladores raramente fazem por custo e complexidade. Em casa inteligente, um gateway local validador é uma opção. Ele precisa de trust anchor atualizada, horário, memória para respostas maiores e suporte a TCP quando UDP excede. DNSSEC aumenta o tamanho por DNSKEY e RRSIG. EDNS(0) permite payload maior, mas fragmentação IP pode falhar. Resolvedores devem suportar fallback para TCP e mitigação de respostas grandes. Firewalls que bloqueiam TCP 53 indiscriminadamente causam falhas. DoT/DoH usam outros transportes, mas o upstream ainda precisa validar. Um teste com `dig +dnssec` mostra registros; o bit AD indica validação pelo resolvedor. `delv` valida localmente. Ferramentas como DNSViz analisam cadeia. Não desabilitar validação global por um domínio quebrado; corrigir o domínio ou aplicar exceção temporária documentada.

DNSSEC oferece autenticidade e integridade dos dados DNS; não oferece confidencialidade. Um observador ainda vê a consulta em UDP/TCP 53. DoT e DoH cifram o transporte até o resolvedor. O resolvedor continua conhecendo. QNAME minimization reduz exposição. DNSSEC também não garante que o servidor apontado seja seguro. Um registro A legítimo pode levar a um serviço vulnerável. TLS, autenticação e atualização continuam. O protocolo não impede bloqueio de respostas nem ataques de negação de serviço. Assinaturas aumentam tamanho e podem ser usadas em reflexão se servidores forem expostos sem controle. Rate limiting, BCP 38 e operação correta são necessários. Outra limitação é que uma zona não assinada é Insecure, não necessariamente rejeitada. DNSSEC não força adoção. Em redes corporativas, DNS split-horizon e zonas internas exigem desenho. Uma zona interna assinada pode usar trust anchor local; se o mesmo nome possui visão pública, conflitos precisam ser tratados. Dispositivos IoT que usam domínios do fabricante dependem da operação externa. Se o fabricante erra um rollover, o produto pode perder cloud para usuários com validação. O operador da casa não deve “resolver” mudando para um DNS não validador permanentemente. Deve confirmar incidente e cobrar. A consequência prática é que DNSSEC reduz envenenamento de cache e respostas forjadas, mas adiciona uma dependência operacional de chaves, relógio e cadeia. A implantação deve incluir monitoramento, não apenas marcar uma opção no registrador.