Subject: Re: [DNSOP] commenting draft-ietf-dnsop-svcb-httpssvc-01

From: Ben Schwartz <[email-masked]>
Date: Mon, 9 Mar 2020 21:27:17 -0400

On Thu, Feb 27, 2020 at 11:48 AM Daniel Migault <[email-masked]> wrote:

> Hi,
>
> I read draft-ietf-dnsop-svcb-httpssvc-01. Please find find some comments
> (with my questions) below I had while reading linearly the document. I hope
> this will help.
>

Thanks for the comments, and sorry about the delay.

>
> Yours,
> Daniel
>
> section 1.1
>
>  _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net.
>
>
> In my opinion, the mechanism that derives QNAME needs to be refined or
> maybe
> the terminology being clarified.
>

Thanks for the comments.  I've filed an issue to track QNAME-related
questions here: https://github.com/MikeBishop/dns-alt-svc/issues/122

> a) The current document describes how to generate the QNAME from an URI.
> The
> QNAME contains a port number while some scheme do not allow or specify port
> subcomponent. Not having the port specified could be particularly useful to
> provide secure transport for schemes that are not necessarily secure for
> example. One the other hand, a scheme that specify a port, may not
> necessarily
> need to have it specified twined in the QNAME. I would be rather inclined
> to
> have the port optional maybe at the expense of an additional RRset, but
> need
> more thoughts.
>

 As you know, the port is indeed optional.

b) It is also unclear to me why HTTPS:443 or HTTP:80 has a specific
> convention.
> The convention tales place for the DNS resolution of a authority as
> opposed to
> the DNS resolution of a FQDN. One possible reason I see could would be to
> prevent having a distinction between http and https (which could be done
> otherwise for example using alpn),  but I am wondering if there are other
> rationale. So far, I do not see the need for a exception for the
> derivation of
> the QNAME (nor for using a specific RRtype).
>

This is explained in Section 7.1 (
https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-02#section-7.1):

   By removing the [Attrleaf] labels used in SVCB, this construction
   enables offline DNSSEC signing of wildcard domains, which are
   commonly used with HTTPS.  Reusing the origin hostname also allows
   the targets of existing CNAME chains (e.g.  CDN hosts) to start
   returning HTTPSSVC responses without requiring origin domains to
   configure and maintain an additional delegation.

> c) The current document, mentions several time HTTP service. The term
> service
> seems to me ambiguous as it has been defined for the DNS service based
> discovery in which case it means a web page. It seems to me preferable we
> keep
> the scope of URI scheme and port authority.
>

I agree, that could help us to improve the terminology.

> As a side note, when scheme is
> thought as a service, the convention adopted by the document slightly
> differs
> from the DNS based service Discovery which would use _baz._udp or
> eventually
> _baz._tcp. The current approach may be simpler.. I would think this is
> mostly a
> terminology issue.
>
>
> section 2.3
>
> """
> Protocol mappings for SVCB MAY remove the port or replace it with
>    other protocol-specific information, but MUST retain the scheme in
>    the QNAME.
> """
>
> I understand that for any scheme, a definition of how scheme and port
> should be
> defined when using SVBC. If that is correct, I would rather see that the
> other
> way around, that is SVBC defining from the scheme definition the QNAME
> derivation.
>

I'm not sure that there's a universal, scheme-independent, mechanical
transformation from URIs that would work.  As you noted, for some schemes
we want to include a port, while for others we don't.  That's why we don't
define a mapping here.

The term MAY also suggest different interpretation will be
> permitted, which could affect interoperability.
>

Yes, everyone definitely needs to agree on the mapping!  The mapping is a
standards document, which needs to be written for each scheme that wants to
use SVCB.

> """
> When a prior CNAME or SVCB record has aliased to an SVCB record, each
>    RR shall be returned under its own owner name.
> """
>
> If I am not misinterpreting this, this seems to be the natural way CNAME
> works
> and I am wondering if the text should not be removed from this section. My
> general comment is that the text refers too much to CNAME. Probably only
> the
> fall back function of CNAME should be mentioned in the main text and other
> considerations may be moved to the appendix to ease the reading. This is
> obviously just a comment.
>

Thanks for the comment.  I filed an issue to track this:
https://github.com/MikeBishop/dns-alt-svc/issues/123

