Resumo

  • O valor enviado numa solicitação RFC 9664 é desejado; a resposta bem-sucedida traz em LEASE e KEY-LEASE os prazos efetivamente concedidos pelo servidor autoritativo.
  • O vencimento limita a publicação na autoridade, mas não comprova serviço ativo, convergência entre servidores nem o desaparecimento imediato de respostas em cache.

Considere uma inscrição ilustrativa. Um dispositivo pede 30 minutos para seus registros de serviço. A autenticação e os pré-requisitos de DNS UPDATE passam, mas a resposta concede quatro horas. Depois de vinte minutos, o dispositivo desliga sem remover os registros e sem renovar.

O DNS pode continuar respondendo corretamente segundo o contrato de tempo, apesar de o destino já não aceitar conexão alguma. O exemplo não descreve uma ocorrência real nem um padrão de produto. Ele mostra a regra decisiva da RFC 9664: o pedido expressa preferência; a resposta define a concessão, que pode ser menor, igual ou maior.

A mesma troca não responde a todas as perguntas

Update Lease é uma opção EDNS(0) dentro do DNS UPDATE da RFC 2136. A operação ainda carrega Zone, Prerequisite, Update e Additional Data, e continua atômica. A aceitação diz se uma identidade pode aplicar aquela mudança ao estado atual da zona.

O arrendamento acrescenta outra decisão: até quando o servidor publicará os RR aceitos se não chegar uma renovação. A terceira decisão, se o serviço está operacional, pertence a uma sonda de rede ou aplicação.

TSIG e SIG(0) podem autenticar a transação. A política pode limitar uma chave a nomes e tipos de RR. Esses mecanismos não observam o processo, a porta, a rota ou uma transação real do usuário. Uma inscrição assinada para um serviço morto continua sendo uma inscrição para um serviço morto.

A trilha de evidências precisa guardar as quatro seções da mensagem, a identidade TSIG ou SIG(0), a autorização aplicada, o formato da opção, os valores pedidos, o RCODE e os valores retornados. “Lease OK” não informa quem concedeu quanto tempo.

Quatro ou oito bytes mudam a custódia do nome

A forma de quatro bytes traz apenas LEASE, um inteiro sem sinal de 32 bits aplicado a todos os RR da seção Update, inclusive KEY. A forma de oito bytes acrescenta KEY-LEASE: RR comuns seguem o primeiro prazo e KEY segue o segundo.

No Service Registration Protocol da RFC 9665, essa separação permite que os registros de descoberta expirem enquanto a KEY continua reservando o nome para o mesmo detentor criptográfico. O nome permanece protegido contra apropriação imediata, mas o serviço não permanece anunciado.

A compatibilidade com implementações antigas pode unificar os dois prazos. Um servidor que recebe quatro bytes deve usar o mesmo valor para ambos. Um solicitante que enviou oito e recebeu quatro também deve aplicar o único valor retornado às duas classes. O que vale é o fio, não a intenção da configuração.

Remoção explícita tem semântica própria: RR retirados pela atualização são removidos permanentemente, sem esperar o vencimento.

A resposta inicia o cronograma operacional

Um servidor compatível deve devolver a opção numa resposta bem-sucedida à solicitação que a continha. O cliente agenda a renovação em 80% do prazo concedido, somando um deslocamento aleatório de 0% a 5%. A dispersão evita uma tempestade de renovações e mantém cerca de 15% a 20% para retransmitir.

Um timer local não prova que houve extensão. É necessário registrar o deslocamento, o horário, os envios, a resposta autenticada e a nova concessão.

Se a resposta vier sem Update Lease, a RFC indica que o servidor não dá suporte. O solicitante deve continuar renovando como se o valor pedido tivesse voltado. Isso preserva compatibilidade do lado cliente; não comprova coleta automática no servidor. O estado correto é “renovação de compatibilidade ativa; expiração no servidor não comprovada”.

Registration e Refresh também são diferentes. Uma Registration introduz informação considerada ausente. Refresh prolonga o estado sem alterá-lo. Se o servidor perdeu dados num reinício, um Refresh pode recriar os RR e passar a mudar a zona, exigindo atualização do serial. Quando não há mudança de conteúdo, a simples renovação não pode incrementar o serial.

Um registro pode vencer e ainda aparecer

Sem renovação, ao fim do prazo o servidor não pode mais devolver o RR. Ele pode apagar a linha armazenada, mas não é obrigado. Estado de consulta e estado físico são evidências distintas.

O TTL rege outra camada. Um resolvedor que obteve a resposta pouco antes do vencimento pode reutilizá-la até consumir o TTL restante. A autoridade não consegue recolher essa cópia. Em sentido inverso, TTL curto não encurta o arrendamento mantido na autoridade.

É preciso separar o fim concedido, a janela de renovação, a mudança de zona e sua passagem por assinador/secundários, e o TTL observado por cada cache. Se o registrador for um primário oculto, sua tabela não prova o que cada autoridade pública ou local anycast responde.

Por fim, disponibilidade exige uma conexão real ao endereço, à porta e ao protocolo anunciados.

Limites são política local

Prazos longos demais deixam dados obsoletos quase permanentes. Prazos curtos demais elevam carga e fazem um atraso comum remover um registro válido. A RFC 9664 recomenda máximos padrão de 24 horas para LEASE e sete dias para KEY-LEASE; recomenda mínimo padrão de 30 segundos e observa que, na maioria dos casos, uma hora ou mais é preferível. O operador pode ajustar esses valores.

Eles não são direito do solicitante nem meta universal. A política do servidor deve ser explícita, versionada e observável. As chaves também precisam de autoridade limitada: o vencimento reduz a persistência de uma alteração, mas não torna segura uma credencial capaz de reescrever a zona inteira.

Fontes