Subject: [dnsext] Practical question about backwards compatibility and new proposals

From: Brian Dickson <[email-masked]>
Date: Thu, 16 Sep 2010 01:00:44 -0300

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

---

From: Andras Gustafsson <[email-masked]>
Date: Thu, 16 Sep 2010 10:19:47 +0300

> new RR type) something that is specified, one way or the other, anywhere

There was some discussion related to this last year, starting with

  http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02683.html

To reiterate what I said then, I think the concepts of "RRs of unknown
type" and "unexpected RRs appearing in some section of a message"
should be treated as orthogonal.  For example, a type MX record
occurring in the answer section of a response to a type A query is an
unexpected RR, but it is not of unknown type.

RFC 3597 deals with unknown types, but I don't think the treatment
of unexpected RRs is currently specified anywhere.  Existing
implementations tend to ignore them when they occur in the answer
section of a response, and may or may not cache them when they occur
in the additional section depending on spoofing defense strategy.

If we end up specifying the treatment of unexpected/unsolicited RRs,
I think whatever treatment we specify should be the same whether the
type is known or unknown.
-- 
Andreas Gustafsson, [email-masked]

---

From: Brian Dickson <[email-masked]>
Date: Fri, 17 Sep 2010 00:06:55 -0300

> type is known or unknown.

Excellent point.

This, and the discussion regarding DTLS in another thread, suggest that
(a) there is a problem with introducing new types, generally,
and (b) changing what should be expected is also a problem, particularly
for caches and middleboxes.

I think the gist of 3597-bis, and the discussion around it, is that changes
to what is "expected", introduce a potential security problem.

I think the answer comes from DNSSEC.

DNSSEC provides the means to validate RRsets, even if the type/class is not
known.
The signature algorithm is well defined, as is the proof mechanism, for
validating
from a known trust anchor.

This provides two paths through a middle box.

First is have the middle box validate the unexpected or unknown RR.

The second is to have the middle box not validate, but to only provide
cached
RRs that are unknown/unexpected, if the CD bit is set. In this case, CD
means
not only does the client do validation, but the client may understand better
than
the middle box, what the unexpected stuff is and how to deal with it.

In both cases, the end-to-end path from the authority server to the client
is authenticated,
which means that the security issue is no worse than, and probably better
than, the case
where the RR types are known and expected.

What do folks think?

Brian

---

From: Florian Weimer <[email-masked]>
Date: Fri, 17 Sep 2010 08:43:16 +0000

> in the additional section depending on spoofing defense strategy.

Quite apparently, implementations which do not implement DNSSECbis and
still set the DO bit in queries (because they implement DNSSEC) ignore
the RRSIG records in the answer, authority, and additional sections of
responses.  I don't think other RRs would receive different treatment,
provided that the DO bit is set in the query.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Andreas Gustafsson <[email-masked]>
Date: Fri, 17 Sep 2010 15:21:11 +0300

> provided that the DO bit is set in the query.

If I'm reading your message correctly, you seem to be agreeing with my
statement "implementations tend to ignore them when they occur in the
answer section" and with the "may not cache" part of "may or may not
cache them when they occur in the additional section".

To demonstrate that both the "may cache" and "may not cache" case
occurs in the wild, I have temporarily delegated the domain
unsolicited.additional.test.araneus.fi to an authoritative server that
responds to a type A query with an unexpected TXT record in the
additional section.

For example, when using the BIND 9 resolver in the OARC DNSSEC
testbed:

  dig unsolicited.additional.test.araneus.fi. A @149.20.64.20

the response does not contain this TXT record, but when using the
Unbound resolver in the same testbed:

  dig unsolicited.additional.test.araneus.fi. A @149.20.64.21

it does, and a second identical query will return a cached copy.
-- 
Andreas Gustafsson, [email-masked]