Subject: comments on DS-12, section 2.2.1.2

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Jan 2003 11:52:43 -0500

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Mon, 13 Jan 2003 21:02:05 -0500

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

thank you, thank you

>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.

Much better than my text, will include in the document.

>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.

I do not think this is correct philosophically:
A server than performs authoritative service as well as recursive service,
should not switch back and forth between the two on a single query. It should
complete the rule set for authoritative service first and then switch to
the recursive service. Thus I would move rule 2 out of this list, and the 
rule is missing the condition that the query MUST have the RD bit set.

>4) If the server is authoritative for a zone above the QNAME, a referral 
>to a more enclosing zone's servers is made.
>
>[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.]

Most of the rules above are in the MUST category.
Rules 1 and 3 are needed in the DS document.
Rules 4 and 5 are standard DNS authoritative server rules and IMHO there is no
need to restate them.

>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.
>
>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.

One minor nit, the only reason SOA is needed in a negative answers along
with NXT is not confuse old resolvers, RFC3225 (DO bit) should have
eliminated the need to include the SOA. If only NXT is sent in the SOA
section then the singer name on the NXT reflects the zone where the
DS belongs in.

I will include this text or suggested successor in version 13 that will be 
submitted late Thursday (unless there is still debate going on about the
text).

         Olafur