Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie <[e-mail]>]

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