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
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
