Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

Tony Finch <> Mon, 24 July 2017 13:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA58E131D14 for <>; Mon, 24 Jul 2017 06:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nzgAAzV1BN5E for <>; Mon, 24 Jul 2017 06:51:42 -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 87CC6131771 for <>; Mon, 24 Jul 2017 06:51:42 -0700 (PDT)
X-Cam-AntiVirus: no malware found
Received: from ([]:50237) by ( []:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dZdls-000J6b-eN (Exim 4.89) (return-path <>); Mon, 24 Jul 2017 14:51:40 +0100
Date: Mon, 24 Jul 2017 14:51:40 +0100
From: Tony Finch <>
To: "Woodworth, John R" <>
cc: 'Peter van Dijk' <>, dnsop WG <>
In-Reply-To: <A05B583C828C614EBAD1DA920D92866BD08246CC@PODCWMBXEX501.ctl.intranet>
Message-ID: <>
References: <> <> <> <> <A05B583C828C614EBAD1DA920D92866BD081C441@PODCWMBXEX501.ctl.intranet> <> <A05B583C828C614EBAD1DA920D92866BD081E686@PODCWMBXEX501.ctl.intranet> <> <A05B583C828C614EBAD1DA920D92866BD08246CC@PODCWMBXEX501.ctl.intranet>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: <>
Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Jul 2017 13:51:44 -0000

Woodworth, John R <> wrote:
> Wildcards are a good start, or at least they appear so on the surface.
> Unfortunately, the vagueness of their definition and various
> implementations of wildcards would make this a poor choice.

Do you mean there are problems with RFC 4592? If so, what are they?
Can you give us details, please?

> Not to mention, wildcards will severely fragment the namespace once
> real PTRs are introduced creating a rather fine mess.

In what way? What do you mean by "fragmented"?

A reverse lookup would get a generic wildcard PTR for unregistered
addresses and a specific PTR for registered hosts. If you choose the PTR
names sensibly then I don't think the namespace would be fragmented.

The main disadvantage (same as BULK) is that it would screw up mail server
anti-spam heuristics.

> This would also add another level of complication and restrict the
> layering capabilities we are attempting to introduce and would
> inevitably prove far more problematic and resource intensive than
> you might expect, simply to compensate for all the fragmentation.

Can you unpack this in more detail please?

What are these layering capabilities you refer to?

Why do you think wildcards are more resource intensive than BULK?

f.anthony.n.finch  <>  -  I xn--zr8h punycode
Dover: Northwest 4 or 5, occasionally 6 at first. Slight. Rain. Moderate or