Resumo

  • RFC 5144 define DCHK como um serviço leve baseado em IRIS e no subconjunto de DREG.
  • active e inactive descrevem publicação no DNS, não disponibilidade contratual para registro.
  • reserved pode impedir o registro normal mesmo quando não há publicação DNS.
  • Disputa e períodos de carência preservam estados que um indicador binário apaga.
  • Criar, excluir, renovar, restaurar, transferir e atualizar pode estar pending ou prohibited.
  • Ator, escopo e autoridade do substatus delimitam a origem da afirmação.
  • Data da base de origem, hora da resposta e hora da decisão são relógios diferentes.
  • Uma referência de registro aponta para outro serviço, mas não leva consigo aprovação.
  • A camada XML de IRIS depende do transporte para autenticação e privacidade.
  • Registros da IANA comprovam identificadores atribuídos, não implantação em produção.
  • A dependência de Nameprep expõe uma fronteira de compatibilidade com IDNA2008.
  • Liderança deve exigir recibos separados para consulta, política, mutação e DNS.

Compressão que muda o sentido

O tipo de status de DCHK aceita uma data de aplicação, um ou mais chamados de serviço, descrições em linguagem natural e um substatus. O substatus pode ser definido fora da RFC, mas precisa declarar a autoridade que o especificou. Há ainda actor, que distingue registry, registrar e registrationServiceProvider; scope, que informa o contexto; e disposition, que pode ser pending ou prohibited.

Remover esses campos não é uma simplificação neutra. “Transfer pending no registrador” vira “domínio transferido”. “Proibido por uma política local” vira “impossível em qualquer lugar”. Uma divergência investigável vira um erro sem dono.

O chamado é especialmente importante porque reconecta o dado público à decisão operacional. Sem ele, a equipe vê o resultado, mas não consegue recuperar a revisão humana, a exceção de política ou o evento que o produziu. O painel fica bonito justamente porque destruiu o caminho de auditoria.

DNS ativo não quer dizer registro disponível

Em RFC 5144, active significa disponível via DNS, por delegação ou publicação direta. inactive significa indisponível via DNS. A palavra “disponível” pertence aqui ao plano de publicação, não ao plano comercial.

O estado reserved existe para dizer que o nome não pode ser obtido pelos procedimentos normais. Um nome pode estar inativo no DNS e reservado. Também pode estar em disputa ou em carência após criação, renovação, renovação automática, transferência ou exclusão.

RFC 3915 mostra por que isso importa. Depois de uma exclusão, um domínio pode permanecer em redemptionPeriod, passar por restauração pendente ou seguir para exclusão pendente. A possibilidade de novo registro aparece ao fim das transições relevantes, não no instante em que o DNS deixa de responder.

Estados de operação também não são recibos de conclusão. DCHK permite create, delete, renew, restore, transfer e update, normalmente refinados por pending ou prohibited. RFC 5731, no contexto de EPP, chama o check de “dica” para antecipar o create, pois os requisitos finais pertencem à política do servidor. Uma transformação processada pode continuar pendente.

A resposta rápida pode carregar um passado lento

lastDatabaseUpdateDateTime registra a última atualização da base que originou o resultado. Não registra a chegada da resposta nem o clique do usuário. Um serviço de baixa latência pode distribuir dados antigos com eficiência impecável.

Por isso, o recibo precisa guardar quatro tempos: estado da fonte, resposta, cache e decisão. Quando uma operação é enviada, surge um quinto. Misturá-los em um único campo impede distinguir atraso de replicação, mudança de política e corrida entre solicitantes.

A referência de registro acrescenta outra fronteira. Ela pode conduzir do registry ao registrar ou ao serviço do registrante. IRIS também permite referências e continuações entre instâncias, alertando para loops. Chegar ao destino comprova navegação, não identidade, saldo, elegibilidade ou aceitação da operação.

Segurança da sessão e autoridade da decisão

RFC 3981 afirma que a camada XML de IRIS não oferece sozinha autenticação ou privacidade; depende do transporte. RFC 5144 exige IRIS-LWZ e torna XPC e BEEP opcionais. Mesmo uma sessão autenticada não atualiza a base, não amplia o escopo do status e não autoriza o solicitante.

A IANA ainda lista dchk1, DCHK1 e o perfil BEEP. RFC 5144 continua Proposed Standard. O erratum verificado corrige apenas a grafia de “Straightforward-NAPTR”. Nenhum desses fatos mede servidores ativos, tráfego ou taxa de acerto.

O campo IDN remete a Nameprep, RFC 3491, hoje obsoleta. RFC 5891 define IDNA2008. Isso não prova que RFC 5144 foi formalmente substituída, mas impede tratar a antiga normalização como garantia de compatibilidade com políticas atuais. RFC 9083 serve como comparação de um modelo posterior de respostas RDAP, não como prova de sucessão formal.

Uma cadeia de recibos, não um veredito precoce

Primeiro, preservar consulta, normalização, autoridade, versão e resposta integral. Depois, idade da fonte, todos os estados, ator, escopo, disposição, chamado e autoridade do substatus. Em seguida, registrar separadamente o destino da referência.

Só então entram identidade e elegibilidade do solicitante, política e preço, envio e aceitação do comando, revisão pendente, mutação confirmada, publicação DNS e serviço observado. Cada recibo abre a próxima verificação. Nenhum deve vestir a autoridade do seguinte.

Fontes

  1. RFC 5144, HTML
  2. RFC 5144, texto
  3. Registro do RFC Editor
  4. Registro do IETF Datatracker
  5. Histórico do documento
  6. Pesquisa de errata
  7. Versão com errata verificada
  8. Registro XML da IANA
  9. Parâmetros S-NAPTR da IANA
  10. Parâmetros BEEP da IANA
  11. RFC 3981: núcleo IRIS
  12. RFC 3982: registro de domínios IRIS
  13. RFC 3983: IRIS sobre BEEP
  14. RFC 4992: pipeline XML para IRIS
  15. RFC 4993: transporte UDP leve para IRIS
  16. RFC 3915: carências no EPP
  17. RFC 5731: mapeamento de domínio no EPP
  18. RFC 3491: Nameprep
  19. RFC 5891: IDNA2008
  20. RFC 9083: respostas JSON do RDAP
  21. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  22. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  23. Running-Code Primacy