Resumo

  • clientTransferProhibited e serverTransferProhibited têm efeito forte e delimitado na RFC 5731: pedidos de transferência do objeto de domínio devem ser rejeitados.
  • O prefixo revela qual lado controla o estado; não registra o fundamento da política, a autorização humana, o prazo de revisão nem a proteção do processo de liberação.
  • Uma decisão explicável une o recibo técnico, com fonte e tempo, a um recibo decisório separado; controles de conta, atualização, exclusão, renovação e DNS continuam independentes.

O bloqueio cumpre o que promete — e só isso

Não há motivo para tratar o status como enfeite. A RFC 5731 usa uma obrigação: diante de clientTransferProhibited ou serverTransferProhibited, o servidor precisa rejeitar a solicitação de transferência. É uma informação operacional importante sobre um verbo específico e o estado do objeto naquele momento.

O erro começa quando a interface amplia a frase. “Solicitado pelo titular”, “fraude detectada”, “registry lock” e “domínio seguro” podem aparecer como rótulos amigáveis, mas não estão embutidos no código. O protocolo descreve a consequência para o comando, não a história da decisão.

A RFC permite que o estado venha acompanhado de texto legível explicando a razão. Essa informação é opcional. Um objeto compatível pode não conter número do caso, instrução do titular, validade ou evidência de revisão recente. A falta desses dados não anula a rejeição. Ela mostra que o motivo precisa ser preservado em outro sistema.

Essa divisão favorece a interoperabilidade. Um predicado estreito é comparável entre servidores. Se um único token tivesse de carregar consentimento, identidade, contrato e cronograma, seu sentido dependeria de convenções locais invisíveis.

O prefixo aponta a porta de controle

Estados iniciados por client são adicionados ou removidos pelo cliente patrocinador, normalmente o registrador. Os iniciados por server ficam sob controle do servidor EPP, em geral o registro. O cliente não pode alterar um estado definido pelo servidor; o servidor pode alterar ou substituir um estado do cliente conforme a política local.

Essa gramática localiza o lado da relação, mas não a pessoa nem a regra que acionou a mudança. O registrador pode bloquear automaticamente um nome novo, obedecer a uma solicitação do titular, refletir um período obrigatório ou responder a um problema na conta. O registro pode impor sua proibição em uma disputa, durante redenção, por solicitação do titular ou como parte de outro procedimento.

A orientação da ICANN para registrantes transforma essa separação em um caminho prático. Códigos client são definidos pelo registrador; códigos server, pelo registro. Para remover o primeiro, o titular procura o registrador. Para remover o segundo, o registrador pode precisar trabalhar com o registro, e a liberação pode demorar mais. Saber a quem recorrer não equivale a saber por que o caso existe.

A razão pertence ao processo de política

Dentro do seu alcance, a Política de Transferência da ICANN descreve decisões que a RFC 5731 não tenta codificar. Ela distingue a autoridade do titular, o envio do pedido pelo registrador receptor, as obrigações do registrador atual e as situações em que uma negativa é permitida e precisa ser explicada.

Essas situações não contam a mesma história. Evidência de fraude difere de uma controvérsia razoável sobre a identidade do titular. Um caso de inadimplência previsto pela política difere de uma objeção expressa. Ordem judicial, procedimento de disputa, registro ou transferência recentes e o bloqueio de sessenta dias após mudança de titular têm fundamentos e relógios próprios.

A política também impede que “Registrar Lock” vire justificativa automática. O estado, sozinho, não sustenta a recusa quando o titular não recebeu oportunidade e capacidade razoáveis de desbloquear antes do pedido. Uma objeção geral do titular exige consentimento expresso e informado, além de uma forma acessível de remover a restrição quando solicitado.

Assim, o status executa o resultado atual; o registro da política explica sua legitimidade e sua saída. O primeiro recibo deve conter o domínio, o valor exato, a fonte, o horário e o estado sucessor. O segundo deve conter a norma ou contrato, quem solicitou ou impôs, a prova de autoridade, a vigência, a revisão ou expiração, a notificação e o caminho de liberação.

