IETF Logo Mail Archive

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

Vernon Schryver <vjs@rhyolite.com> Sun, 23 July 2017 00:28 UTC

Return-Path: <vjs@rhyolite.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3DF129B61 for <dnsop@ietfa.amsl.com>; Sat, 22 Jul 2017 17:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReJpJcKpvIp2 for <dnsop@ietfa.amsl.com>; Sat, 22 Jul 2017 17:28:56 -0700 (PDT)
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 559DC129468 for <dnsop@ietf.org>; Sat, 22 Jul 2017 17:28:56 -0700 (PDT)
Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v6N0RcmI047051 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org> env-from <vjs@rhyolite.com>; Sun, 23 Jul 2017 00:27:39 GMT
Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v6N0Rc7E047050 for dnsop@ietf.org; Sun, 23 Jul 2017 00:27:38 GMT
Date: Sun, 23 Jul 2017 00:27:38 +0000
From: Vernon Schryver <vjs@rhyolite.com>
Message-Id: <201707230027.v6N0Rc7E047050@calcite.rhyolite.com>
To: dnsop@ietf.org
In-Reply-To: <A05B583C828C614EBAD1DA920D92866BD08246CC@PODCWMBXEX501.ctl.intranet>
X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qHzchXmS56o3X3Dv3nd1dLLSlMw>
Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Jul 2017 00:28:58 -0000

> From: "Woodworth, John R" <John.Woodworth@CenturyLink.com>

> > One could make $GENERATE more efficient without actually implementing
> > the BULK RR, by taking your pattern matching logic and implementing it
> ...

> This would still be a vendor-hack (bind) and not a standard.

The examples I've noticed in this thread look similar to RPZ patterns,
although perhaps I've missed examples that do not fit the RPZ mold.

RPZ is not exactly a standard and certainly not without controversy,
but it is documented and available for more than BIND.
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/

RPZ is officially only for recursive resolvers, but that is because
superficially it makes little sense for an authority to rewrite its
own response.  However, RPZ works on authorities (masters) in at
least BIND.

Could RPZ be a partial solution to the problem that the BULK RR
would solve?

I agree that a statement of the problems solved by the BULK RR would
be good.


Vernon Schryver    vjs@rhyolite.com

v2.23.0 | Report a Bug | By Email