comments on DS-12, section 2.2.1.2

[Edward Lewis <edlewis@arin.net>]

To the group - please scrutinize...In the spirit of "sending text":

#2.2.1.2 Special processing when child and an ancestor share server
#
#   When a child zone and a ancestor other than parent share an
#   authorative server, a DS aware server MUST answer with information
#   from child zone, as specified in section 2.2.1.1. This is to prevent
#   the server to be marked as lame for child.

Special rules are needed to permit DS RR aware servers to gracefully 
interact with older caches which otherwise might falsely label a 
server as lame because of the new placement of the DS RR set.

Such a situation might arise when a server is authoritative for both 
a zone and it's grandparent, but not the parent.  This sounds like an 
obscure example, but it is very real.  The root zone is currently 
served on 13 machines, and "root-servers.net." is served on 4 of the 
same 13, but "net." is served elsewhere.

When a server receives a query for (<QNAME>, DS, IN), the response 
MUST be determined from reading these rules in order:

1) If the server is authoritative for the zone that holds the DS RR 
set (i.e., the zone that delegates <QNAME> away, aka the "parent" 
zone), the response contains the DS RR set as an authoritative answer.

2) If the server is offering recursive service, the server performs 
the query itself (according to the rules for resolvers described 
below) and returns it's findings.

3) If the server is authoritative for the zone that holds the 
<QNAME>'s SOA RR set, the response is an authoritative negative 
answer as described in 2.2.1.1.

4) If the server is authoritative for a zone above the QNAME, a 
referral to a more enclosing zone's servers is made.

5) If the server is not authoritative for any part of the QNAME, a 
response indicating a lame server for QNAME is given.

[Editorial comment: notice the lack of RFC 2119 terms below this 
line.  I am not sure what to require, most of what I have written 
might be considered recommendations for finding the data.]

Using these rules will require some special processing on the part of 
a DS RR aware resolver.  To illustrate this, an example is used.

Assuming a server is authoritative for roots.example.net. and for the 
root zone but not the intervening two zones (or the intervening two 
label deep zone).  Assume that QNAME=roots.example.net., QTYPE=DS, 
and QCLASS=IN.

The resolver will issue this request (assuming no cached data) 
expecting a referral to a net. server.  Instead, rule number 3 above 
applies and a negative answer is returned by the server.  The 
reaction by the resolver is not to accept this answer as final as it 
can determine from the SOA RR in the negative answer the context 
within which the server has answered.

A solution to this is to instruct the resolver to hunt for the 
authoritative zone of the data in a brute force manner.

This can be accomplished by taking the owner name of the returned SOA 
RR and strip off enough left-hand labels until a successful NS 
response is obtained.  A successful response here means that the 
answer has NS records in it.  (Entertaining the possibility that a 
cut point may be two labels down in a zone.)

Returning to the example, the response will include a negative answer 
with either the SOA RR for "roots.example.net." or "example.net." 
depending on whether roots.example.net is a delegated domain.  In 
either case, removing the least significant label of the SOA owner 
name will lead to the location of the desired data.

#
#   This answer can cause problem for a DS aware resolver that is
#   traversing this branch of the DNS tree for the first time. The
#   resolver is expecting to get back either DS record or a delegation
#   information. The SOA with same name as QNAME informs the resolver
#   that the answer orignated from the zone below the one where the DS
#   resides. At this point the resolver has no information on how to get
#   from the ancestor to the parent. In this case the resolver SHOULD
#   attempt to fetch the delegation information by issuing a query with a
#   QNAME one label shorter and type NS. This will yield the NS set for
#   the parent, allowing the resolver to query for the DS record.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer


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