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

[Brian Dickson <[e-mail]>]

On Thu, Aug 6, 2020 at 6:22 AM Mark Andrews <[e-mail]> wrote:

>
>
> I really don’t know how this thread got started with clear and unambiguous
> instructions to add all the records to the additional section.
>

The possibility of changing what is specified in the draft, was what
started this thread.
Your responses all suppose that it is not possible to change what is
specified in the draft.
It would be helpful (IMHO) to the conversation to give consideration to the
contents of the thread, from the perspective that the specs in the draft
are not absolutely set in stone and immutable.

Here's the quote from Ben:

I think Section 4.1 is pretty clear that everything goes in the Additional
section.  (But this can be changed!)



>
> "Cooperating DNS recursive resolvers will perform subsequent record
> resolution (for SVCB, A, and AAAA records) and return them in the
> Additional Section of the response. Clients either use responses included
> in the additional section returned by the recursive resolver or perform
> necessary SVCB, A, and AAAA record resolutions. DNS authoritative servers
> can attach in-bailiwick SVCB, A, AAAA, and CNAME records in the Additional
> Section to responses for a SVCB query."
>
> Yes this means you need may need to change additional section process to
> chase other records.  Named was already doing this for one type and with
> HTTPS and SVCB needing we made the processing general.  Yes, it also means
> that one has to add CNAMEs to the additional section when processing HTTPS
> or SVBC.
>
>
We can all read, and we understand what the current draft says.
That's NOT what is being discussed (how to interpret those words).
What IS being discussed in this thread is whether it may be more sensible
to align the process of handling the "alias" form in a manner more
consistent with how CNAME processing happens.
It is a proposal to change the spec itself, rather than an alternate
interpretation of what the current draft of the spec says.

This is why I suggested that, while it is not CNAME per se, treating it as
"constrained alias applicable only to SVCB queries" isn't a huge leap, and
would simplify the code for handling alias form, on both the server and
client side of a lookup.

If the standard says they belong in the Answer section (as I am
suggesting), I think the expected BIND client-side handling of SVCB records
(alias and non-alias, if in-bailiwick) and CNAME records if they are both
placed in the answer section by the server should be okay, in both
situations: when SVCB is "unknown" (it's a match to QTYPE), or when SVCB
handling logic is added.

Brian