Re: [dns-privacy] Fwd: New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features

Vladimír Čunát <> Wed, 26 May 2021 18:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67D113A0CD5 for <>; Wed, 26 May 2021 11:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5vdlFps5KZ-8 for <>; Wed, 26 May 2021 11:21:07 -0700 (PDT)
Received: from ( [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 396923A0CCE for <>; Wed, 26 May 2021 11:21:06 -0700 (PDT)
Received: from [IPv6:2a02:768:2d1c:226::a2e] (unknown [IPv6:2a02:768:2d1c:226::a2e]) by (Postfix) with ESMTPSA id 9702F140963 for <>; Wed, 26 May 2021 20:21:01 +0200 (CEST)
References: <> <>
From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <>
Message-ID: <>
Date: Wed, 26 May 2021 20:21:01 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------FEEDC4D9CC94E3FB08CF2746"
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [dns-privacy] Fwd: New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features
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, 26 May 2021 18:21:12 -0000

I like it in principle, so I say adopt.

I already see a significant problem, though I expect we can fix it 
somehow after adoption:

> After sending out all requests for SVCB records [...]

My understanding of section 3 implies that an implementing resolver MUST 
NOT ask any of the nameservers until *all* their SVCBs have been 
attempted, in the most common case where no encryption is supported by 
the nameserver-set.  That would *not* scale at all.  Even with 13 NSs 
it's a rather bad amplification factor, and it reminds me of the recent 
NXNS attack.

On the whole, if a NS set has (many?) names without encryption support, 
I'm afraid the corresponding zones may have to do without a guarantee of 
getting encryption, though glue might help.

On 26/05/2021 15.21, Stephen Farrell wrote:
> SVCB in the parent zone will take years to happen

The SVCB glue is just a slight optimization.  I don't think it can even 
save latency, just a packet per NS (and only in cases where the SVCB