Subject: [DNSOP] draft-ietf-dnsop-svcb-httpssvc-01 feedback

From: Eric Orth <[email-masked]>
Date: Fri, 6 Dec 2019 17:43:56 -0500

Been reviewing the latest draft with a bunch of relevant experts within the
Chrome team.  As has been stated in previous emails and in WG sessions, we
generally like the HTTPSSVC approach and are very interested in trying out
an implementation.

Some specific feedback:

   - The name: I still hate the name “HTTPSSVC” because I have trouble
   saying it.  Please paint the bikeshed a different color.
   - Section 1.3: Compared to previous drafts, not much value anymore in
   SvcFieldPriority being a first-class field outside SvcFieldValue.  Client
   will need to fully parse SvcFieldValue to decide the real priority (to
   prefer ESNI and discount unsupported protocols, etc).  Although I will
   admit that it is elegant that multiple aliases get treated as multiple
   0-priority records in that one is randomly picked and non aliases get
   ignored.
   - Section 2.5: We see no valid reason to support an alias chain 8 nodes
   long.  Such a case is likely only configuration error, and following the
   full chain would subject our users to bad performance that the configurer
   is not likely to notice and fix.  Therefore, unless somebody comes up with
   a good reason that longer chains need to be supported, we intend to only
   follow 1 or 2 links before giving up on following the chain further, and
   the spec should be updated to say that such chains should be limited as
   such.  I hear not everybody in the stack can reasonably enforce this limit,
   so maybe state that longer chains are not valid, should not be created, and
   clients/resolvers that can enforce limits should use the value specced here
   for that enforcement.

   I think it would also be helpful for this section to clarify the
   expected behavior on detection of a loop or too-long chain: Fail entirely,
   use the non-SVCB fallback addresses, or use the furthest-down-the-chain
   service records found if such records are mixed with alias records?
   - Section 4: Very much “yes, please” on including the recursive results
   in Additional to prevent additional queries.  We are very sensitive to
   unnecessary latency in DNS.
   - Section 6.1: We have some concerns with the use of ALPN values to
   specify this.  This is complicated enough that we will start a separate
   email thread soon to discuss this point.
   - Section 7: States that HTTPSSVC is only used for http and https
   schemes.  But Chrome also deals with other schemes with implied http URLs,
   like websockets.  There should be clarification text that HTTPSSVC is also
   used for these schemes, with wss:// queried as if it were https:// and
   ws:// queried as if it were http://.  We consider it important for HSTS
   and HSTS-like behavior such as HTTPSSVC existence to also apply to the
   related ws:// URL.
   - Section 7.4: I believe this is saying the correct thing with a strict
   reading (that http://example.com:80 becomes HTTPSSVC(example.com)), but
   I think some more clarity would be helpful.  The text of “specify port 443”
   and such may make it sound like you’re constructing the HTTPSSVC query URL
   including specifying 443 (HTTPSSVC(_443._https.example.com)), but from
   section 7.1, the port is obviously not supposed to be specified.  Maybe
   some extra clarity that these rules are for constructing the actual
   redirect URL (not the query URL) and that that URL then gets encoded into
   an HTTPSSVC query via the rules of section 7.1.

   Also, this section seems slightly inconsistent with section 7.1 in that
   7.1 states HTTPSSVC is used for http and https, but in actuality, HTTPSSVC
   is only used for querying https and section 7.4 shows how to create an
   appropriate https URL to query when you’re starting from an http URL.

   Also, I think this section should clarify that any HTTPSSVC result,
   including alias form, is sufficient for the client to read it as a signal
   to upgrade to HTTPS. Otherwise there may be some confusion over whether or
   not only service form records are sufficient.

   Also, this section states that connection should be abandoned on
   SERVFAIL because it might be a DNSSEC error.  But I think the spec should
   clarify that the client may continue if it has reason to believe the error
   was not caused by DNSSEC validation (e.g. because of an EDE specifying that
   the error was something else).
   - Section 8.1: We’re very sensitive to any situation where it’s too easy
   to accidentally configure DNS to disable QUIC -> TCP fallback. Some of our
   users are behind networks where QUIC cannot get through. If the HTTPSSVC
   records with esiconfig are h3, section 8.1 imples we cannot try TCP because
   that would lose ESNI. Ideally this would be treated as a misconfiguration
   somehow. Failing that, perhaps the ESNI fallback rules should be left open
   to client policy.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 6 Dec 2019 15:13:55 -0800

On Fri, Dec 6, 2019 at 2:45 PM Eric Orth <ericorth=
[email-masked]> wrote:

> Been reviewing the latest draft with a bunch of relevant experts within
> the Chrome team.  As has been stated in previous emails and in WG sessions,
> we generally like the HTTPSSVC approach and are very interested in trying
> out an implementation.
>
> Some specific feedback:
>
>    - Section 2.5: We see no valid reason to support an alias chain 8
>    nodes long.  Such a case is likely only configuration error, and following
>    the full chain would subject our users to bad performance that the
>    configurer is not likely to notice and fix.  Therefore, unless somebody
>    comes up with a good reason that longer chains need to be supported, we
>    intend to only follow 1 or 2 links before giving up on following the chain
>    further, and the spec should be updated to say that such chains should be
>    limited as such.  I hear not everybody in the stack can reasonably enforce
>    this limit, so maybe state that longer chains are not valid, should not be
>    created, and clients/resolvers that can enforce limits should use the value
>    specced here for that enforcement.
>
>
There are several important points on this, particularly from the
perspective of DNS folks.

   1. The main motivation for ANAME, and for us being happy with H6C
   solving the problems with ANAME and making it un-necessary, is that current
   "apex CNAME hacks" are all limited to incompatible vertically-integrated
   providers. Too short an alias chain has the potential effect of
   constraining actual use of H6C to vertically-integrated providers. This is
   not acceptable, and non-negotiable; the minimum length needs to be
   demonstrated as facilitating real-world use in heterogenous environments.
   2. The whole concept of CNAME (and implicitly H6C) is that the owner of
   the CNAME (left hand side) and the target (right hand side) aren't
   guaranteed to be under control of a single administrative entity. The
   operator of the target may not even be aware of being the target of a
   CNAME. So, the semantic construct "configurer" isn't really guaranteed to
   exist, and performance issues may not reside in a single entities' area of
   responsibility.
   3. Notwithstanding the desire of browsers to have good performance,
   there is no way to force good performance universally, regardless of such
   desire. DNS latency is often unrelated to number of iterations in
   CNAME/DNAME/H8C.
   4. Latency will only occur at the time of first resolution of any given
   chain. Resolver caches will serve the results for min({TTL of all records
   in the chain}). Refreshing expired records (similar to HAMMER) can mitigate
   any cache expiry impact.

There are any number of reasons longer chains might be created, and I think
having data to analyze on the distribution of lengths of chains, plus the
relative popularity, should inform any choice of limit.
Once that data is available, I'd suggest something like 3 sigmas above
median value, as a starting point for the discussion.

Brian

---

From: Patrick McManus <[email-masked]>
Date: Sat, 7 Dec 2019 10:07:27 -0500

On Fri, Dec 6, 2019 at 5:45 PM Eric Orth <ericorth=
[email-masked]> wrote:

>
>
>    - Therefore, unless somebody comes up with a good reason that longer
>    chains need to be supported, we intend to only follow 1 or 2 links before
>
>
>
I'm sure you're not trying to undermine the standards process, but that's
what happens as a side effect of statements like that. We're at an -01,
let's discuss (as Brian does downthread) the reasoning behind design
decisions and see if we can get to consensus on them without threatening to
take the ball and go home already. If there is eventual consensus and
you're in the rough and feel its bad for your product then the appropriate
thing to do is not to implement a standard you don't believe in. but
implementing a different protocol and calling it httpsssvc does nothing but
lead to breakage and undermine the entire point of having a standards based
definition.

Maybe you mean you strongly believe this standard should allow at most 2
links?

Brian has got a good point that these are pointers, and pointers don't know
how long the list is and the parties in the list are not strongly
coordinated (which is what makes a pointer powerful - its permissionless).
This also complicates ESNI, but its a fact of life. Also, people trade
latency off against indirection all of the time for reasons they think are
valuable (that's true of DNS but also in general). It would be interesting
to study the distribution of chain lengths, but I can say off the cuff that
3 is really common in web space and imo, this spec should be aligning
itself with existing deployment strategies in order to make its own path to
deployment as frictionless as possible.

;; ANSWER SECTION:
download.microsoft.com. 1471 IN CNAME 2-01-4ca6-0004.cdx.cedexis.net.
2-01-4ca6-0004.cdx.cedexis.net. 19 IN CNAME main.dl.ms.akadns.net.
main.dl.ms.akadns.net. 160 IN CNAME download.microsoft.com.edgekey.net.
download.microsoft.com.edgekey.net. 12 IN CNAME e3673.dscg.akamaiedge.net.
e3673.dscg.akamaiedge.net. 8 IN A 23.46.196.215

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 9 Dec 2019 13:03:35 -0500

Changed title to reflect this thread's topic.

I wanted to add some background on this question (which is also
tracked on Github:
https://github.com/MikeBishop/dns-alt-svc/issues/57).

SVCB supports two forms, one of which ("AliasForm") acts somewhat like
a CNAME, and in principle could be chained indefinitely.  The current
draft says

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

This discussion is about finding a good replacement for this
placeholder language.  (IMHO the placeholder is also problematic
because it arguably alters requirements for CNAME handling.)

SVCB is fully "mixable" with CNAME, so there's no need to use SVCB's
AliasForm when CNAME will do.  CNAME chains are followed at every step
of SVCB resolution.  AliasForm's only significant* advantage is that
it can be used at a zone apex.

AliasForm also has a serious downside compared to CNAME: clients whose
recursive resolver is not SVCB-aware will have to follow the alias
themselves, resulting in significantly slower resolution than a CNAME.
For this reason, domain owners should avoid using AliasForm if CNAME
will suffice.

If zone owners are testing/benchmarking with recursive resolvers that
are SVCB-aware or have very low latency (as seems likely), they may
not expect this penalty, and there is no way for them to detect or
measure it after deployment.  I have heard this called a "performance
footgun".  Hopefully this explains why some developers have asked to
limit the use of AliasForm.

Currently (pre-SVCB), the number of apex names that can be present in
a chain is zero (excluding the final name).  The question at hand is:
should we increase this limit to 1? 2? 8? Unspecified?  We have a
clear use case for 1 (aliasing https://example.com/), but I have yet
to hear of a use case that needs a limit higher than 1.

There are also several other possible ways to discourage unnecessary
uses of AliasForm.  For example, we could:
 - make it possible for zone owners to tell whether their clients are
using an SVCB-aware recursive, by making clients' alias chasing
behavior different from recursives'
 - extend the W3C Resource Timing API (at the W3C) to indicate when
multiple DNS queries were required
 - ask SVCB-aware recursives to SERVFAIL on AliasForm records that are
not at an apex (excluding _prefixed labels)

--Ben

*For HTTPSSVC (but not SVCB), another difference is that CNAME would
affect all protocols, whereas AliasForm only affects HTTP connections.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 9 Dec 2019 14:43:11 -0500

we should not limit the alias chain length across zones (other than for
loop protection which should be standardized) because there is no
administrative consistency across zones - its just a pointer. So the alias
you're pointing at now might become an alias itself later totally out of
your control.. or it might inconsistently do so thanks to
localized/balanced results you don't have any view into. Or, vice-versa,
someone might be pointing an alias at you when you do add an alias record
and you break them suddenly. You can say "don't point at an apex", but the
property of an apex isn't a constant one either - so someone adds a new
apex and breaks everyone that has an alias pointing at them. This is not
centrally coordinated so adding rules that need to be socially tracked
beyond the configuration you actually control is an un-necessarily fragile
system.

I also don't think a value of 1 achieves performance goals because when it
works it just replaces aliases with cnames and they perform the same. Plus,
it creates situations where it doesn't work - and that definitely performs
worse :)

As for use cases, I don't think there is any reason to think an apex wants
fewer redirections than non-apex. We all know that 0 is a real problem, and
that non-apex can have quite a few. redirections are a performance problem,
but substituting cname pointers for alias pointers doesn't improve that.

The loop protection text should indicate that the length of the chain is
inclusive of both kinds of indirections.

-P

On Mon, Dec 9, 2019 at 1:03 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

> > Chains of consecutive SVCB and CNAME records SHOULD be limited to (8?)
> prior to reaching terminal address records.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Brian Dickson <[email-masked]>
Date: Mon, 9 Dec 2019 12:46:35 -0800

> limit the use of AliasForm.
So, there is historical experience with other deployments of tech, that
leads to me suggest we not take this approach.*

The gist of the issue is, whether we can consider this RRTYPE to be a first
class type.

My position is, if this is something adopted, it MUST be a first-class type.

I recognize that this may seem a hard line to take, but the alternative
approaches all lead to delayed uptake on the resolver side, which can lead
to an eventual failure of the type itself.*

While there is definitely a potential down-side to early use of the new
type, there may be ways of mitigating this, by strongly encouraging
upgrades to resolvers to support this type.

E.g. this could potentially be added to something like the DNS "Flag Day"
for an upcoming year, ideally if we can get this all locked down and
published, in 2020's flag day. Or, pushed as a security thing with a CVE
(real or not).

The example I like to use for adding something that by itself might not
have been compelling, where having it has been very helpful in retrospect
was having DNAME being required as part of DNSSEC and thus implicitly
required for EDNS support.

Making AliasForm a first class type, means making it exactly the same
semantically as CNAME (and DNAME, it is worth noting), with no restrictions
on either location or chain length (beyond loop checking) from DAY ONE, not
at some unspecified later date.

The issues of performance SHOULD (IMNSHO) be directed where they really
belong, on the recursive resolvers, not the authoritative servers (via
limits on where and how deep chains can occur).

I'm happy to elaborate on any of this to educate anyone not intimately
familiar with Flag Day, DNAME, EDNS, or other DNS-history-specific things
referenced here -- contact me offline at your convenience.

Brian

* SPF; anything else that overloaded TXT; DNSSEC validation; EDNS(0); DNS
MTU generally; OPT RRTYPE handling of new/unknown TLVs; new/unknown
RRTYPEs; etc.

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 13 Dec 2019 16:03:43 +0100

On 12/6/19 11:43 PM, Eric Orth wrote:
> Section 1.3: Compared to previous drafts, not much value anymore in
> SvcFieldPriority being a first-class field outside SvcFieldValue. [...]

There's still advantage for resolvers implementing the chain-jumping
(Sec. 4); it allows them to avoid looking inside SvcFieldValue.  That
might indirectly help the overall deployment, as that feature seems to
be desired a lot (on this list).

--Vladimir

---

From: Eric Orth <[email-masked]>
Date: Mon, 23 Dec 2019 15:22:01 -0500

Maybe it would help if we scoped down any chain limiting:

1) Any chain limiting only applies to SVCB alias form, not CNAME.

CNAMEs already exist without a standardized limit.  Good or bad, too late
to change that without breaking things.  SVCB alias chains, as well as
aliasing apex names, are new and thus currently limited to zero.

2) Any chain limiting enforcement only applies to stubs following chains,
not recursives.

Recursives are already following CNAMEs without a standardized limit.
Speaking for the one stub resolver I know well, Chrome DNS, we don't
currently directly follow any CNAME links, relying on the recursive to do
it for us.  So the current CNAME chain limit in Chrome is also zero.  Any
chain following at all, CNAME or SVCB alias, is an increase of our current
practical limit of zero.

SVCB-aware recursives could resolve the chain without limit as they
currently do with CNAME.  Unlimited chain following anywhere seems
non-ideal to me, but my expertise is not on the recursive side so maybe
it's completely reasonable.  But if we're relying on the stubs to follow
chains (that may not have been followed there at all before) to account for
SVCB-unaware recursives, we should empower them to use chain limits
reasonable for them.  Being typically further away from results and with
less caching, unlimited chain following just does not seem reasonable for a
stub like Chrome, and it seems to us to have a big potential to be
detrimental to our users' experiences compared to the status quo of not
following any chains.

This point of scoping down is partly in response to Brian Dickson's reply
that SVCB alias should be first class and at least as powerful as CNAME.
Limiting chains in stubs makes chains practically limited everywhere for
most general cases because authoritatives will want to support the cases
where the recursive is SVCB-unaware.  But if there's going to be some "Flag
Day" by which all the recursives we care about add SVCB support without
limit, that will be the point after which the practical limit will be gone
and SVCB aliasing becomes fully empowered as a CNAME substitute.

3) Any chain limiting only applies to HTTPSSVC, not SVCB.

