A adoção do DNSSEC é segurada pela custódia das chaves, não pela complexidade criptográfica.
O DNSSEC é um padrão há mais de uma década, mas a adoção continua desigual. A criptografia é bem compreendida; o modelo operacional é bem documentado. O que impede muitas organizações de habilitá-lo é a custódia: a chave de assinatura (KSK) e a chave de assinatura de zona (ZSK) são as raízes de confiança de toda a zona, e a maioria das empresas não quer essas chaves nas mãos de um fornecedor.
Provedores de DNS em nuvem oferecem sign-and-serve DNSSEC, mas as chaves vivem no KMS do provedor. O provedor pode revogar, rotacionar ou ser intimado — a integridade da sua zona fica condicionada à operação contínua do provedor. Algumas organizações aceitam esse compromisso; muitas em setores regulados (governo, defesa, financeiro) não podem.
A alternativa histórica é operar um pipeline de assinatura DNSSEC autogerenciado: BIND com gerenciamento customizado de chaves, scripts para rotacionar chaves em cronograma, integração externa com HSM, configuração de slaves para receber registros assinados. Isso funciona, mas a sobrecarga operacional é significativa e os modos de falha são silenciosos (RRSIG expirada, cadeia NSEC ausente).
O TR7 GTM traz o DNSSEC para a mesma superfície de operador que o resto do plano DNS autoritativo — opt-in por domínio, registros assinados como dados de primeira classe, transferência de zona que carrega a assinatura — sem depender de um serviço externo de assinatura.
Nossa abordagem
O DNSSEC é uma flag de funcionalidade por domínio combinada com suporte de primeira classe a todos os tipos de registro DNSSEC. O sign-and-serve acontece no nó TR7 GTM; a custódia da chave permanece com o operador.
Opt-in DNSSEC por domínio
Cada domínio DNS no TR7 GTM habilita ou desabilita DNSSEC independentemente por um campo booleano de schema. Implantações mistas — algumas zonas assinadas, outras não — coexistem na mesma frota sem forçar um compromisso para toda a frota.
Oito tipos de registro DNSSEC como dados de primeira classe
DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, RRSIG, CDS, CDNSKEY fazem parte da lista de tipos de registro suportados ao lado de A, AAAA, CNAME, MX e o restante. O schema os trata como dados, não como um subsistema separado.
Modos de edição SOA controlam o avanço do serial
O operador escolhe como o serial SOA incrementa: DEFAULT (formato YYYYMMDD01), INCREASE (+1 por alteração), EPOCH (timestamp UNIX) ou OFF (controle manual). O avanço do serial importa para os validadores DNSSEC e para os slaves downstream.
A transferência de zona carrega registros assinados intactos
O AXFR/IXFR transfere registros DNSSEC ao lado de outros tipos. Slaves em modo Express servem as respostas assinadas do master sem reassinar — único ponto de assinatura, múltiplos pontos de serving.
Capacidades
O DNSSEC no TR7 GTM cobre a superfície operacional — schema, transferência, serving, integridade — sem delegar a um signatário de terceiros.
Validar, não apenas assinar
Assinar prova as suas zonas ao mundo. Validar protege os seus próprios utilizadores: as respostas que voltam pelo resolver recursivo são verificadas contra a cadeia de confiança, por isso uma resposta forjada ou alterada quebra antes de entrar em cache — e uma subida súbita de veredictos bogus é um alarme, porque ou é um ataque ou é uma zona partida, e ambas precisam de ser conhecidas já.
Flag booleana DNSSEC por domínio
Cada domínio DNS carrega um campo booleano `dnssec`. Quando true, a zona é tratada como DNSSEC-ativa: DNSKEY e DS são esperados, registros RRSIG acompanham cada RRset no fio e registros NSEC/NSEC3 cobrem o espaço de nomes da zona.
Gerenciamento de registros DNSKEY
Os registros DNSKEY (as chaves públicas da zona) são gerenciados como registros regulares no schema. Os operadores importam ou definem o conteúdo do DNSKEY; a rotação é tratada adicionando novos DNSKEY antes da remoção dos antigos, seguindo padrões padrão de rollover pre-publish.
Suporte a registros DS para delegação da zona pai
Os registros DS (Delegation Signer) são gerenciados na zona pai. Quando as zonas pai e filha estão ambas hospedadas no TR7 GTM, os registros DS se propagam naturalmente; quando a pai está em outro lugar, os operadores exportam os DS para submissão upstream.
Negação autenticada de existência com NSEC e NSEC3
Os registros NSEC e NSEC3 provam que um nome consultado não existe. NSEC3 adiciona salt e iterações para impedir a enumeração da zona. Ambos são cidadãos de primeira classe no schema e servem como parte da zona.
Registros de assinatura RRSIG
Os registros RRSIG carregam as assinaturas criptográficas sobre os RRsets. O schema suporta RRSIG como tipo de registro; a transferência AXFR/IXFR carrega RRSIGs ao lado dos RRsets assinados.
CDS e CDNSKEY para atualizações automáticas da pai
Os registros CDS e CDNSKEY comunicam o estado DS pretendido da zona filha à zona pai — habilitando automação no lado da pai (RFC 7344). Útil para organizações que operam delegações entre múltiplos provedores de DNS.
Modos de edição SOA para controle de serial
Quatro modos selecionáveis pelo operador para avanço do serial SOA: DEFAULT (baseado em data YYYYMMDD01), INCREASE (+1 por alteração), EPOCH (timestamp UNIX), OFF (controle manual). Os valores de serial são críticos para DNSSEC porque zonas assinadas devem avançar o serial em cada alteração para invalidar assinaturas em cache.
IPs de servidores slave para replicação de zona assinada
Cada domínio pode listar IPs de servidores slave para os quais envia atualizações de zona assinada via NOTIFY. Os operadores rodam seus próprios slaves downstream (PowerDNS, BIND, NSD) e recebem cópias assinadas para serving distribuído.
Compatível com o modo Express para assinatura hidden-master
Os domínios em modo Express puxados de um master upstream herdam o estado DNSSEC do master. Se o master assina, o TR7 serve as respostas assinadas; se o master não assina, o TR7 serve sem assinatura. A decisão de assinatura pertence ao master.
35 tipos de registro DNS no total, incluindo 8 tipos DNSSEC
A lista completa de tipos de registro (A, AAAA, AFSDB, ALIAS, CAA, CERT, CDNSKEY, CDS, CNAME, DNSKEY, DNAME, DS, HINFO, KEY, LOC, MX, NAPTR, NS, NSEC, NSEC3, NSEC3PARAM, OPENPGPKEY, PTR, RP, RRSIG, SOA, SPF, SSHFP, SRV, TKEY, TSIG, TLSA, SMIMEA, TXT, URI) inclui oito tipos relacionados a DNSSEC como membros de primeira classe.
Profundidade operacional
O DNSSEC no TR7 GTM é operado em conjunto com a transferência de zona, rotação de chaves, delegação pai e expectativas de validador.
Granularidade de opt-in por domínio
O DNSSEC é habilitado por domínio. Os operadores fazem o rollout do DNSSEC zona por zona, validando cada uma antes de expandir. Estados mistos são suportados indefinidamente — algumas zonas assinadas, outras não, na mesma frota TR7.
Rotação de chave via gerenciamento de registro
O rollover de DNSKEY segue padrões padrão pre-publish / double-signature: adicionar a nova chave como registro DNSKEY, esperar caches refrescarem, alternar o signatário ativo, retirar a chave antiga. O schema trata cada chave como dado; o cronograma de rollover é controlado pelo operador.
Janelas de validade do RRSIG
Os registros RRSIG carregam intervalos de validade. Os operadores definem a cadência de refresh — normalmente as assinaturas são refrescadas antes da expiração para evitar falhas de validador durante problemas transitórios no pipeline de assinatura. A plataforma expõe expirações próximas para ação do operador.
Seleção entre NSEC e NSEC3
NSEC permite zone walking (um atacante pode enumerar todos os nomes); NSEC3 adiciona salt e iterações para prevenir o walking. Os operadores escolhem por zona — zonas voltadas ao público frequentemente usam NSEC3 para impedir enumeração; zonas fechadas podem usar NSEC para simplicidade.
Coordenação de delegação pai
A delegação de zone-cut exige que a pai publique um registro DS. Quando a zona pai é hospedada no TR7, os registros DS fazem parte do conjunto de registros da pai. Quando a pai está em outro lugar, os operadores exportam valores DS dos registros CDS e os submetem upstream.
Compatibilidade com servidores slave
Os servidores slave downstream recebem zonas assinadas via AXFR/IXFR e as servem. Os slaves não reassinam; eles confiam nas assinaturas do master. Isso suporta serving distribuído (múltiplos POPs slave, caches regionais) sem sobrecarga de reassinatura.
Quando usar
Integridade DNS para governo e defesa
Zonas do setor público que exigem integridade DNSSEC para compliance frequentemente precisam manter as chaves de assinatura dentro do perímetro de segurança. O DNSSEC on-prem do TR7 suporta esse requisito sem delegar a um provedor de nuvem.
Zonas assinadas do setor financeiro
Zonas bancárias e de processamento de pagamentos usam DNSSEC para prevenir ataques de spoofing DNS contra serviços voltados ao cliente. O opt-in por domínio permite que bancos façam o rollout do DNSSEC zona por zona, validando cada uma antes de um rollout mais amplo.
Arquiteturas hidden-master com serving assinado
O master assina a zona; os nós TR7 atuam como slaves Express e servem as respostas assinadas do master. A assinatura acontece uma vez; o serving acontece em escala sem sobrecarga de reassinatura por borda.
DNS multi-provedor com coordenação de pai baseada em CDS
Organizações que usam múltiplos provedores de DNS para redundância publicam registros CDS via TR7 para que a zona pai possa aprender automaticamente os valores DS atuais. A automação no lado da pai reduz a coordenação manual de rollover.
Perguntas frequentes
O TR7 gerencia chaves DNSSEC ou preciso trazer as minhas?
Posso usar DNSSEC em zonas no modo Express?
Como o modo de edição SOA afeta o DNSSEC?
E sobre o NSEC zone walking?
Como os servidores slave são tratados com DNSSEC?
O DNSSEC é compatível com as funcionalidades de GSLB e seleção de DC?
Assine suas zonas na sua própria infraestrutura.
Percorra o DNSSEC on-prem com o TR7 GTM: opt-in por domínio, todos os tipos de registro DNSSEC como dados de primeira classe e transferência de zona que carrega as assinaturas intactas.