Re: [dns-privacy] [Ext] Restarting the discussion of draft-ietf-dprive-unilateral-probing

Daniel Kahn Gillmor <> Wed, 28 September 2022 21:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11438C15AE0F for <>; Wed, 28 Sep 2022 14:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Status: No, score=-2.107 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=Apkr+R/S; dkim=pass (2048-bit key) header.b=vpNUE2tI
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eOMv1lFJKYXz for <>; Wed, 28 Sep 2022 14:17:20 -0700 (PDT)
Received: from ( [IPv6:2001:470:1:116::7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id BE666C14CF1F for <>; Wed, 28 Sep 2022 14:17:20 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=2019; t=1664399838; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=rNZj2nhXf40iDwmqwwWkAWfJae4UazQn01Y7tDbqez4=; b=Apkr+R/S/s47Q+tMC/ChW1J+Svt3DSqCewL5yoTOGNSsvvpWg5dhPygEydH4+eQPz4TmU ShTghqFrPu41jQfCw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=2019rsa; t=1664399838; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=rNZj2nhXf40iDwmqwwWkAWfJae4UazQn01Y7tDbqez4=; b=vpNUE2tIonS6DP9/WOsCkWS4jhjOP6DFm4f6WtnExwrrxmPz4dkjZDDFrUw349L2NfmXx pOC97JewzrN/OTdmCNWRFG+EcV7oSJBhLff1yDValcHCM2PXG45sO9AEGkC7qQdvDEwoBwp NdjJw2qKcUydsyb0pVNRmJpM2YnNr6doWNcnAnO47mQmSIuIlwxLxdFY1SmVD1xdlCsq4r/ PiXekImalbizu/st5GL+tkXkJOhWEuVCYUMaJJhYYDJ6eFcec492fPpIKZpYL67EnXpcGRq T0pZLDScOwu7uasq+wtPPFxLjYpdtI0MNL0tSiHPVpcyCqLh7G4lPwDY+pBg==
Received: from (unknown []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by (Postfix) with ESMTPSA id 7513AF9AE; Wed, 28 Sep 2022 17:17:18 -0400 (EDT)
Received: by (Postfix, from userid 1000) id C88CC20431; Wed, 28 Sep 2022 16:04:15 -0400 (EDT)
From: Daniel Kahn Gillmor <>
To: Paul Hoffman <>, Puneet Sood <>
Cc: DNS Privacy Working Group <>
In-Reply-To: <>
References: <> <> <>
Autocrypt:; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH
Date: Wed, 28 Sep 2022 16:04:10 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [dns-privacy] [Ext] Restarting the discussion of draft-ietf-dprive-unilateral-probing
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Addition of privacy to the DNS protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Sep 2022 21:17:25 -0000

Thanks for addressing these suggestions from Puneet, Paul.

I'm not so sure about this text:

On Mon 2022-09-26 22:32:32 +0000, Paul Hoffman wrote:
> Puneet wrote:
>> Generally any NS IP with working encryption should be preferred over
>> Do53.
>    All resolvers currently keep NS sets and, in case of encrypted
>    transport failures, the sets MAY be checked for other IPs instead
>    of falling back to Do53 on the same IP. If there is only one IP
>    address with encrypted transport, this means falling back to
>    unencrypted DNS. If a nameserver has three IP addresses,
>    two of which have encrypted transport and the first of those two
>    causes a transport failure, the second of those two will get
>    a large load due to encrypted traffic moving from the first. 

Nothing in the draft so far makes any attempt to tell the recursive
resolver how to select between different authoritative IP addresses
derived from an NS set.

Adding this text actually makes the draft more complex than it needs to
be, and there are some potentially subtle consequences that might
discourage adoption of encrypted transport if we encourage the behavior
Paul has hinted at as a MAY here.  (i grant that MAY is not a strong
prescription, but it does appear to be an endorsement)

I'm particularly concerned that wide adoption of this particular
approach by recursive resolvers would make it so that adoption of
encrypted transport by a single authoritative server within an NS set
would cause that authoritative to attract a disproportionately high
fraction of queries for that NS set, leading to problematic resource
consumption that would appear to be the fault of encrypted transport.

It seems possible that this could lead to authoritative server operators
(especially those who operate one part of a larger NS set) declining to
attempt encrypted transport out of fear of this kind of imbalance.

I'd prefer that the unilateral-probing draft not include any guidance
about how to select an IP from the NS set over hinting that a recursive
resolver might want to do it this way.