Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie <[e-mail]>]

Andrew Sullivan wrote:
> ...
>> we should note that an upward or sideways or other non-downward referral is
>> a sign of misconfiguration and must be treated as SERVFAIL.
>
> I am a little uncomfortable with using this document to specify
> protocol behaviour as opposed to specifying protocol behaviour already
> specified elsewhere.  I may have missed them, but I am not sure either
> of these requirements (musts) are stated so baldly in any RFC.  Have I
> missed something?

when i stupidly introduced the idea of upward referrals while evidently 
hallucinating on crack cocaine back in the mid 1990's, the section of 
RFC 1034 that somebody should have printed, rolled up, and smacked me 
with was 4.1:

> 4.1. Introduction
>
> Name servers are the repositories of information that make up the domain
> database.  The database is divided up into sections called zones, which
> are distributed among the name servers.  While name servers can have
> several optional functions and sources of data, the essential task of a
> name server is to answer queries using data in its zones.  By design,
> name servers can answer queries in a simple manner; the response can
> always be generated using only local data, and either contains the
> answer to the question or a referral to other name servers "closer" to
> the desired information.

the operative phrase is '"closer" to'. this is repeated in 4.3.1:

> 4.3.1. Queries and responses
>
> The principal activity of name servers is to answer standard queries.
> Both the query and its response are carried in a standard message format
> which is described in [RFC-1035].  The query contains a QTYPE, QCLASS,
> and QNAME, which describe the types and classes of desired information
> and the name of interest.
>
> The way that the name server answers the query depends upon whether it
> is operating in recursive mode or not:
>
>    - The simplest mode for the server is non-recursive, since it
>      can answer queries using only local information: the response
>      contains an error, the answer, or a referral to some other
>      server "closer" to the answer.  All name servers must
>      implement non-recursive queries.

here again we see '"closer" to' as the allowed behaviour. of course, we 
also see that Unbound, and BIND with "recursion no;", are out-of-spec. 
so there's evidently a lot of fuzz here. that's why i'd love to see your 
current "clarifying referrals" document reference RFC 1034 4.1 and 4.3.1 
and somehow reinforce that this wasn't a part of the spec that folks can 
just ignore, even though many have and others probably will.

in [ibid], this is reinforced a third time:

> If recursive service is not requested or is not available, the non-
> recursive response will be one of the following:
>
>    - An authoritative name error indicating that the name does not
>      exist.
>
>    - A temporary error indication.
>
>    - Some combination of:
>
>      RRs that answer the question, together with an indication
>      whether the data comes from a zone or is cached.
>
>      A referral to name servers which have zones which are closer
>      ancestors to the name than the server sending the reply.
>
>    - RRs that the name server thinks will prove useful to the
>      requester.

this time the phrase is "closer ancestors" which is even clearer than 
'"closer" to' as used earlier in the document. and then in 4.3.2 we see:

>          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.

here, some inclarity is introduced by implication, since in what we now 
call a "mixed mode" name server, indirect descendant information may be 
present, and at least one name server whose innards i'm aware of would 
send a cached referral. also if a name server is authoritative for two 
zones, one the parent of the other, then when it receives a query it 
will not know which zone the iterative resolver client thinks it is "in" 
and will send the "closest" answer which may hide the parent's 
delegation to the child, effectively gluing two zones into one. i don't 
think you'll want to bite off all that in this document, but i want to 
reintroduce this problem to the e-mail archives since the last time it 
was spoken of was on the namedroppers list in the early 1990's. ("unix 
mount point" semantics are a steep climb, but the only way out.)

importantly however, the time when the algorithm described in [ibid] is 
allowed to send a referral is when a match would "take us out of the 
authoritative data", and the referral contents are copied from the 
non-authoriative NS RRset at the bottom of the zone we were searching. 
so, further evidence that upward or sideways referrals are off-spec.

-- 
P Vixie