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

[Vernon Schryver <[e-mail]>]

> From: Mukund Sivaraman <[e-mail]>

> > 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.


> 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.


Vernon Schryver    [e-mail]