HTTPSSVC is a much more specific area where the usecases are more
understood.  I think when we say we don't see any usecases where needing
more than one alias makes sense, we're really only talking about the
well-understood HTTPS cases.  Anything else using SVCB is more generic and
hard to pin down whether or not any limits make sense or would be
reasonable.

And when you scope down chain limiting to just HTTPSSVC, the arguments
become less valid that aliasing could point to other organizations without
coordination over whether or not the one allowed alias is yet used.  In
HTTPS, the end server needs the cert for the domain.  There should be
coordination and trust between organizations in the alias chain, and the
organizations should be able to coordinate who is in charge of aliasing
from an apex domain.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 23 Dec 2019 12:57:31 -0800

> aliasing apex names, are new and thus currently limited to zero.

Disagree. These alias-form changes are not yet standardized, and the limits
(zero or otherwise) are "vacuously defined". I.e. the limit of the length
of a sequence which is undefined, is itself undefined.

They are currently limited to not exist, so we can't make any assertions
about the length of chains of these things (yet).

We are presently (here, in this conversation) discussing what limits to
apply, if any. Let's start from there...

> it's completely reasonable.
>

It is completely reasonable. Reminder: the chain following stuff only gets
done on the first reference(s) to client-side rewriting that occurs (CNAME,
DNAME, and new alias-form), and the recursive side CACHES THOSE RESULTS AND
RETURNS THEM.

