[dns-operations] Reporting glue as authoritive data -- Bug!

[Edward Lewis]

At 13:15 +1100 1/29/08, Mark Andrews wrote:
>>  * Matt Larson:

>>  > Chapter and verse, please.  I believe this situation is not cut and

>	RFC 1034.
>
>    3. ...b. If a match would take us out of the authoritative data,
>             we have a referral.  This happens when we encounter a
>             node with NS RRs marking cuts along the bottom of a
>             zone.

But there's more

#            Copy the NS RRs for the subzone into the authority
#            section of the reply.  Put whatever addresses are
#            available into the additional section, using glue RRs
#            if the addresses are not available from authoritative
#            data or the cache.  Go to step 4.
#
#   4. Start matching down in the cache.  If QNAME is found in the
#      cache, copy all RRs attached to it that match QTYPE into the
#      answer section.  If there was no delegation from
#      authoritative data, look for the best one from the cache, and
#      put it in the authority section.  Go to step 6.

If you want to believe that other parts of 1034 disallow putting the 
glue into the answer section, I will argue that step 4 permits the 
action.  There is no restriction on the consideration of the 
provisioned glue as the seed of the server's cache.

I wholeheartedly agree with Matt, I too believe this situation is not 
cut and dry.

Recall we are talking about queries for a name server address 
matching the glue provisioned in the registry generating the zone. 
There are many queries that will get a canonical referral as 
described in 4b, but these particular queries can be argued to be 
covered by step 4.

>	RFC 2181 also has a retriction about promoting additional
>	records (glue) to the answer section.

I searched for "promo" - not found. I then searched for glue and 
found 8 mentions.

The first 4 were in the passage about trustworthiness.  The remaining 
are copied here:

#   Note that, glue excluded, it is impossible for data from two
#   correctly configured primary zone files, two correctly configured
#   secondary zones (data from zone transfers) or data from correctly
#   configured primary and secondary zones to ever conflict.  Where glue
#   for the same name exists in multiple zones, and differs in value, the
#   nameserver should select data from a primary zone file in preference
#   to secondary, but otherwise may choose any single set of such data.
#   Choosing that which appears to come from a source nearer the
#   authoritative data source may make sense where that can be
#   determined.  Choosing primary data over secondary allows the source
#   of incorrect glue data to be discovered more readily, when a problem
#   with such data exists.  Where a server can detect from two zone files
#   that one or more are incorrectly configured, so as to create
#   conflicts, it should refuse to load the zones determined to be
#   erroneous, and issue suitable diagnostics.
#
#   "Glue" above includes any record in a zone file that is not properly
#   part of that zone, including nameserver records of delegated sub-
#   zones (NS records), address records that accompany those NS records
#   (A, AAAA, etc), and any other stray data that might appear.

RFC 2181 recognizes that glue in conflict is a natural affliction of 
the DNS.  This sounds like "deal with it and treat it" rather than 
"ban it."


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20080129/a3b1a81c/attachment.html>