Resumo

  • A RFC 8334 separa o Registro de Lançamento da Aplicação de Lançamento. No modelo de aplicação, um create válido pode retornar EPP 1001, applicationID e pendingCreate, mesmo que o registro ainda não tenha alocado o domínio.
  • O sucesso comprova a aceitação do comando e a criação do objeto de aplicação. Não comprova prioridade de marca, alocação final, publicação registral, delegação DNS nem operação do serviço.
  • A história auditável junta transações, fase e versão da política, estados e mensagens poll ordenados e o domain:panData final. Depois lê separadamente o objeto de domínio, a projeção pública, o DNS e o serviço.

Sistemas de provisionamento precisam responder rápido. Por isso reduzem processos longos a poucos estados: enviado, sucesso, falha. O risco aparece quando “sucesso” deixa de nomear uma operação e passa a descrever um ativo que ainda não existe.

O exemplo da RFC 8334 responde Command completed successfully; action pending. O resultado é 1001 e inclui fase e applicationID. O comando terminou. A ação que decidirá a alocação permanece aberta.

Publicada em março de 2018 na trilha de padrões do IETF, a RFC é trabalho conjunto de J. Gould, W. Tan e G. Brown. O registro de extensões EPP da IANA aponta para a RFC 8334. Gavin Brown é o sujeito desta análise porque sua coautoria ajuda a tornar visível um intervalo operacional importante. Ele não é autor único, operador do registro, validador ou responsável pessoal por qualquer alocação.

O perfil oficial do IETF preservado em 31 de agosto de 2026 registra vinte e cinco anos de experiência em DNS e nomes de domínio, vinte e dois na Team Internet PLC, antiga CentralNic, catorze como CTO, e trabalho atual na ICANN. Lista quatro RFCs, incluindo a RFC 8334, e funções públicas como presidente do trabalho RESTful Provisioning Protocol e revisor ARTART. É contexto datado, não mandato sobre políticas locais.

A operação cria uma aplicação

Um Registro de Lançamento é um registro único, produzido durante uma fase em modelo de ordem de chegada. Uma Aplicação de Lançamento expressa intenção. O servidor pode manter várias aplicações para o mesmo domínio e selecionar mais tarde uma delas para alocação.

Essa multiplicidade é condicional. Nem todo lançamento a usa; nem todo servidor oferece essa forma; nem toda fase segue a mesma sequência. A especificação descreve a linguagem interoperável. A política do servidor escolhe o modelo e o procedimento.

Ao aceitar um create válido de aplicação, o servidor deve criar o objeto, atribuir um identificador, definir o estado RFC 5731 como pendingCreate e devolver o applicationID. O ID individualiza uma aplicação mesmo quando o nome solicitado coincide com outras.

O resultado é concreto. Há um objeto persistente e uma operação correlacionável. Mas o objeto é uma aplicação. applicationID não é título sobre o domínio. pendingCreate não é sinônimo de registro concluído.

Um campo chamado apenas domain_create_success apaga essa diferença. O cliente recebe “domínio criado”; faturamento reconhece receita; DNS procura uma delegação inexistente; automação de segurança trata o nome como ativo. A correção é registrar o objeto de cada verbo: aplicação aceita, validada, alocada ou rejeitada; domínio criado; publicação realizada; delegação e serviço observados.

O alcance do resultado 1001

A RFC 5730 define o núcleo EPP. O resultado 1001 indica comando concluído com êxito e ação pendente. A resposta pode repetir o identificador da transação do cliente e deve incluir o identificador do servidor, permitindo cruzar registros.

Um recibo útil guarda horário, cliente patrocinador, domínio, endpoint, ambos os IDs, fase, subfase, forma de create, política aplicável, resultado, applicationID, estado RFC 5731 e estado de lançamento.

Ele sustenta uma frase: este servidor aceitou e registrou esta operação de aplicação neste contexto e momento. Não sustenta que o requerente ganhou prioridade jurídica; que a validação terminou; que a aplicação venceu concorrentes; que existe um objeto de domínio estável; que RDAP publicou; que a zona pai delegou; ou que um serviço responde.

Os verbos têm agentes diferentes. O cliente do registrador envia. O validador avalia evidência quando necessário. O registro aplica política e aloca. Outro sistema publica dados. O operador da zona insere delegação. Servidores autoritativos respondem. O provedor configura a aplicação. O sucesso de um não importa a autoridade dos seguintes.

Fase é contexto, não regulamento completo