I.e. After the first stub asks for something that requires chain following,
the FULL CHAIN is cached, and the next stub gets the WHOLE CHAIN. (Modulo
stupid DNS tricks like ECS.)

>   But if we're relying on the stubs to follow chains (that may not have
> been followed there at all before) to account for SVCB-unaware recursives,
> we should empower them to use chain limits reasonable for them.
>

Why? If you want to make the argument, you need to solidly justify a
difference in behavior between two things implementing the same standard:
stubs with unaware recursives, vs stubs with aware recursives.

There are substantial implications to having any such distinction.

Specifically, this means that chains ARE PROHIBITED (for length > N) when
stubs use unaware recursives, but NOT PROHIBITED (of any length) when stubs
use aware recursives.

This in turn, places a burden on the entire DNS ecosystem (and in
particular, zone owners, operators, and intra-provider heterogenous
deployments, aka non-vertical-integrated zone owners with multiple
providers, e.g. CDN vs Hosting vs DNS).

Wanting things to resolve fast CANNOT trump the other requirements from the
larger DNS community.

> Being typically further away from results and with less caching, unlimited
> chain following just does not seem reasonable for a stub like Chrome, and
> it seems to us to have a big potential to be detrimental to our users'
> experiences compared to the status quo of not following any chains.
>

