Re: [DNSOP] [Ext] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

Petr Špaček <> Tue, 13 July 2021 10:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11B083A11B9 for <>; Tue, 13 Jul 2021 03:15:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, 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) header.b=qAEeHcgj; dkim=pass (1024-bit key) header.b=Vxkg6ePh
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JyRrRnBZGJwv for <>; Tue, 13 Jul 2021 03:15:53 -0700 (PDT)
Received: from ( [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D92AE3A11C2 for <>; Tue, 13 Jul 2021 03:15:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPS id 7F8153AB023 for <>; Tue, 13 Jul 2021 10:15:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=ostpay; t=1626171351; bh=IevhixTIjBr5g15EDM5Q+2P0RUaHLViZOVlj3IfjPYs=; h=To:References:From:Subject:Date:In-Reply-To; b=qAEeHcgj/Eio58RECHj+NC05160M8AeCm+BQ4AyhJ9Cbafjc/kxC3+Titq+YmZNv8 5jcRbnatBIUWD0MxQffy/g1c7TXrZtTCRwXq50WlMmsnTPe/h5JMigpvBTmGKdkYHv LE69f/VaApLotaSnntkBkp3BDGH4WETC5Z2eWgkg=
Received: from (localhost.localdomain []) by (Postfix) with ESMTPS id 6FAE1160075 for <>; Tue, 13 Jul 2021 10:15:51 +0000 (UTC)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 2AB1D16006D for <>; Tue, 13 Jul 2021 10:15:51 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 2AB1D16006D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1626171351; bh=dZj0PJ41f0DQzzOSJMUAk6xtF9x0FDiS7IwaM4Yx5QU=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=Vxkg6ePh875EX526f08qqIS340y6P8DLPa49v91N9Lixg6aUolHBRaToxneY40649 Es4ojJcK07Ea9nXLo/3mnsbvymLXmQn6rB52IAcUlNfTmZPiq/ocY4AHr67XUZAk4A leaP4M4zVFkmvYbOs/5EbK0n4Lp9k7Mr6st0uF7w=
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id bWhKyqVDoeSY for <>; Tue, 13 Jul 2021 10:15:51 +0000 (UTC)
Received: from [] ( []) by (Postfix) with ESMTPSA id 6B5E0160046 for <>; Tue, 13 Jul 2021 10:15:50 +0000 (UTC)
References: <> <> <> <>
From: Petr Špaček <>
Message-ID: <>
Date: Tue, 13 Jul 2021 12:15:46 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] [Ext] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis
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: Tue, 13 Jul 2021 10:15:59 -0000

On 13. 07. 21 0:28, Warren Kumari wrote:
> On Mon, Jul 12, 2021 at 6:18 PM Viktor Dukhovni <> wrote:
>> [ Resending complete message, previous draft was incomplete... ]
>>> On 12 Jul 2021, at 11:18 am, Paul Hoffman <> wrote:
>>> The current text is sufficient to tell resolver developers, and resolver operators, why they should even think about underscore labels when they create a QNAME minimisation strategy. Elevating such a strategy to a SHOULD as a work-around for broken middleboxes that might (hopefully!) be fixed in the future seems like a very wrong direction for the WG.
>> If this were just a work-around for breakage, I'd be more inclined
>> to agree, but it is also a solid opportunity to improve performance,
>> because privacy-relevant changes of administrative control across
>> special-use labels should be very rare to non-existent.

I hear you Viktor, but I fail to see why performance optimization cannot 
be optional. Why this specific optimization is so important that it 
cannot be left to vendors to decide?

>> So short-circuiting qname minimisation when a special-use label is
>> encountered seems like a win-win.
>> Measuring qname minimisation for TLSA RRs I see that today breakage
>> of qname minimisation is rare.  An example is:
>> In which many (but not all) of the nameservers return NXDOMAIN for the
>> ENT.  Out of 150k RRsets, O(10) have ENT-related issues.
>> So one might reasonably neglect the breakage, but it is not clear that
>> we need to go looking for it, just to "punish" the operators in question.
>> There's an opportunity here to make qname minimisation more performant for
>> SRV, TLSA, ... lookups, speeding up Domain Control and LDAP server lookups,
>> email delivery, ...

Please note I do not object to the method by itself - I agree it might 
be useful. My disagreement is limited to using stronger requirement than 
MAY. Let vendors have some leeway, please.

Petr Špaček

>> Of course if the WG cannot come to consensus on "SHOULD"/"RECOMMENDED", I'll
>> gratefully settle for the current "MAY" (thanks for the document update)...
> Another option would be to keep the current text, and simply add
> another sentence describing why implementations may want to do this;
> the current paragraph starts off with:
> " Another potential, optional mechanism for limiting the number of
> queries is to assume that labels that begin with an underscore (_)
> character do not represent privacy-relevant administrative
> boundaries." - the context around this is mainly around limiting the
> many labels attack, but it could also mention the ENT / other
> performance gain.
> Whatever the case, this conversation is still ongoing, so I'd like to
> keep it open for a few more days...
> W