On Wed, Aug 5, 2020 at 10:08 AM Ben Schwartz <bemasc= [email protected]> wrote:
> On Wed, Aug 5, 2020 at 12:06 PM Pieter Lexis <[email protected]> > wrote: > ... > >> Do *both* alias-target{1,2}.example.net|SVBC records end up in the >> ADDITIONAL section. Or are they (as is the case with an in-zone CNAME) >> considered an answer and should they go into the ANSWER section? >> > > I think Section 4.1 is pretty clear that everything goes in the Additional > section. (But this can be changed!) > > I find the alias mode semantics (on the DNS-level) unclear and >> under-specified in the draft. I look forward to guidance from the authors. >> > > And I look forward to guidance from you! How do you think it should > work? Send text! > > Personally, I'd like to know which of these questions actually need to be > resolved in the standard, and which can safely be left to the discretion of > implementors. Is there a compatibility concern with any of these > questions, or is it only a question of consistency across implementations? > Both, actually, since bad coding practices abound. It is not unheard of for implementers to work off of results they get from other implementations, and assume that is the only variation they will get. Consistency across implementations thus ends up being really important for interoperability. It's not how it should be, of course. But, clear and concise RFCs lead to the best possible outcomes. > > 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. The Unknown Type logic is why the in-bailiwick stuff is SHOULD rather than MUST (and that's the right rule to use). 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) (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.) 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. > > 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?) Brian
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
