Resumo

  • Uma assinatura DNS Push aceita desloca a prova de atualidade: o TTL armazenado deixa de diminuir enquanto o servidor deve comunicar mudanças naquele RRset e naquela sessão DSO.
  • Encerrar a conexão elimina as assinaturas. Um handshake TLS retomado começa uma nova sessão sem estado Push; cada NAME, TYPE e CLASS precisa de novo SUBSCRIBE e novo estado inicial.
  • A evidência operacional une descoberta, identidade TLS, vida de DSO, resposta da assinatura, PUSH de inclusão/remoção, estado do relógio e teste separado do serviço.

Um canal verde e uma dívida encerrada

Considere uma sequência ilustrativa. Um cliente assina um RRset SRV e recebe no PUSH inicial um destino com TTL 120. Dez minutos depois, o operador retira o destino. Uma falha de caminho interrompe a conexão quase ao mesmo tempo. TLS é retomado com rapidez e o painel volta ao verde, mas o cliente não envia um novo SUBSCRIBE.

O servidor antigo já não deve a esse cliente uma mensagem de remoção: o fechamento terminou DSO e todas as assinaturas associadas. Se o cache mantiver o TTL congelado, transforma uma afirmação de dois minutos em permanência local ilimitada. A criptografia recuperou um canal; não recuperou a obrigação que justificava ignorar a passagem do tempo.

RFC 8765 separa os estados de forma explícita. TCP conectado, TLS retomado, DSO estabelecido e assinatura aceita não são sinônimos. Um sistema de observabilidade que os comprime em connected apaga justamente a fronteira que determina se o dado ainda pode ser chamado de atual.

A exceção ao envelhecimento

No cache DNS comum, a autoridade publica um TTL e o resolvedor o reduz. Depois de zero, outra consulta é necessária para renovar a informação. Para RRsets voláteis, polling frequente reduz o atraso de descoberta, porém desperdiça recursos sempre que nada mudou.

DNS Push mantém estado. O cliente solicita um NAME, TYPE e CLASS exatos. O servidor aceita ou rejeita cada assinatura de forma independente. Se o conjunto de respostas já for não vazio, o sucesso é seguido imediatamente por um PUSH inicial. Alterações posteriores chegam no fluxo ordenado TLS/TCP.

O cliente guarda o TTL de cada inclusão, mas não o decrementa enquanto houver assinatura relevante. A razão é contratual, não temporal: uma mudança no TTL gera atualização e o desaparecimento do registro deve gerar remoção. A zona não prolongou a vida do RR; o cliente passou a depender de uma obrigação ativa de entrega.

UNSUBSCRIBE encerra uma assinatura. Fechar DSO encerra todas. Nesse momento o envelhecimento recomeça a partir do TTL guardado, e o registro sai do cache quando chega a zero. Congelar e descongelar precisam ser eventos auditáveis, vinculados à identidade da sessão.

Descoberta e autenticação não cabem num único selo

O primeiro contato costuma ser o resolvedor configurado via DNS over TLS, porta 853. Ele pode manter uma assinatura a montante e repassar resultados. Quando isso não funciona, o serviço pode ser descoberto por _dns-push-tls._tcp.<zone>. O recibo deve guardar resposta, TTL, resultado DNSSEC, resolvedor e ponto de observação.

Strict Privacy é obrigatório. Ainda assim, TLS protege o peer definido pelas entradas usadas na autenticação; não corrige uma descoberta adulterada. Um SRV falso pode levar a uma conexão impecavelmente cifrada com o servidor errado. Por isso target, SNI, certificado ou TLSA e endereço efetivo permanecem campos separados.

Keepalive ou a própria solicitação Push estabelece DSO. SUBSCRIBE usa MESSAGE ID não zero e carrega um triplo. O RCODE da resposta cria ou rejeita aquela assinatura. Um servidor pode falar DSO sem Push, não ser autoridade para o nome, falhar ao assinar a montante ou recusar estado por capacidade. A conexão nunca equivale a admissão.

Mudanças válidas apenas no contexto certo

PUSH é unidirecional, parte do servidor e usa MESSAGE ID zero. TTL entre zero e 0x7FFFFFFF inclui um RR. 0xFFFFFFFF remove um RR individual. 0xFFFFFFFE, com RDATA vazio, remove coletivamente conforme TYPE e CLASS.

