Dealing with the NS RRSet [Re: Why *can* cached DNS replies be overwritten?]

[Peter Koch <[e-mail]>]

On Tue, Aug 12, 2008 at 10:31:21AM +0200, Antoin Verschuren wrote:

> I actually like the simple behavior that an authoritative answer can override an already cached answer.
> It's efficient, and follows the simple rule that an authorative answer can be cached.

well, I had read your earlier comments slightly differently, especially
w.r.t. the "name server lock-in" problem.

> It only goes wrong if people don't maintain their DNS entries operationally, and forget to delete entries they are no longer authoritative for.

... or aren't informed or don't cooperate for other reasons. We know how to
gracefully migrate from one NS RRSet do another, even disjoint, one,
but we also know that this migration doesn't really happen that often
in today's mass hosting environments.  But can catch two birds with one
stone here, I believe:

Let's see what different flavors the forged responses can have:

-----------------------------------------------------------------------------
;; QUESTION SECTION:
;345678.example.org.		IN	A

;; ANSWER SECTION:
345678.example.org.        3600	IN	A	192.0.2.1

;; AUTHORITY SECTION:
example.org.               3600	IN	NS      ns1.example.org.
example.org.               3600	IN	NS	ns2.example.net.

;; ADDITIONAL SECTION:
ns1.example.org.           3600	IN	A	10.0.0.42
www.example.org.           3600	IN	A	192.0.2.80
-----------------------------------------------------------------------------

Unsolicited additional information should already be ignored and data
from the additional section shouldn't overwrite a (previous) authoritative
answer as per RFC 2181. 0 points.

-----------------------------------------------------------------------------
;; QUESTION SECTION:
;345678.example.org.		IN	A

;; ANSWER SECTION:
345678.example.org.        3600	IN	A	192.0.2.1

;; AUTHORITY SECTION:
example.org.               3600	IN	NS      www.example.org.
example.org.               3600	IN	NS	ns2.example.net.

;; ADDITIONAL SECTION:
www.example.org.           3600	IN	A	192.0.2.80
-----------------------------------------------------------------------------

The additional section data is logically justified, but RFC 2181 helps.
0 points.

-----------------------------------------------------------------------------
;; QUESTION SECTION:
;345678.example.org.		IN	A

;; ANSWER SECTION:
345678.example.org.        3600	IN	A	192.0.2.1

;; AUTHORITY SECTION:
example.org.               3600	IN	NS      evil1.example.net.
example.org.               3600	IN	NS      evil2.example.net.
-----------------------------------------------------------------------------

Now, to have gotten here, the resolver has already followed a referral.
In theory, the referral and the authoritative data are always in sync,
so there's no need to replace one with the other. In practice, though,
the authoritative NS RRSet is the more credible one.
Distinguish between a referral NS RRSet and an "authoritative" NS RRSet
(quotes because it stems from the authoritative source, but isn't
formally covered by the AA bit):  let the latter _only_ overwrite the
former.  This brings back the window of opportunity whose size is
determined by the TTL of the "authoritative" NS RRSet.

However, there's a remaining risk here at those levels where a positive
authoritative response does not normally occur under normal operations,
most prominently most of the TLDs.

-----------------------------------------------------------------------------
;; QUESTION SECTION:
;345678.example.org.		IN	A

;; ANSWER SECTION:
345678.example.org.        3600	IN	A	192.0.2.1

;; AUTHORITY SECTION:
example.org.               3600	IN	NS      345678.example.org.
-----------------------------------------------------------------------------

Same as above. It's the NS RRSet, not the address data.

> In the DNS hierarchy, you don't want every query to hit the root.
> My concern is that if records always expire, like Unbound does, parent nameservers are hit more.

Sure, but this is hard to predict. It depends on the relation of TTLs
between both NS RRSets as well as the TTLs of the authoritative NS RRSet
and the TTL of the data you're actually interested in.

But, isn't the phantom referral the really hard one:
-----------------------------------------------------------------------------
;; QUESTION SECTION:
;345678.www.example.org.		IN	A

;; AUTHORITY SECTION:
www.example.org.           3600	IN	NS      evil1.example.net.
www.example.org.           3600	IN	NS      evil2.example.net.
-----------------------------------------------------------------------------

What are mitigation techniques here?

o let the resolver remember the (potentially invisible) zone cut
o expire all RRSets atthe same owner at once (bad effect on the parent)
o really delegate at every level (have fun with IP6.ARPA and ENUM)
o ...

-Peter

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>