On 8/5/20 8:03 PM, Brian Dickson wrote: > > > On Wed, Aug 5, 2020 at 10:08 AM Ben Schwartz > <[email protected] > <mailto:[email protected]>> wrote: > > On Wed, Aug 5, 2020 at 12:06 PM Pieter Lexis > <[email protected] <mailto:[email protected]>> wrote: > ... > > Conceptually, AliasMode is not a CNAME: it only affects SVCB queries > (not other RR types), and can safely be implemented entirely as an > RFC 3597 Unknown RR Type. That suggests that it is at least safe, > and perhaps least-surprising, for the authoritative server to put > all responses for other owner names in the Additional section, as > the current text seems to indicate fairly clearly. > > > I beg to differ, in that I would view AliasMode as a constrained CNAME.
I agree with Brian here. Compliant DNS servers (be it auth or recursor) MUST treat an Alias-mode SVCB (or derived) record as a CNAME for the purposes of processing that SVCB or derived record. i.e. foo.example.com SVCB 0 srv1.example.net == (logically) foo.example.com CNAME srv1.example.com when QType = SVCB, but not for any other QType. > What I would suggest is the following, paraphrased (i.e. please clean it > up before using in the I-D, if you agree it's the right semantics): > > * In-bailiwick CNAME, SVCB, A, and AAAA records SHOULD be added (and > for CNAME and SVCB, in-bailiwick RDATA for those SHOULD also be > iteratively processed for inclusion) > * CNAME and SVCB records MUST be placed in the Answer section (because > of existing CNAME rules and because of RRTYPE match to the query) > * A and AAAA records MUST be placed in the Additional section (since > those would not match the query RRTYPE of SVCB) +1 to this summary. It reflects how I see the semantics of alias mode as well. > (I am not sure of the question/issue of including the SOA, or where that > would go, but I'll defer to anyone who knows or has an opinion. My gut > says, do whatever gets done for CNAME.) The SOA MUST go in the packet. As a compliant resolver talking to an auth that does not implement SVCB will follow the chain and the auth will respond with NODATA (and thus the SOA). After reading section 4.2, I also think that a resolver that implements this MUST include the SOA as well if the final target has no SVCB record, to indicate that the answer to the actual question (example.com|SVCB) yielded NODATA after alias chaining. A compliant client can ignore the fact that the DNS says NODATA and use the A/AAAA records from the ADDITIONAL section (or send a query for them based on the final target). > All the in-bailiwick stuff is essentially an optimization. Authority > servers may not implement that, and would still be compliant if they did > not. > Resolvers MUST be prepared to handle the non-inclusion of in-bailiwick > stuff from authority servers, as this would not be an error or violation > of the (eventual) RFC. Yes. > P..S. The text on this point has recently > changed: https://github.com/MikeBishop/dns-alt-svc/pull/199#discussion_r444979971. > One of the questions there is what should happen for > AliasMode->CNAME->ServiceMode->AAAA, all in-bailiwick. The draft > says "Clients and recursive resolvers MUST follow CNAMEs as > normal.", but it no longer says anything about authoritatives. > > > IMHO, I think this is correct, or at least consistent with what I wrote > above. (If there are any inconsistencies, could you highlight what those > would be, please?) I believe you are correct. Cheers, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
