Andrew Sullivan wrote:
Hi,
On Mon, Nov 13, 2017 at 08:14:14AM -0800, Paul Vixie wrote:
If I ask the authoritative server for example.com about a name
label.example.net, in a graph-theoretic sense the NS RRset for the
root zone is clearly closer to label.example.net than anything else I
can give.
dns is not that kind of graph.
...
Obviously. But your example is still on the current tree, just not
immediately below. The example I gave is in a completely different
section of the tree, and my point is that none of the text you quoted
shows why "." isn't the "closer server" that an authoritative server
somewhere beneath com. can give in response to a qname that is
somewhere beneath net. We might think today that is a misfeature in
STD13, but I don't think it's a misinterpretation of what STD13 says.
I don't know what kind of graph would make that false.
actually, i had misread you (com vs net). i apologize. let me re-answer.
there is no reason for an authority server to know who the root name
servers are. so, there can be no expectation that it would know any
"closer" name server set than the one at its zone bottom.
since RFC 1034 talks about zone bottoms, and "closest enclosing", and
its algorithm speaks specifically of a referral being generated by
copying non-authoritative NS RRs from the zone bottom into the answer,
there is no reasonable interpretation of "closer" other than an NS RRset
which is closer, along the path from the zone apex to the qname, than
the zone apex was. in fact, from that algorithm, there is no way to
generate a referral other than by copying along-the-path data into an
answer.
any attempt to interpret "closer" in an off-the-path way is a clear
misinterpretation of RFC 1034. we are only on "the current tree" here.
as i wrote during the SOPA wars, REFUSED has been widely used as an
administrative denial, and repurposing it would not be effective at this
late date.
This, too, seems to be a claim that is at best poorly justified. It
might be that it is how BIND interprets the RCODE, but it's not what
it is defined to be.
it's defined as "administrative denial" not merely "widely interpreted
as administrative denial" as i wrote above.
... I'm anyway not sure your description in the circleid piece (or
elsewhere) is inconsistent with the RFC 1035 definition of RCODE 5:
"The name server refuses to perform the specified operation for
policy reasons." Refusing to respond to this or that IP address is a
policy, and refusing to perform upwardreferrals is also a policy, no?
"no." the client isn't asking for an upward referral, it's asking for an
answer, and is expecting either an answer (positive or negative or
empty) or an on-the-path referral copied from the non-authoritative data
at the bottom of the authority zone. it is not expecting its query to be
interpreted as a request for an upward referral, so, it cannot treat
REFUSED as an administrative denial of that upward referral.
the rest of the text of the definition of REFUSED makes this clearer:
<<For example, a name server may not wish to provide the information to
the particular requester, or a name server may not wish to perform a
particular operation (e.g., zone transfer) for particular data.>>
the word "particular" appears four times.
as witnessed in discussions of the u.s. constitutions and the christian
bible, arguments about the literal intent of the authors are interesting
mostly to scholars, whereas our concern should be with the actions taken
by the far end given the data pattern we transmit and the circumstances
as we know them.
while specific guidance was not given as to resolver action in response
to each possible authority RCODE, i have both witnessed and implemented
full resolvers which treated REFUSED as a permanent failure whereas
SERVFAIL was a temporary failure. that is, receipt of a REFUSED from any
authority consulted during iteration would cause a final error code
(assuming no other authority gave a more useful answer) of NO_RECOVERY,
whereas if only timeouts and SERVFAILs were heard, the final error code
would be TRY_AGAIN. (these are BSD h_errno values, but modern API's have
equivalents.)
---
treating "i don't have the zone configured" as a REFUSED condition,
while treating "i can't write the secondary zone" or "i can't read the
primary zone" as SERVFAIL conditions, adds no value, but does subtract
it. usually when i don't have a zone configured that is delegated to me,
it's because i have not caught up with my inbox, or i have FUBAR'd my
configuration file using "git" or similar. in those cases, the name
being looked up _might exist_ and retrying later _might succeed_.
i have heard a number of folks argue that this logic is common, but i
have heard noone argue that it is superior to known alternatives. can we
hear someone who is in favour of this for reasons beyond "five million
frenchmen cannot be wrong"?
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