"""
>  As an example:
>
>    _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net.
>    svc4..example.net <http://svc4.example.net>.  7200  IN SVCB 3 (
> svc4.example.net. alpn="bar"
>                                       port="8004" esniconfig="..." )
> """
>
> While many examples are useful for the understanding, they often provide
> the
> impression RRsets are in the same zone file. I am wondering if that would
> not
> be clarifying to show and mention zone files are different. Note this is
> just a
> feed back and your ar efree to ignore it.
>
>
Filed as https://github.com/MikeBishop/dns-alt-svc/issues/124

>
> 2.5.  SVCB records: AliasForm
>
> It seems strange to me to have a single RRset type associated to different
> functionalities, i.e. Alias and Service. I suspect that it is more
> convenient
> to have the same RRtype while requesting among different administrative
> domains, but I would be happy to know the rationals for this design. I
> have the
> impression that alias form is used to indicates the next RRtype (in our
> case,
> SVCB) while service form indicates a terminal request.
>

Thanks.  I filed an issue to track this question:
https://github.com/MikeBishop/dns-alt-svc/issues/125

Having spent some time thinking about it in response to your question, I
think that splitting the RR type into two would (1) at least double the
load on recursive and authoritative servers, and (2) not actually result in
any simplification, because ServiceForm lookups require chasing AliasForm
records.

"""
>  The SvcDomainName MUST point to a domain name that contains another
>    SVCB record, address (AAAA and/or A) records, or both address records
>    and a ServiceForm SVCB record.
> """
>
> I have some issue parsing the sentence with the AND and OR, but I also
> suspect
> that the first SVCB refers to an Alias form.
>

I've opened a PR to simplify this sentence:
https://github.com/MikeBishop/dns-alt-svc/pull/118

> The sentence above could be read as the owner of api.example.com pointing
> to
> svc4.example.net. need to check these conditions are met.
>

Yeah, I think that's accurate.  If the conditions aren't met,
api.example.com is going to stop working, so that's the person who cares
about this.

> I believe the
> conditions need to be enforced by the owner of the SvcDomainName. The
> confusion
> may be due to the fact that SvcDomainName is both a key and an RDATA.
>

This requirement is really stating the obvious so I'm not too concerned
about whose responsibility it is.

I have the impression "." or the owner domain MUST NOT be used, but I do not
> see this being mentioned, though I see it later.
>

We can clarify the processing rules here.

"""
> The AliasForm's primary purpose is to allow aliasing at the zone
>    apex, where CNAME is not allowed.  For example, if an operator of
>    https://example.com wanted to point HTTPS requests to a service
>    operating at svc.example.net, they would publish a record such as:
>
>    example.com. 3600 IN SVCB 0 svc.example.net.
>
> """
>
> My understanding is that SVCB "solves" the apex issue by splitting the
> query in
> two parts with different RRtypes and a specific resolution.
>

For any given URI scheme, there is only one new RR type in this draft.  Is
there something we could clarify on this point?

> I have the
> impression that SRV would have achieved this as well.
>

I agree.  We have a comparison with SRV here:
https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-02#appendix-A.1

> I would suggest to have
> one annex section dedicated to this apex issue/discussion.. The main
> reason is
> that it is recurrently being mentioned without really exposing the
> problem. In
> addition, I don't see this as the main motivation for SVCB.
>
>
> """
>  Note that the SVCB record's owner name MAY be the canonical name of a
>    CNAME record, and the SvcDomainName MAY be the owner of a CNAME
>    record.  Clients and recursive resolvers MUST follow CNAMEs as
>    normal.
> """
>
> I am not sure this is should be mentioned in the main part of the document
> and
> maybe annex would be more appropriated.
>
>
> 2.6.1.  Special handling of "." for SvcDomainName in ServiceForm
>
> """
>  (The SvcDomainName of an SVCB RR in AliasForm MUST
>    NOT have this value.)
> """
>
> It seems to me that section 2.5 is more adapted for this normative text.
>

OK, i've opened a PR to remove it:
https://github.com/MikeBishop/dns-alt-svc/pull/119

> This section is the first time HTTPSSVC is mentionned. My interpretation of
> HTTPSSVC is that HTTPS is mentiond in the RRtype because that information
> is
> not contained into the QNAME. My understanding is that using RRTypes was
> discouraged though I might misinterpret 8556.
>

