Unbound e a troca da KSK raiz: como verificar se a chave 38696 já é confiável

Tutorial completo de auditoria DNSSEC no Unbound: chave 38696, âncora confiável, Root Key Sentinel e bancada isolada, com 24 blocos de comandos e limites dos testes.

Por Lucas Vinicius Santos | LVNetwork

A IANA mantém 11 de outubro de 2026 como data prevista para a troca da chave de assinatura da raiz do DNS. Para quem opera resolvedores validadores, o trabalho agora é verificar se a KSK-2024, tag 38696, já faz parte da confiança do serviço. Uma resolução bem-sucedida hoje pode continuar dependendo da KSK anterior, tag 20326. [1]

Este roteiro reúne três evidências: a chave publicada no DNS, a âncora efetivamente confiável no Unbound e o comportamento da validação. A primeira parte usa inspeções e consultas de baixo volume, sem alteração administrativa. O apêndice reserva a criação de arquivos e processos para uma bancada isolada.

Referência temporal: documentação consultada em 6/10/2026. A versão upstream atual verificada é o Unbound 1.26.1, publicada em 16/9/2026. Versões empacotadas podem receber correções por backport; o número upstream sozinho não decide a situação de um pacote. [3]

Sobre as saídas: os trechos identificados como “resultado esperado” explicam o que procurar. Eles não representam medições de um cliente. A execução completa contra a Internet pública depende de acesso DNS de saída; uma rede que bloqueia esse tráfego não permite demonstrar AD, descoberta natural de ADDPEND ou o par sentinel. O registro de verificação ao fim do artigo separa o que foi executado das expectativas documentais.

Três camadas de evidência. Diagrama conceitual.

1. Identifique exatamente o servidor que será auditado

Tenha acesso autorizado à instância, ao arquivo de configuração e à âncora pública; não é necessário expor chaves privadas de controle. Os comandos pressupõem Linux, shell Bash, dig e utilitários do Unbound já disponíveis. Na auditoria, não instale pacotes nem habilite controle remoto para completar o roteiro.

Nos terminais, $ normalmente indica usuário comum e #, root. Os blocos abaixo não incluem esses caracteres de prompt. Execute como usuário comum; quando uma leitura exigir mais privilégios, use apenas o acesso administrativo já autorizado.

command -v dig unbound unbound-checkconf unbound-control
unbound -V
dig -v
date -u

Esperado: caminhos dos executáveis, versões e horário UTC coerente. Interpretação: estabelece a referência da coleta. Limite: unbound -V descreve o binário invocado; em sistemas com várias instalações, confirme que corresponde ao daemon. [18]

Em Linux com systemd, descubra como o serviço é iniciado:

systemctl show -p ExecStart unbound
ps -eo pid,args | grep '[u]nbound'

Procure a opção -c e confirme a unidade correta. Appliances, contêineres e unidades com outro nome exigem a interface do fornecedor. Não suponha que /etc/unbound/unbound.conf seja universal.

Defina os parâmetros depois dessa conferência. O endereço abaixo é apenas o exemplo de uma instância local na porta padrão:

RESOLVER='127.0.0.1'
PORT='53'
CONF='/CAMINHO/CONFIRMADO/unbound.conf'

Substitua CONF. Se o serviço estiver em outro endereço ou porta, ajuste esses valores. Em anycast ou atrás de um VIP, teste os backends e pontos de observação relevantes. Uma consulta a um DNS público diferente examina outro serviço.

2. Confirme a configuração de validação e localize a âncora

unbound-checkconf "$CONF"

Esperado: configuração aceita, código de saída 0. Interpretação: o arquivo passou na verificação. Limite: isso não prova que o processo atual o carregou.

unbound-checkconf -o module-config "$CONF"
unbound-checkconf -f -o auto-trust-anchor-file "$CONF"

Esperado: o módulo validator e o caminho da âncora gerenciada. A opção -f considera o chroot ao mostrar o caminho. Interpretação: identifica onde o estado RFC 5011 é persistido. Limite: pode haver várias âncoras; selecione a referente à raiz. Se a segunda consulta estiver vazia, examine trust-anchor-file, trusted-keys-file e trust-anchor antes de concluir que não existe âncora. [4]

