Hi Vernon On Fri, Dec 30, 2016 at 11:45:23AM +0000, Vernon Schryver wrote: > > From: Mukund Sivaraman <m...@isc.org> > > > > In 4.1.1 (IP address encoding in triggers), I suggest adding: > > > > > > - The encoded address prefix MUST NOT not have any extra trailing 1s > > > (longer address prefix than the prefix length) or the rule will be > > > rejected. E.g., the following trigger will be rejected: > > > > > > 8.1.0.0.10.rpz-client-ip > > The draft tries to address that issue with these final words of 4.1.1 in > https://tools.ietf.org/html/draft-vixie-dns-rpz-04 > > ] In the case of an address block, either IPv4 or IPv6, the address > ] part MUST NOT contain any non-zero bits after the section indicated > ] by the prefix length. For example, "8.2.0.0.10.rpz-client-ip" is not > ] a valid trigger, because in the address "10.0.0.2" expressed in > ] binary notation, a one occurs outside the first 8 bits or prefix of > ] the address block. > > Please suggest improvements. > > > > > Some minor nits: > > > > > > - Include an IPv4 example in 4.1.1 (IP address encoding in triggers) > > I don't understand how that would differ from the second paragraph of 4.1.1 > which is > > ] For example, the address block 192.0.2.0/24 is encoded as > ] "24.0.2.0.192". > > Could you suggest some more or better text? > > > > > - Maybe include that "zz" label in v6 encoding can also appear on > > > - either side of the address bits label sequence > > I don't understand. Describing how zz/:: works seemed difficult (as > demonstrated by the tech.note), so the draft tries to punt to RFC 5952. > As always, please suggest better words than are now in the draft.
It seems that I was again reading an older revision of the draft! It
appears Paul did make the changes. I'm sorry for the confusion.
> > 2. BIND makes the assumption that a trigger is exclusive within a zone.
> > So for example, if a zone transfer of an RPZ zone has taken place, and
> > currently the RPZ summary datastructures are being updated, the
> > datastructures can contain policy rules partially from an older version
> > of the zone and partially from a newer version of the zone (from the
> > transfer). As long as the change to an entire RR of a policy rule is
> > applied atomically, to BIND this is a consistent set of policy rules
> > (some of rules from previous version of zone, remaining from newer
> > version). This behavior is consistent with the RPZ rules so far, but it
> > would be wise to make a note of it.
> >
> > (Note that this behavior is different from the old BIND RPZ
> > implementation and so you may not be familiar with it.)
>
> Are you saying that the rdataset held st->r.r_rdataset or st->r.ns_rdataset
> could be bogus in old versions of BIND? Or that st->r.ns_rdataset and
> st->r.r_rdataset might be from differing versions of red/black trees?
> If so, that sounds like a good bug fix that might be documented in
> BIND release notes or elsewhere, but not like something that should
> be mentioned in description of the protocol.
>
> Or do you mean that there should be words somewhere to the effect that
> RPZ results must be sane despite concurrent AXFR/IXFR activity of
> individual policy zones? If so, please suggest some words. 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.
What I mean is is effectively this: an update to an RPZ zone on the
resolver may not be atomic, i.e., the resolver may not match policy
rules against a consistent before- or after- copy of the RPZ zone during
its zone transfer.
It may have a copy of RPZ policy rules in a datastructure that is
partially from a previous revision of the zone, and partially from the
incoming next revision.
Let A be the pre-transfer revision of the zone. B be the post-transfer
revision of the zone:
1. If trigger X doesn't exist in zone A and doesn't exist in zone B, the
resolver will not match against X during the transfer. This is
consistent with the case when the zone update is done atomically.
2. If trigger X exists in zone A and doesn't exist in zone B, the
resolver may or may not match against X during the transfer. This is
consistent with the case when the zone update is done atomically.
3. If trigger X doesn't exist in zone A and exists in zone B, the
resolver may or may not match against X during the transfer. This is
consistent with the case when the zone update is done atomically.
4. If trigger X exists in zone A and exists in zone B, the resolver will
match against trigger X from zone A or zone B during the transfer. This
is consistent with the case when the zone update is done atomically.
What I mean to say is that a zone transfer of policy zone is not atomic.
The resolver may match against triggers in A or B depending on the
progress of update. Only 1 trigger may match within a zone, so this can
be assumed with current RPZ syntax. But this behavior of RPZ zone
transfers not being treated atomically should be documented.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