This puts the necessary and appropriate pressure on stub clients to their
resolver operators, to deploy Alias-form aware resolvers.

Putting in place (IMHO) hacks, to reduce or eliminate that "pain", removes
ANY incentive for resolver operators to actually deploy this stuff.

If resolver operators NEVER deploy this stuff, we may as well chuck it
before we adopt this, since there will be literally zero benefit, while
creating non-trivial amounts of cost (in terms of stub client
implementations, authority-server implementations, zone owner deployments,
etc.)

BTW, I'm strongly in favor of this getting adopted, and getting deployed in
recursive resolvers.

Thus, I'm in favor of NOT having alias-form limits, even on the stubs. This
will lead to much faster adoption, compared to "Real Soon Now", "Some Day",
"Eventually", and "We Never Promised To Do That".
(The latter set of responses paraphrased from an un-named registrar who
eventually reneged on "promises" to deploy DNSSEC support.)

> and SVCB aliasing becomes fully empowered as a CNAME substitute.

Correct. The issue is putting substantial PRACTICAL limits in place (on
stubs) well before the Flag Day, is a Bad Idea, because it removes the
incentives to participate in Flag Day itself.

On the other hand, I think it would be possibly a good idea to roll out
limited user experimentation of unlimited stub chain lengths, to get the
experiences (and data) regarding user experience, and to get implementation
experience and debugging done, prior to Flag Day.