O acompanhamento automático por RFC 5011 usa auto-trust-anchor-file. Uma âncora estática depende de outro procedimento de atualização. Confira também val-permissive-mode, domain-insecure e ignore-cd-flag: essas opções podem mudar o significado dos testes. [5]

Quando unbound-control já estiver operacional:

unbound-control -c "$CONF" status
unbound-control -c "$CONF" list_forwards
unbound-control -c "$CONF" list_insecure

Esperado: identificação da instância, encaminhamentos e exceções atuais. Interpretação: ajuda a distinguir recursão própria, forwarding e zonas sem validação. Limite: uma falha de acesso ao controle não demonstra falha de DNSSEC. Não crie certificados nem mude permissões para contorná-la. Para contadores, prefira stats_noreset; stats pode zerá-los. [10]

3. Verifique a confiança no arquivo e no processo

Defina ANCHOR com o caminho confirmado, considerando o sistema de arquivos da instância:

ANCHOR='/CAMINHO/CONFIRMADO/root.key'
grep 'id = 38696' "$ANCHOR"

Esperado: a linha da chave 38696 acompanhada de state=2 [ VALID ] em um arquivo gerenciado já inicializado. Interpretação: a chave está em estado confiável nesse arquivo. Limite: ADDPEND significa inclusão pendente; ausência da linha requer examinar o arquivo completo. Um bootstrap ainda em formato DS pode não possuir esses comentários. A tag é um identificador operacional, não substitui autenticar a origem da chave. [6]

Corrobore com o processo que está respondendo:

dig @"$RESOLVER" -p "$PORT" trustanchor.unbound. CH TXT \
  +noall +comments +answer

Esperado: a entrada da raiz inclui 38696 entre as tags; por exemplo, uma lista com 20326 e 38696. Interpretação: consulta as âncoras carregadas pelo Unbound. Limite: hide-trustanchor: yes pode produzir REFUSED; isso não significa chave ausente. Não altere a proteção só para obter a resposta. [5][16]

Por que ADDPEND merece atenção? O RFC 5011 estabelece um período de inclusão de pelo menos 30 dias, associado a observações autenticadas. Descobrir a chave em outubro não completa esse período antes de 11/10. A publicação ocorreu em 11/1/2025, mas o que importa para uma instância nova ou que ficou offline é seu próprio estado. Um bootstrap autenticado por outro mecanismo é diferente de aguardar a transição automática. [1][2]

4. Observe a publicação e teste a validação

dig @"$RESOLVER" -p "$PORT" . DNSKEY \
  +dnssec +nocdflag +multiline

Esperado: DNSKEYs da raiz, incluindo a chave 38696 no período atual, e assinaturas. Interpretação: mostra o material publicado disponível por esse caminho. Limite: uma chave na resposta DNSKEY ainda pode estar em ADDPEND no validador.

Controle positivo:

dig @"$RESOLVER" -p "$PORT" . SOA +dnssec +nocdflag

Esperado: NOERROR e a flag ad. Interpretação: o resolvedor declara aquela resposta autenticada. Limite: a resposta pode estar em cache e, antes da troca, a confiança pode depender da KSK anterior. A ausência de AD pede investigação do caminho e das políticas; não é motivo para desabilitar validação.

Controle negativo, com o domínio público de teste documentado pela ICANN:

dig @"$RESOLVER" -p "$PORT" dnssec-failed.org. A \
  +dnssec +nocdflag

Esperado: SERVFAIL. Interpretação: o validador rejeita uma resposta deliberadamente inválida. Limite: rede, políticas e falhas autoritativas também podem causar SERVFAIL. Compare com:

dig @"$RESOLVER" -p "$PORT" dnssec-failed.org. A \
  +dnssec +cdflag

Esperado: resposta ao dispensar a verificação, se CD for respeitado e o domínio estiver acessível. Interpretação: o contraste ajuda a atribuir a recusa à validação. Limite: esse retorno não aprova a segurança da resposta nem autoriza uma exceção permanente. [6]

As flags têm funções distintas: +dnssec liga DO e solicita registros DNSSEC; ad é uma declaração do resolvedor; +cdflag pede que aquela consulta não seja bloqueada por validação. O dig não vira um validador local ao receber +dnssec. Prefira consultar a instância localmente ou por um caminho confiável; AD sozinho não autentica o transporte entre cliente e resolvedor. [7]

5. Teste especificamente a confiança na chave 38696

