Resumo

  • A RFC 3375 descreveu um sistema compartilhado no qual vários registradores administravam objetos patrocinados, enquanto um único registro continuava autoritativo para cada espaço de nomes e zona.
  • Identidade do objeto, patrocínio, associação a recurso compartilhado, transferência, resultado da transação e publicação no DNS eram evidências distintas. O sucesso em uma etapa não concluía todas as demais.

Para quem registra um domínio, a relação parece bilateral. O titular escolhe um registrador, envia dados e recebe uma confirmação. Só que o registrador precisa conversar com o registro, o repositório central que coordena as delegações. Mais adiante, uma seleção desses dados alimenta a zona DNS. O serviço é contínuo para o cliente, mas seu poder está deliberadamente repartido.

Publicada em setembro de 2002 como Informational, a RFC 3375 apresentou requisitos para um protocolo genérico entre registro e registrador. Não era um Internet Standard nem um levantamento de implantações. Seu objetivo era permitir que sistemas com diferentes modelos operacionais compartilhassem uma linguagem mínima de provisionamento.

O documento distinguiu três papéis. O registrante solicita nomes por meio de um registrador. O registrador atende o público e acessa o registro. O registro mantém o repositório central associado às delegações e normalmente gera e distribui arquivos de zona. Em um sistema compartilhado, diversos registradores independentes utilizam o mesmo serviço de registro com acoplamento frouxo.

A abertura comercial não repartia a autoridade final. Para a RFC 3375, havia um e apenas um registro autoritativo para certo espaço de nomes e zona, ainda que um registro pudesse cuidar de vários. O registrador recebia capacidade de gestão sobre objetos patrocinados, mas não se tornava soberano sobre o espaço em que esses objetos existiam.

O protocolo precisava gerir sessões, consultar objetos, criar, alterar, renovar, excluir e transferir. Também deveria identificar e autenticar clientes e servidores, aplicar autorização e explicar o resultado. Operações que modificassem objetos recebiam um identificador de transação único no registro. Esse identificador criava rastreabilidade; não provava a intenção do titular, a geração de um arquivo de zona, o carregamento nos servidores autoritativos ou a resposta observada por um resolvedor remoto.

A identidade dos objetos tinha vida mais longa que a custódia. Cada objeto precisava de um identificador globalmente único, preservado durante toda a existência no repositório mesmo quando o controle administrativo mudasse. Assim, transferir um domínio trocava o registrador patrocinador sem apagar sua continuidade histórica. A mesma identidade antes e depois tornava a mudança auditável.

Recursos compartilhados exigiam outra separação. Um objeto de servidor de nomes administrado pelo registrador X poderia atender também um domínio patrocinado pelo registrador Y. Y precisava associar esse servidor ao domínio, mas não deveria ganhar permissão para alterar o servidor. Uma referência era uma dependência, não um título de controle. Confundir as duas permitiria a um usuário indireto afetar muitos outros domínios.

A transferência de domínio era, por isso, um processo autorizado. O registrador que pretendia se tornar o novo administrador iniciava o pedido. O sistema devia confirmar a autorização, mostrar o estado, explicar quais objetos associados acompanhariam a transferência, permitir cancelamento antes da decisão e informar aprovação ou rejeição. Servidores registrados dentro do próprio domínio podiam ser transferidos junto com ele, consequência que não deveria ficar implícita.

A RFC 3375 também acomodou registros grossos e finos. No modelo grosso, o registro guardava tanto informações técnicas da delegação quanto informações sociais, como contatos. No fino, uma parte permanecia com os registradores. O protocolo comum buscava interoperabilidade entre esses desenhos; não obrigava todos a usar a mesma arquitetura de banco de dados.

A fronteira com o DNS é decisiva. As RFCs 1034 e 1035 descrevem zonas, servidores autoritativos, cache e resolução. A RFC 2136 apresenta atualização dinâmica de zonas. A RFC 3375 trata de objetos do registro e atribui ao registro a geração de arquivos de zona. Uma renovação ou mudança de contato pode ter sucesso sem mudar o DNS. Uma alteração de delegação aceita ainda pode depender de projeção, distribuição, carregamento e expiração de cache até ficar visível.

A RFC 2832 já havia especificado o Registry Registrar Protocol. Depois, a RFC 3730 definiu o EPP; a RFC 5730 substituiu a base, enquanto as RFCs 5731, 5732 e 5733 detalharam os mapeamentos de domínio, host e contato. Essa sequência registra refinamento técnico, não prova de adoção universal ou de uma latência operacional uniforme.

O vocabulário da RFC 2119 evita outra extrapolação. MUST e SHOULD expressam requisitos para o protocolo, não certificados de que todos os operadores os cumpriram. A política de internacionalização da RFC 2277 lembra ainda que caracteres, idiomas, contatos humanos e identificadores DNS traziam necessidades próximas, mas não idênticas.

A noção de Lu Heng de uma especificação inicial mínima ajuda a interpretar a escolha: definir o núcleo necessário para cooperação, preservando decisões futuras e locais. Sua análise das camadas da realidade oferece o teste de evidência. Pedido do titular, autorização do registrador, patrocínio, aceitação pelo registro, estado do repositório, geração de zona, serviço autoritativo e observação do resolvedor estão ligados, mas não podem ser fundidos.

O legado da RFC 3375 foi fazer a escala depender de fronteiras claras. O mercado podia ter muitas vitrines e ainda assim manter uma autoridade coerente para o espaço de nomes. Um objeto podia mudar de responsável sem mudar de identidade. Um recurso podia ser usado por mais de um registrador sem se tornar controlável por todos. A operação só permanece confiável quando a prova respeita essas divisões.

Fontes