Resumo

  • O draft-skoglund-epp-registry-lock-00 propõe um fluxo EPP pendente no qual um ou mais contatos de bloqueio autorizam alterações em um domínio protegido antes de um prazo.
  • A política pode definir o número de aprovações e a resposta por poll pode identificar os contatos que aprovaram, mas o texto não padroniza prova de identidade, vínculo do desafio nem independência entre pessoas, canais e meios de recuperação.
  • Operadores precisam de um registro separado da cerimônia de aprovação, ligando estado anterior e posterior, política e contatos vigentes, domínios de controle, desafios, respostas, exceções, tempo e resultado final. Trata-se de uma proposta de governança, não de uma exigência do IETF.

O quórum exerce uma atração imediata porque oferece um número simples. Uma aprovação parece frágil; duas ou três sugerem separação de poder. A aparência pode enganar. Dois contatos cadastrados com endereços diferentes podem usar o mesmo tenant corporativo de e-mail, recuperar suas contas na mesma central de suporte e receber códigos em aparelhos administrados pela mesma equipe. O protocolo registra duas respostas. O atacante talvez só precise dominar uma infraestrutura administrativa.

Essa diferença é decisiva no bloqueio de registro. O serviço existe para domínios em que uma alteração indevida pode produzir efeitos muito além da recuperação de uma conta comum. Uma troca de servidores de nomes pode desviar tráfego e e-mail; uma mudança de titular pode deslocar o controle jurídico; uma transferência pode mover a relação operacional para outro registrador. O bloqueio no registro acrescenta uma instituição fora da trilha habitual de credenciais do registrador. Automatizar parte dessa defesa só é vantajoso se a automação preservar a independência que justificou a segunda instituição.

A versão 00 da proposta, draft-skoglund-epp-registry-lock-00, foi publicada em 30 de junho de 2026. O cabeçalho renderizado traz “Standards Track”, enquanto o Datatracker a classifica como Internet-Draft individual, sem stream, status RFC pretendido ou posição formal no processo de padronização do IETF. Ela deve ser lida como uma ideia em discussão, não como RFC nem como consenso estabelecido do grupo REGEXT.

O bloqueio abre um segundo plano de decisão

A proposta descreve o registry lock como uma proteção aplicada pelo registro, não apenas pelo registrador. Serviços desse tipo já existem, mas seguem procedimentos distintos e muitas vezes manuais. A extensão procura permitir que um cliente EPP patrocinador crie e administre um domínio bloqueado de modo mais automatizado.

Depois da ativação, o domínio deve portar serverDeleteProhibited. Enquanto uma transformação aguarda aprovação, deve portar serverPendingUpdate. A criação do bloqueio ou a atualização de um domínio bloqueado recebe o código EPP 1001: o comando foi aceito, mas depende de uma ação posterior. Uma autorização dentro do prazo gera uma mensagem de poll de sucesso; o esgotamento do prazo sem autorização produz uma mensagem de falha.

O significado operacional do comando muda. Enviar a solicitação não equivale mais a concluir a transição. O comando inaugura um episódio de autorização. Depois, o cliente precisa correlacionar um evento da fila com a ordem anterior, e as equipes não podem confundir “aceito e pendente” com “aplicado”.

Os dados de poll propostos ajudam nessa correlação. Eles identificam o domínio, a operação, um identificador de transação anterior do servidor e os IDs dos contatos registrados como aprovadores. A resposta externa também conserva os identificadores comuns de fila e transação do RFC 5730. Assim, início e conclusão podem ser ligados no plano protocolar. O intervalo decisório entre os dois, porém, continua quase invisível.

Contar pessoas não separa poderes

A política pode trazer um tempo-limite opcional e um número positivo, não nulo, de aprovações, grafado quorom na revisão 00. O servidor pode restringir os valores permitidos. Um domínio pode possuir vários contatos de bloqueio, e o número escolhido indica quantos precisam aprovar.