O Root Key Sentinel permite observar essa confiança por consultas especiais. A Cloudflare documentou nomes assinados para a tag 38696 em 24/9/2026. Os comandos abaixo consultam o seu resolvedor, não necessariamente o serviço da Cloudflare. [8]

dig @"$RESOLVER" -p "$PORT" \
  root-key-sentinel-is-ta-38696.dnstest.dev. A \
  +dnssec +nocdflag

Esperado para chave confiável: NOERROR, com resposta A. Interpretação: primeira metade do teste. Limite: precisa do controle complementar.

dig @"$RESOLVER" -p "$PORT" \
  root-key-sentinel-not-ta-38696.dnstest.dev. A \
  +dnssec +nocdflag

Esperado para chave confiável: SERVFAIL. Interpretação: o par NOERROR/SERVFAIL é consistente com confiança em 38696 num validador compatível. Limite: uma falha genérica isolada não certifica o estado.

dig @"$RESOLVER" -p "$PORT" \
  root-key-sentinel-not-ta-38696.dnstest.dev. A \
  +dnssec +cdflag

Esperado: resposta A, pois CD evita o processamento especial. Se houver comportamento diferente, registre o resultado e investigue antes de aprovar.

O sentinel depende de validação Secure, consulta A/AAAA, CD desligado e suporte habilitado. Um forwarder sem validação local pode refletir o upstream; cadeias mais complexas podem ser inconclusivas. Confira a topologia e corrobore com a âncora local. [9]

Expectativa documental antes do rollover, após descoberta autenticada e com sentinel habilitado. Nenhum ensaio A/B ao vivo é apresentado.

6. Transforme os resultados em uma decisão operacional

Considere a instância preparada quando a evidência da âncora confiável e carregada for coerente com os controles funcionais, sem exceções que invalidem a conclusão. Registre data, backend, versão, configuração e resultados. Repita nos demais nós.

Se 38696 estiver ausente ou pendente, investigue o mecanismo de distribuição, o tempo de operação, o relógio e a persistência do estado. O usuário do Unbound precisa escrever tanto no arquivo quanto no diretório da âncora; chroot, controles de acesso do sistema e volumes somente leitura podem interferir. [12][13]

Em sistemas com systemd, uma leitura auxiliar é timedatectl show -p NTPSynchronized -p TimeUSec. Confira também a fonte de tempo usada pelo serviço NTP/chrony e o desvio observado; um indicador de sincronização sozinho não autentica essa fonte.

Não execute unbound-anchor -a como se fosse uma checagem inofensiva. Ele pode criar ou atualizar o arquivo. Seu código de saída também exige cuidado: 1 pode significar bootstrap/atualização; 0 pode ocorrer inclusive em erro. unbound-anchor -l mostra material embutido, não o estado do daemon. [11]

A correção deve seguir o fornecedor e um plano aprovado, com preservação da configuração e retorno definido. Não apague root.key como primeira tentativa, não use chmod 777 e não desabilite DNSSEC para produzir uma resposta “verde”. O apêndice permite estudar os estados sem fazer essas intervenções no serviço do cliente.

Fluxo de interpretação. Alterações em produção exigem plano e aprovação.

Apêndice A — Bancada isolada para comparar VALID e ADDPEND

A1. Escopo e condições

Este procedimento cria arquivos e inicia dois processos locais. Execute-o apenas em uma VM ou ambiente descartável aprovado, como usuário comum. Ele não é uma etapa da auditoria de produção.

Pré-requisitos: Unbound e unbound-anchor 1.26.1 disponíveis no PATH, unbound-checkconf, dig, Bash, ss para inspecionar listeners, relógio correto e conectividade DNS autorizada para a Internet pública. Registre também SO, arquitetura, dig, OpenSSL e a origem/hashes dos binários. A receita fixa a versão do Unbound; versões exatas das demais dependências precisam constar no manifesto da execução para reprodução completa.

A instalação depende da distribuição. Obtenha pacotes do fornecedor ou use a fonte oficial versionada, conferindo SHA-256 e assinatura pelo procedimento da NLnet Labs. Não use uma imagem de origem desconhecida nem execute um instalador no servidor de produção. A referência oficial de build está em [18].

Dependência temporal: a comparação descrita pressupõe que 20326 ainda consiga autenticar a raiz. Depois do rollover, a condição muda. Não altere o relógio para simular a troca: isso também altera a validade das assinaturas.