I wasn't able to find this reference.

> 2.6.2.  SvcFieldPriority
>
> This field is also part of the AliasForm and a specific description may
> also be
> described in the aliasform as to specify how to handle SVCB RRsets with 0
> and
> non 0 SvcFieldPriority.
>

This has been changed in the -02 draft, so hopefully it's clearer now.

> 3.  Client behavior
>
> """
>
>    1.  Issue parallel AAAA/A and SVCB queries for the name HOST.  The
>        answers for these may or may not include CNAME pointers before
>        reaching one or more of these records.
> """
>
> While AAAA/A is well understood, I believe that AAAA and A is more
> accurate.
>

The problem with "AAAA and A" is that single-stack clients will not issue
both AAAA and A queries.  We can improve the phrasing but we shouldn't
accidentally tell everyone to perform both queries.

I believe he sentence "The answers... is not necessary, but I made that
> comment
> earlier.
>
> I have the impression that the behavior considers that either alias forms
> or
> service form are returned, but not necessarily when both forms are
> returned.
> Such scenario does not seems to me realistic for example to perform load
> sharing/offload the traffic. It could also happen due to misconfiguration.
> The
> current text seems to state that as long as alias form are found,look for
> the
> alias form (transition from 2) to 3)).
>

That's correct.

> It probably end up in having all
> different possibilities, but I am wondering if this is what we always
> want. It
> is likely that 2) and 3) can be processed in parallel.
>

We can certainly consider other behaviors.  However, I don't currently see
any configuration where mixing AliasForm and ServiceForm records would be
an advantage, and we would have to make sure that we are not increasing
resolvers' workload for no reason.

"""
>  If the
>        connection fails, the client MAY try to connect using values from
>        a lower-priority record.  If none of the options succeed, the
>        client SHOULD connect to the origin server directly.
> """
>
> This seems to me more like an application policy rather than a DNS
> resolution.
>

It's important to specify this because server operators depend on the
client behavior when setting up their zones.  If clients don't have this
fallback behavior, that means server operators need to provide higher
reliability and compatibility in their SVCB endpoints.

>
> """
> Some important optimizations are discussed in Section 5 to avoid
>    additional latency in comparison to ordinary AAAA/A lookups.
> """
>
> I think that reduced is more accurate than avoided as, if I understood
> correctly, when an alias is returned most likely another request follows.
>

With a conforming resolver and client-side caching (as specified in Section
5), clients never need to perform a follow-up query.

Recursive resolution can be slower when caches are cold, but only if the
zone owner adds a layer of indirection, which SVCB enables but does not
require.

"""
> When responding to a query that includes the DNSSEC OK bit
>    ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers
>    MUST accompany each RRSet in the Additional section with the same
>    DNSSEC-related records that it would send when providing that RRSet
>    as an Answer.
> """
>
> This seems like the normal processing.
>

Yes, that's the idea.  It's not clear to me that this is mandatory if we
don't specify it.

With DNSSEC and parameters that includes keys, it might happen that response
> may be large and that the server may select some responses to put in the
> additional data. Some selection algorithms could be provided and DNSSEC
> protected RRsets should be given a preference - though this won't be the
> only
> criteria.
>

The situation where a single ServiceForm RRSet refers to domains of which
some are signed and some are not seems pathological, so I'm not inclined to
propose an optimization for it.  If the zone owner wants to prefer the
signed zones, they can give them higher SvcFieldPriority.

>
> """
> If none of the SVCB records are consistent with any active or in-
>    progress connection, clients must proceed as described in Step 3 of
>    the procedure in Section 3.
> """
>
> I think a normative MUST woudl be more accurate.
>
>
> 7.  Using SVCB with HTTPS and HTTP
>
> """
>    Note that none of these forms alter the HTTPS origin or authority.
>    For example, clients MUST continue to validate TLS certificate
>    hostnames based on the origin host.
> """
>
> Just to clarify for myself, the TLS certificate on svc4.example.net will
> use
> example.com.
>

Yes.

7.4.  HTTP Strict Transport Security
>
> I am wondering if that would be possible to make https the default scheme
> and
> considering http scheme as https with alpn set to null.
>