A RFC 8334 define sunrise, landrush, claims, open e custom. O cliente precisa indicar a fase; o servidor deve validá-la e pode validar uma subfase. Fases podem se sobrepor, e o atributo de nome permite subdivisões.

Esses campos localizam a operação, porém não contêm toda a política. Dois registros podem usar sunrise com janelas, validadores, preços, requisitos e métodos de seleção diferentes. Parte da decisão permanece fora de banda por desenho.

Por isso, a transação precisa da versão da política e de sua vigência. O rótulo sozinho não informa quais provas eram obrigatórias, se havia várias aplicações, quais estados poderiam ser pulados nem como o vencedor seria escolhido.

A RFC 7848 define objetos de marca e marca assinada usados por mecanismos relacionados. Conforme fase e forma, a RFC 8334 transporta marca, objeto assinado, código ou aviso. São dados de proveniência, não alocação automática. Uma marca válida pode cumprir uma condição; um aviso pode provar uma interação; a política do registro ainda decide o resultado.

Também não se pode exigir todos os campos em toda forma. Antes de declarar uma lacuna, o auditor deve provar o que a fase, subfase, forma e política então vigentes exigiam. A especificação mínima coordena; a decisão local precisa ser identificável e responsabilizada.

O estado pendente precisa de ordem

Os estados incluem pendingValidation, validated, invalid, pendingAllocation, allocated, rejected e custom. Enquanto um estado de lançamento não é final, o objeto mantém pendingCreate. A política pode pular estados intermediários.

Guardar apenas o último rótulo perde quais avaliações ocorreram, quais foram omitidas legitimamente, quando o cliente foi informado e quanto tempo cada decisão levou.

A fila poll da RFC 5730 leva as mudanças assíncronas. Mensagens têm ID, são recuperadas e confirmadas. A RFC 8334 recomenda poll para mudanças intermediárias e exige o domain:panData da RFC 5731 para os finais allocated e rejected.

O histórico preserva ordem, ID da mensagem, entrada na fila, recebimento, confirmação, estado, aplicação e transações. Allocated prova a seleção da aplicação e permite o objeto de domínio. Rejected prova que ela não virou aquele registro. Silêncio, expiração ou busca pública vazia não equivalem a nenhum deles.

A existência e o conteúdo das aplicações podem ser confidenciais. Operações não autorizadas recebem 2201; uma visão pode ser filtrada. Ausência pública descreve a visão e suas permissões, não necessariamente a realidade do servidor.

A alocação abre novos testes

Após allocated, deve-se ler o objeto de domínio da RFC 5731. Em seguida, observar separadamente a publicação do registro ou RDAP, a delegação na zona pai, a resposta DNS autoritativa e o funcionamento do serviço.

Cada diferença aponta para um dono. Alocação sem objeto: provisionamento do registro. Objeto sem delegação: publicação da zona ou configuração do registrante. Delegação sem resposta: operação DNS. DNS correto sem serviço: aplicação, rede, certificado ou hospedagem.

Running-Code Primacy disciplina a conclusão: EPP comprova estado EPP; o readback do registro comprova seu objeto; RDAP comprova sua projeção; DNS comprova uma resposta em determinado ponto e instante; uma conexão comprova a observação de serviço. Nenhum recibo fala por todas as camadas.

A junção mínima

Uma decisão relevante deve reconstruir:

  1. IDs de transação, horário, cliente, domínio, endpoint e resultado;
  2. fase, subfase, forma, versão da política e procedimento de alocação;
  3. applicationID, pendingCreate, estado inicial e leitores autorizados;
  4. validador, marca, objeto assinado, código e aviso apenas quando aplicáveis;
  5. estados e poll ordenados, recebimentos, confirmações, saltos e exceções;
  6. domain:panData final allocated ou rejected;
  7. objeto RFC 5731 resultante se alocado;
  8. registro/RDAP, zona, DNS autoritativo e serviço como observações distintas;
  9. fundamento de confidencialidade, filtragem, retenção e dono da auditoria.

Essa cadeia permite comprovar aceitação sem transformá-la em alocação. O requerente preserva seu recibo; o registro explica a decisão; o validador delimita sua contribuição; operações localizam o atraso sem publicar material confidencial.

A RFC 8334 dá identidade, história e fechamento ao que ainda está pendente. O applicationID nomeia a espera, os estados e poll guardam o percurso, o panData registra o fim. Governança responsável é não achatar tudo em uma luz verde.

Fontes