A2. Crie diretórios novos e privados

if [ "$(id -u)" -eq 0 ]; then
  printf '%s\n' 'Use um usuário comum no ambiente descartável.'
  exit 1
fi

umask 077
LAB=$(mktemp -d "${TMPDIR:-/tmp}/unbound-ksk.XXXXXX")
mkdir "$LAB/valid" "$LAB/pending"
printf 'Diretório da bancada: %s\n' "$LAB"
unbound -V
dig -v
date -u
ss -lntu

Esperado: um diretório novo, somente seu, identificação dos binários e lista dos listeners. Confirme que 1053 e 1054 estão livres em UDP e TCP. Interpretação: estado independente da instalação de produção. Limite: pare se a versão não corresponder à referência ou se alguma porta estiver ocupada; não pare outro serviço para liberá-la.

A3. Prepare a condição de confiança atual

if unbound-anchor -a "$LAB/valid/root.key" -v \
  > "$LAB/valid/bootstrap.log" 2>&1; then
  ANCHOR_RC=0
else
  ANCHOR_RC=$?
fi
cat "$LAB/valid/bootstrap.log"
printf 'Código retornado pelo bootstrap: %s\n' "$ANCHOR_RC"

Esperado: material de confiança atual no arquivo e registro do bootstrap. Interpretação: prepara a instância A. Limite: examine arquivo e log; o exit code sozinho não aprova nada. Um erro de rede ou autenticação deve interromper o avanço, não ser ignorado.

O material embutido na versão 1.26.1 contém 20326 e 38696. A atualização alternativa verifica a assinatura do material da IANA com o certificado de atualização. A origem da confiança não deve ser resumida a um download HTTPS ou a uma chave copiada de uma resposta DNS não autenticada. [14][15]

A4. Prepare uma condição didática inicialmente limitada à chave anterior

O próximo bloco extrai somente para a bancada a âncora anterior embutida no mesmo binário autenticado. Não aponta para nenhum arquivo de produção.

unbound-anchor -l > "$LAB/builtin-anchors-and-cert.txt"
awk '$1 == "." && $2 == "IN" && $3 == "DS" && $4 == "20326" \
  { print }' "$LAB/builtin-anchors-and-cert.txt" \
  > "$LAB/pending/root.key"

test -s "$LAB/pending/root.key" || {
  printf '%s\n' 'A âncora de referência não foi encontrada. Pare aqui.'
  exit 1
}
cat "$LAB/pending/root.key"

Esperado: exatamente o DS de 20326, conferido com a fonte autenticada. Interpretação: a instância B começará sem confiar diretamente em 38696. Limite: não rode o bootstrap do passo A3 sobre esse segundo arquivo e não edite comentários de estado para fabricar ADDPEND. A transição deve ser produzida pelo software.

A5. Crie as configurações locais

for MODE in valid pending; do
  if [ "$MODE" = valid ]; then
    LAB_PORT=1053
  else
    LAB_PORT=1054
  fi

  cat > "$LAB/$MODE/unbound.conf" <<EOF
server:
    interface: 127.0.0.1
    port: $LAB_PORT
    so-reuseport: no
    access-control: 127.0.0.1/32 allow
    username: ""
    chroot: ""
    directory: "$LAB/$MODE"
    pidfile: "$LAB/$MODE/unbound.pid"
    do-daemonize: no
    use-syslog: no
    logfile: "$LAB/$MODE/unbound.log"
    verbosity: 1
    module-config: "validator iterator"
    auto-trust-anchor-file: "$LAB/$MODE/root.key"
    root-key-sentinel: yes
    hide-trustanchor: no
    val-permissive-mode: no
    ignore-cd-flag: no
remote-control:
    control-enable: no
EOF

  unbound-checkconf "$LAB/$MODE/unbound.conf" || exit 1
done

Esperado: as duas configurações aceitas. Interpretação: a diferença experimental está na confiança inicial, com portas e arquivos próprios; a reutilização de porta fica desabilitada nessa bancada. Limite: username: "" e chroot: "" servem ao processo não privilegiado dentro da bancada isolada; não são recomendação de endurecimento para produção. Não há listeners públicos nem controle remoto habilitado.

A6. Inicie e observe os processos

