Resumo

  • RFC 9953 recomenda ID DNS igual a 0 para que pedidos DoC equivalentes compartilhem uma Cache-Key do CoAP.
  • A resposta reaproveitada só é utilizável dentro da conta entre Max-Age e TTL DNS; ela não prova, sozinha, origem, validação, política ou efeito.

Um medidor acorda, pergunta por um nome e recebe uma representação de um proxy CoAP no caminho. A rádio transmite menos; a bateria agradece. O registro mais curto dirá que houve acerto de cache. O registro que realmente permite governar a automação precisa dizer mais: qual foi a pergunta, quanto daquela vida útil já passou, qual foi o RCODE DNS, que tipo de servidor respondeu a montante, como a resposta estava protegida e o que a regra local decidiu fazer com ela.

O RFC 9953, de março de 2026, define DNS over CoAP (DoC) para consultas DNS de OPCODE 0. Cada par consulta-resposta DNS é levado por uma operação de requisição-resposta CoAP. A consulta fica no corpo de um FETCH, e a mensagem DNS usa application/dns-message, Content-Format 553. É um desenho que aproveita recursos do CoAP em equipamentos restritos. Não é uma declaração de que o pacote externo carregue toda a autoridade do dado DNS.

O campo de ID foi reduzido justamente para tornar o objeto compartilhável. O cliente DoC SHOULD definir o ID do cabeçalho DNS como 0, evitando que consultas dos mesmos dados obtenham Cache-Keys diferentes apenas por IDs transacionais distintos. Um cache CoAP em rota pode então reutilizar a representação. O servidor DoC MUST copiar na resposta o ID que recebeu. O valor zero não é certificado, nome de autoridade, nem consentimento para automatizar. Ele remove uma diferença que atrapalharia o cache.

A contrapartida é uma regra de tempo obrigatória. O servidor DoC MUST garantir que Max-Age do CoAP mais cada TTL DNS na resposta seja menor ou igual ao TTL correspondente recebido a montante. Se o Max-Age não vier explícito, o valor padrão de 60 segundos também entra na conta. Ao receber, o cliente MUST somar o Max-Age aos TTLs DNS e trabalhar com os valores calculados. Portanto, o tempo retido pela camada CoAP e o tempo restante no conteúdo DNS não podem ser auditados como se fossem vidas independentes.

O algoritmo recomendado escolhe o menor TTL DNS como Max-Age e desconta esse valor de todos os TTLs no corpo. Assim um intermediário não deveria entregar sem querer um registro vencido, enquanto um ETag baseado no conteúdo pode continuar igual após a atualização do TTL em um cache ascendente. Erros que só merecem retenção breve podem receber Max-Age menor ou zero. A norma organiza a expiração; não transforma uma entrada retida em fato novo.

Há ainda duas leituras de status. Uma resposta DNS interpretável deve preferencialmente viajar em 2.05 Content, ainda que o próprio DNS carregue NXDOMAIN ou outro RCODE de falha. Código CoAP não bem-sucedido fica para erro da camada CoAP ou pedido incompatível com DoC. Quem mede apenas 2.05 pode ocultar falhas DNS. Quem publica apenas o RCODE pode apagar que o transporte e o cache funcionaram como previsto.

O servidor DoC pode ser autoritativo, stub ou recursivo e PODE atuar como validador DNSSEC para clientes restritos. (D)TLS ou OSCORE podem oferecer proteção à troca. Nada disso obriga toda resposta a ser validada por DNSSEC, resolve a política do dispositivo ou demonstra um resultado posterior. A leitura editorial de Daniel Kade, inspirada por Heng Lu, é simples: uma representação econômica não deve apropriar-se das provas que pertencem a outras camadas.

Fontes