That sounds like an HTTPS->HTTP downgrade attack that can be executed by
the recursive resolver.

On Thu, Feb 27, 2020 at 11:48 AM Daniel Migault <[email-masked]> wrote:

> Hi,
>
> I read draft-ietf-dnsop-svcb-httpssvc-01. Please find find some comments
> (with my questions) below I had while reading linearly the document. I hope
> this will help.
>
> Yours,
> Daniel
>
> section 1.1
>
>  _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net.
>
>
> In my opinion, the mechanism that derives QNAME needs to be refined or
> maybe
> the terminology being clarified.
>
> a) The current document describes how to generate the QNAME from an URI.
> The
> QNAME contains a port number while some scheme do not allow or specify port
> subcomponent. Not having the port specified could be particularly useful to
> provide secure transport for schemes that are not necessarily secure for
> example. One the other hand, a scheme that specify a port, may not
> necessarily
> need to have it specified twined in the QNAME. I would be rather inclined
> to
> have the port optional maybe at the expense of an additional RRset, but
> need
> more thoughts.
>
> b) It is also unclear to me why HTTPS:443 or HTTP:80 has a specific
> convention.
> The convention tales place for the DNS resolution of a authority as
> opposed to
> the DNS resolution of a FQDN. One possible reason I see could would be to
> prevent having a distinction between http and https (which could be done
> otherwise for example using alpn),  but I am wondering if there are other
> rationale. So far, I do not see the need for a exception for the
> derivation of
> the QNAME (nor for using a specific RRtype).
>
> c) The current document, mentions several time HTTP service. The term
> service
> seems to me ambiguous as it has been defined for the DNS service based
> discovery in which case it means a web page. It seems to me preferable we
> keep
> the scope of URI scheme and port authority. As a side note, when scheme is
> thought as a service, the convention adopted by the document slightly
> differs
> from the DNS based service Discovery which would use _baz._udp or
> eventually
> _baz._tcp. The current approach may be simpler.. I would think this is
> mostly a
> terminology issue.
>
>
> section 2.3
>
> """
> Protocol mappings for SVCB MAY remove the port or replace it with
>    other protocol-specific information, but MUST retain the scheme in
>    the QNAME.
> """
>
> I understand that for any scheme, a definition of how scheme and port
> should be
> defined when using SVBC. If that is correct, I would rather see that the
> other
> way around, that is SVBC defining from the scheme definition the QNAME
> derivation. The term MAY also suggest different interpretation will be
> permitted, which could affect interoperability.
>
> """
> When a prior CNAME or SVCB record has aliased to an SVCB record, each
>    RR shall be returned under its own owner name.
> """
>
> If I am not misinterpreting this, this seems to be the natural way CNAME
> works
> and I am wondering if the text should not be removed from this section. My
> general comment is that the text refers too much to CNAME. Probably only
> the
> fall back function of CNAME should be mentioned in the main text and other
> considerations may be moved to the appendix to ease the reading. This is
> obviously just a comment.
>
>
> """
>  As an example:
>
>    _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net.
>    svc4..example.net <http://svc4.example.net>.  7200  IN SVCB 3 (
> svc4.example.net. alpn="bar"
>                                       port="8004" esniconfig="..." )
> """
>
> While many examples are useful for the understanding, they often provide
> the
> impression RRsets are in the same zone file. I am wondering if that would
> not
> be clarifying to show and mention zone files are different. Note this is
> just a
> feed back and your ar efree to ignore it.
>
>
> 2.5.  SVCB records: AliasForm
>
> It seems strange to me to have a single RRset type associated to different
> functionalities, i.e. Alias and Service. I suspect that it is more
> convenient
> to have the same RRtype while requesting among different administrative
> domains, but I would be happy to know the rationals for this design. I
> have the
> impression that alias form is used to indicates the next RRtype (in our
> case,
> SVCB) while service form indicates a terminal request.
>
> """
>  The SvcDomainName MUST point to a domain name that contains another
>    SVCB record, address (AAAA and/or A) records, or both address records
>    and a ServiceForm SVCB record.
> """
>
> I have some issue parsing the sentence with the AND and OR, but I also
> suspect
> that the first SVCB refers to an Alias form.
>
> The sentence above could be read as the owner of api.example.com pointing
> to
> svc4.example.net. need to check these conditions are met. I believe the
> conditions need to be enforced by the owner of the SvcDomainName. The
> confusion
> may be due to the fact that SvcDomainName is both a key and an RDATA.
>
> I have the impression "." or the owner domain MUST NOT be used, but I do
> not
> see this being mentioned, though I see it later.
>
> """
> The AliasForm's primary purpose is to allow aliasing at the zone
>    apex, where CNAME is not allowed.  For example, if an operator of
>    https://example.com wanted to point HTTPS requests to a service
>    operating at svc.example.net, they would publish a record such as:
>
>    example.com. 3600 IN SVCB 0 svc.example.net.
>
> """
>
> My understanding is that SVCB "solves" the apex issue by splitting the
> query in
> two parts with different RRtypes and a specific resolution. I have the
> impression that SRV would have achieved this as well. I would suggest to
> have
> one annex section dedicated to this apex issue/discussion.. The main
> reason is
> that it is recurrently being mentioned without really exposing the
> problem. In
> addition, I don't see this as the main motivation for SVCB.
>
>
> """
>  Note that the SVCB record's owner name MAY be the canonical name of a
>    CNAME record, and the SvcDomainName MAY be the owner of a CNAME
>    record.  Clients and recursive resolvers MUST follow CNAMEs as
>    normal.
> """
>
> I am not sure this is should be mentioned in the main part of the document
> and
> maybe annex would be more appropriated.
>
>
> 2.6.1.  Special handling of "." for SvcDomainName in ServiceForm
>
> """
>  (The SvcDomainName of an SVCB RR in AliasForm MUST
>    NOT have this value.)
> """
>
> It seems to me that section 2.5 is more adapted for this normative text.
>
> This section is the first time HTTPSSVC is mentionned. My interpretation of
> HTTPSSVC is that HTTPS is mentiond in the RRtype because that information
> is
> not contained into the QNAME. My understanding is that using RRTypes was
> discouraged though I might misinterpret 8556.
>
>
> 2.6.2.  SvcFieldPriority
>
> This field is also part of the AliasForm and a specific description may
> also be
> described in the aliasform as to specify how to handle SVCB RRsets with 0
> and
> non 0 SvcFieldPriority.
>
> 3.  Client behavior
>
> """
>
>    1.  Issue parallel AAAA/A and SVCB queries for the name HOST.  The
>        answers for these may or may not include CNAME pointers before
>        reaching one or more of these records.
> """
>
> While AAAA/A is well understood, I believe that AAAA and A is more
> accurate.
>
> I believe he sentence "The answers... is not necessary, but I made that
> comment
> earlier.
>
> I have the impression that the behavior considers that either alias forms
> or
> service form are returned, but not necessarily when both forms are
> returned.
> Such scenario does not seems to me realistic for example to perform load
> sharing/offload the traffic. It could also happen due to misconfiguration.
> The
> current text seems to state that as long as alias form are found,look for
> the
> alias form (transition from 2) to 3)). It probably end up in having all
> different possibilities, but I am wondering if this is what we always
> want. It
> is likely that 2) and 3) can be processed in parallel.
>
> """
>  If the
>        connection fails, the client MAY try to connect using values from
>        a lower-priority record.  If none of the options succeed, the
>        client SHOULD connect to the origin server directly.
> """
>
> This seems to me more like an application policy rather than a DNS
> resolution.
>
> """
> Some important optimizations are discussed in Section 5 to avoid
>    additional latency in comparison to ordinary AAAA/A lookups.
> """
>
> I think that reduced is more accurate than avoided as, if I understood
> correctly, when an alias is returned most likely another request follows.
>
> """
> When responding to a query that includes the DNSSEC OK bit
>    ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers
>    MUST accompany each RRSet in the Additional section with the same
>    DNSSEC-related records that it would send when providing that RRSet
>    as an Answer.
> """
>
> This seems like the normal processing.
>
> With DNSSEC and parameters that includes keys, it might happen that
> response
> may be large and that the server may select some responses to put in the
> additional data. Some selection algorithms could be provided and DNSSEC
> protected RRsets should be given a preference - though this won't be the
> only
> criteria.
>
>
> """
> If none of the SVCB records are consistent with any active or in-
>    progress connection, clients must proceed as described in Step 3 of
>    the procedure in Section 3.
> """
>
> I think a normative MUST woudl be more accurate.
>
>
> 7.  Using SVCB with HTTPS and HTTP
>
> """
>    Note that none of these forms alter the HTTPS origin or authority.
>    For example, clients MUST continue to validate TLS certificate
>    hostnames based on the origin host.
> """
>
> Just to clarify for myself, the TLS certificate on svc4.example.net will
> use
> example.com.
>
>
> 7.4.  HTTP Strict Transport Security
>
> I am wondering if that would be possible to make https the default scheme
> and
> considering http scheme as https with alpn set to null.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 18 Mar 2020 22:34:15 -0400

