Re: [dns-privacy] how can we ADoT? (with github url)

Manu Bretelle <> Wed, 11 November 2020 22:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 871683A1168 for <>; Wed, 11 Nov 2020 14:03:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.848
X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SHORTENED_URL_HREF=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9_uGlMm1RPZ7 for <>; Wed, 11 Nov 2020 14:03:30 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 455563A114C for <>; Wed, 11 Nov 2020 14:03:30 -0800 (PST)
Received: by with SMTP id s10so3935653ioe.1 for <>; Wed, 11 Nov 2020 14:03:30 -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=cRcrTeKVhSMNz7HUViYl9Y/GrpxVafCo6GycE9YrXfQ=; b=kxqPgr6NuIfv65RWnPKvAKXqmX1dGPGn4eT6gHVbKS5hkDvfRcWfTlTsbxIhOgf0ig hGyAZEUmjZLaBjRXktlQr+gPNhkK5HDpZ1Sc2WAoFKb7xzK/SfHL9/K79t22MlL+JvRb A9ktYwpRFeEUqhi7lMggimO/bjkJ1oa085o5V521KWT/YSCXC6uL1HiqKEwFAwE6TBsC PdeDYsvsevB0pEzJgkKsSEk4oUhRG/FPn1tF6ZkIRW6va/CN8FMejJ/6fgKBa97EAa8j HVVd56l30PSSM/i5W0NKRyy25MI5KzBd9YWBv2UlWuxr9wYTb9NXhCh5/9Z+H9mKQt+q vuvw==
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=cRcrTeKVhSMNz7HUViYl9Y/GrpxVafCo6GycE9YrXfQ=; b=Ir/A6lJX8BljEjY7qQV/ELAl1U2nJ7nKGha4fNborGbS7s25b9OT7QGC/zvZnMRnAJ nD+AKY4eWTFnZKJXS6osH2Ryq1EaYuCr7c35YJs3PJdPfca7R46jEqPxIOS69//mFJJ5 XJZajyFN8GWh94u6z5L1CyMC1zUueJKhSg8ieziniR4cw6hNW1IbiYMUYR3XG0SGDytL 5xTxITtFKkZtmKWbGt5a4xnD5mPuAa1F3L/vFJY6aFvuDBEcKEEaGucQOkit78hVbv6c 54aDKR3GhQkYao8ann7mSVgG0AV7ylHFFMR7jA+sg/jzK3pcbkiR76oEuW30e8CTS6eN zZbg==
X-Gm-Message-State: AOAM530fNg3fE6pST8leAevtt/7X0Kepk7sTSBgL+QdZpLU5o6ctkNqn RB8SLZ0z7Y9XdSZe4N7fDlDR6rFM2E0frBEYpCuqk2ONSKYVIQ==
X-Google-Smtp-Source: ABdhPJyxxCl7ckPzoERp7TTOl1pU5eCkbs+KGnP9v8qnf63B8giMImpsvHligjc7kulz9v/v5YTSHclW/Bn8t93hzTk=
X-Received: by 2002:a5e:8e01:: with SMTP id a1mr16133739ion.7.1605132209380; Wed, 11 Nov 2020 14:03:29 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Manu Bretelle <>
Date: Wed, 11 Nov 2020 14:03:18 -0800
Message-ID: <>
To: Tony Finch <>
Cc: DNS Privacy Working Group <>
Content-Type: multipart/alternative; boundary="00000000000028641c05b3dbf7d8"
Archived-At: <>
Subject: Re: [dns-privacy] how can we ADoT? (with github url)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Nov 2020 22:03:33 -0000

On Wed, Nov 11, 2020 at 1:20 PM Tony Finch <> wrote:

> Manu Bretelle <> wrote:
> > Having this as an ID or possibly a github repo may make it easier to
> refer
> > to/iterate than just this email.
> Yes!


> > I had attempted to quickly categorize some of those approaches (albeit a
> > much smaller list) in a matrix in [0] but did not follow through since.
> >
> > [0]
> Ah, I haven't been paying enough attention to meetings so I missed this! I
> think I need the speaker notes to understand it properly :-)

Totally fair, pretty sure there were no speaker notes ;) . The
presentation is available at .
Originally, there was this draft
and the solutions in the slide deck were compiled from feedback/ideas that
came up while talking with other folks.

> Your title "DoT for insecure delegations" is interesting: one of the
> problems with what I have written so far is that it is too much a post-hoc
> justification for using TLSA records to support ADoT. So I have built
> nameserver authentication on top of TLSA on top of DNSSEC.

Speaking of which, I think Brian Dickson did a good job of describing an
"hybrid" approach which I had notes of, but never got to write down
properly. Here is the link:

My TL;DRed notes, in the context of serving zones across name servers in
(multiple) out-of-bailiwick zones, that I think echoes Brian's more
throughout description:

Other approaches to signalling DoT support to the recursive nameservers may
be through the presence of TLSA record, special record at the name server
side. In the end, the name server zone owner will have to be authoritative,
such authoritative answer can only be validated if it is signed. By
separating zones from nameservers, one can provide DNSSEC signing at the
name server zone level without having to enforce it at the zones which are
served. Having multiple name server zones would:

   - allow enabling DNSSEC on a subset of the nameservers without risking
      impacting all the DNS traffic.
      - allow to stage key roll on a subset of the nameservers, and
      ensuring that in the worst case, only a subset of the traffic is impacted
      in case of mishap.

> One of my unstated assumptions is that DoT will be problematic for TLDs,
> and (with QNAME minimization) it matters more for leaf zones, so it is
> likely to be deployed there first. But DNSSEC is deployed to a much higher
> proportion of TLDs than leaf zones, so there's a good chance I'm wrong.

yeah, and this is where zones hosted by DNS providers may benefit of this
hybrid approach if the providers are supporting DNSSEC for their name
server zones. But I just quickly checked Route53 and Google Domain, and
none of them have their NS names signed.


> Tony.
> --
> f.anthony.n.finch  <>
> Shetland Isles: Southerly 6 to gale 8, decreasing 4 or 5 later in west.
> Rough
> or very rough. Rain or drizzle. Moderate or poor, becoming good later in
> west.