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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
