Re: [Add] questions about the Examples section of svcb-dns-02

[Peter van Dijk <[e-mail]>]

Hi Ben,

On Fri, 2021-04-09 at 10:50 -0400, Ben Schwartz wrote:
> On Fri, Apr 9, 2021 at 9:16 AM Eric Rescorla <[e-mail]> wrote:
> > On Fri, Apr 9, 2021 at 12:37 AM Peter van Dijk <[e-mail]> wrote:
> > 
> ... 
> > > I think this one hits the core of the problem for me. I'm not confused
> > > about what -empty- SvcParams mean. I am (well, I was) confused by
> > > alpn=h2,h3 meaning alpn=dot,h2,h3.
> > 
> > I agree. Merging default with provided is a surprising behavior. If there is a provided ALPN it should replace the default.
> > 
> 
> This behavior was chosen for SVCB primarily due to concerns about 'alpn=h3' in the HTTPS context.  Without the merge-default behavior, 'alpn=h3' would (in some cases) result in clients failing the connection if QUIC is blocked, and not falling back to TCP (because no TCP-compatible ALPN is advertised).  Some participants viewed this as a serious "footgun", because H3-only configurations will generally appear to work in testing but result in an outage when deployed, and other participants felt it was important to support H3-only endpoints, so we attempted to make it hard to do this by accident (but still possible if you really want).

Somebody said to me 'but it is exactly like in HTTPS' - my response was
'it would be if the default alpn was do53, not dot'.

> SVCB is in WGLC in DNSOP, so if you think this compromise is not reasonable, we should probably discuss it there.

Making it hard to accidentally drop https/1.1 makes sense to me, so the
compromise is reasonable.

Making it easy to accidentally include dot does not make sense to me,
so the compromise is not reasonable (as long as the default alpn is
dot).

> > > So I wonder if having a default, but alpn= always *replacing* that
> > > default instead of appending to it, might make more sense. It certainly
> > > feels clearer to me.
> 
> The interpretation of "alpn" and "no-default-alpn" is currently specified to be protocol-independent in SVCB.  We could override this in the DNS mapping (e.g. "for DNS, no-default-alpn is not used, and the ALPN is 'dot' if the alpn key is absent").  Making use of this key subtly different in each mapping makes me sad, and might make it harder to share code for handling the ALPN set, but it is possible.

I also don't like making the -logic- protocol dependent, and agree we
should avoid that when possible.

> Setting "dot" as the default ALPN seems logical to me.  However, I think it would also be reasonable to say that there is no default ALPN, because DoT is not a well-established default for encrypted DNS, in the way that HTTP/1.1 over TLS is for HTTPS.

Yes! This is exactly the insight I had in an offline conversation.
These protocols are not in the same class for their respective
purposes.

So, if we say there is no default alpn, then 


SVCB 1 @ alpn=h2,h3 dohpath=/dns-query{?dns}

means DoH, full stop. To mean what it used to mean, it would have to
say alpn=h2,h3,dot.


SVCB 2 @ port=8530

is invalid and would need alpn=dot.


SVCB 3 fooexp ( port=5353 alpn=foo no-default-alpn foo-info=... )

means what it did, with a useless no-default-alpn stanza.


I like this. Making the default alpn empty solves the confusion for
svcb-dns without affecting the https use case.

(If we go this way, it may make sense to put a few words in the parent
draft on choosing a default alpn, including the option of picking
'none', for protocols that use SVCB. I'm happy to try and write
something for that if you like.)

> > > In terms of packet size, some records may spend four more bytes on
> > > 'dot,' because they do combine it with DoH in one SVCB record. Other
> > > records will spend a few bytes less on not needing no-default-alpn. I
> > > don't know how this balances out in the end.
> 
> I expect that most encrypted DNS servers will implement DoT, especially in ADoT contexts where size is a concern, so I think the record size question will favor the current model.  However, I don't think this is a major concern.

I expect that most encrypted DNS *services* will implement DoT; I have
a harder time predicting whether they will do so on the same IPs/names
that serve DoH, DoQ, 'fooexp'. That said, I also don't consider the
size difference between defaultalpn=dot and defaultalpn='' to be a
major concern.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/