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

[Daniel Migault <[e-mail]>]

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

On Mon, Mar 9, 2020 at 9:27 PM Ben Schwartz <[e-mail]> wrote:

>
>
> On Thu, Feb 27, 2020 at 11:48 AM Daniel Migault <[e-mail]>
> 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.
>
>
<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>

> """
>> 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.
>
> <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 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?
>
>
<mglt>
no, my comment was mostly that there were too much focus on the apex
problem.
</mglt>

> 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.
>
> <mglt>
here is the text I was referring.
https://tools.ietf.org/html/rfc8552#section-1.2
</mglt>

>
>> 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.
>
<mglt>
You are correct. I did not considered that case ;-).
</mglt>

>
> 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.
>
<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>

>
>
>>
>> """
>> 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.
>
> <mglt>
I did not saw this through this angle... The initial intention was to
advertise HTTP. I have to rethink of this.
</mglt>

> On Thu, Feb 27, 2020 at 11:48 AM Daniel Migault <[e-mail]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>

-- 
Daniel Migault
Ericsson