unbound -d -c "$LAB/valid/unbound.conf" \
  > "$LAB/valid/console.log" 2>&1 &
PID_VALID=$!

unbound -d -c "$LAB/pending/unbound.conf" \
  > "$LAB/pending/console.log" 2>&1 &
PID_PENDING=$!

printf 'Processos da bancada: %s %s\n' "$PID_VALID" "$PID_PENDING"
ps -p "$PID_VALID,$PID_PENDING" -o pid,args

Esperado: ambos vivos e associados aos arquivos recém-criados. Interpretação: a bancada está pronta para consultas. Limite: se algum sair, leia seu console/log e investigue; não desative validação nem segurança de rede para fazê-lo iniciar.

Faça uma primeira consulta a cada instância e aguarde a aquisição normal do estado, acompanhando os arquivos:

for P in 1053 1054; do
  dig @127.0.0.1 -p "$P" . SOA +dnssec +nocdflag
  dig @127.0.0.1 -p "$P" trustanchor.unbound. CH TXT
done

grep 'id = 38696' "$LAB/valid/root.key"
grep 'id = 38696' "$LAB/pending/root.key"

Esperado antes do rollover: AD pode aparecer nas duas respostas SOA; A deve ter 38696 confiável, enquanto B deve mostrá-la pendente após descobri-la. Interpretação: demonstra a diferença entre validar agora e confiar na sucessora. Limite: se o estado não for esse, preserve o resultado real e investigue. Não substitua a saída por uma esperada.

A7. Compare o sentinel e os controles

for P in 1053 1054; do
  printf '\nInstância local na porta %s\n' "$P"
  dig @127.0.0.1 -p "$P" \
    root-key-sentinel-is-ta-38696.dnstest.dev. A \
    +dnssec +nocdflag +noall +comments +answer
  dig @127.0.0.1 -p "$P" \
    root-key-sentinel-not-ta-38696.dnstest.dev. A \
    +dnssec +nocdflag +noall +comments +answer
  dig @127.0.0.1 -p "$P" dnssec-failed.org. A \
    +dnssec +nocdflag +noall +comments +answer

  printf 'Controles CD na mesma instância, porta %s\n' "$P"
  dig @127.0.0.1 -p "$P" \
    root-key-sentinel-is-ta-38696.dnstest.dev. A \
    +dnssec +cdflag +noall +comments +answer
  dig @127.0.0.1 -p "$P" \
    root-key-sentinel-not-ta-38696.dnstest.dev. A \
    +dnssec +cdflag +noall +comments +answer
  dig @127.0.0.1 -p "$P" dnssec-failed.org. A \
    +dnssec +cdflag +noall +comments +answer
done

Expectativa documental, sujeita às condições anteriores:

Evidência: Chave 38696 no estado gerenciado
Instância A: VALID
Instância B: ADDPEND, após descoberta
Evidência: Consulta da raiz SOA antes do rollover
Instância A: NOERROR com AD
Instância B: Pode ser NOERROR com AD
Evidência: Sentinel is-ta-38696
Instância A: NOERROR com A
Instância B: SERVFAIL
Evidência: Sentinel not-ta-38696
Instância A: SERVFAIL
Instância B: NOERROR com A
Evidência: Controle bogus com CD desligado
Instância A: SERVFAIL
Instância B: SERVFAIL

Os três controles CD no mesmo loop devem obter resposta A quando os nomes estiverem acessíveis e CD for respeitado. Eles consultam explicitamente as portas da bancada, sem reutilizar as variáveis da auditoria de produção. Não compare latências entre as instâncias como se o experimento medisse desempenho: os caches e estados de aquisição podem diferir.

A8. Encerre somente a bancada

Na mesma sessão, confirme que os PIDs ainda correspondem aos comandos da bancada:

ps -p "$PID_VALID,$PID_PENDING" -o pid,args

Depois dessa conferência, envie TERM somente aos dois processos identificados:

kill -TERM "$PID_VALID" "$PID_PENDING"
wait "$PID_VALID" "$PID_PENDING"

Preserve o diretório impresso em A2 para revisão. Não há comando de exclusão neste roteiro. Arquive as saídas, horários e versões antes de descartar a VM pelo procedimento do laboratório.

A9. O que foi verificado para este artigo

