Resumo

  • draft-brown-epp-deleg-03 propõe operações EPP para consultar, criar, acrescentar, retirar ou apagar todos os registros DELEG associados a um domínio.
  • O texto prevê longa convivência entre DELEG e NS; assim, um estado coerente no repositório pode alimentar duas representações públicas ainda divergentes.
  • O recibo de mudança precisa seguir da transação até a geração da zona, publicação no pai, DNSSEC, servidores autoritativos, capacidade do resolvedor, cache e teste da aplicação.

O incidente que vale prevenir não começa com um erro. Começa com uma confirmação.

Um cliente patrocinador envia deleg:all. O servidor autentica a sessão, aceita a atualização e devolve o identificador da transação. O objeto no registro fica sem DELEG. A sonda de disponibilidade continua consultando NS e encontra os mesmos servidores. Do ponto de vista do cadastro e do monitor legado, tudo terminou bem.

Falta saber o que o pai entregou a um resolvedor que entende DELEG.

A revisão 03 do rascunho EPP dá forma exata a esse risco. Ela passa a usar elementos nomeados deleg:param, muda o namespace XML, cria deleg:all para remoção completa e acrescenta requisitos operacionais. O registro no Datatracker e o histórico delimitam a autoridade do texto: trata-se de Internet-Draft individual, sem fluxo RFC. Não é padrão IETF nem evidência de implementação.

Um recibo de repositório

O mapeamento oferece três superfícies. info pode mostrar a representação armazenada; create pode levar registros DELEG na abertura do domínio; update pode adicionar, remover registros exatos ou retirar todos. Isso permite reconstituir o que o servidor aceitou.

RFC 5730 define comandos, respostas e identificadores do EPP. RFC 5731 mapeia domínios e RFC 5732, hosts. O resultado positivo fecha a transação no repositório. Ele não é emitido pelo gerador de zona, pelo assinador DNSSEC, por cada autoridade do pai ou pelos resolvedores recursivos.

O servidor chama de patrocinador o cliente autorizado a administrar o objeto. Essa autorização é real, mas limitada. Ela não concede ao cliente poder sobre caches, versões de software, carregamento de zona ou resultado para o usuário.

Coexistir significa reconciliar

O rascunho afirma que a maioria dos domínios precisará manter DELEG e NS no pai no futuro previsível. Por isso, recomenda permitir DELEG ao lado de objetos ou atributos de host. A migração cria duas projeções, não apenas duas colunas.

O texto de base do grupo de trabalho, Extensible Delegation for DNS, tenta eliminar a antiga ambiguidade entre NS no pai e no ápice filho. DELEG seria autoritativo no pai, extensível e protegível com DNSSEC. Mesmo assim, o RRset pode aparecer com ou sem NS. Sem NS, software que desconhece DELEG não resolve a zona delegada.

Logo, deleg:all pode significar recuo voluntário para NS, reversão de teste ou exclusão indevida da nova via. A monitoração NS permanece saudável nos três casos. A semântica operacional depende do plano de migração e do estado público, não apenas do XML.

O rascunho DNSOP de extensões de delegação trata sinalização de capacidade e resistência a downgrade. O EPP não consegue atestar que autoridades e resolvedores executaram esse protocolo só porque armazenou os parâmetros.

O vocabulário também muda

A revisão 03 obriga o servidor a rejeitar nomes desconhecidos e valores inválidos. Dentro de um registro, o nome do parâmetro é único. Cliente e servidor também devem atualizar periodicamente a lista de DelegInfoKeys registrados.

Essa disciplina evita extensões improvisadas, mas cria um relógio adicional. O cliente pode conhecer uma chave que o servidor ainda rejeita. Depois, ambos podem aceitá-la enquanto o gerador não a publica. Mais tarde, parte do conjunto autoritativo pode continuar incompatível. Validade sintática, suporte de componentes e presença no DNS são estados diferentes.

O rascunho DELEG pede um novo registro IANA de informações; o rascunho EPP pede namespace e registro da extensão. RFC 7451 estabelece o mecanismo, e o registro ativo da IANA mostra as atribuições efetivas. Na fotografia congelada para este relatório, a proposta DELEG não aparece. Um pedido em Internet-Draft não é uma atribuição.

A segunda metade começa na zona pai

O rascunho base proíbe DELEG no ápice filho porque o local errado pode causar falha de validação DNSSEC. RFC 4035 descreve o contexto de autenticação e validação. Um RRset validado prova o que a cadeia permite provar sobre os dados recebidos. Não prova que eles correspondem à intenção EPP mais recente nem que NS e DELEG levam ao mesmo destino.

O dossiê correto começa com intenção, aprovador, identidade do cliente, bytes da requisição, namespace, fotografia das DelegInfoKeys e os dois identificadores de transação. Em seguida registra a versão efetivamente gravada e a regra de reconciliação entre DELEG, hosts e NS.

Depois vêm entrada e saída do gerador, serial do pai, assinatura, carregamento e resposta de cada autoridade. É preciso consultar caminhos compatíveis e incompatíveis com DELEG. No resolvedor, registre versão, sinalização, validação, época do cache e fallback. Feche com um canário de aplicação e uma decisão explícita de prosseguir ou voltar.

Os três ensaios de Heng Lu são lentes editoriais declaradas, não fonte normativa. A primazia do código em execução manda verificar o estado servido; a especificação mínima com decisão local separa formato comum de política de adoção; as camadas de realidade impedem que um recibo administrativo se passe por resultado técnico.

Registro oficial

O pacote preserva o estado atual, o histórico, a revisão 03, os rascunhos DELEG e DELEXT, e as RFC de EPP central, domínio, host, registro de extensões e DNSSEC, além da IANA. Nenhuma delas demonstra operação ou incidente nomeado.