Re: [DNSOP] SVCB chain lengths

[Brian Dickson <[e-mail]>]

On Mon, Dec 9, 2019 at 10:03 AM Ben Schwartz <[e-mail]> wrote:

> Changed title to reflect this thread's topic.
>
>
> 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.
>
>
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.