Resumo

  • A RFC 10037 define o membro opcional ttl0_data para objetos de domínio e servidor de nomes no RDAP.
  • O TTL publicado vem da configuração do registro, não da vida restante observada em uma consulta DNS.

Um número, duas perguntas diferentes

O RDAP já conseguia apresentar servidores de nomes, endereços de glue e registros DS associados a um domínio. Faltavam os TTLs desses RRsets. Esse parâmetro expressa intenção operacional: por quanto tempo um resolvedor pode reutilizar o conjunto antes de consultar novamente.

O objeto ttl0_data contém um mapa values, que relaciona mnemônicos de tipos DNS a valores TTL, e pode incluir observações do RDAP. O servidor decide se oferece o campo. Se o fizer, precisa anunciar ttl0 em rdapConformance.

A regra central trata da origem do valor. Ele deve refletir o TTL provisionado no banco do registro, não a contagem regressiva vista numa resposta DNS. Um valor de 3.600 diz que uma hora está registrada para o RRset. Não prova que todos os servidores autoritativos já servem esse valor, que todos os caches receberam a mudança ou que restam exatamente 3.600 segundos em algum cache.

Essa separação melhora o diagnóstico. Durante um incidente, é possível comparar configuração do registro, respostas autoritativas e estado do resolvedor recursivo. Uma divergência ajuda a localizar o problema entre provisionamento, publicação, propagação e cache. O RDAP fornece uma referência fora de banda; não vira monitoramento em tempo real.

A divulgação é opcional, o significado não

O registro mantém o poder de decidir se publica ttl0_data. Uma vez publicado, o formato é delimitado: os tipos devem estar registrados na IANA e em maiúsculas; o TTL pertence ao RRset; e o número JSON deve ser inteiro, sem fração ou expoente, entre zero e 2.147.483.647.

O padrão controla vocabulário, formato e sinal de conformidade. O registro controla divulgação e estado representado. O cliente controla o uso. Nenhuma dessas partes passa a controlar o DNS ao vivo apenas porque compartilha a configuração.

Registradores, titulares, provedores DNS e equipes de incidente ganham uma referência comum sem acesso privilegiado ao sistema interno. Mas a RFC não certifica a atualidade do banco, a autorização de uma mudança nem a igualdade entre banco e DNS publicado.

Extensibilidade cobra flexibilidade do cliente

Clientes precisam aceitar qualquer tipo DNS válido em values, inclusive tipos futuros. Frameworks que convertem JSON em classes fechadas podem rejeitar respostas corretas. Por isso, a especificação orienta separar esse mapa dinâmico e acompanhar o registro de tipos da IANA.

Publicação via RDAP também é separada do provisionamento EPP definido na RFC 9803. Um registro pode expor o valor sem implementar a extensão EPP. Ver o TTL não revela quem o escolheu, qual política o limitou ou quem pode alterá-lo. A RFC 10037 deixa essas questões fora de seu escopo.

Evidência, contrafactual e desconhecidos

Sem a extensão, o RDAP continuaria mostrando registros DNS relacionados, mas não os TTLs configurados pelo registro. Operadores dependeriam do DNS em serviço ou de canais próprios do registro, sem uma referência padronizada fora de banda. Esse é um contrafactual inferido das especificações, não um resultado medido.

As fontes primárias não informam quantos registros usam ttl0_data, se a extensão reduz a duração de incidentes, se a exposição é uniforme entre objetos ou se muda o comportamento de clientes e registros. Tampouco provam a exatidão de uma implementação específica num dado momento. Esses resultados permanecem desconhecidos.

Fontes