Resumo
- A RFC 8490 distingue transporte conectado de sessão DSO estabelecida; o estado começa com uma troca explícita bem-sucedida, não com a mera existência do socket.
- Um Primary TLV, IDs de mensagem, timers separados e Retry Delay tornam criação, manutenção e término atribuíveis.
- Keepalive comprova alcance do caminho, não a utilidade nem a autoridade continuada da operação retida.
O socket não recebeu mandato
O DNS clássico associa pergunta e resposta. TCP permite reaproveitar a conexão, mas não autoriza sozinho uma assinatura, uma atualização futura ou estado após a resposta. Continuidade do transporte não é autoridade da aplicação.
A RFC 8490, de março de 2019, foi escrita por Ray Bellis, Stuart Cheshire, John Dickinson, Sara Dickinson, Ted Lemon e Tom Pusateri. Ela define DNS Stateful Operations, DSO, no OPCODE 6 e atualiza as RFCs 1035 e 7766. Sua contribuição central é nomear um estado persistente que os dois participantes reconhecem.
Primeiro há apenas conexão. Fora de casos estreitos de early data, a sessão DSO nasce quando o cliente envia uma solicitação e recebe resposta bem-sucedida com o mesmo identificador. Se um servidor antigo silencia, não se presume aceitação. Depois do limite, a conexão é abortada e o cliente volta a um estado conhecido.
Uma operação principal por mensagem
DSO usa o cabeçalho DNS, mas leva operações em Type-Length-Value. Cada mensagem tem um Primary TLV. Ele define se há uma solicitação, com MESSAGE ID diferente de zero e resposta obrigatória, ou mensagem unidirecional, com ID zero e sem resposta.
Solicitações podem ser encadeadas e as respostas chegar fora de ordem, embora as ações sigam a ordem de recebimento. Primary TLV desconhecido recebe DSOTYPENI; TLV adicional desconhecido é ignorado. A extensão não exige fingir que significado desconhecido foi aceito.
Dois relógios para o silêncio
Uma conexão quieta pode ter sido abandonada ou manter assinatura válida à espera de mudança. Por isso a RFC separa inactivity timeout de keepalive interval.
O primeiro mede trabalho útil. Uma operação longa continua ativa até ser cancelada, ainda que não haja tráfego. O segundo testa alcance e pode conservar estado de NAT e firewall. O pulso mantém o caminho; não renova automaticamente a finalidade da operação.
Misturá-los derruba assinaturas silenciosas ou torna estado velho imortal. É necessário ver os dois timers e a operação pendente que justifica a memória.
Encerrar sem corrida de reconexão
Retry Delay permite ao servidor encerrar e indicar quanto esperar antes de voltar. Códigos distinguem reinício normal, formato fatal, falta de recursos e reconfiguração. Isso reduz tempestades após uma parada controlada.
Os sinais são limitados: SERVFAIL não expõe a causa interna da sobrecarga; REFUSED não comprova culpa ou retirada permanente. DSO exige transporte confiável e ordenado, DNS sobre TCP ou TLS. UDP não tem sessão; HTTPS gerencia a sua de outro modo.
A RFC 8765 usa DSO em DNS Push Notifications. O caso demonstra que o valor está no ciclo de vida compartilhado, não apenas numa conexão longa. O registro da IANA prova alocação de códigos, não adoção ou qualidade.
O trabalho de Ray Bellis aparece nas fronteiras: estabelecer, manter, silenciar, sobrecarregar, terminar e tentar de novo são eventos diferentes. Persistência deixa de ser autoridade invisível.
Fontes
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
