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

Peter van Dijk <> Mon, 12 July 2021 08:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F6953A136E for <>; Mon, 12 Jul 2021 01:19:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.402
X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zLDkIBf5R9UW for <>; Mon, 12 Jul 2021 01:19:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BABC43A1369 for <>; Mon, 12 Jul 2021 01:19:28 -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 ESMTPSA id 16E286A0CD; Mon, 12 Jul 2021 10:19:26 +0200 (CEST)
Received: from plato ([]) by with ESMTPSA id kHcgBA7762BVUgAA3c6Kzw (envelope-from <>); Mon, 12 Jul 2021 10:19:26 +0200
Message-ID: <>
From: Peter van Dijk <>
To: dnsop <>
Date: Mon, 12 Jul 2021 10:19:25 +0200
In-Reply-To: <>
References: <>
Organization: PowerDNS.COM B.V.
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] 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: Mon, 12 Jul 2021 08:19:33 -0000

tl;dr: No.

On Wed, 2021-07-07 at 13:54 -0400, Warren Kumari wrote:
> If resolving "", once you hit the _tcp label
> you are quite likely in ENT territory, and some implementations
> (especially those behind firewalls / middleboxes) are still broken.

Then they shall suffer. It is not the job of the resolver vendors and
operators to keep working around broken auths. We'd like to remove more
workarounds from the resolver, not add more.

> There is also a performance hit.

This is fair.

> Version 10 of the document added:
> "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. For example, if the QNAME is ""
> and the algorithm has already searched for "", the
> next query can be for all the underscore-prefixed names together,
> namely ""."

This is good text, with the note that I like Peter Thomassen's
modification of only jumping to the next non-underscore label, instead
of immediately to the end the moment an underscore is found.

> What does the WG think? Does the privacy win of getting this deployed
> and enabled sooner outweigh the potential small leak if there *is* a
> delegation inside the _ territory of the name?

This looks like a false choice to me. I am unconvinced deployment is
hindered by the difference between MAY and SHOULD for this
recommendation. I also don't think the leak potential is very

> Should the advice above be strengthened to SHOULD / RECOMMENDED?

No. MAY is a perfect level for this advice. It is good to let
implementers know that somebody thought of this trick, and it might
make sense for many implementations, but we should not be overly

Kind regards,
Peter van Dijk