Subject: Re: comments on DS-12, section 2.2.1.2

From: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 25 Feb 2003 13:48:37 -0500

At 11:52 2003-01-02, Edward Lewis wrote:
>To the group - please scrutinize...In the spirit of "sending text":

thanks for the 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

s/,/and the RD bit is set in 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

s/zone/zone(s)/

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

Much better than my text, I have included this with the edits shown
above.

         Olafur

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