Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

Mukund Sivaraman <muks@isc.org> Fri, 30 December 2016 12:52 UTC

Return-Path: <muks@isc.org>
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 2FBC01295B7 for <dnsop@ietfa.amsl.com>; Fri, 30 Dec 2016 04:52:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 CYIM_zRHcwcX for <dnsop@ietfa.amsl.com>; Fri, 30 Dec 2016 04:52:17 -0800 (PST)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0511294EA for <dnsop@ietf.org>; Fri, 30 Dec 2016 04:52:17 -0800 (PST)
Received: from jurassic (unknown [115.118.27.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 403EA2FA0350; Fri, 30 Dec 2016 12:52:14 +0000 (GMT)
Date: Fri, 30 Dec 2016 18:22:11 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Vernon Schryver <vjs@rhyolite.com>
Message-ID: <20161230125211.GA5437@jurassic>
References: <20161230091702.GA32139@jurassic> <201612301145.uBUBjNdi061755@calcite.rhyolite.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr"
Content-Disposition: inline
In-Reply-To: <201612301145.uBUBjNdi061755@calcite.rhyolite.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FO4af01xWxAi6oyBtvKkP-FNPLg>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 30 Dec 2016 12:52:18 -0000

On Fri, Dec 30, 2016 at 11:45:23AM +0000, Vernon Schryver wrote:
> Then there is what should happen if a transfer of a policy zone
> happens between the time QNAME rules are checked and the generally
> later time when NSIP and NSDNAME rules are checked.  The draft tries
> to pretend that all of the rules in all of the policy zones are
> checked instantaneously, and never mind real code or the delays forced
> by recursion.  Words about these issues are not BIND specific would
> probably be good, so please suggest some.

This is also a good point. Perhaps just saying that RPZ zone transfers
are not assumed to be atomic for the whole zone, but only at the
RR/policy rule level will suffice?

Paul mentioned during the RPZ bar/pub meeting that the purpose of this
RFC is to document BIND's behavior. BIND is not atomic in handling RPZ
updates. So the draft should explicitly state as unknown what happens
during a zone transfer when there are QNAME and NSIP triggers, where
QNAME comes from a previous revision of the zone and the NSIP comes from
the next revision of the zone.

		Mukund