Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan <[e-mail]>]

Hi,

On Wed, Nov 29, 2017 at 07:39:42AM +1100, Mark Andrews wrote:
> The AA bit may or may not be set depending upon whether the response contains
> a CNAME/DNAME or not.  
> 

I replied with an enthusiastic "thanks" because this struck me as
obviously correct, but then I though I'd better look at the algorithm
again.  And now I have a problem.

3.a is the CNAME case, but it's not a referral in the 1035 sense.

3.b takes us out of the authoritative data, so AA should not be set.

Now, in RFC 6672 the DNAME processing happens at step 3.C, which
undertakes the DNAME processing.  The resulting answer goes into the
answer section and processing continues.

None of these steps seems to provide the case where a referral happens
but the AA bit is set.  So, while I feel like I agree that in some
cases the AA bit should be set and not clear in case the response
contains a CNAME or DNAME, I'm trying to figure out whether such
responses are really referrals or else just intermediate steps. RFC
6672 doesn't call them referrals.  Maybe this is a bit of informal
jargon that needs clarifying?

Thanks for the contribution, and best regards,

A

> > On 29 Nov 2017, at 6:50 am, Andrew Sullivan <[e-mail]> wrote:
> > 
> > Dear colleagues,
> > 
> > Joe Abley and I have just submitted a draft
> > (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/)
> > that is intended to capture the discussion here about referrals and
> > how to describe them.  It is intended for BCP, and it discourages
> > upward referrals by authoritative servers.
> > 
> > That leaves the task of the referrals definition.  I have some new
> > text below:
> > 
> > ---%<---cut here---
> > 
> > Referral: A type of response in which a server, signalling that it is
> > not authoritative for an answer, provides the querying resolver with
> > an alternative place to send its query.  A referral contains an empty
> > answer section.  It contains the NS RRset for the referred-to zone in
> > the authority section.  It may contain RRs that provide addresses in
> > the additional section.  The AA bit is clear.
> > 
> > There are two types of referral response.  The first is a downward
> > referral (sometimes described as "delegation response"), where the
> > server is authoritative for some portion of the QNAME.  The Authority
> > section RRset's RDATA contains the name servers specified at the
> > referred-to zone cut.  In normal DNS operation, this kind of response
> > is required in order to find names beneath a delegation.
> > 
> > The second is an upward referral (sometimes described as "root
> > referral" or just "referral response", as distinct from the delegation
> > response above), where the server is not authoritative for any portion
> > of the QNAME.  When this happens, the referred-to zone in the
> > Authority section is usually the root zone (.).  In normal DNS
> > operation, this kind of response is not strictly speaking required to
> > work, and in practice some authoritative server operators will not
> > return referral responses beyond those required for delegation.
> > 
> > [optional: see draft-sullivan-dnsop-refer-down-00 or whatever.  We'll
> > only include this reference if the other draft reaches WG consensus
> > before terminology-bis]
> > 
> > ---cut here--->%---
> > 
> > Comments, please.  Also, Joe and I solicit comments on the referrals
> > draft proper, but it would be nice to put that in a different thread.
> > 
> > Best regards,
> > 
> > A
> > 
> 

-- 
Andrew Sullivan
[e-mail]