Re: [DNSOP] SVCB chain lengths

Brian Dickson <> Mon, 09 December 2019 20:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 380071207FC for <>; Mon, 9 Dec 2019 12:46:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r8u5BuOgjJcs for <>; Mon, 9 Dec 2019 12:46:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C41701201AA for <>; Mon, 9 Dec 2019 12:46:47 -0800 (PST)
Received: by with SMTP id o42so6262753uad.10 for <>; Mon, 09 Dec 2019 12:46:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2VcheeDFMb/HkEvf+1tKrJgOrUvFlt5HMgimvxmHPh0=; b=cazqyN/Lm5IDdwrcNHu+w1aNlGorwauwAWMXeBkbQAjovy0NUJnm7jcMC6VRCTAlOT CfTswfmin9+dRMhgkB9lk4ao6kAw+e390wtEICw53lVbzpm39q724FS+ptofj7iesLie bUq6mY3A708KMunX8gSUQBVCGmLCpoqYIRrzrTxoS/PrYkqEGoAS+V1ud2HiCB4FDAW5 qo7VkEC+qsQuayuYGLBv5+yb4bD/zm8zXP9j+Fer5p1pN8XF681juFZoJPAeYLa8wel6 EOsz/V0gof2lxe+bpFlyNdn1EMCmKW46/euFHFVDEJfGPBz2ExvbNM8NWoAhRLDUWOY+ AUeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2VcheeDFMb/HkEvf+1tKrJgOrUvFlt5HMgimvxmHPh0=; b=bvU/Fy+kPd/Yg+tVWaTzS1C0eFInYn3O/V+3NYBcfOWnbVnW9HpQB6TOEFlzl2DITh S/TD2BK/9GgComXR+BXfb37QnHcSZ8TePG6ZRNjLX+I19pNcLiy/BBPD2i7Grkhnm7LV Bf+g4ygA0T2atFdnkqgFuBgueOQB7Goi4+PHeqhl2uulEQeAyxSxSlc2e6KoxBbDy7HP mxheqd8leR41zGE5q7kcQq2u4nWwnY3fJqVcf5JI+vy0E7DAB5zV+mIufJlUccBFtRK1 bvFgPoYZLLtPuYWfLQ9cQW9ePAxFlu3eKe7uBy2JXa3kre8rM7E9yAqEHoDRXPVISTd8 iNDg==
X-Gm-Message-State: APjAAAVqGu2qkTFOMVYfp/5UDwPDcNhXLVw3AOhT6gN4AksBKkik4Y1g AspQ56wekOtmmVNzKwnTUcS0lt1u9IdxZphkiPA=
X-Google-Smtp-Source: APXvYqx2StUHmZKsiRju2gaReMTkmeWcMKTGL5obvpWWECBglfnq6erFvOVsqLaDdUtBZcsxxlcCIZJl1tsMDdvuvts=
X-Received: by 2002:ab0:74c8:: with SMTP id f8mr25040159uaq.114.1575924406716; Mon, 09 Dec 2019 12:46:46 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Mon, 9 Dec 2019 12:46:35 -0800
Message-ID: <>
To: Ben Schwartz <>
Cc: Eric Orth <>, dnsop <>
Content-Type: multipart/alternative; boundary="000000000000748c6d05994b7ec6"
Archived-At: <>
Subject: Re: [DNSOP] SVCB chain lengths
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Dec 2019 20:46:50 -0000

On Mon, Dec 9, 2019 at 10:03 AM Ben Schwartz <>; 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.


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