Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan <[e-mail]>]

Hi,

On Mon, Nov 13, 2017 at 11:03:11PM -0800, Paul Vixie wrote:
> 
> 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.

I think your claim there depends on a strict role separation that is
not in the protocol definition (yet).  It implies that there is such a
thing as "an authority server", whereas it seems to me that we have
not defined servers quite so exclusively (yet).  Interestingly (and
really helpfully I must emphasise), you have just made me realise that
there's actually a problem in the definition of "authoritative server"
in 7719 and -bis.

In that definition, we quote 2182:

    A server that knows the content of a DNS zone from local
      knowledge, and thus can answer queries about that zone without
      needing to query other servers.

But then we go on to say that the server has been configured to answer
with AA set for the zone.  Yet that is not entailed by 2182's
definition, for it seems to me that 2182's definition of "knows the
content" could under one reading include the root hints file.  I note
that RFC 8109 doesn't actually cover the case of an authoritative
server, and of course we haven't (yet) got consensus that mixed-mode
servers are harmful, either.

Now, one might argue (I can see such a reading, and I think it is what
you are arguing) that the root hints file is RFC 1034's SBELT
structure, and that 1034 defines SBELT is to "be used when the
resolver doesn't have any local information to guide name server
selection", and that the SBELT structure is anyway defined only for
resolvers and not servers.  All of that _should_ mean that a server
that is only ever authoritative ought not to have this sort of
information and probably also that it ought never to reveal it when
the RD bit is clear even if it did have it.  I think it is reasonble
to say, however, that this information is not entirely clear from the
RFCs as they currently stand, particularly since the algorithm in
section 4.3.2 of RFC 1034 seems explicitly to contemplate having a
cache, and it's not clear (at least to me) in that algorithm whether
there are ever cases where a cache ought to be excluded completely
from consideration.

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

Step 4 of the algorithm in RFC 1034 reads to me like a flat-out
contradiction of your claim there:

   4. Start matching down in the cache.  If QNAME is found in the
      cache, copy all RRs attached to it that match QTYPE into the
      answer section.  If there was no delegation from
      authoritative data, look for the best one from the cache, and
      put it in the authority section.  Go to step 6.

So your entire argument turns on whether a server should ever have a
root hints file and use it.  If there is written down somewhere advice
that some class of servers should never have such information, I have
overlooked it.

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

Where is it defined that way?  RFC 1035 just says it is refused "for
policy reasons", and the IANA registry is less descriptive than that
because it refers to RFC 1035.  I'm unaware of another place this is
defined.

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

I don't think that you have shown this follows from the algorithm, and
the fact that clients seem not to spit up on root referrals strikes me
as empirical evidence that your assertion of what the client is
expecting is at least in doubt.

> <<For example, a name server may not wish to provide the information to the
> particular requester

Right.  Such as, for instance, not wishing to provide the upward
referral (or anything else).  The particular requester might be a
member of the class, "all requesters asking for zones for which I am
not authoritative".  I get why your interpretation is one plausible
one, but I do not see that it is the _only_ one.

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

Well, I want to be neither talmudic nor supreme.  I don't think I
disagree with your view (though FWIW I find your tone a little
patronizing), but I think we are doing two things in this discussion:

    1.  Providing fodder for a draft I've already started writing that
    provides guidance not to return upward referrals.

    2.  Providing the necessary information for the terminology
    document so that we have written down our current best
    understanding of terms as people use them.

I do not believe that (2) ought to include an effort to define terms
to exclude operations we (for some value of we) think are a bad idea.
IMO, the goal of 7719bis is not to define problems out of existence
but to give us a clear and common set of terms to talk about all of
this, _so that_ we can specify improvements to what the traditional
specifications say.

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

And that "permanent failure" marks the server dead, not the
server-qname or even server-zone combination dead, I guess.  I think I
have seen this too.  That seems like another thing that ought to be
documented, however, as a possible issue: at least one full service
resolver interprets an RCODE somewhat more liberally than the
specification does under some (other) plausible reading.  I'm here to
document things so that we can maximise interoperation, not specify
what is Correct.

Best regards,

A

-- 
Andrew Sullivan
[e-mail]