Post Flag Day, turning it on universally, would then be reasonable to do,
and IMNSHO, this would be the right way to approach it.

> organizations should be able to coordinate who is in charge of aliasing
I'm not disagreeing with the argument on the "should", but that is very
different from anything related to specifications, standards, and "must".

In particular, you need to be REALLY careful, that this can (and in many
cases will) involve different departments in larger organizations, e.g. the
hosting vs DNS, possibly CA, perhaps Load Balancer, and even other groups
responsible for domain purchasing etc.

While those might be coordinated, they might not be, or might be only
vaguely/loosely coordinated, and may not involve ongoing coordination.

There is a huge difference between "best practices" and "mandatory to
implement", and I am afraid you're unintentionally conflating the two.

I.e. Arguments becoming "less valid" is not the same as "this is not a
valid argument", and without it being the latter, it's pretty much
necessary to stomp on this line of argument.

Sorry, and I wish it wasn't the case, but let's face it, DNS is pretty much
a very messy thing when you start allowing client-side rewriting (CNAME)
and then expand it.

Brian

---

From: Paul Vixie <[email-masked]>
Date: Mon, 23 Dec 2019 21:08:59 +0000

On Monday, 23 December 2019 20:22:01 UTC Eric Orth wrote:
> to change that without breaking things.  ...

