Resumo
- O cliente que patrocina um domínio e um host subordinado pode não controlar os domínios de outros clientes que usam esse host como servidor autoritativo.
- Renomear o host para um nome supostamente inexistente ou para um serviço recursivo não autoritativo transfere risco; o RFC 9874 proíbe essas práticas observadas.
- Um recibo entre clientes deve registrar autoridade, escopo, estado DNS, alerta, notificação, prazo de redenção, restauração e conclusão do expurgo assíncrono.
O cliente X quer excluir domain1.example. Sob ele existe ns1.domain1.example. O cliente Y, porém, usa esse host para delegar domain2.example. X pode alterar seus próprios objetos, mas não o domínio de Y. Talvez nem tenha permissão para enxergar a associação completa. O servidor do registro tem uma visão que nenhuma das duas partes possui isoladamente.
Esse privilégio de visão cria uma obrigação. Se o servidor aceitar a ordem, deve ser possível reconstruir quais dependências foram avaliadas, qual efeito foi autorizado e como os afetados puderam reagir. O código de resultado não carrega tudo isso.
Três coerências por trás de uma cautela
O RFC 5731 recomenda não excluir um domínio enquanto houver hosts subordinados associados. O RFC 5732 recomenda não excluir um host ainda ligado a outros objetos. A razão imediata é DNS: o nome do host pode deixar de resolver, ou domínios que dependem dele podem perder serviço.
Há também consistência entre cliente e servidor. Se o registro remove relações implicitamente, o inventário do cliente pode continuar mostrando algo que já não existe. E há consistência relacional no banco do registro, em que domínio e host podem ter vínculos que não toleram remoção parcial.
No caso entre clientes, surge a coerência de autoridade. Y é quem pode atualizar domain2.example; X é quem deseja encerrar o objeto de que Y depende. Uma política responsável não chama o desconforto de erro de usuário. Ela administra a transição.
O host sacrificial precisa de custódia
Renomear o host para fora do domínio original permite que a exclusão prossiga. O chamado host sacrificial preserva a referência com outro nome. A escolha desse nome decide onde o risco ficará.
Usar um domínio externo presumido inexistente parece barato. Se alguém registrar o domínio pai mais tarde, poderá criar o host e receber consultas dos domínios ainda associados. O RFC 9874 determina que essa prática observada não seja usada.
Apontar glue para um resolvedor público também não cria autoridade. As consultas podem falhar com SERVFAIL, e tentativas repetidas podem multiplicar tráfego inútil. Essa prática igualmente não deve ser usada.
Na alternativa admitida, o cliente mantém o domínio pai, protege seu registro e opera DNS autoritativo nos endereços publicados. O risco de tomada diminui, mas nasce uma obrigação contínua. Renovação, lock, monitoramento e sucessão organizacional passam a fazer parte da exclusão. Se a custódia se perder anos depois, a vulnerabilidade reaparece.
A redenção dá forma ao intervalo
O outro desenho permite excluir explicitamente mesmo com associações externas. O servidor pode informar ao solicitante o alcance, exigir confirmação consciente e avisar clientes afetados pelo EPP Change Poll ou mecanismo equivalente.
Com a extensão de período de graça do RFC 3915, o domínio, os hosts e as associações podem permanecer em pendingDelete. O DNS pode refletir a retirada enquanto o grafo ainda é restaurável. Uma ação acidental, maliciosa ou mais danosa que o previsto pode ser revertida durante a redenção. O expurgo definitivo vem no fim.
Como não há limite definido para o número de associações, desabilitar, reabilitar e expurgar podem ser operações assíncronas. A hora do aceite não é a hora em que todos os efeitos terminam. Um sistema que registra apenas a primeira perde justamente a cauda em que aparecem falhas parciais.
Um recibo orientado ao grafo
O recibo começa com identidade de transação, cliente autenticado, objeto, política aplicada, momento e fundamento para efeitos entre clientes. Em seguida congela o alcance: quando e como as dependências foram enumeradas, quais hosts estavam envolvidos, quantos domínios seriam afetados e quais limites de visibilidade existiam.
Depois vem o DNS: nomes e endereços autoritativos antes e depois, estado esperado da zona, observação real, condições de DNSSEC e DS, e a prática escolhida. Alertas exibidos, detalhes fornecidos, aprovação humana e justificativa formam o registro da decisão.
O bloco de notificação mostra enfileiramento, entrega e reconhecimento para cada cliente afetado, sem expor dados privados do registrante. O bloco de reversibilidade fixa prazo de redenção, autoridade de restore, associações retidas e teste de reconstrução. O fechamento lista tarefas assíncronas, falhas parciais, tentativas, expurgo e observação final.
Esse recibo é uma recomendação editorial, não um campo do RFC 9874. Contagens e referências opacas podem preservar privacidade. O que não pode desaparecer é a prova de que o registro contou, avisou e resolveu as dependências.
DNSSEC não corrige uma fonte incoerente
DNSSEC e múltiplos servidores podem reduzir riscos, mas o RFC 9874 descreve uma exceção importante. Se um invasor controla um servidor e a manutenção automática de DS aceita CDS/CDNSKEY sem verificar todos os autoritativos, o material do invasor pode influenciar o DS. CSYNC pode ampliar a mudança.
O recibo precisa indicar se a automação estava ativa, quais servidores foram consultados, se as respostas coincidiram e quem autorizou o resultado. “DNSSEC habilitado” é estado de capacidade, não atestado da transição.
Cinco sucessos, cinco provas
O RFC 9874 recomenda um host sacrificial autoritativo mantido pelo cliente, exclusão explícita com detalhes, notificação e restauração, ou um domínio de uso especial adequado. Atalhos que transferem custo a resolvedores, terceiros ou futuros registrantes são rejeitados.
Excluir continua sendo uma operação legítima. A disciplina é não misturar cinco alegações: o servidor aceitou; o alcance foi enumerado; os afetados foram avisados; a restauração permanece possível; o expurgo terminou. Quando cada uma tem relógio e evidência, o comando pode ser auditado. Quando todas viram uma linha verde, o sucesso deixa de ser confiável.
Fontes
- Registro do RFC 9874 no IETF Datatracker
- Minimum Initial Specification — Heng Lu
- The Policy Mirror — Heng Lu
- SAC125 — gestão de servidores de nomes por registradores
- Informações e status do RFC 9874
- RFC 3915 — período de graça no EPP
- RFC 5730 — protocolo EPP
- RFC 5731 — mapeamento de domínios no EPP
- RFC 5732 — mapeamento de hosts no EPP
- RFC 8590 — EPP Change Poll
- RFC 9520 — cache negativo de falhas DNS
- RFC 9874 — exclusão de objetos de domínio e host
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