Thanks for the response. I apology for the late response. Please see inline
some comments/responses. I will review 02 later.

Note I am interested in SVC RRsets as I am using them to discover DNS
resolvers [1]  - using non http or https scheme. Comments or
suggestion regarding the use SVCB would be highly appreciated.

Yours,
Daniel

[1] https://tools.ietf.org/html/draft-mglt-add-rdp-00#section-8.2

> standards document, which needs to be written for each scheme that wants to
<mglt>
That is better there is an expectation that each scheme require a
specification to use SVCB. My reading of 01 was that the document defined
it for every scheme. In particular, the reasons you do not add _http(s)
could also apply - at least partly to other schemes.
</mglt>

> <mglt>
unless I am missing something. I do not see the use of two RRsets doubling
the load. The mechanism coudl be similar as the Alias Form specifying the
next RRtype.
</mglt>

>> The sentence above could be read as the owner of api.example.com
>> pointing to
<mglt>
no, my comment was mostly that there were too much focus on the apex
problem.
</mglt>

>> I am not sure this is should be mentioned in the main part of the
>> document and
> <mglt>
here is the text I was referring.
https://tools.ietf.org/html/rfc8552#section-1.2
</mglt>

> accidentally tell everyone to perform both queries.
<mglt>
You are correct. I did not considered that case ;-).
</mglt>

