[dns-operations] Reporting glue as authoritive data -- Bug!
Ed.Lewis at neustar.biz
Tue Jan 29 16:18:28 UTC 2008
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
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
Edward Lewis +1-571-434-5468
Think glocally. Act confused.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dns-operations