CNAME loops must be detected, so whatever unstandardized limit is chosen, must 
be both greater than one, and finite. i agree with your associated SVCB 
reasoning, but we should be clear here that there are standardized boundaries 
for CNAME chain lengths, even if there is no specific standardized limit for 
same.

-- 
Paul

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 24 Dec 2019 11:00:49 +0900

Eric Orth wrote:

> to change that without breaking things.

According to rfc1034:

	Domain names in RRs which point at another name should
	always point at the primary name and not the alias.

CNAME chain is prohibited, though, according to the robustness
principle, the rfc says chains should be followed.

 > aliasing apex names, are new and thus currently limited to zero.

Seems to be a reasonable restriction.

						Masataka Ohta

---

From: Eric Orth <[email-masked]>
Date: Fri, 27 Dec 2019 12:54:52 -0500

On Mon, Dec 23, 2019 at 3:57 PM Brian Dickson <[email-masked]>
wrote:

>
>
>> Being typically further away from results and with less caching,
>> unlimited chain following just does not seem reasonable for a stub like
>> Chrome, and it seems to us to have a big potential to be detrimental to our
>> users' experiences compared to the status quo of not following any chains.
>>
>
> BTW, I'm strongly in favor of this getting adopted, and getting deployed
> in recursive resolvers.
>
> Thus, I'm in favor of NOT having alias-form limits, even on the stubs.
> This will lead to much faster adoption, compared to "Real Soon Now", "Some
> Day", "Eventually", and "We Never Promised To Do That".

Chrome is not willing to subject its users to such an easily avoidable
"pain" simply as an incentive to other operators to help fix the badness.
As much as users taking a latency hit of following long chains would
incentivize recursives to follow the chains on their side, requiring long
chain following would be an even stronger incentive to browsers and other
stub clients to not support any HTTPSSVC alias following or maybe not
support standardized HTTPSSVC at all.

But I also disagree that all incentive for recursives to follow chains is
removed if stubs only follow one alias link.  Even following that single
alias in the stub is going to almost always be a bit slower than if the
recursive does it.

---

From: Eric Orth <[email-masked]>
Date: Fri, 27 Dec 2019 13:25:29 -0500

I propose we add the following 4 statements to the spec:
1) Alias-form SVCB records SHOULD NOT delegate to names with any form of
alias record such as alias-form SVCB or CNAME.
2) Clients receiving SVCB records MAY limit the length of chains of
alias-form SVCB records that they will follow.
3) Stub resolvers SHOULD follow at least one alias-form HTTPSSVC record
before enforcing chain limits.
4) Recursive resolvers SHOULD follow at least (8?) alias-form
HTTPSSVC records before enforcing chain limits.

