Summary

  • An individual Internet-Draft proposes that a nonvalidating recursive resolver clear the DNSSEC OK bit upstream when the incoming request has it clear.
  • A later proof-seeking client forces that resolver to recognize a proof-less cache entry and query the authoritative server again. Smaller first answers buy more cache states and some second trips.

The DNS resolver gets a small answer and files it away. A second customer asks for the cryptographic proof. The drawer has the answer, but the proof was never delivered. Now the resolver has to return to the authoritative server. That is the trade inside Clearing the DO bit for DNSSEC, submitted on 30 October by Warren Kumari, Geoff Huston and Peter Thomassen. It is an individual Internet-Draft, an idea for discussion rather than an adopted IETF rule.

The DO bit tells a DNS server whether to include DNSSEC records with its response. Under RFC 3225 and RFC 4035, a DNSSEC-aware recursive resolver sets DO on its outgoing query even if the client did not. The recursive server can then strip proofs before returning an answer to that client while retaining them in its cache. That default spends bytes on the authoritative leg to keep proof material available for later demand.

The draft suggests a different purchase. When the recursive resolver is not validating and the incoming query has DO clear, it should clear DO on the outgoing query. The authoritative server would omit automatic DNSSEC records. The motivation is post-quantum DNSSEC: larger future signatures could increase message sizes, truncation and TCP fallback. The draft gives no measured byte savings, deployment count or failure rate. Its claim is an engineering proposition, not an observed win.

The cache is where the proposition becomes a contract. The draft says a resolver that follows it must track which answers were obtained without DNSSEC records. If a validating stub or forwarded resolver later sends a DO-set request for such an entry, the recursive server must query the authority with DO set to retrieve the proof. A cache hit that ignores how the entry arrived would serve an apparently useful answer without the material the new client needs to validate it. The required second query may also shift traffic back to the authoritative side.

The early DNSOP discussion shows the competing design choice: use a smaller UDP answer where proofs are not requested, or move more DNS traffic to a stream transport that accommodates large answers. Both choices spend infrastructure capacity somewhere. The draft has not priced either route. A credible trial must show the cache behavior under both arrival orders, correct validation for the later client, and actual authoritative query and transport load. The missing evidence is a resolver implementation tested against both DO states with those measurements.

Internet-Draft · RFC 3225 · RFC 4035 · IETF DNSOP exchange