Resumo

  • A revisão 05 do RDAP DELEG eliminou priority e target, adotou o nome DelegInfos e refez os exemplos para acompanhar o DELEG-11.
  • A revisão 02 do mapeamento EPP, citada normativamente, continua definindo os dois atributos em um esquema XML descrito como completo.
  • A proposta RDAP já exige o identificador dnsDeleg, mas ainda marca como TBD a especificação integral das chaves e dos valores do JSON.
  • As fontes não mostram perda real de dados, software implantado ou incidente. Elas mostram que o percurso EPP–DNS–RDAP ainda não tem um contrato reproduzível.

A resposta RDAP alcançou o modelo novo

O anúncio do Internet-Draft registra draft-albanna-regext-rdap-deleg-05 em 4 de setembro de 2026. O texto quer incluir informações DELEG e DELEGPARAM nas respostas RDAP de objetos de domínio. Em outras palavras, não cria a delegação DNS; cria uma janela de dados de registro sobre ela.

O histórico da própria revisão enumera a mudança: removeu referências a priority e target, renomeou delegInfo como DelegInfos e passou a basear os exemplos no DELEG-11. O DELEG-11 afirma que, apesar de reutilizar o desenho de parâmetros do SVCB, não possui SvcPriority nem TargetName. Seu conteúdo é uma lista de pares de chave e valor.

O conjunto inicial traz server-ipv4, server-ipv6, server-name e include-delegparam, além de mandatory. Uma proposta de registro IANA atribuiria a cada chave futura número, nome, significado, referência estável e controlador de mudança. O objetivo é permitir extensão com uma fronteira pública de interoperabilidade.

Na leitura RDAP, portanto, a revisão 05 seguiu a retirada feita no modelo-base.

O caminho de entrada continua em outra revisão

O problema está na segunda referência normativa do RDAP: o mapeamento EPP para DELEG. O EPP permite ao cliente patrocinador criar, alterar e consultar o objeto de domínio de um registro. A extensão proposta acrescenta elementos DELEG ao modelo de domínio padronizado pelo RFC 5731.

Na revisão 02 do EPP DELEG, a seção de sintaxe declara oferecer um esquema completo, próprio para validação automática de XML. O tipo delegType ainda contém um atributo priority do tipo inteiro curto sem sinal e um atributo target. O contêiner de parâmetros aceita outros atributos com processContents="skip".

A sequência das datas oferece uma explicação simples: EPP-02 é de 21 de julho, DELEG-11 de 23 de julho, e RDAP-05 de setembro. Mas atraso editorial não define comportamento. Uma mensagem que passe pelo esquema EPP disponível pode conter dois campos que o DELEG atual exclui e o RDAP atual já apagou dos exemplos.

Os textos não determinam se a passagem deve rejeitar, ignorar, guardar ou migrar esses valores. Tampouco há nas fontes um operador executando essa passagem. A diferença é real no papel e ainda não foi demonstrada em rede.

dnsDeleg identifica a extensão, não a linhagem

O RDAP-05 diz que respostas com seus dados devem incluir dnsDeleg em rdapConformance. O RFC 9083 usa esses identificadores para informar quais especificações ajudaram a construir a resposta. Eles permitem que o cliente reconheça JSON adicional, mas não registram a origem de cada valor nem a transformação aplicada antes da consulta.

Essa distinção é decisiva porque a seção de resposta do próprio RDAP-05 ainda deixa como TBD a lista completa dos pares admitidos em DelegInfos. O texto espera a evolução de DELEG e EPP. Os exemplos mostram uma forma possível, não uma conversão normativa entre XML EPP, apresentação e bytes DNS, e JSON RDAP.

No congelamento da pesquisa, dnsDeleg não constava do registro IANA de extensões RDAP. O projeto pede seu registro para qualquer operador. A ausência não é rejeição da IANA; é apenas a situação de uma solicitação que ainda não virou entrada.

Há uma proposta separada do REGEXT sobre versionamento em RDAP. Ela prevê versões legíveis por máquina, relações de antecessor e sucessor, avisos de descontinuação e políticas de transição. O RDAP DELEG-05 ainda não vincula seus dados a uma identidade desse tipo.

Maturidade não se transfere por referência

O Datatracker do RDAP DELEG o classifica como Internet-Draft individual, sem fluxo RFC ou Area Director responsável. O mapeamento EPP também é individual. Publicar um I-D não é obter aprovação do IETF.

O DELEG-11 é documento do grupo DELEG em Working Group Last Call, uma posição mais avançada. Ainda é rascunho e mantém números de tipo DNS e o novo registro de chaves como pedidos ou valores a definir. Seu status não transforma automaticamente os dois textos acompanhantes em normas adotadas.

O diagnóstico proporcional é uma costura aberta. Chamar isso de vulnerabilidade, indisponibilidade ou corrupção ultrapassaria a evidência.

O elo ausente é uma regra de custódia

Um contrato completo precisa dizer qual revisão governa cada campo, como a entrada EPP se torna estado DNS autoritativo, como esse estado vira RDAP e o que pode ser perdido de propósito. Também deve dizer se a resposta pública reflete a intenção do registro, uma observação da zona autoritativa ou outra projeção declarada.

Sem isso, dois servidores podem anunciar dnsDeleg e aplicar políticas diferentes sem mostrá-las. A parte que controla a conversão controla qual versão da intenção se torna visível. É nessa passagem que um detalhe de esquema se converte em governança.