Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

Stephen Farrell <> Wed, 31 March 2021 01:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A11103A0F4A for <>; Tue, 30 Mar 2021 18:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 89cG3O5K4JB2 for <>; Tue, 30 Mar 2021 18:37:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 292FC3A0FCA for <>; Tue, 30 Mar 2021 18:36:58 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB09ABE3E; Wed, 31 Mar 2021 02:36:56 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RAiqZrgLGcW0; Wed, 31 Mar 2021 02:36:47 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 69CF5BE2D; Wed, 31 Mar 2021 02:36:47 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1617154607; bh=ZWNJlxFGBIqOlY8VacuKEAsx7Egjq3DcBzs7HSxrfV0=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=Nkvl0rfMNTDJxl8aVbs9rmTMiIpUsuH4V3iu44YfxSv37ABwzM09q6eOAcxEBMvDD eKETQYrQkbB9NpQ+1gdBXzfA57odUVIJDtrG/XuwQ+0Z53F1NME6YqUity68aFzZwR o177xpyttlixpjnnM0o1PSuj2LJ6k+FRe0n8r8/8=
To: Erik Kline <>
Cc: Eric Rescorla <>, "Hollenbeck, Scott" <>, "" <>, Rob Sayre <>
References: <> <> <> <> <> <>
From: Stephen Farrell <>
Message-ID: <>
Date: Wed, 31 Mar 2021 02:36:46 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hlBXKdnvfKhBDa6O3Ia4JdyAvoeqvZbPM"
Archived-At: <>
Subject: Re: [dns-privacy] Root Server Operators Statement on DNS Encryption
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, 31 Mar 2021 01:37:05 -0000


On 31/03/2021 01:53, Erik Kline wrote:
> I think, "IN NS com." doesn't reveal much information.

Right. And such cases are probably a huge percentage of
both all, and all-of-the-sensitive, queries to root

> But perhaps "IN NS sensitive-tld." could have privacy implications
> for some folks?

I guess that's a fair point that querying some e.g. ccTLD
NS from some locales could sometimes be an issue. Do we
have any information as to the prevalence of such? (Or of
cases where such queries are abused in ways that decrease
privacy or enforce censorship.)

Maybe in addition to recommending QNAME minimisation it'd
be good if root server operators also recommended services
that face such issues deploy those services lower down in
the naming hierarchy? My guess is that service providers
will do that anyway but no harm to give a bit of direction.

On 31/03/2021 02:17, Eric Rescorla wrote:
> However, recall that the TLS connection to the parent is what
> protects the NS records for the child, as they are not DNSSEC signed.
> Thus, one has a somewhat fragile situation if one has to store a
> lookaside list of the TLS status (and at some level the nameservers!)
> for the TLDs. I'm not saying it's unmanageable, but it's not
> amazing.

Also fair. Requiring the parent to be involved is a big deal
for any of the offered solutions here (regardless of whether
or not DNSSEC is involved).

In any case, I still think we ought be able to live with a
situation where the root server operators do less than the
TLD server operators - it's the queries to the latter that
more or less have to include the vast majority of sensitive
information. (And if a solution that works for .com is found,
then I bet we'd be able to find something that works as well
for root server operators.)