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

Brian Dickson <> Wed, 14 July 2021 03:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA5663A159C for <>; Tue, 13 Jul 2021 20:13:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z_k14R30kBhX for <>; Tue, 13 Jul 2021 20:13:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 042293A1597 for <>; Tue, 13 Jul 2021 20:13:38 -0700 (PDT)
Received: by with SMTP id t17so1078310lfq.0 for <>; Tue, 13 Jul 2021 20:13:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jfc4cLOm6hSB3pcOUTZ7BlQzHoQEscxMIE7wynuDqtY=; b=XNTOL8GgSur6FE+kipbJOAk8K3PeMJ8qv1iiIfrOWm8iWQiCKW/V9tMR1wxgKEKfOy lOVNOaV07TMAnSlE5rU0mFbJ92e9K7TCDSFtuBRMxw5/sGQnOcezhaLWkIfA5VJYiP3K kAoVbJ1tlP+4G+GrUcnfhZtPNcJufvM8eO5F4gpIirX0kS5HwLcw3DTis0QNVK70e4tn ob6ddhhmmPbKgKsu90aVHEaV2DSSGEiBghGIsFY9dkenh1BgvjJ7EfMldcq5kc4CA4ga hxc08jj0Zef7QDoMMxkfKpMO5NWMudeXdhLmlktPi9siJlSD+ZhcmmI2pnQvu4krkmXJ HXdg==
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; bh=jfc4cLOm6hSB3pcOUTZ7BlQzHoQEscxMIE7wynuDqtY=; b=Dcbvj673LbxP4s0Ns2+M9grGiEWGIuIyApqta7fMaDTQ7Xfm8A1vSGZFurUdK9wVm6 1gI1PxRjlH87orgibmaPPex9jURqaSBSzDfR19oH+YQwE5Zkj3zHVIEgbvBlCr6loIbi XQ0hJXLo0osqQ62yoA64O7DbGu1J+THKbx0V+vzdp04yFTzRkuM8h1qZNLKt/5msymu1 iXOs6QO3NZeGsqmpiCqrk+pb6rUnwmsMNYFGmyIH5Q8ZKaeS9cYzQIrh6AdamxhFLt4c hOPOy6LOFE4NmjT8jQObDRFyyqEZArmGz7tYybd5mX86qAhvGOLdHXiBmV2hZiyqOkQS 2RrA==
X-Gm-Message-State: AOAM530OuqDHbWwS+Z3pGJRO0XgwJ3YDCDrvnX6UJt6jMXONGOEXMLGg 2YYuVAp5HNNP2wA3yJN7/wAmXCswupNgIYtpN3ih7Jjx
X-Google-Smtp-Source: ABdhPJwTbKg53LDBellXCuPNyQsJrRPTftCL6wqbl4I1V2//6n8SegXwcWgY0VF1CQGNUYX/NJ59J5f7uz4FtWrlvpQ=
X-Received: by 2002:ac2:425a:: with SMTP id m26mr6189066lfl.458.1626232415271; Tue, 13 Jul 2021 20:13:35 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Tue, 13 Jul 2021 20:13:23 -0700
Message-ID: <>
To: " WG" <>
Content-Type: multipart/alternative; boundary="0000000000006f407705c70cbdb0"
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: Wed, 14 Jul 2021 03:13:46 -0000

On Tue, Jul 13, 2021 at 10:01 AM Viktor Dukhovni <>

> > On 13 Jul 2021, at 6:22 am, Petr Špaček <> wrote:
> >
> > As Viktor pointed out in
> , it seems that this problem plagues roughly tens out of 150k domains he
> surveyed. I think this makes further discussion about _necessity_ of the
> workaround kind of moot.
The plural of anecdotes is not data... unfortunately.

So, I don't recall who presented it, where, or when, but it was some time
in the last couple of years, maybe at an IETF or OARC meeting.
But, the gist of the presentation was that the presenters studied query
sources from a number of vantage points, over a period of years, and
concluded there are approximately 3 million resolvers.

Those resolvers are not all directly connected to the Internet, and
some/many are configured as forwarders (with potentially multiple
forwarders in chains/trees).

The point here is, that Viktor represents one out of three million vantage
points, which undoubtedly have different characteristics in terms of
resolver software and version, and intermediate servers (e.g. forwarding to
resolvers, or forwarding to forwarders).

Additionally, Viktor's data set was TLSA, which is already a niche set that
is self-selected to be on DNSSEC-signed zones, meaning relatively new and
mainstream code bases (possibly over-generalizing admittedly.)
Examining larger data sets on domains that are not DNSSEC-signed, may show
a different prevalence of the ENT problem.

The other distinction is that the problems leading to bad ENT results, may
not be on the authoritative servers, but may be in front of them (close to
the authoritatives), or may be other middle-boxes closer to the resolvers,
or between forwarders and resolvers, etc. Thus the scope of the ENT problem
may vary based on the vantage point being used to collect results.

Thus, in the absence of any statistically meaningful data, I disagree with
the mootness of the issue.

That doesn't mean we can't reach consensus, of course, and given that this
is a -bis document, and we are discussing how to handle the corner case of
underscore ENTs, some focus should be given to the impact rather than the
prevalence. This includes both the impact on code paths, and on the effects
to client apps affected by ENT broken-ness.

It may be helpful to note that the draft itself already differentiates
behavior by the number of labels, in section 2.3 (in a MAY context) using
the MAX_MINIMIZE_COUNT logic. Thus, if an implementation is already doing
that work, adding underscore handling might not be a large burden (and
might mesh nicely in terms of coding). For example, in evaluating the
break-points when partitioning the labels to limit the total number of
queries, the sequence COULD treat any contiguous sequence of underscore
labels as if it were a single label, and then do its partitioning of labels
using the same relative logic.

The main point being, if the implementer is already doing anything other
than literally iterating over all the labels one at a time, under all
circumstances, then adding underscores into its handling isn't likely
significantly burdensome.
The difference between the many-labels problem and the underscore
situation, is the difference between weakness against attacks and
inefficiency (many labels), versus actual brokenness (for some
indeterminate fraction of the namespace from some indeterminate portion of
the resolvers on the Internet).

I'm hoping to advance the discussion even if no one is persuaded.


> Full disclosure, I only tested TLSA records.  I can't speak to what
> one might expect with SRV or other record types.  Yes, failures are
> not that common, for what is worth another example:
> Here the "A" query for the ENT was unexpectedly "REFUSED". :-(
> If implementations at least seriously consider the advice to treat
> special-use labels *specially*, I'll declare victory...
> --
>         Viktor.
> _______________________________________________
> DNSOP mailing list