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
