[dnsext] Practical question about backwards compatibility and new proposals

[Brian Dickson <[e-mail]>]

I'll try to keep this one brief...

In any proposal to modify some parts of the DNS, it may be desirable or even
necessary to introduce some new ways to answer old questions.

(E.g. DNAME causing answers with synthesized CNAMEs in addition to the DNAME
and post-rewrite answer. Extrapolate to other kinds of multi-answers, which
might included similarly synthesized CNAMEs.)

One issue is how to "propagate" answers involving combinations of known and
unknown types, through caches (and possibly other middle-boxes), to
new-type-aware clients.

RFC 3597 is about "handling" unknown RR types, but I presume that to be
rather narrow, in that the new RR type/class is the qtype/class, not
something that shows up in an answer as "extra stuff" in the answer, or in
the "additional" section.

Is this (caching of new RR types in answer to questions that *aren't* the
new RR type) something that is specified, one way or the other, anywhere
yet?

If not, it seems to be a show-stopper to backward compatibility as a general
thing, as opposed to very narrow built-in compatibility solutions. And thus
to forward compatibility, i.e. new RR types other than those of very narrow
scope.

In an ideal world, when a cache receives a bunch of RRsets that get returned
from an authority server, with suitable owner name(s), even if their type is
unknown, should be cached with the answer, and returned in answer to client
queries that match the original query that caused the cache to get populated
in the first place.

Then, largely, caches would be nearly completely future-proof, and it would
be feasible to introduce new RR types, sets of types, and even logic,
without having to worry as much about the caches.

I.e., if a query for qname "example.com" of type FOO, returns answers with
name "example.com", for type FOO, plus type BAR, and maybe an existing type,
and matching RRSIGs for the new types, caching the results as a "set of
sets" means subsequent queries for FOO/example.com can be answered from the
cache, just as if the query had been sent directly to the authority server.
So, without knowing the rules, a query for FOO, can return
FOO+BAR+stuff+RRSIGs, both the first time, primed by the authority server,
and subsequent times, based on cache look-up.

Obviously there are security considerations, e.g. bailiwick, but if the
records are not cached in the general cache, but rather only underneath the
specific name/qclass/qtype tuple, I think the security issues are largely
minimized...

Pointers? Thoughts? Suggestions?

Brian