Em 6/10/2026, a fonte oficial do Unbound 1.26.1 teve SHA-256 e assinatura OpenPGP conferidos e foi compilada em Debian 13.6, Linux x86_64, com OpenSSL 3.5.7. Não houve instalação global nem alteração de DNS de produção. Os 24 blocos Bash passaram em bash -n, que verifica a gramática do shell sem executar os comandos. O caminho unbound-checkconf -o leu as duas configurações exatas de A5 e retornou as opções solicitadas. Esses resultados cobrem sintaxe e leitura de configuração, não o funcionamento recursivo.

A suíte oficial retornou 1.306.749 verificações aprovadas. Quatro replays offline incluídos na fonte também passaram: root_key_sentinel, autotrust_init_ds, autotrust_addpend_once e autotrust_valid_use. Eles usam dados de teste upstream, inclusive históricos; não observam a raiz atual nem os domínios de sentinel pela Internet.

O ambiente bloqueou a enumeração de interfaces com Operation not permitted; por isso, a verificação completa de unbound-checkconf e a inicialização dos daemons não terminaram com sucesso. Os probes DNS públicos em UDP e TCP/53 retornaram Network is unreachable. Essas restrições não foram contornadas. Não foram concluídos: bootstrap de rede, consultas CH no daemon, respostas AD, controle bogus/CD, descoberta natural de 38696 em ADDPEND e par sentinel ao vivo. A matriz de A7 permanece uma expectativa documental; a receita não foi integralmente executada e nenhum teste descrito certifica o resolvedor de um cliente.

Apêndice B — Interpretação das falhas

Resultado: 38696 publicada, mas ADDPEND
Hipóteses a verificar: Descoberta recente, estado reiniciado, período de inclusão incompleto
Próxima leitura segura: Datas/metadados da âncora e histórico operacional
Limite: Presença no DNS não antecipa o hold-down
Resultado: VALID no disco, ausente na consulta CH
Hipóteses a verificar: Arquivo ou instância diferente; configuração ainda não carregada
Próxima leitura segura: Processo, caminhos, namespace e configuração selecionada
Limite: Não reiniciar apenas para forçar coincidência
Resultado: CH retorna REFUSED
Hipóteses a verificar: hide-trustanchor ou política de acesso
Próxima leitura segura: Configuração e método local permitido
Limite: Não equivale a chave ausente
Resultado: SOA positivo também retorna SERVFAIL
Hipóteses a verificar: Relógio, âncora, transporte ou problema geral
Próxima leitura segura: Horário, logs existentes e disponibilidade do caminho
Limite: Não atribuir tudo ao rollover
Resultado: Bogus retorna NOERROR com CD desligado
Hipóteses a verificar: Validação ausente, permissive-mode, exceção, política ou cadeia de forwarding
Próxima leitura segura: Módulos, exceções e controles positivos
Limite: Confirmar também o estado atual do domínio de teste
Resultado: Sentinel retorna NOERROR nos dois nomes
Hipóteses a verificar: Sentinel desabilitado/não suportado, resposta não Secure ou nó não validador
Próxima leitura segura: root-key-sentinel, CD e âncora local
Limite: Resultado inconclusivo sobre 38696
Resultado: Sentinel retorna SERVFAIL nos dois
Hipóteses a verificar: Falha geral, upstream interferindo ou condição não atendida
Próxima leitura segura: Controle positivo, CD e encaminhamentos
Limite: Não aprovar nem reprovar somente por esse par
Resultado: UDP falha e TCP responde
Hipóteses a verificar: Transporte, fragmentação, política ou interceptação
Próxima leitura segura: Repetir a mesma consulta com +tcp e registrar diferença
Limite: Não liberar firewall automaticamente
Resultado: Resultados variam entre consultas
Hipóteses a verificar: VIP, anycast, múltiplos backends, política ou cache
Próxima leitura segura: Backend/ponto de observação, horários e TTLs
Limite: Uma resposta boa não cobre todos os nós

Consultas DNS naturalmente movimentam cache e contadores. “Sem alteração administrativa” significa que este roteiro não recarrega o serviço, não limpa caches e não modifica sua configuração. A coleta é pontual, sem loops de carga.

Não publique logs integrais de clientes. Remova nomes internos, endereços privados, identificadores operacionais e qualquer credencial antes de compartilhar evidências. A chave pública da raiz não é uma credencial secreta, mas arquivos privados de controle administrativo são.