Re: [DNSOP] Clarifying referrals (#35)

[Mark Andrews <[e-mail]>]

GO READ STD13!

> On 29 Nov 2017, at 12:44 pm, Andrew Sullivan <[e-mail]> wrote:
> 
> 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]
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]