Point (1) is an extension/clarification of the similar rule for CNAME in
RFC1034.  I think SVCB would work a lot better if everybody just always
aliases to the final server whenever possible and reasonable.

Point (2) essentially serves as a warning to not assume long chains will
always be followed.  The allowed length may vary, but many operators are
going to impose a limit at some point out of practicality.

Points (3) and (4) set the expectation of reasonable minimum limits for
everything to work well.  Recursives are given a higher limit because, as
stated in this thread, it is very reasonable for those operators to support
such higher limits.  Stubs are given a lower limit because it is less
reasonable for them to support the long chains, but they are still expected
to follow at least one alias because that is the minimum to support the
obvious usecase of allowing https://example.com/ aliasing.  Both these
points only apply to HTTPSSVC, and leave SVCB less defined, as what is
reasonable behavior may be more varied in non-HTTPS cases.

On Fri, Dec 27, 2019 at 12:54 PM Eric Orth <[email-masked]> wrote:

>
>
> On Mon, Dec 23, 2019 at 3:57 PM Brian Dickson <
> [email-masked]> wrote:
>
>>
>>
>> Putting in place (IMHO) hacks, to reduce or eliminate that "pain",
>> removes ANY incentive for resolver operators to actually deploy this stuff.
>>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 27 Dec 2019 12:05:55 -0800

> "pain" simply as an incentive to other operators to help fix the badness.

I'm a bit confused by the usage of "other" here. Chrome is not an operator,
unless I am mistaken?

You may be overstating or overestimating the amount of (perceived) "pain",
and the reason I put "pain" in quotes in the first place, it it mostly
boils down to the number of queries to the recursive.

If the recursive is comparatively close to the client, the extra iterations
should add a negligible amount of latency, well below the threshold of
impact to user experience. E.g. a 5ms RTT would add an extra 5ms for a
chain of 2, etc., once the resolver has obtained and cached the additional
elements of the chain.

The worst-case latency is only seen the first time every element of a chain
is resolved. Even though the client (browser) does need to chase the SVCB
component(s), it still does so through its resolver, not directly, and all
the benefits of caching are still reaped.

> support standardized HTTPSSVC at all.

As was discussed (mostly by me) up-thread, the real-world expectation on
chains should be 2, not 1, as a median value.

The main motivations for ANAME (within DNSOP) which were (gladly) subsumed
by SVCB, were interoperation between different classes of providers, and
multi-vendor operation (for reliability, availability, etc.). Those use
cases typically REQUIRE a minimum of 2 levels of SVCB chaining: 1 for the
internal use within a particular class of provider, plus 1 for the
inter-operator dereference operation.

Limiting this to a chain length of 1 (i.e. requiring SVCB to not point to
another SVCB or CNAME) then turns into a requirement to dynamically update
the target fields of the SVCB or CNAME, a requirement that was the death
knell of the original ANAME spec. ANAME went through a large number of
iterations trying to solve this issue or to limit its impact, and was
determined to be insolvable.

Having the client side do the chain following is the only viable
alternative, which REQUIRES a non-trivial chain length (i.e. > 1) to
preserve this benefit (i.e. requirement).

> alias in the stub is going to almost always be a bit slower than if the

The main issue that you seem to be missing here, is that it isn't about
recursives, it is about the authoritatives who are serving the various
records (CNAME, alias-form SVCB, DNAME, and non-alias-form SVCB). For the
most part, they are not doing so out of laziness or as a design choice; it
is a requirement from the domain owners who are customers of the various
entities.

Placing restrictions on chain length, places restrictions on those entities
in terms of how they can select providers, and even whether multi-provider
options are feasible.

This is harmful to consumers, harmful to competition, and harmful to the
larger Internet's availability and performance.

So, please, let's look at this from the holistic and systemic level, rather
than the myopic perspective of "just the browser".

I'm in favor of encouraging sensible choices and best practices. However,
IMNSHO, those belong in things like BCPs and operator guidance docs, not
hard limits in core standards documents.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Fri, 27 Dec 2019 12:18:07 -0800

> aliases to the final server whenever possible and reasonable.

