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.
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.
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.
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.
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.
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.
O DNSSEC no TR7 GTM cobre a superfície operacional — schema, transferência, serving, integridade — sem delegar a um signatário de terceiros.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.