Esse número elimina uma ambiguidade útil: cliente e servidor não deveriam discordar secretamente sobre quantas respostas bastam. Mas ele não informa se os contatos são pessoas diferentes, se respondem a empregadores diferentes, se usam dispositivos separados ou se dependem de rotas de recuperação distintas. Três IDs podem terminar em uma única caixa compartilhada. Duas subsidiárias podem depender do mesmo provedor de identidade. Um fornecedor terceirizado pode administrar todos os telefones e tokens.

Multiplicidade e independência não são sinônimos. Multiplicidade é uma propriedade do cadastro: há várias linhas de contato. Independência é uma propriedade da arquitetura: uma única falha, coerção ou recuperação administrativa não consegue satisfazer todas as aprovações exigidas.

O protocolo não precisa resolver toda a governança corporativa. Ainda assim, um operador não deveria vender quorom=2 como integridade por duas pessoas se a cerimônia não impõe separação. A alegação requer, no mínimo, uma política declarada de independência e evidência de que as respostas concretas a cumpriram.

O nome do canal não mede a garantia

Cada contato de bloqueio possui um identificador e pode indicar um método de aprovação. A proposta oferece nomes conhecidos — e-mail, texto, carta, telefone e token — e permite que o servidor aceite outros.

Esses rótulos classificam meios de entrega, não níveis de garantia. “E-mail” não informa se houve link assinado, resposta simples, login em portal ou conversa com suporte. “Texto” não revela se o número foi verificado recentemente, se está protegido contra reatribuição ou se pertence à pessoa designada. “Token” pode ser um autenticador físico ou apenas um código encaminhável. “Telefone” não prova quem atendeu, e uma carta não demonstra muito sem destinatário e desafio registrados.

A extensão não normaliza o conteúdo do desafio, o vínculo com a alteração solicitada, a resistência a replay, o cadastramento do canal, a prova de identidade ou a recuperação da conta. Essa escolha pode ser razoável para um mapeamento EPP inicial: registros já operam modelos diferentes, e uma cerimônia universal poderia dificultar a adoção.

Mas a omissão limita o que o resultado comprova. Um ID em approvedBy mostra que o registro contabilizou uma aprovação segundo seu próprio processo. Não transforma todos os processos em equivalentes nem permite que o registrador conclua que houve resistência a uma falha compartilhada.

Congelar o contato fecha apenas uma rota

Enquanto um objeto de contato estiver associado como contato de bloqueio de um domínio protegido, a proposta exige rejeitar sua atualização e sua exclusão. Isso fecha um ataque óbvio: trocar e-mail ou telefone no objeto e aprovar logo depois pelo endpoint recém-inserido.

Ao mesmo tempo, a sintaxe de atualização do próprio bloqueio permite adicionar e remover contatos e alterar a política. Qualquer atualização no domínio bloqueado deve entrar no fluxo pendente, mas surge uma pergunta recursiva: quais autoridades antigas podem autorizar a mudança do conjunto que define as autoridades futuras?

Adicionar um terceiro aprovador não tem o mesmo efeito de trocar um servidor de nomes. Remover o único contato fora do sistema de identidade de uma empresa pode destruir a separação. Reduzir o quórum ou encurtar o prazo pode enfraquecer a cerimônia antes de uma mudança operacional posterior. Uma mensagem genérica de “atualização concluída” não necessariamente mostra qual política anterior legitimou a nova.

Por isso, o estado anterior precisa ser imutável para fins de decisão. A mudança do conjunto de autoridades deve ser avaliada sob a política e a lista de contatos vigentes quando o pedido começou, com regras expressas para saída, incapacidade ou indisponibilidade. Caso contrário, o fluxo se torna autoemendável exatamente quando mais precisa de continuidade.

As exceções delimitam a proteção real

Bloquear não significa impedir todo ato. A proposta permite a renovação e admite que o registro deixe o provisionamento automatizado de DNSSEC escapar da autorização, citando a leitura de CDSS ou CSYNC como exemplo. A remoção do bloqueio permanece um procedimento operacional manual, fora do escopo da especificação.

Há razões válidas para cada limite. Proibir a renovação poderia transformar uma proteção em risco de expiração. Automatizar DNSSEC pode evitar interrupções em trocas de chave. Manter a remoção fora de uma primeira versão automatizada pode preservar um rito emergencial mais forte.

