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

Warren Kumari <> Mon, 12 July 2021 22:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10E5A3A13A4 for <>; Mon, 12 Jul 2021 15:29:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IwEbKqVmv1nr for <>; Mon, 12 Jul 2021 15:29:41 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C56C73A13EE for <>; Mon, 12 Jul 2021 15:29:37 -0700 (PDT)
Received: by with SMTP id r20so26746913ljd.10 for <>; Mon, 12 Jul 2021 15:29:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=x6EfCJwkbE+kgWcAiWLjsalALRGKjRyYHVv1tCsg2kc=; b=O72MMlJZSE0KsoeIzK/NQqU5/Lgd4NB0jSiVh6lBJ3NRLh0Mc7qw5+CFTizbS8isnh zrrF2lxylIXBkNs/tkV/xYR5tGQ9wK436vH8ZIRtm0s12kkyfU4Os66Trhu/EEPD0kJ4 MU6Qw1RQ21PUbTTtaExk4Ct0eMOlalYWA1qBnLhSSEHm1L5uDWfsks/4eluDXjJfrLSV KlNiuWfcbQkkcjW1TtSI+m3g6ZKemvSccVK2fjmmo2dU/YpCsmHCsy3Gy1gbWSzi6Mo3 CjUlorqS9sM9GXgwwgwqnZQ0r9chZKdQAhiIJ5JbEhzu/acwW2YqK9TB4DKx2RngZBRx pOPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=x6EfCJwkbE+kgWcAiWLjsalALRGKjRyYHVv1tCsg2kc=; b=FHIogPAATcCbIIF5N2P2XE3Hjll6R948hz86jflQa1zBJHvnPCikrozrsZgdxKGzuF slyNhvyaPny39y+6DwcgKVWn9Iqp7HJH3k+1MgOQclRAkHu0gror4Nu1aqnaD3ZevyMb VNj0xRvx5eqQviolE30vQa69mQar0hkP7zr962t7Dldqpsqn8Q4VRyFh4lWQ0YqkzLNQ /GXYsxZNscSbDtMuL2fE+durHolB1F5aCJ2QTK0ibrozdsZa11ddRwlxADDnaHBWiw// LEFkfXy2M6RKw61p5ynQUsNR57gksiD5iM40GX0zKwIS9lCrPeiXeqHqc5qWUIx2/9CB 2wew==
X-Gm-Message-State: AOAM530BMdyhLzjPJABvnBbYCVEHNfoAbnHO83Uamx55U5smcaYiCxun qaz0PEVsdN3zOlLCnu7ExUvWfugRQm47MxpMiIRx4DI4QAy5pA==
X-Google-Smtp-Source: ABdhPJwC589TqjEUZ3u0M1lU7/SCpgtpKTPkPjG/tzhAwgSkTd56xe//BF4S1MBm37W1PpUFyxn46lXyZ7ym5PZkwC0=
X-Received: by 2002:a2e:2e0a:: with SMTP id u10mr1229924lju.309.1626128974167; Mon, 12 Jul 2021 15:29:34 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Mon, 12 Jul 2021 18:28:57 -0400
Message-ID: <>
To: dnsop <>
Content-Type: text/plain; charset="UTF-8"
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: Mon, 12 Jul 2021 22:29:50 -0000


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.
> 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, ...
> 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...


> --
>         Viktor.
> _______________________________________________
> DNSOP mailing list

The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra