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

From: Alessandro Ghedini <[email-masked]>
Date: Fri, 17 Apr 2020 11:19:32 +0100

Hello,

First off, I have started implementing support for SVCB and HTTPSSVC as part of
the dnspython library [0] and I'd be interested in doing some interop testing
with other people's implementations.

I also have a few comments/questions about the draft, apologies if they have
already been discussed in the past (haven't been following the draft from the
start).

1. For interop testing purposes it would be very helpful if the draft listed
commonly agreed upon code-points for the new RR types. Ideally in the form of an
official early assignment from IANA, but if that's not possible picking a couple
of codepoints at random from the "private use" range would also be helpful. In
my implementation I'm currently using "65481" for SVCB and "65482" for HTTPSSVC.

2. The structure of the draft is a bit odd, as it lists a bunch of examples
before introducing any of the records. This was a bit confusing to me, so I'd
suggest moving sections 1.5 and 1.6 _before_ the examples (that is, immediately
after the introduction). It might also be a good idea to just move the examples
to an Appendix instead.

3. Would it make sense to move the ESNI/ECHO config paramenter to the ESNI/ECHO
draft instead? This way the DNS draft wouldn't need to depend on the ESNI draft
(so e.g. if ESNI ends up taking longer, this draft could be published without
having to wait for it).

4. What is the point of differentiating between AliasForm and ServiceForm? Like,
couldn't the draft just say that the SvcFieldValue is an optional field and be
done with that? It seems like not having to explicitly differentiate the two
cases would simplify the draft a bit without sacrificing much, though I might
be missing something.

5. Section 2.1.1 says

   The presentation format for SvcFieldValue is a whitespace-separated
   list of elements representing a key-value pair, with an absent value
   or "=" indicating an empty value.

It took me longer than I'd like to admit to understand the "with an absent value
or "=" indicating an empty value" part. I'd suggest rewording that paragraph to
something like:

   The presentation format for SvcFieldValue is a whitespace-separated list of
   key=value pairs (e.g. "key123=value1 keys456=value2"). When the value, or
   both the value and the "=" are omitted, the value should be interpreted as
   being empty.

Or something better :)

6. In Section 2.2 it says (in reference to param field values):

   o  an octet string of the length defined by the previous field.

It might be good to say here that the format of this octet string is defined
according to the corresponding SvcParamKey, and then reference section 6 for
ths currently defined keys. The same applies for section 2.1.1 for the
presentation format.

7. Section 4.3 says:

   All DNS servers SHOULD treat the SvcParam portion of the SVCB RR...

Should it be SvcFieldValue instead of SvcParam? "SvcParam" is not mentioned
anywhere else.

8. Maybe I'm missing something, but the following sentence in Section 6.4 seems
wrong:

   When SvcDomainName is ".", server operators SHOULD NOT include these hints,
   because they are unlikely to convey any performance benefit.

My understanding is that ipv4hint and ipv6hint are the way to solve the ESNI
multi-CDN problem, so let's say I have "www.example.net" that CNAMEs to both
"cname.cdn-a.example" and "cname.cdn-b.example". A client queries both A and
HTTPSVC concurrently for "www.example.net", and receives two answers (the answer
to the A query points to CDN A, while the answer to HTTPSSVC points to CDN B):

    www.xample.net      3600 IN CNAME cname.cdn-a.example
    cname.cdn-a.example 3600 IN A 192.0.2.1

and

    www.xample.net      3600 IN CNAME cname.cdn-b.example
    cname.cdn-b.example 3600 IN HTTPSSVC 1 . alpn=h3 esniconfig="..."

My understanding is that in this case the client could end up connecting to
192.0.2.1 (CDN A) with CDN B's ESNI config (or e.g. with the wrong ALPN). So if
the server doesn't provide IP hints there would indeed be impact on performance
because the client would just straight up fail to connect initially (e.g. maybe
CDN A doesn't support HTTP/3, but CDN B's HTTPSSVC says the client can use it,
or just because of the wrong ESNI config).

Long story short, I don't think the text should discourage setting ipv4hint and
ipv6hint here. I get that it's SHOULD NOT and not MUST NOT, but it's pretty
confusing nevertheless.

9. Speaking of multi-CDN, AFAICT the problem is mentioned only once in the whole
draft and only in relation to ESNI. However this is not ESNI-specific and also
affects e.g. HTTP/3 as per the example above. So I think it would be useful to
go into a little more detail on this.

10. Section B.2: s/pther/other/

Cheers

[0] https://github.com/rthalley/dnspython/pull/452

---

From: Mark Andrews <[email-masked]>
Date: Mon, 20 Apr 2020 15:37:33 +1000

> On 17 Apr 2020, at 20:19, Alessandro Ghedini <[email-masked]> wrote:
> 
> Hello,
> 
> official early assignment from IANA,

Lets wait until we are certain that the format will not change.  Every time I’ve
updated the branch there has been a non backwards compatible change.

> but if that's not possible picking a couple

BIND’s implementation is available at:

https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/2135

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Eric Orth <[email-masked]>
Date: Mon, 20 Apr 2020 19:29:39 -0400

> cases would simplify the draft a bit without sacrificing much, though I

I think the stronger distinction makes it easier to describe the required
behavior differences.  Much simpler to just say things like don't mix both
forms in the same response, and to ignore non-alias if any aliases are
present, than to make more detailed descriptions about what specific
optional contents are allowed to be mixed or not to accomplish the same
thing.

> list of

I don't think the hints are intended for this problem.  I think the general
design idea is that A/AAAA are the definitive address results for a given
name, and clients can just optionally shortcut querying A/AAAA if given
hints.

In your example, I believe the "." HTTPSSVC entry indicates that the A/AAAA
addresses for "cname.cdn-b.example" should be used, so it doesn't seem like
there is a multi-CDN problem.  The correct addresses for the correct CDN
are used.

But I think this might point out a potential problem with skipping hints
for "." results.  If the HTTPSSVC result passes through a CNAME, a
non-HTTPSSVC-supporting recurssive will handle the CNAME, but not lookup
A/AAAA for the HTTPSSVC.  So the client gets an HTTPSSVC result
for cname.cdn-b.example but only queried A/AAAA for www.xample.net, so
without hints, the client will have to do an extra set of A/AAAA queries
for cname.cdn-b.example.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 20 Apr 2020 19:36:55 -0400

> after the introduction). It might also be a good idea to just move the

Noted as https://github.com/MikeBishop/dns-alt-svc/issues/135

3. Would it make sense to move the ESNI/ECHO config paramenter to the
> ESNI/ECHO

That's an interesting question.  My main concern with separating it is that
ECHO is the only reason we need to disable fallback, and the need to
support clients that can't use fallback is a major factor in the design.

> cases would simplify the draft a bit without sacrificing much, though I

It's true that there is no great distinction to an authoritative server.
However, the resolution procedure is quite different.  If there is an
AliasForm, the resolver should follow only one RR (ignoring all the
others), and should re-query SVCB.  Otherwise, it should follow all the
RRs, but only querying A and AAAA.

(To an authoritative, the only distinction I can think of is that "." is
not allowed for AliasForm, because it represents a reference cycle.)

>    both the value and the "=" are omitted, the value should be interpreted

Noted as https://github.com/MikeBishop/dns-alt-svc/issues/136

> Should it be SvcFieldValue instead of SvcParam? "SvcParam" is not mentioned

You're right.  https://github.com/MikeBishop/dns-alt-svc/pull/137

8. Maybe I'm missing something, but the following sentence in Section 6.4
> seems
> multi-CDN problem

Not exactly.  Hints are not required for that.  Instead, the requirement is
that each RR contains a matched SvcFieldValue and SvcDomainName, from the
same CDN.  The A/AAAA lookup for the SvcDomainName then provides the IPs.

The purpose of IP hints is to reduce resolution latency in that scenario,
only in the case where the recursive resolver is not SVCB-aware, by
avoiding the need to wait for the A/AAAA lookup.

, so let's say I have "www.example.net" that CNAMEs to both
>     cname.cdn-b.example 3600 IN HTTPSSVC 1 . alpn=h3 esniconfig="..."
(You have two distinct CNAMEs for "www.xample.net" listed there.
Technically this is not allowed by the CNAME specification.  However, we
can ignore that issue.)

> 192.0.2.1 (CDN A) with CDN B's ESNI config (or e.g. with the wrong ALPN).

No, this is not possible.  When using B's ESNI config, the only allowed IP
addresses are those for cname.cdn-b.example.

In this case (as with any case where SvcDomainName=".", IP hints would not
provide a performance advantage, because HTTPSSVC is always queried in
parallel with A/AAAA, so the record for cname.cdn-b.example will come back
along with the corresponding IPs anyway.

...

> go into a little more detail on this.

OK, please suggest text.

> 10. Section B.2: s/pther/other/

Will fix.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 20 Apr 2020 19:39:07 -0400

On Mon, Apr 20, 2020 at 7:30 PM Eric Orth <ericorth=
[email-masked]> wrote:

>> 8. Maybe I'm missing something, but the following sentence in Section
>> 6..4 seems
>> wrong:
>>
>> So if
> I don't think the hints are intended for this problem.  I think the
> general design idea is that A/AAAA are the definitive address results for a
> given name, and clients can just optionally shortcut querying A/AAAA if
> given hints.
>
> In your example, I believe the "." HTTPSSVC entry indicates that the
> A/AAAA addresses for "cname.cdn-b.example" should be used, so it doesn't
> seem like there is a multi-CDN problem.  The correct addresses for the
> correct CDN are used.
>
> A/AAAA for the HTTPSSVC.

I don't think this can happen.  Any CNAME that affects HTTPSSVC will also
affect the corresponding A/AAAA queries, which are always issued
simultaneously and to the same QNAME.

>   So the client gets an HTTPSSVC result for cname.cdn-b.example but only
> queried A/AAAA for www.xample.net, so without hints, the client will have
> to do an extra set of A/AAAA queries for cname..cdn-b.example.
>
>
>>

---

From: Eric Orth <[email-masked]>
Date: Mon, 20 Apr 2020 21:24:34 -0400

On Mon, Apr 20, 2020 at 7:39 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

> [email-masked] <[email-masked]>> wrote:
>
>>
>>
>>> 6...4 seems

alessandro@'s case was for multiple CNAME's and a recursive with behavior
that could follow those in different directions for the different
requests.  Not technically legal, but the more important question here is
whether or not significant instances behave in this non-standard way.  If
they do, this will lead to a situation where hints would be beneficial even
for "." records.

So does anybody know how common such non-standard behavior is? My 5-minute
research says that some versions of BIND allow round-robin between multiple
CNAME records.

>> queried A/AAAA for www.xample.net, so without hints, the client will
>> have to do an extra set of A/AAAA queries for cname..cdn-b.example.
>>
>>
>>>

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 20 Apr 2020 23:02:00 -0400

On Mon, Apr 20, 2020 at 9:25 PM Eric Orth <ericorth=
[email-masked]> wrote:

>>> On Fri, Apr 17, 2020 at 6:20 AM Alessandro Ghedini <
>>> [email-masked]> wrote:
>>>
>>>> Hello,
>>>>
>>> I think the stronger distinction makes it easier to describe the
>>> required behavior differences.  Much simpler to just say things like don't
>>> mix both forms in the same response, and to ignore non-alias if any aliases
>>> are present, than to make more detailed descriptions about what specific
>>>> 6....4 seems

Thanks for the explanation.  I would prefer to warn against this, rather
than encourage more use of hints.  When SvcDomainName is ".", I think not
including hints is going to perform better on average, even in the case of
multiple CNAMEs, because the split-CNAME cases should be very rare (due to
caching), but the hints add overhead to every response.  They can also
impair load balancing if managed poorly.