<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [dns-operations] Reporting glue as authoritive
data --</title></head><body>
<div>At 13:15 +1100 1/29/08, Mark Andrews wrote:</div>
<div>>> * Matt Larson:</div>
<div><br></div>
<div>>> > Chapter and verse, please. I believe this
situation is not cut and</div>
<div><br></div>
<div>><x-tab> </x-tab>RFC
1034.<br>
></div>
<div>> 3. ...b. If a match would take us out of the
authoritative data,</div>
<div>>
we have a referral. This happens when we encounter a<br>
>
node with NS RRs marking cuts along the bottom of a</div>
<div>>
zone.<br>
</div>
<div>But there's more</div>
<div><br></div>
<div>#
Copy the NS RRs for the subzone into the authority<br>
#
section of the reply. Put whatever addresses are<br>
#
available into the additional section, using glue RRs<br>
# if
the addresses are not available from authoritative<br>
#
data or the cache. Go to step 4.<br>
#</div>
<div># 4. Start matching down in the cache. If QNAME
is found in the<br>
# cache, copy all RRs attached to it
that match QTYPE into the<br>
# answer section. If there was no
delegation from<br>
# authoritative data, look for the best
one from the cache, and</div>
<div># put it in the authority section.
Go to step 6.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>I wholeheartedly agree with Matt, I too believe this situation is
not cut and dry.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>><x-tab> </x-tab>RFC 2181
also has a retriction about promoting additional</div>
<div>><x-tab> </x-tab>records
(glue) to the answer section.</div>
<div><br></div>
<div>I searched for "promo" - not found. I then searched for
glue and found 8 mentions.</div>
<div><br></div>
<div>The first 4 were in the passage about trustworthiness. The
remaining are copied here:</div>
<div><br></div>
<div># Note that, glue excluded, it is impossible for data
from two<br>
# correctly configured primary zone files, two correctly
configured<br>
# secondary zones (data from zone transfers) or data from
correctly<br>
# configured primary and secondary zones to ever
conflict. Where glue<br>
# for the same name exists in multiple zones, and differs
in value, the<br>
# nameserver should select data from a primary zone file
in preference<br>
# to secondary, but otherwise may choose any single set of
such data.<br>
# Choosing that which appears to come from a source nearer
the<br>
# authoritative data source may make sense where that can
be<br>
# determined. Choosing primary data over secondary
allows the source<br>
# of incorrect glue data to be discovered more readily,
when a problem<br>
# with such data exists. Where a server can detect
from two zone files<br>
# that one or more are incorrectly configured, so as to
create<br>
# conflicts, it should refuse to load the zones determined
to be<br>
# erroneous, and issue suitable diagnostics.<br>
#<br>
# "Glue" above includes any record in a zone
file that is not properly<br>
# part of that zone, including nameserver records of
delegated sub-<br>
# zones (NS records), address records that accompany those
NS records<br>
# (A, AAAA, etc), and any other stray data that might
appear.<br>
</div>
<div>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."</div>
<div><br></div>
<div><br></div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<span
></span>-=-=-=-<br>
Edward
Lewis <span
></span
> <span
></span
> <span
></span
> <span
></span> +1-571-434-5468<br>
NeuStar</div>
<div><br></div>
<div>Think glocally. Act confused.</div>
</body>
</html>