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

[Ben Schwartz <[e-mail]>]

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

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

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


> 2) Clarification question: Can  SvcDomainName point to another AliasForm
> 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"
> 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.)
>

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.

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

Correct.

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

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
>>
>
> s/MUST be able fetch/MUST be able to fetch
>

Thanks.  Fixed!


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

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

> 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
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>