Resumo

  • O cliente X pode patrocinar o domínio e o host que deseja remover, enquanto um domínio do cliente Y ainda usa esse host como servidor de nomes.
  • Renomear, entrar em pendingDelete, notificar, restaurar, expurgar e recuperar o DNS são eventos separados; uma resposta de sucesso não comprova todos.

Um comando de exclusão EPP parece confinado ao patrocinador. O caso de RFC 9874 mostra o contrário: X patrocina um domínio e seu host subordinado; Y associou o mesmo host a outro domínio. X pode remover a própria associação, mas não pode atualizar o objeto de Y.

RFC 5731 já recomenda não excluir um domínio enquanto houver hosts subordinados associados. RFC 5732 desaconselha excluir um host ligado a outros objetos. As restrições evitam que uma operação limpa produza uma interrupção silenciosa de DNS, mas deixam a pergunta comercial: como permitir a saída legítima de X sem obrigá-lo a servir Y para sempre?

Uma prática observada renomeia o host para fora do domínio removido. A associação permanece, porém o controle pode mudar de mãos. Se o novo pai for registrável ou ganhar outro titular, essa pessoa poderá criar o host e receber consultas destinadas aos domínios dependentes. O RFC 9874 proíbe escolher um nome externo apenas presumido inexistente.

Apontar para um resolvedor recursivo conhecido também falha: ele não oferece a autoridade exigida pela delegação. Nomes AS112 não são um serviço sacrificial universal; o uso indevido pode facilitar sequestro local e impor trabalho fora de sua finalidade.

Publicado como BCP 244, o RFC 9874 delimita três caminhos seguros. O cliente pode manter um host sacrificial autoritativo, conservar o pai, publicar endereços e operar DNS de verdade. O servidor pode excluir hosts e associações explicitamente, com detalhes, aviso e restauração. Ou a comunidade pode estabelecer um domínio sacrificial de uso especial, recomendando sacrificial.invalid se esse caminho vier a existir. O texto não afirma que as duas últimas opções estejam implantadas hoje.

Na opção reversível, domínio, hosts subordinados e associações cruzadas permanecem representados durante pendingDelete. O DNS público pode já estar indisponível, antecipando o impacto, enquanto RFC 3915 ainda oferece restauração antes do expurgo final. Pedido, estado reversível, janela de reação e eliminação irreversível precisam de horários próprios.

Aviso tampouco é reparo. O servidor pode mostrar ao solicitante quais objetos serão atingidos e usar o change poll de RFC 8590 para informar outros clientes. Criar a mensagem não prova leitura pelo registrador, contato com o titular, correção da delegação ou retorno do serviço.

As associações podem ser ilimitadas, exigindo desativação, restauração ou expurgo em lotes assíncronos. Isso gerencia carga, não concede autoridade. O término de uma tarefa não demonstra mudança simultânea nem convergência dos resolvedores.

As camadas da realidade de Heng Lu separam intenção declarada, relações preservadas, transição aceita, zona autoritativa, observação dos resolvedores e resultado do usuário. Sua especificação inicial mínima combina contrato estreito com decisões locais de aprovação e recuperação. A primazia do código em funcionamento exige rastros reproduzíveis, não confiança em um status satisfatório.

DNSSEC reduz algumas ameaças, sem substituir evidência. Automação que aceite CDS/CDNSKEY controlados por um invasor a partir de um único servidor pode converter divergência em transferência de controle.

O SAC125 e a apresentação Risky BIZness da IETF 115 contextualizam riscos no gerenciamento de servidores de nomes. Não provam vulnerabilidade ou conduta atual de operador algum. O RFC 9874 é uma resposta de projeto a uma classe de risco, não um relato de incidente.

Fontes