Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01

[Ben Schwartz <[e-mail]>]

On Wed, Aug 5, 2020 at 12:06 PM Pieter Lexis <[e-mail]>
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?

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.

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.