>> sharing/offload the traffic. It could also happen due to
>> misconfiguration. The
> With a conforming resolver and client-side caching (as specified in
> Section 5), clients never need to perform a follow-up query.
>
<mglt>
I was suggesting the client prefers DNSSEC signed RRsets. Since a
delegation can occur to multiple cloud providers, I envisioned that some
may support DNSSEC other do not or are under NTA for example.
</mglt>

> <mglt>
I did not saw this through this angle... The initial intention was to
advertise HTTP. I have to rethink of this.
</mglt>

>> The sentence above could be read as the owner of api.example.com
>> pointing to
>> I am not sure this is should be mentioned in the main part of the
>> document and
>> sharing/offload the traffic. It could also happen due to
>> misconfiguration. The

-- 
Daniel Migault
Ericsson

---

From: Ben Schwartz <[email-masked]>
Date: Sun, 22 Mar 2020 18:22:40 -0400

On Wed, Mar 18, 2020 at 10:34 PM Daniel Migault <[email-masked]> wrote:

> Thanks for the response. I apology for the late response. Please see
> inline some comments/responses. I will review 02 later.
>

Thanks in advance.

> suggestion regarding the use SVCB would be highly appreciated.

I'll be happy to advise on that topic.  I would start by looking at the
adaptive DNS draft, which is pursuing similar idea:
https://tfpauly.github.io/draft-pauly-adaptive-dns-privacy/draft-pauly-adaptive-dns-privacy.html#rfc.section.3.1

> the load. The mechanism coudl be similar as the Alias Form specifying the

Clients would have to perform queries for both types separately (double the
queries to the recursive).  A recursive resolver processing a query for the
"service form" type would have to query the authoritative for both the
service form and the alias form, at every step of the alias chain (double
the queries to the authoritative).

...

>>> HTTPSSVC is that HTTPS is mentiond in the RRtype because that
>>> information is

I think the draft follows that recommendation, by splitting each protocol
into its own RRSet to avoid sending the client irrelevant information.

...

> may support DNSSEC other do not or are under NTA for example.

Sure, but the domain owner also knows which of its cloud providers support
DNSSEC.  The domain owner is free to increase the priority of those that
use DNSSEC.