Resumo

  • draft-ranjbar-regext-rdap-subordinate-referrals-01 propõe relações direcionais para descobrir um serviço RDAP designado pelo titular para nomes, redes ou endereços subordinados a um objeto registrado.
  • Os dados de destino são declarados pelo titular, não pelo operador do registro. Subordinação estrita, vínculo de retorno e limite de um salto contêm o alcance, enquanto o titular passa a observar as consultas recebidas.
  • O cliente deve preservar uma emenda de autoridade: objeto de cobertura do registro, ato de designação e resposta subordinada do titular precisam permanecer evidências separadas.

O percurso comum do RDAP começa no bootstrap da IANA, encontra o serviço responsável por um domínio ou intervalo numérico e desce até o objeto mais específico mantido por aquele operador. A sequência parece uma única cadeia de autoridade.

Ela, porém, termina onde o registro decidiu não guardar mais detalhes. Um registro de domínios pode conhecer o domínio registrado sem armazenar todos os nomes criados dinamicamente abaixo dele. Um RIR pode manter uma alocação de cobertura ou atribuição agregada sem conservar cada rede mais específica ou endereço entregue internamente pelo titular. O dado fino pertence ao sistema onde muda.

O Internet-Draft individual propõe tornar essa fonte encontrável. O titular designaria um servidor RDAP próprio ou operado por terceiro. A resposta do registro apontaria para baixo; a resposta do titular manteria um caminho de volta ao serviço que cobre o recurso. O ganho é obter especificidade sem obrigar a base central a absorver um conjunto volátil.

O custo surge quando a interface apaga a mudança de autoridade.

Direção descendente não transfere mandato

A revisão 01 chama de rdap-base-down a relação para a URL-base do serviço a jusante e de rdap-base-up a relação inversa para a URL-base do registro de cobertura. Os nomes descrevem direção entre serviços. Não transformam o operador a jusante em registro.

O limite é expresso: o servidor designado só é fonte candidata para recursos totalmente subordinados ao objeto de origem. A URL deve usar HTTPS e o cliente não pode reconhecer autoridade sobre recurso irmão, superior ou alheio. O vínculo inverso preserva a navegação ao pai. O número de indicações deve ser limitado; um salto de titular basta aos casos descritos.

Mesmo assim, há duas afirmações. O registro afirma que aquele titular designou aquele serviço para aquele âmbito. O titular afirma o conteúdo do objeto subordinado. Rotular tudo como “dados do registro” converte a primeira afirmação em endosso da segunda.

Compatibilidade pode ocultar a troca de voz

A proposta conserva o comportamento para clientes antigos. Quando o ponteiro foi registrado, o servidor do registro continuaria redirecionando a busca subordinada ao serviço designado. Um cliente que ignora a nova relação ainda recebe o registro mais específico. Um cliente capaz pode descobrir o link e atravessar a fronteira de modo deliberado; quem quiser também a ficha do registro pode suprimir o redirecionamento conforme a ideia do rascunho complementar.

Isso protege a compatibilidade, mas redirecionamentos HTTP são discretos. Bibliotecas os seguem automaticamente. A tela final não mostra necessariamente que fornecedor, disponibilidade, privacidade e força probatória mudaram no trajeto.

draft-ietf-regext-rdap-referrals-04 define um pedido explícito de redirecionamento a um recurso RDAP relacionado. Havendo um único link adequado e autorização, o servidor responde com status HTTP de redirecionamento e Location. O texto também trata seleção de relação, negociação, cache e múltiplos saltos. Ele evita transferir uma ficha inteira apenas para extrair um link, mas não resolve como atribuir a voz final.

O titular publica e observa

A seção de segurança diz que os dados servidos pelo destino são afirmados pelo titular, não pelo operador do registro. Exibir essa procedência define quem corrige, quem mantém continuidade, quem responde por erro e qual fonte pode sustentar uma disputa.

Quando a consulta chega à infraestrutura do titular, ele observa interesse nos próprios recursos. O texto compara essa visibilidade à de um operador DNS e permite que clientes com exigência de confidencialidade não sigam. Essa escolha só funciona se aparecer antes da travessia e se a ficha de cobertura continuar acessível.

A disponibilidade também se divide. Se o serviço do titular falha, some o detalhe adicional, não a resposta própria do registro. “RDAP indisponível” não basta: queda do registro, ponteiro quebrado e queda a jusante têm responsáveis diferentes.

A designação é a dobradiça fora do escopo

O documento não especifica como o titular comunica o servidor ao registro. Um portal ou futura extensão EPP são exemplos. É uma delimitação técnica razoável, mas deixa fora do protocolo o ato administrativo que decide para onde a consulta vai.

Quem cria, altera e revoga o ponteiro? O prestador que opera o servidor pode mudar a designação? Quando o novo destino começa a valer? Uma transferência do domínio ou recurso numérico invalida automaticamente o destino anterior? Que registro permanece após comprometimento ou erro?

O registro deveria validar que o destino fornece RDAP conforme para os recursos do titular antes de emitir a indicação. Conformidade não é posse. Um servidor pode responder JSON correto sobre algo que não controla. O ciclo precisa de criação autenticada, prova de âmbito, teste do destino, ativação, renovação, alteração, revogação e limpeza após transferência.

Registrar a emenda de autoridade

Proponho uma ficha da emenda de autoridade para cada indicação seguida. Não é requisito do rascunho. É a prova mínima para que descoberta não vire aprovação silenciosa.

A primeira camada registra bootstrap, objeto de cobertura, serviço do registro, relação, destino designado, ator e canal da designação, ativação, âmbito e última checagem de conformidade. O que não estiver disponível permanece desconhecido.

A segunda camada registra a travessia: caminho consultado, redirecionamento comum ou relação explícita, status HTTP, escolha de supressão, URL, resultado TLS, horário e quantidade de saltos. Também informa se o usuário soube que o titular poderia observar a consulta.

A terceira camada mantém separada a afirmação do titular: serviço respondente, objeto subordinado, horário, marcas de conformidade, prazo de cache e vínculo de volta ao registro. A interface pode mostrar o detalhe como “afirmado pelo titular” ao lado do objeto de cobertura.

Na falha a jusante, o cliente conserva o registro superior e nomeia a camada quebrada. Após revogação ou troca de titular, alegações em cache vencem. Uma resposta fora da subordinação estrita é rejeitada, não legitimada pela existência do link.

As relações foram generalizadas para servir também à descoberta de RPKI delegado ou híbrido e à modernização de RWhois ou SWIP. A reutilização reduz vocabulário, mas “a jusante” indica topologia, não mandato jurídico, qualidade ou nível de serviço. Cada aplicação precisa manter seu contexto.

A revisão 01 é um Internet-Draft individual de 21 de julho de 2026. O Datatracker não mostra posição formal, fluxo ou status RFC pretendido, embora o cabeçalho diga Standards Track. O autor prefere a incorporação ao documento do grupo REGEXT. A seção de implementação relata um serviço do lado do titular e identifica como ausente o salto do lado do registro. Não é prova de adoção ampla.

Há informação útil abaixo do ponto onde o bootstrap para. O desenho responsável permite que a descoberta continue sem emprestar a autoridade do registro à voz do titular.

Fontes