Subject: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02

From: Dragana Damjanovic <[email-masked]>
Date: Wed, 6 May 2020 22:17:27 +0200

I have some minor comments and clarification questions.

1) in "Example: Protocol enhancements":

> and the key=value pairs indicate that it supports QUIC in addition to
> HTTPS over TLS
>

Should  "HTTPS over TLS" be "HTTPS over TCP"? HTTP3 is also HTTPS over TLS

2) Clarification question: Can  SvcDomainName point to another AliasForm
record? As I understand it, it cannot. It can point to a CNAME that points
to an AliasForm record.
The descriptions of the server and client behavior sections do not mention
this. Should they mention this again?
I am just wondering if the description in "Client behavior" and "DNS Server
Behavior" should be more precise and mention this constraint and also the
limit for a chains of CNAME and SVCB of 8?

3) Proxies should not use SVCB/HTTPSSVC. section "Clients using a Proxy"
should say that explicitly. (To make useful for a proxy to use
SVCB/HTTPSSVC records, there should be a way to communicate back to the
client about that SVCB/HTTPSSVC parameters. This does not exist at the
moment and will add a delay in some cases, etc.)

4) If no-default-alpn is present the alpn parameter must be present as
well, otherwise the "ALPN set" is empty?

5) A clarification question: In the section "ipv4hint and ipv6hint":

> An empty list of addresses is invalid.

Empty hints will not mean that the record is malformed, i.e. it is not a
fatal error that will make the whole record invalid?

6) Nit:

> As discussed in {{client-behavior}}, clients MUST be able fetch additional
> information that is required to use
>

s/MUST be able fetch/MUST be able to fetch

dragana

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 6 May 2020 21:32:26 -0400

> Should  "HTTPS over TLS" be "HTTPS over TCP"? HTTP3 is also HTTPS over TLS

You're right; that would be clearer.  Change proposed at
https://github.com/MikeBishop/dns-alt-svc/pull/146.

> record? As I understand it, it cannot.
>

Technically, SvcDomainName doesn't point to a record.  It provides a domain
name, and the recursive resolver should perform some queries to that name.
The QTYPE of those queries can vary depending on context.

If the SVCB record is in AliasForm (priority=0), the resolver should query
A, AAAA, and SVCB for the SvcDomainName.  If the SVCB record is in
ServiceForm, the resolver should query A and AAAA records on the
SvcDomainName.  All of these queries follow CNAMEs as per usual.

It can point to a CNAME that points to an AliasForm record.

>From SVCB's perspective, CNAME is completely transparent.

...

> I am just wondering if the description in "Client behavior" and "DNS
> Server Behavior" should be more precise and mention this constraint and
> also the limit for a chains of CNAME and SVCB of 8?
>

The chain length limit has been discussed at some length here without
consensus.  The current draft says

>  Chains of consecutive SVCB and CNAME records SHOULD be limited to (8?)
prior to reaching terminal address records.

I suspect that we are going to end up removing this number entirely, and
leaving the choice of limit to implementations.  This isn't ideal for
interoperability, but it seems to be no worse than the status quo with
CNAME.

3) Proxies should not use SVCB/HTTPSSVC.. section "Clients using a Proxy"
> moment and will add a delay in some cases, etc.)

I agree that transport proxies cannot issue SVCB or HTTPSSVC
queries, because they do not know what protocol/scheme is running over the
transport.  Tracked at https://github.com/MikeBishop/dns-alt-svc/issues/147.

> well, otherwise the "ALPN set" is empty?

Correct.

> fatal error that will make the whole record invalid?

An RR with an empty IP hint is malformed, in presentation format or wire
format.

6) Nit:
>
>> As discussed in {{client-behavior}}, clients MUST be able fetch
>> additional information that is required to use
>>
>

Thanks.  Fixed!

>
> dragana
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

On Wed, May 6, 2020 at 4:18 PM Dragana Damjanovic <[email-masked]>
wrote:

> I am just wondering if the description in "Client behavior" and "DNS
> Server Behavior" should be more precise and mention this constraint and
> also the limit for a chains of CNAME and SVCB of 8?
>
>
> 3) Proxies should not use SVCB/HTTPSSVC.. section "Clients using a Proxy"
>> As discussed in {{client-behavior}}, clients MUST be able fetch
>> additional information that is required to use
>>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>