O cliente só aplica um registro se ele corresponder a uma assinatura ativa naquela sessão. Um PUSH que cruzou no caminho com UNSUBSCRIBE pode ser ignorado quando o interesse já terminou. Essa tolerância exige que a auditoria preserve o contexto; uma linha “RR removido” sem sessão e assinatura não prova que a mutação era autorizada.

O fluxo TCP ordena bytes dentro de uma conexão. Ele não fornece um cursor durável entre conexões, e o zero de PUSH não é número de sequência. Várias mudanças podem compartilhar uma mensagem. Depois da ruptura, continuidade só pode ser reconstruída com nova assinatura e novo estado inicial, nunca presumida.

Uma resposta SUBSCRIBE bem-sucedida também não prova conjunto não vazio. O PUSH inicial é obrigatório quando já existem respostas. O silêncio pode ser a representação correta de um conjunto vazio. Métricas devem conservar aceitação e conteúdo separadamente.

Keepalive e RECONFIRM não são oráculos

O intervalo Keepalive sustenta estado em NAT e firewall e testa conectividade. Uma assinatura ativa evita que a sessão seja considerada ociosa, mesmo sem mudanças. Isso não prova que a assinatura upstream continua, que nenhuma baixa se perdeu, que o cache aplicou tudo ou que o endpoint funciona.

RECONFIRM é útil com Discovery Proxy: um cliente que encontra um serviço aparentemente morto pode provocar novas consultas multicast; uma ausência confirmada leva a PUSH posteriores. Em outros servidores, o efeito é indefinido e NOERROR não obriga trabalho. Rotular a resposta como “dado validado” daria ao código mais autoridade do que o padrão concede.

Retomada sem herança

O ticket TLS reduz custo, mas o fechamento anterior extinguiu DSO. Após resumption, o servidor não conserva assinaturas e procede como em uma sessão nova. A sequência de recuperação registra: fim antigo; retorno do envelhecimento; nova conexão; handshake completo ou retomado; novo DSO; SUBSCRIBE para cada RRset; RCODE; estado inicial; só então novo congelamento.

SUBSCRIBE pode viajar em early data. O 0-RTT não oferece garantia geral contra replay entre conexões e não tem a mesma forward secrecy. Uma repetição pode criar estado temporário duplicado. Portanto o envio antecipado não é recibo de execução única; a resposta aceita na sessão real continua sendo o ponto de autoridade.

Se Push falha, polling é fallback explícito. RFC 8765 recomenda intervalo de pelo menos o menor entre 900 segundos e TTL mais dois segundos, tentando recuperar Push antes de cada consulta. O painel deve mostrar esse modo e sua idade; ocultá-lo sob “tempo real” elimina a informação decisória.

O que “atual” precisa provar

O dossiê registra descoberta e TTL, DNSSEC, target, SNI, peer e credencial; identifica conexão TCP, tipo de handshake, início/fim DSO, Keepalive, inactivity e Retry Delay. Para cada assinatura, guarda MESSAGE ID, NAME, TYPE, CLASS, bytes, RCODE e horário.

Para cada PUSH, guarda ordem, inclusão/remoção, RR, TTL armazenado, assinatura correspondente e decisão do cache. O fechamento distingue UNSUBSCRIBE, close_notify, FIN, timeout, reset e erro fatal. O aplicativo acrescenta consulta direta à autoridade e probe ao serviço.

Essas provas sustentam frases pequenas: canal autenticado; DSO vivo; assinatura aceita; RRset atual sob Push; resposta autoritativa observada; serviço alcançável. Nenhuma dessas frases deve substituir outra.

Coordenação fina, decisão local

O mínimo comum de Heng Lu aparece no wire: OPCODE, TLV, papéis, identidade da assinatura, temporizadores, segurança e encerramento. Orçamento de capacidade, retenção, UX, probes e rollback ficam com quem assume o risco. Um servidor pode limitar inscrições; um cliente pode mantê-las apenas enquanto existe demanda real.

Adesão voluntária não nasce da publicação do RFC nem do código IANA. Surge quando implementações interoperam e canários demonstram os estados. A primazia do código exige olhar o efeito: se o programa congela TTL depois de perder a obrigação que o autorizava, o comportamento executado é a prova da falha, não uma justificativa.

Fontes