one approach to handling DS

[Edward Lewis <edlewis@arin.net>]

The DS RR as defined changes what elements determine the 
authoritative zone for data.  E.g., pre-DS, the authoritative zone 
for (QNAME, QTYPE, QCLASS) was a function of (QNAME,QCLASS).[0]  The 
DS RR makes the function need the QTYPE also.  This fundamental 
change is the reason that we are having backwards compatibility 
problems with the DS RR.

This is a situation that we discussed at the pre-55 workshop and a 
proposed set of requirements for a solution.

Given a DS-aware resolver trying to get (a.b.c., DS, IN), with a 
caching server in the path between the resolver and the authoritative 
servers, what happens when the cache is either DS aware/non-aware, 
and what happens when the authoritative servers are DS 
aware/non-aware?  (Assume that the resolver cannot pass packets to 
the auth srvrs directly.  I.e., the cache is part of a, say, proxy 
firewall.)

A couple of notes in the case diagrams:
   DS in upper left means the box is DS aware. (No DS, not aware.)
   In all cases, the cache holds (abc NS IN) but not (abc DS IN).
   abc is really a.b.c., bc is b.c., and c is c.
   All zones are one label deep.
   The only query ever issued is for (abc DS IN).
   The two auth srvrs are "upper srvr" and "lower srvr" referring to the
      position in the ASCII-art.

Case 1. (Everything is DS aware.)

     resolver              cache                         auth srvrs
     ---------             ----------------              -----------
     |DS     |             |DS            |              |DS       |
     |       |------------>| knows abc NS |------------->| auth c  |
     |       |             |              |--            | auth abc|
     ---------             ----------------  \           -----------
                                              \
                                               \         -----------
                                                -------->|DS       |
                                                         | auth bc |
                                                         -----------

In this case, the cache realizes that the abc NS is not helpful in 
finding the DS record.  So it asks the c zone (upper srvr), half 
expecting a referral to bc.  The proper response from the upper srvr 
is a delegation to the bc zone, at the lower srvr.  The lower srvr 
will answer (positively or negatively).

Everything is good - because all the elements are aware that the DS 
resides at the parent.  The important thought here is that the upper 
srvr responds with a referral - in case 3 this would be a problem.

Case 2. The lower srvr is not DS aware.

     resolver              cache                         auth srvrs
     ---------             ----------------              -----------
     |DS     |             |DS            |              |DS       |
     |       |------------>| knows abc NS |------------->| auth c  |
     |       |             |              |--            | auth abc|
     ---------             ----------------  \           -----------
                                              \
                                               \         -----------
                                                -------->|         |
                                                         | auth bc |
                                                         -----------

Again, the cache realizes that the abc NS is not helpful in finding 
the DS record.  So the the cache asks the lower srvr, the lower srvr 
will respond with a referral to the abc zone because the old logic is 
that anything in abc will be found at an abc server.

In this case, the cache has to exercise its awareness of DS and 
conclude that the lower srvr is "DS-lame" and declare that the proper 
answer is "no data" to the resolver.  Unlike DNS lameness, DS 
lameness means that the DS does not exist, not that there is a 
misconfiguration.

Requirement #1.  DS aware resolvers have to be cognizant of DS-lame servers.

Case 3. Only the cache is DS non-aware.

     resolver              cache                         auth srvrs
     ---------             ----------------              -----------
     |DS     |             |              |              |DS       |
     |       |------------>| knows abc NS |------------->| auth c  |
     |       |             |              |--            | auth abc|
     ---------             ----------------  \           -----------
                                              \
                                               \         -----------
                                                -------->|DS       |
                                                         | auth bc |
                                                         -----------

In this case the cache uses the old logic to conclude that the abc NS 
will lead to the DS record.  A query will be sent to the upper srvr 
in the expectation that an authoritative answer from abc will be sent 
back.

In case 1, the same query is sent and the conclusion there was that a 
referral was the right thing to return.  With a DS non-aware cache, 
however, this will result in the cache marking the upper srvr lame 
and not ask it for any data pertaining to abc (even when it should).

With an unaware cache, the upper srvr should return with a no data 
answer.  The problem is how can the upper srvr determine whether the 
cache is aware or not.

A secondary problem is that answering with no data may be misleading. 
It could be that there is a DS at bc, but the cache will not ask that 
server because it holds the wrong zone under the old rules.

There are two requirements that arise here.

Requirement #2.  There is a need for the answering server to know 
whether the querier is DS aware.  In case 1, the correct answer (from 
the upper srvr) is a referral and in case 3, the correct answer is an 
authoritative no-data.  The difference between case 1 and case 3 is 
that the cache is DS aware in 1, and unaware in 3.

Requirement #3.  There is a need for the resolver to know whether the 
server is DS aware.  When the DS unaware cache answers with "no data" 
to the query for the DS, the resolver has to realize that the cache 
is likely (or possibly) saying this because it just didn't ask the 
right place.

Summary.

To address these requirements, the following is suggested:

1) Inclusion in the DS RR definition rules for detecting DS lameness.

2) An indication in the query that the querier is DS aware, with 
rules at the responder to "copy on reply" if the responder is DS 
aware.  Specifically, adding a DS-aware bit "EDNS0 DA bit" in 
addition to the DNSSEC OK bit.

3) When a DS aware querier detects that it is getting data from a DS 
unaware responder, the querier must "hard fail."  The querier should 
either move to the next possible server or give up on getting a 
secured response.

Problems with this.

#0 Should we bother trying to solve this?  (Quoting Wes Griffin:) Do 
we want to solve the "clear path" problem by working around old 
software, or do we just want to fully break old software?  (Clear 
path referring to the idea of having just DS aware elements in the 
path from end to end.)

#1 This gets a bit further down the road of the querier/responder 
negotiating a level of service in the DNS protocol.  This isn't a 
good thing.

#2 This solution does not assure that the DS aware resolver can ever 
get the needed DS records to achieve the higher grade of security.

Alternatives -

The name/label hack.  Putting the DS record at another name in the 
DNS - means that we either increase the number of queries needed 
(e.g., asking for arin.net and then arin.ds.net while descending the 
tree) or will require extra processing on the server (while getting 
arin.net, also put arin.ds.net into the response).  Another problem 
is the how resolvers will attach a credibility to the data that 
arrives outside the normal query (will arin.ds.net records have any 
credibility if the query is for arin.net and no CNAME in the response 
points to arin.ds.net?)

[0] Yes, the upper NXT is an exception, but there is a lower NXT at 
the legacy answer.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer