Subject: [DNSOP] SVCB without A/AAAA records at the service name

From: "Martin Thomson" <[email-masked]>
Date: Fri, 15 Jan 2021 10:43:17 +1100

As requested (I'm not engaged here enough to understand the terms of engagement, so my apologies for using an interaction form I'm accustomed to), moving discussion from https://github.com/MikeBishop/dns-alt-svc/issues/287 to here:

The SVCB draft basically mandates a fallback to A/AAAA.  I think that this is not universal and that this should instead be made an option.

For HTTP, the fallback is necessary.  For a new protocol, a fallback could be undesirable.  Especially if you want to deploy that protocol using a service name on which you have already deployed HTTP.  If you don't want your HTTP servers getting connection attempts for the new protocol, the fallback is more nuisance than useful.

---

From: Shane Kerr <[email-masked]>
Date: Fri, 15 Jan 2021 09:15:33 +0100

Martin,

> For HTTP, the fallback is necessary.  For a new protocol, a fallback could be undesirable.  Especially if you want to deploy that protocol using a service name on which you have already deployed HT…

This is an interesting observation.

Certainly with the MX fallback to A records sometimes SMTP delivery is 
attempted (or made!) to the wrong server. So we know that this happens.

Cheers,

--
Shane

---

From: Paul Vixie <[email-masked]>
Date: Fri, 15 Jan 2021 00:48:11 -0800

Martin Thomson wrote on 2021-01-14 15:43:
> ...
> 
> The SVCB draft basically mandates a fallback to A/AAAA.  I think that
> this is not universal and that this should instead be made an
> option.
> 
> For HTTP, the fallback is necessary.  For a new protocol, a fallback
> could be undesirable.  Especially if you want to deploy that protocol
> using a service name on which you have already deployed HTTP.  If you
> don't want your HTTP servers getting connection attempts for the new
> protocol, the fallback is more nuisance than useful.

i see what you mean and i agree.

vixie

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 15 Jan 2021 14:01:53 -0500

FWIW, I think this is really an editorial question.  The SVCB draft lays
out how we expect SVCB to be used initially, but there are very few
constraints on how some future protocol specification could make use of the
RR type.  That includes the various possible fallback behaviors.

I'm happy to adjust the text for clarity on this point.  Here are two
alternatives for how to clarify the text:

1. Specify the expected behavior of future SVCB-reliant protocols (which do
not yet exist):
https://github.com/MikeBishop/dns-alt-svc/pull/288

2. Clarify that this section's recommendations are only defaults, and
future protocols can do whatever they want:
https://github.com/MikeBishop/dns-alt-svc/pull/289

On Thu, Jan 14, 2021 at 6:43 PM Martin Thomson <[email-masked]> wrote:

> As requested (I'm not engaged here enough to understand the terms of
> engagement, so my apologies for using an interaction form I'm accustomed
> to), moving discussion from
> https://github.com/MikeBishop/dns-alt-svc/issues/287 to here:
>
> The SVCB draft basically mandates a fallback to A/AAAA.  I think that this
> is not universal and that this should instead be made an option.
>
> For HTTP, the fallback is necessary.  For a new protocol, a fallback could
> be undesirable.  Especially if you want to deploy that protocol using a
> service name on which you have already deployed HTTP.  If you don't want
> your HTTP servers getting connection attempts for the new protocol, the
> fallback is more nuisance than useful.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Eric Orth <[email-masked]>
Date: Fri, 15 Jan 2021 15:02:12 -0500

My preference would be the change in 289.  Maximizes keeping things open
for future protocols rather than attempting to predict the needs of the
protocols.

On Fri, Jan 15, 2021 at 2:02 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

> 1. Specify the expected behavior of future SVCB-reliant protocols (which
> do not yet exist):
>> this is not universal and that this should instead be made an option.
>>
>> could be undesirable.  Especially if you want to deploy that protocol using
>> a service name on which you have already deployed HTTP.  If you don't want

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 18 Jan 2021 09:56:42 +1100

On Sat, Jan 16, 2021, at 06:01, Ben Schwartz wrote:
> FWIW, I think this is really an editorial question.  
...
... 
> https://github.com/MikeBishop/dns-alt-svc/pull/289

Neither of these work for me.  Both do the same thing in different ways.  Both are unspecific about what changes might be made to the algorithm.  That leads to far less certainty about how the information is consumed than I think is sensible.

What I'm looking for here is for the specification to describe what happens when the protocol needs to fall back to A/AAAA and what happens when it does not.  The first is important, because that is what HTTP will need.  The second because I think that is a better approach for any new protocol (I had hoped that webtransport would be able to take advantage of this, but they made a different choice for reasons I'm yet to understand).

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 19 Jan 2021 10:09:45 -0500

On Sun, Jan 17, 2021 at 5:57 PM Martin Thomson <[email-masked]> wrote:

> Neither of these work for me.  Both do the same thing in different ways.
> Both are unspecific about what changes might be made to the algorithm.

To my eye, #288 looks extremely specific.  I'm surprised we disagree about
this!

>   That leads to far less certainty about how the information is consumed
> than I think is sensible.
>
> What I'm looking for here is for the specification to describe what
> happens when the protocol needs to fall back to A/AAAA and what happens
> when it does not.

I think #288 is quite "specific" about what happens in that case.  (Whether
it's "sensible" is a separate question.)

>   The first is important, because that is what HTTP will need.  The second
> because I think that is a better approach for any new protocol (I had hoped
> that webtransport would be able to take advantage of this, but they made a
> different choice for reasons I'm yet to understand).
>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 20 Jan 2021 08:11:36 +1100

On Wed, Jan 20, 2021, at 02:09, Ben Schwartz wrote:
> I think #288 is quite "specific" about what happens in that case.  
> (Whether it's "sensible" is a separate question.)

Sorry, I was talking mostly about #299, which has the problem I identified.

The problem with #288 is that it doesn't say that the A/AAAA queries aren't made if they aren't needed.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 19 Jan 2021 17:17:47 -0500

> aren't made if they aren't needed.

As I noted in that discussion, the client generally doesn't know in advance
that they aren't needed.  In principle, we could describe two different
kinds of future protocols (one in which clients know they aren't needed,
and one in which they do not), but I think that would just add confusion.
I do expect these A/AAAA records to be useful in the common case for future
protocols.

Another thing I like about the arrangement in #288 is that it simplifies a
protocol-independent app/library boundary.  The app can say
"SVCBQuery(hostname, prefixes)" and get back a fully resolved object like
{svcbEntries: [{...}, ...], hostIPs: [...]}.  If the hostIPs aren't useful
for this protocol, the app can ignore them, while still getting the latency
benefit if any of the svcbEntries rely on them.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 20 Jan 2021 11:40:31 +1100

On Wed, Jan 20, 2021, at 09:17, Ben Schwartz wrote:
> As I noted in that discussion, the client generally doesn't know in 
> advance that they aren't needed.  

I am asserting that the client very much knows.  Indeed, it has to know.  If we define a new protocol that relies on SVCB and that protocol is able to use SVCB exclusively (which would be a good thing in my view, all this parallel DNS querying is unnecessary, even if the DNS protocol is pretty good at it), then a client can very much know.

> Another thing I like about the arrangement in #288 is that it 
> simplifies a protocol-independent app/library boundary.  The app can 
> say "SVCBQuery(hostname, prefixes)" and get back a fully resolved 
> object like {svcbEntries: [{...}, ...], hostIPs: [...]}.  

I'm suggesting that the interface might be a little wider.  If the interface is provided with a scheme, them the library might be able to lookup the scheme and know whether A/AAAA is needed, but it might be better to have a very different interface for those protocols that might need fallback as opposed to those that don't.

A protocol might genuinely need SVCB.  If additional SVCB information is critical to the operation of the protocol (think ECH here, but there might be other reasons for this), then the API might look like (eliding the attr-leaf and prefixing stuff):

svcb.query(name) -> svcbEntry[] // where the API fills in an address (or addresses) for each svcbEntry

This is far more ergonomic for something that doesn't care about A/AAAA.  And less wasteful.  If a fallback is possible, then you get something very different, which requires additional logic to handle:

svcb.query_with_fallback(name) -> Either<svcbEntry[], address[]>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 19 Jan 2021 22:00:35 -0500

On Tue, Jan 19, 2021 at 7:40 PM Martin Thomson <[email-masked]> wrote:

> I am asserting that the client very much knows.  Indeed, it has to know.
> If we define a new protocol that relies on SVCB and that protocol is able
> to use SVCB exclusively (which would be a good thing in my view, all this
> parallel DNS querying is unnecessary, even if the DNS protocol is pretty
> good at it), then a client can very much know.
>

Querying in parallel is of course just an optimization, but the client
can't obviously know that those queries won't be needed, even for a
protocol that uses SVCB exclusively.

Every SVCB mapping ultimately relies on A/AAAA records for the ServiceMode
TargetName.  The client doesn't know what that TargetName will be until it
gets the SVCB response.  However, in every protocol considered thus far,
the most likely TargetName is the original hostname (or its CNAME alias).
By querying that name in parallel, the client can short-circuit a
subsequent lookup and reduce latency.  This has nothing to do with fallback.

Section 10.2 ("Structuring zones for performance") takes this observation
and turns it into a recommended convention for the use of TargetName.  You
can place TargetName anywhere, but if you can line it up with the hostname
you'll get better performance, so that's recommended.

If I were arguing for your version, I would say either:
1. By the time we have SVCB-reliant protocols, nearly all resolvers will
have implemented Additional Section processing, so the client won't have to
issue A/AAAA queries at all.
OR 2. There will be SVCB-reliant protocols where it is normally
inconvenient to use A/AAAA records on the hostname, so the client knows
that the TargetName->hostname convention doesn't apply.

Personally, I don't believe either of those things ... and since they're
both predictions about future standards, we can always clarify in the
future.

It's worth noting that the sentence in question (Section 3 point 2) has no
normative force.  That section is just describing what clients are expected
to do.  So if you want to do it differently ... whatever works.

> I'm suggesting that the interface might be a little wider.

Sure, that's fine too.

...

> svcb.query_with_fallback(name) -> Either<svcbEntry[], address[]>

Nit: Pair<svcbEntry[], address[]>.  If the svcbEntries are all unreachable,
clients SHOULD fall back to bare IPs.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 22 Jan 2021 17:43:28 +0000

From: DNSOP <[email-masked]> On Behalf Of Ben Schwartz
Sent: Tuesday, January 19, 2021 10:01 PM
To: Martin Thomson <[email-masked]>
Cc: dnsop <[email-masked]>
Subject: [EXTERNAL] Re: [DNSOP] SVCB without A/AAAA records at the service name

On Tue, Jan 19, 2021 at 7:40 PM Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

   Querying in parallel is of course just an optimization, but the client can't obviously know that those queries won't be needed, even for a protocol that uses SVCB exclusively.

   Every SVCB mapping ultimately relies on A/AAAA records for the ServiceMode TargetName.  The client doesn't know what that TargetName will be until it gets the SVCB response.  However, in every protocol considered thus far, the most likely TargetName is the original hostname (or its CNAME alias).  By querying that name in parallel, the client can short-circuit a subsequent lookup and reduce latency.  This has nothing to do with fallback.

   [SAH] We need to think about the impact on the servers that have to respond to those queries, too. Sending unnecessary queries to the root and TLD servers puts a load on those servers that can have an impact on every client/resolver that needs to be able to reach them. This is a further motivation for the resolver to implement qname minimization with a single resource record type.

   It might be worth reading this blog post to get a better understanding of the impact of another recent source of unintended additional queries to the root servers:

   https://blog.verisign.com/domain-names/chromiums-reduction-of-root-dns-traffic/

   Scott

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 22 Jan 2021 13:29:17 -0500

On Fri, Jan 22, 2021 at 12:43 PM Hollenbeck, Scott <shollenbeck=
[email-masked]> wrote:

> *From:* DNSOP <[email-masked]> *On Behalf Of * Ben Schwartz
> *Sent:* Tuesday, January 19, 2021 10:01 PM
> *To:* Martin Thomson <[email-masked]>
> *Cc:* dnsop <[email-masked]>
> *Subject:* [EXTERNAL] Re: [DNSOP] SVCB without A/AAAA records at the
> service name
>
>
>
>
>
>
>
> *[SAH] We need to think about the impact on the servers that have to
> respond to those queries, too. Sending unnecessary queries to the root and
> TLD servers puts a load on those servers that can have an impact on every
> client/resolver that needs to be able to reach them.*
>

This is important, but I don't think it's applicable here.  The various
options under consideration all impose the same amount of load on root and
TLD servers.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 25 Jan 2021 13:05:50 +0000

From: Ben Schwartz <bemasc=[email-masked]>
Sent: Friday, January 22, 2021 1:29 PM
To: Hollenbeck, Scott <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: Re: [DNSOP] SVCB without A/AAAA records at the service name

On Fri, Jan 22, 2021 at 12:43 PM Hollenbeck, Scott <shollenbeck=[email-masked]<mailto:[email-masked]>> wrote:

   From: DNSOP <[email-masked]<mailto:[email-masked]>> On Behalf Of Ben Schwartz
   Sent: Tuesday, January 19, 2021 10:01 PM
   To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
   Cc: dnsop <[email-masked]<mailto:[email-masked]>>
   Subject: [EXTERNAL] Re: [DNSOP] SVCB without A/AAAA records at the service name

   [SAH] We need to think about the impact on the servers that have to respond to those queries, too. Sending unnecessary queries to the root and TLD servers puts a load on those servers that can have an impact on every client/resolver that needs to be able to reach them.

   This is important, but I don't think it's applicable here.  The various options under consideration all impose the same amount of load on root and TLD servers.

   [SAH] So if some number if queries X and some number of queries Y are processed in parallel, the value of X + Y will be the same as if those queries are processed serially?

   Scott

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 25 Jan 2021 17:04:01 -0500

On Mon, Jan 25, 2021 at 8:06 AM Hollenbeck, Scott <shollenbeck=
[email-masked]> wrote:

> *[SAH] So if some number if queries X and some number of queries Y are
> processed in parallel, the value of X + Y will be the same as if those
> queries are processed serially?*
>

Yes, if the SVCB record uses the hostname as the TargetName, as suggested
in section 10.2, then there are no additional queries; they are merely
issued in parallel rather than sequentially.

Regardless of whether the speculative queries are wasted, your question was
whether they would impose more load on TLD or root servers.  If the
domain's NS record is cached at the resolver, then they certainly will
not.  (All queries will go to the authoritative nameserver.)  If QNAME
minimization is applied, they also should not.  (They will all trigger the
same qname-minimized query to the root and TLD, and a reasonably
intelligent resolver shouldn't emit duplicate queries when one is already
in flight.)

If the NS record is not cached, and the resolver does not implement qname
minimization, then perhaps it is possible that the additional queries could
leak to the TLD, or to the root if the TLD NS record is not cached.  The
behavior would be similar to speculative AAAA queries today.  (I'm not
aware of these being a cause for alarm among root or TLD operators.)

Note that this conversation only concerns hypothetical future non-HTTP
protocols that rely exclusively on SVCB.  We are a very long way from any
such protocol (1) existing and (2) having enough usage to concern the root
or TLD operators.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 26 Jan 2021 12:52:23 +0000

From: Ben Schwartz <bemasc=[email-masked]>
Sent: Monday, January 25, 2021 5:04 PM
To: Hollenbeck, Scott <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: Re: Re: [DNSOP] SVCB without A/AAAA records at the service name

On Mon, Jan 25, 2021 at 8:06 AM Hollenbeck, Scott <shollenbeck=[email-masked]<mailto:[email-masked]>> wrote:

   Yes, if the SVCB record uses the hostname as the TargetName, as suggested in section 10.2, then there are no additional queries; they are merely issued in parallel rather than sequentially.

   Regardless of whether the speculative queries are wasted, your question was whether they would impose more load on TLD or root servers.  If the domain's NS record is cached at the resolver, then they certainly will not.  (All queries will go to the authoritative nameserver.)  If QNAME minimization is applied, they also should not.  (They will all trigger the same qname-minimized query to the root and TLD, and a reasonably intelligent resolver shouldn't emit duplicate queries when one is already in flight.)

   If the NS record is not cached, and the resolver does not implement qname minimization, then perhaps it is possible that the additional queries could leak to the TLD, or to the root if the TLD NS record is not cached.  The behavior would be similar to speculative AAAA queries today.  (I'm not aware of these being a cause for alarm among root or TLD operators.)

   Note that this conversation only concerns hypothetical future non-HTTP protocols that rely exclusively on SVCB.  We are a very long way from any such protocol (1) existing and (2) having enough usage to concern the root or TLD operators.

   [SAH] Thanks for the clarification, but I have to disagree that it’s not a concern for operators. We would be wise to pay attention to such things long before use causes measurable impact on those servers.

   Scott

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 26 Jan 2021 14:59:27 -0500

I'd like to try to get to consensus on this point, which is one of the last
open issues for the draft.

To restate my previous argument, let P_svcb be the probability that a SVCB
record is present, and if so, let P_targethost be the probability that it
contains a TargetName that is the hostname.  Then (ignoring Additional
Section processing) the initial AAAA/A query saves (1 - P_svcb) +
P_svcb*P_targethost resolver roundtrips, on average.

Currently, for HTTPS, P_svcb is about 15%(!), and P_targethost is ~100%*,
so this always saves one resolver roundtrip.

For a SVCB-reliant protocol, P_svcb is 100%, so the formula simplifies to
"P_targethost".  If P_svcb for HTTPS were to approach 100%, the result
would be the same, even though HTTPS is not SVCB-reliant.

In other words, keeping P_targethost high, and using speculative queries,
is good for performance when SVCB is heavily used.

* Assuming Cloudflare has the only current large-scale deployment of HTTPS
records.

On Tue, Jan 19, 2021 at 10:00 PM Ben Schwartz <[email-masked]> wrote:

> Nit: Pair<svcbEntry[], address[]>.  If the svcbEntries are all
> unreachable, clients SHOULD fall back to bare IPs.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 27 Jan 2021 11:35:18 +1100

My apologies here, I think that I misunderstood the structure of the proposed algorithm originally, however, that might be an opportunity to improve the description.

My conclusion here is not the same as yours.  If you require SVCB, you might need a different algorithm, or at a minimum you need to run the math (as you have) for whether you will get a TargetName and whether the TargetName will be "." before considering the optimizations you are promoting.

If you use HTTPS as the example, the algorithm, as described, is completely reasonable.  But HTTPS is weird.  If you are looking at a new protocol deployment, other factors, such as compatibility with HTTPS deployments, might change those numbers considerably.  That is, P_svcb in this alternative setting is 1.  If we were to do this for a protocol that was allergic to HTTPS - SMTP is probably a bad example because MX exists, but imagine a similar deployment arrangement - the result might be that the probability of there being a TargetName in the record is closer to 0 due to the prevalence of outsourcing of serving.  At that point, you might decide not to spend the cycles on A/AAAA queries.

HTTPS is also weird in the sense that it is so aggressively latency sensitive.  Even if P_targethost was extraordinarily low (maybe not 1%, but we've wasted cycles on gains with far worse odds), we'd still probably spend the effort on it.

So I think that you have this entirely backwards.   The concurrent querying of SVCB and A/AAAA is some combination of an optimization and unique to the one worked example we have.  Acknowledging that might allow the draft to be much clearer about the logical structure of the process clients follow AND make it clearer where the optimization opportunities are and how clients might reasonably decide to take advantage of them.  Then you can explain how different deployment choices (such TargetName == ".") might further take advantage of those optimizations.

As it is, the algorithm is presented as being definitive, but it really isn't.  What you have is the optimized version of the algorithm, with no real acknowledgment that alternatives might exist.

--Martin

On Wed, Jan 27, 2021, at 06:59, Ben Schwartz wrote:
> I'd like to try to get to consensus on this point, which is one of the 
> last open issues for the draft.
> 
> To restate my previous argument, let P_svcb be the probability that a 
> SVCB record is present, and if so, let P_targethost be the probability 
> that it contains a TargetName that is the hostname.  Then (ignoring 
> Additional Section processing) the initial AAAA/A query saves (1 - 
> P_svcb) + P_svcb*P_targethost resolver roundtrips, on average.  
> 
> Currently, for HTTPS, P_svcb is about 15%(!), and P_targethost is 
> ~100%*, so this always saves one resolver roundtrip.
> 
> For a SVCB-reliant protocol, P_svcb is 100%, so the formula simplifies 
> to "P_targethost".  If P_svcb for HTTPS were to approach 100%, the 
> result would be the same, even though HTTPS is not SVCB-reliant.
> 
> In other words, keeping P_targethost high, and using speculative 
> queries, is good for performance when SVCB is heavily used.
> 
> * Assuming Cloudflare has the only current large-scale deployment of 
> HTTPS records.
> 
> > Section 10.2 ("Structuring zones for performance") takes this observation and turns it into a recommended convention for the use of TargetName.  You can place TargetName anywhere, but if you can line it up with the hostname you'll get better performance, so that's recommended.
> > 
> > 1. By the time we have SVCB-reliant protocols, nearly all resolvers will have implemented Additional Section processing, so the client won't have to issue A/AAAA queries at all.
> > OR 2. There will be SVCB-reliant protocols where it is normally inconvenient to use A/AAAA records on the hostname, so the client knows that the TargetName->hostname convention doesn't apply.
> > 
> > Personally, I don't believe either of those things ... and since they're both predictions about future standards, we can always clarify in the future.
> > 
> > It's worth noting that the sentence in question (Section 3 point 2) has no normative force.  That section is just describing what clients are expected to do.  So if you want to do it differently ... whatever works.
> > 
> > Nit: Pair<svcbEntry[], address[]>.  If the svcbEntries are all unreachable, clients SHOULD fall back to bare IPs. 
> Attachments:
> * smime.p7s