This element of 1034 has never been observed by implementers or operators.

If you REALLY need this clarified, maybe a 1034-bis that removes this rule
on CNAMEs, would make the documentation on DNS consistent with deployed
reality.

If you insist on SVCB mirroring 1034, please be prepared for a lot of
pushback, up to and including such a -bis document...

SVCB might work better if everyone does what you ask, but the underlying
reality is that that is not always possible (at all), where "not always"
means "anywhere that single-vendor vertical integration is not occurring".

There are currently artificial barriers to interoperation, which result in
several (more than 3?) instance of vertical integration, each of which has
20% (in many cases, much less) of the total domain name space.

This limitation on SVCB prevents real-world use of SVCB for inter-provider
(hybrid, redundant, whatever) usage.

I'd like to see an eventual deployment scenario where any domain can use
SVCB for any appropriate use case, and where resolvers do all the SVCB
heavy lifting.

We can't get there if we can't get beyond the vertical integration
limitation, which Point (1) necessarily prohibits for 99% of existing
actual deployed apex "cname" usage, which is likely to be the earliest and
biggest use case of alias-form SVCB.
(Specifically, adding SVCB aliases to SVCB alias or CNAME records within
vertical integration environments.)

As for Point (3), I don't think we are yet at a consensus of which value of
"N" (e.g. "one") is reasonable, given the functional requirement for
deployment in the real world.

Brian

>>> This puts the necessary and appropriate pressure on stub clients to
>>> their resolver operators, to deploy Alias-form aware resolvers.
>>>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 27 Dec 2019 12:56:58 -0800

top-reply clarification:

Chain-length and chain processing should not actually require more than 2
SVCB lookups, and those should only be in direct succession.
Chains involving CNAME are already handled by resolvers, so the incremental
work done by stubs would be limited to 1 or 2 iterations of the SVCB
components.

The supported chains should be, at most, CNAME* (zero or more, no limit) ->
SVCB-alias -> {optional second SVCB-alias -> any other type | non-alias
SVCB} with a restriction that if the "any other type" happens to be a CNAME
or DNAME, that no further SVCB be expected or allowed.

Hopefully this clarifies my comments about chain length and the incremental
addition of SVCB to the chains.

I think "1 or 2" is a reasonable limit to impose *on SVCB* within chains,
without further restrictions on any other chaining that might occur during
resolution (all of which can already be handled by resolvers).

Brian

On Fri, Dec 27, 2019 at 12:05 PM Brian Dickson <
[email-masked]> wrote:

> I'm a bit confused by the usage of "other" here. Chrome is not an
> operator, unless I am mistaken?
>
> If the recursive is comparatively close to the client, the extra
> iterations should add a negligible amount of latency, well below the
> threshold of impact to user experience. E.g. a 5ms RTT would add an extra
> 5ms for a chain of 2, etc., once the resolver has obtained and cached the
> additional elements of the chain.
>
> The worst-case latency is only seen the first time every element of a
> chain is resolved. Even though the client (browser) does need to chase the
> SVCB component(s), it still does so through its resolver, not directly, and
> all the benefits of caching are still reaped.
>
>
> Placing restrictions on chain length, places restrictions on those
> entities in terms of how they can select providers, and even whether
> multi-provider options are feasible.
>
> So, please, let's look at this from the holistic and systemic level,
> rather than the myopic perspective of "just the browser".
>

---

From: "John Levine" <[email-masked]>
Date: 27 Dec 2019 16:00:50 -0500

>"pain" simply as an incentive to other operators to help fix the badness.

Hi.  I'm a guy in a hard to pronounce country somewhere in the
southern hemisphere.  I just set up a little web site at my local ISP.
They handle the DNS and said something about CNAME and SVCB and the
guy complained that the national domain registry never answers the
phone and it takes a month to register new 2LD names.

When my mother looks at my web site on her Android phone, what will
she see?

Signed,
Wondering

---

From: Paul Vixie <[email-masked]>
Date: Fri, 27 Dec 2019 22:24:03 +0000

On Friday, 27 December 2019 18:25:29 UTC Eric Orth wrote:
> [explaination]

sgtm. +1.

-- 
Paul