Mesmo assim, cada exceção integra a política efetiva. Um domínio anunciado apenas como “bloqueado no registro” ainda pode sofrer alterações por meio de um scanner automatizado. A maior saída — retirar o bloqueio — é governada em outro lugar. O status EPP representa uma barreira com aberturas nomeadas, não uma imobilidade absoluta.

Uma exceção DNSSEC deveria registrar qual scanner iniciou a ação, quais registros ele observou, que regra autorizou a passagem e qual foi o estado anterior e posterior da delegação. Uma remoção manual deveria produzir evidência correlacionável com o histórico EPP. Sem isso, o caminho de maior poder pode acabar sendo o menos auditável por máquina.

Serviços existentes revelam a variedade escondida

O registro de extensões EPP da IANA já lista a Swedish Internet Foundation Registry Lock Extension como especificação ativa, não RFC, para .se e .nu. Essa presença documenta uma extensão operacional existente; não significa que o novo Internet-Draft individual tenha sido padronizado.

Na descrição pública da Internetstiftelsen, o registrador decide como verificar que o solicitante é o titular. Ele desbloqueia o domínio, executa a alteração e volta a bloqueá-lo de imediato ou após um período definido pelo próprio registrador. Assim, a verificação e o tempo de exposição dependem de escolhas operacionais do registrador.

A DENIC descreve outra cerimônia para .de. O titular nomeia um contato do lock. Quando chega um pedido de mudança pelo provedor, a DENIC envia um token ao celular armazenado e um e-mail ao endereço registrado. O pedido é recusado se não houver confirmação em sete dias corridos, e a DENIC examina separadamente pedidos de criação, modificação ou retirada do bloqueio e de alteração dos dados protegidos.

Nenhuma dessas descrições deve ser tomada como implementação da revisão 00. Elas funcionam como comparação. A mesma expressão, registry lock, abriga modelos diferentes de cadastramento, verificação, prazo, desbloqueio e novo bloqueio. Uma sintaxe EPP comum não apagará essas diferenças; tornará mais urgente declará-las.

Preservar o registro da cerimônia

Proponho um registro da cerimônia de aprovação para cada transformação pendente de bloqueio. É uma recomendação de governança de Daniel Kade, e não um conjunto de campos imposto pelo draft.

O registro começa com a mudança pedida: domínio, cliente patrocinador, sessão EPP autenticada, clTRID, svTRID, instante, operação e representação canônica do estado anterior e posterior. Conserva a política existente, o tempo-limite, o quórum, o conjunto de contatos e a versão da política. Uma atualização posterior não pode reescrever esse ponto de partida.

Para cada aprovador exigido, identifica a autoridade representada, o ID do contato, a data de cadastramento, o método e os domínios de controle relevantes: empregador ou autoridade beneficiária, provedor de identidade, tenant de e-mail, administração do dispositivo, conta telefônica, emissor do token e central de recuperação. Dados sensíveis podem aparecer como referências controladas ou identificadores pseudônimos estáveis, sem exposição pública.

O desafio liga um nonce ou digest à alteração exata, ao endpoint de entrega, aos horários de emissão e expiração, ao instante de resposta, ao resultado da validação e ao estado antirreplay. O histórico distingue ausência de resposta, negativa explícita e falha de verificação. A decisão final declara a regra de independência aplicada, quais aprovações contaram, quais foram excluídas, se houve exceção ou intervenção manual e quem autorizou o desvio.

A conclusão vincula a transação pendente original ao poll, ao resultado EPP, ao estado efetivamente aplicado e às notificações. Se uma automação DNSSEC contornar o quórum, o registro identifica a automação, a observação e a política. Se a remoção ocorrer fora do EPP, um identificador da cerimônia externa entra na mesma cronologia.

O objetivo não é publicar um dossiê sobre domínios protegidos. É manter uma narrativa durável, sob controle de acesso, que permita a titular, registrador e registro demonstrar algo além de uma soma de IDs. O quórum numérico responde quantas aprovações o servidor contou. A cerimônia responde se elas encarnavam a autoridade independente prometida pelo produto de segurança.

Fontes