Yes, what I just sent. So how does one end up in 3.b with the AA bit and still have a "referral" according to 1034, section 4.3.2?
A On Wed, Nov 29, 2017 at 12:49:48PM +1100, Mark Andrews wrote: > AA Authoritative Answer - this bit is valid in responses, > and specifies that the responding name server is an > authority for the domain name in question section. > > Note that the contents of the answer section may have > multiple owner names because of aliases. The AA bit > corresponds to the name which matches the query name, or > the first owner name in the answer section. > > > On 29 Nov 2017, at 12:46 pm, Mark Andrews <ma...@isc.org> wrote: > > > > GO READ STD13! > > > >> On 29 Nov 2017, at 12:44 pm, Andrew Sullivan <a...@anvilwalrusden.com> > >> 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 <a...@anvilwalrusden.com> > >>>> 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 a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