Três relógios podem produzir uma tela enganosa

O servidor marca quando a proibição entrou no estado EPP autorizado. O processo decisório marca quando o fundamento começou e quando deve ser revisto. RDAP, Whois, o portal e o monitor externo marcam apenas quando recuperaram e exibiram uma observação.

Uma resposta pública pode estar em cache. O portal pode manter um selo depois da alteração interna. A base jurídica pode vencer antes da remoção técnica, ou o servidor pode liberar antes da atualização do agregador. A captura de tela prova uma apresentação em certo momento; não prova automaticamente o valor atual, o ator que o definiu ou o motivo.

Há um teste de coerência particularmente útil na RFC 5731. pendingTransfer não pode coexistir com nenhuma das proibições de transferência. O primeiro diz que uma ação foi processada e ainda não terminou; a proibição exige rejeitar a solicitação. Quando os dois aparecem juntos, a investigação deve começar por horários, cache, mistura de fontes e transformação de interface. A inconsistência exige reconstrução, não uma acusação imediata de fraude ou de não conformidade.

“Bloqueado” não é sinônimo de “imutável”

A linguagem cotidiana faz o bloqueio parecer total. O EPP separa proibições de transferência, atualização, exclusão e renovação porque cada verbo tem alcance próprio. Estados hold tratam da publicação da delegação no DNS. Impedir transferência não prova que contatos não possam ser modificados, que o nome não possa ser excluído ou que a conta do registrador esteja protegida.

Se um invasor assume essa conta, pode tentar remover um estado client. No sentido inverso, um produto comercial de registry lock pode acrescentar ligação fora de banda, duas aprovações, credencial separada e espera obrigatória. Esses controles merecem crédito quando contrato e operação os demonstram; o nome do estado EPP não os cria.

A própria orientação de segurança da ICANN apresenta o transfer lock como camada adicional, não proteção infalível. Ela recomenda separadamente cuidar das informações da conta e considerar autenticação em várias etapas. Uma avaliação completa registra, cada qual em seu plano, acesso, privilégios, authInfo, atualização, exclusão, DNS, renovação e contatos de recuperação.

A atribuição de Hollenbeck também tem alcance

Scott Hollenbeck é o autor indicado nas RFCs 5730 e 5731. O perfil público do IETF registra participação desde meados dos anos 1990, presidência de vários grupos de trabalho e atuação como Applications Area Director de 2004 a 2006. A página atual lista 39 RFCs.

Isso comprova uma contribuição extensa aos padrões. Não torna Hollenbeck operador de registro, autor da política de um caso particular ou controlador de um domínio. Seu nome pertence à proveniência da especificação. O registrador ou registro responsável pertence à proveniência da mudança. Delimitar ambos preserva contribuição e responsabilidade.

Um dossiê que responde sem expor segredos

O conjunto mínimo liga estado exato, fonte, tempo, próximo estado e identificadores de consulta ou transação disponíveis. Em seguida associa, sem misturar, a versão da política, solicitante, função responsável, evidência de autoridade, período, revisão, avisos, exceções e liberação. Se houve tentativa de transferência, guarda horário, tratamento da autorização, resposta do servidor, estado pendente, motivo comunicado e desfecho.

Senhas, códigos de autorização e dados pessoais desnecessários não devem ser publicados. A cadeia de proveniência que permite a um auditor autorizado diferenciar proteção legítima, erro, disputa e invasão precisa permanecer disponível.

O melhor contraponto é verdadeiro: a proibição protege. Num estado conforme, ela bloqueia a transferência. Bloqueios padrão e serviços de registro bem operados podem aumentar muito a resistência ao sequestro do nome. O equívoco não é confiar no protocolo, mas exigir que ele confirme decisões fora do seu campo.

O mapeamento de Hollenbeck entrega uma frase rigorosa: rejeite este comando. A organização que impôs o status deve completar a explicação: quem decidiu, sob qual autoridade, por quanto tempo e por qual saída. O bloqueio impede o movimento; só evidência atribuível explica a medida.

Fontes