Re: [DNSOP] BULK RR as optional feature

"Woodworth, John R" <> Thu, 30 March 2017 20:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39A0D1270A7 for <>; Thu, 30 Mar 2017 13:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rPWcv77AuUvN for <>; Thu, 30 Mar 2017 13:49:05 -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 D9DCC124B0A for <>; Thu, 30 Mar 2017 13:49:04 -0700 (PDT)
Received: from ( []) by (8.14.8/8.14.8) with ESMTP id v2UKn3Ov011674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Mar 2017 14:49:04 -0600
Received: from (unknown []) by IMSA (Postfix) with ESMTP id DF5AB1E0035; Thu, 30 Mar 2017 14:48:58 -0600 (MDT)
Received: from lxdnp32k.corp.intranet (unknown []) by (Postfix) with ESMTP id B938E1E0061; Thu, 30 Mar 2017 14:48:58 -0600 (MDT)
Received: from lxdnp32k.corp.intranet (localhost []) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v2UKmwd0049637; Thu, 30 Mar 2017 14:48:58 -0600
Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet []) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v2UKmwAZ049624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Mar 2017 14:48:58 -0600
Received: from PODCWMBXEX501.ctl.intranet ([]) by vodcwhubex501.ctl.intranet ([]) with mapi id 14.03.0339.000; Thu, 30 Mar 2017 15:48:58 -0500
From: "Woodworth, John R" <>
To: 'John R Levine' <>
CC: "" <>, "Woodworth, John R" <>
Thread-Topic: [DNSOP] BULK RR as optional feature
Thread-Index: AQHSp/GxEz7tgyTElE2qFZBLVlV576GrDi6A///pAzCAAHKOgIAAGG8A//+zUjCAAPDVAIABbY1wgAB8swD//6x4EAAL0lyAAApru7A=
Date: Thu, 30 Mar 2017 20:48:57 +0000
Message-ID: <A05B583C828C614EBAD1DA920D92866BD0733A4F@PODCWMBXEX501.ctl.intranet>
References: <20170328183156.2467.qmail@ary.lan> <> <A05B583C828C614EBAD1DA920D92866BD0717CFC@PODCWMBXEX501.ctl.intranet> <> <alpine.OSX.2.20.1703282245500.4804@ary.local> <A05B583C828C614EBAD1DA920D92866BD071C1E3@PDDCWMBXEX507.ctl.intranet> <alpine.OSX.2.20.1703290833160.5140@ary.local> <A05B583C828C614EBAD1DA920D92866BD07336F0@PODCWMBXEX501.ctl.intranet> <> <A05B583C828C614EBAD1DA920D92866BD0733877@PODCWMBXEX501.ctl.intranet> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [DNSOP] BULK RR as optional feature
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: Thu, 30 Mar 2017 20:49:09 -0000

> -----Original Message-----
> From: DNSOP [] On Behalf Of John R Levine
> That's a lot of "if"s.  It is quite common for primary and secondary
> providers to have only a loose relationship, and they do not know or
> care about their detailed capabilities.  I swap secondary service
> with a bunch of other people I rarely talk to (no need) and if they
> started sending me BULK records, the results would not be good.

Hi John,

Thanks again for your time.

This seems to me more a problem of demand vs. capabilities.

If my secondary provider didn't offer a feature that was important
to me, say DKIM, I would _have_to_ contact them and request they
upgrade stressing its importance to me and my business.  If there
was no chance of support within a reasonable time-frame I would
have no choice but to move.  If enough requests were made to support
DKIM, it may justify an upgrade to that provider.  This is really no
different, if there is no demand then support is always optional.

  Not to pick on DKIM, this could really be anything, DNSSEC,
  dual-stack support, etc.

> It seems like you are assuming that everyone will eventually support

More blind optimism than an assumption :)

I would hope at least NPN validation support would be eventually
included nearly everywhere but understand even if this should turn out
to be true it will likely take many years.

> I see no reason to assume that -- for those of us with small systems,
> and who do not want to do generic 6 rDNS (see
> draft-ietf-dnsop-isp-ip6rdns) it's just bloat.  This means it'll
> always be optional, and optional DNS features present new
> operational issues that we haven't begun to address.

Agreed and if it were important to hypothetical me, hypothetical I
might hypothetically say "We're gonna need a bigger boat" :)


> Regards,
> John Levine,, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
> _______________________________________________
> DNSOP mailing list
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.