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

"Woodworth, John R" <> Sat, 22 July 2017 22:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F7BD12EC1D for <>; Sat, 22 Jul 2017 15:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sxzrvDIsUwNY for <>; Sat, 22 Jul 2017 15:20:17 -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 2D2DE129B6A for <>; Sat, 22 Jul 2017 15:20:17 -0700 (PDT)
Received: from lxomp90v.corp.intranet ( []) by (8.14.8/8.14.8) with ESMTP id v6MMKG3J005385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 22 Jul 2017 17:20:16 -0500
Received: from lxomp90v.corp.intranet (localhost []) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMKBn1052079; Sat, 22 Jul 2017 17:20:11 -0500
Received: from lxdnp31k.corp.intranet (lxomp81v.corp.intranet []) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMKAM9052075 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Sat, 22 Jul 2017 17:20:10 -0500
Received: from lxdnp31k.corp.intranet (localhost []) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMKAoQ057868; Sat, 22 Jul 2017 16:20:10 -0600
Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet []) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id v6MMKAia057865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Jul 2017 16:20:10 -0600
Received: from PODCWMBXEX501.ctl.intranet ([]) by vodcwhubex502.ctl.intranet ([]) with mapi id 14.03.0339.000; Sat, 22 Jul 2017 17:20:10 -0500
From: "Woodworth, John R" <>
To: "'Peter van Dijk'" <>, dnsop WG <>
CC: "Woodworth, John R" <>
Thread-Topic: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"
Date: Sat, 22 Jul 2017 22:20:09 +0000
Message-ID: <A05B583C828C614EBAD1DA920D92866BD08246CC@PODCWMBXEX501.ctl.intranet>
References: <> <> <> <> <A05B583C828C614EBAD1DA920D92866BD081C441@PODCWMBXEX501.ctl.intranet> <> <A05B583C828C614EBAD1DA920D92866BD081E686@PODCWMBXEX501.ctl.intranet> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
X-CFilter-Loop: Reflected
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: Sat, 22 Jul 2017 22:20:18 -0000

> -----Original Message-----
> From: DNSOP [] On Behalf Of Peter van Dijk
> Hello John,
> 1 and 2 could be covered with a wildcard PTR, as I think Tony Finch pointed out.

Hi Peter,

Thanks for your comments.

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.

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

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.

> > Forget for a moment about IPv6.  This draft makes $GENERATE more
> > memory efficient, scales bigger, stays intact through AXFR's and yes
> > -it makes some nameservers (authoritative) work a bit more as a
> > trade-off.
> One could make $GENERATE more efficient without actually implementing
> the BULK RR, by taking your pattern matching logic and implementing it
> inside the name server. Of course, this makes generating the NSEC/NSEC3
> chain much harder than it is with today’s $GENERATE implementations
> that actually generate all the names.

This would still be a vendor-hack (bind) and not a standard.  We are
looking for a vendor agnostic solution and feel a standards body is
ultimately right choice.  Additionally, this does not address the
ability to AXFR the 'intent' ($GENERATE).

> A very interesting puzzle would be implementing BULK support, based
> on the pattern matching in the draft, -without- doing NSEC(3)
> white/black lies - i.e. generating the widest possible NSEC instead
> of the narrowest one. For NSEC3 I suspect this is not feasible.

Unfortunately, there are lots of ways DNS is abused to provide an
undue prejudice against huge swaths of mild-mannered, legitimate IPs.

While our solution (NPN) offers the same opportunity for abuse, it
doesn't preemptively defeat other options, such as online signing
where BULK generated records are *exactly* like any other record.


> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV -
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.