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

[Vernon Schryver <[e-mail]>]

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

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

I understand the goal of the draft a little differently.  I think it
should document the RPZ mechanism that originally existed only in BIND,
but without bugs or BIND9 specific oddities that no one not reading
BIND9 code would discover.  It must be readily added to other recursive
server implementations whose internal mechanisms differ from those of BIND9.

]                                     BIND is not atomic in handling RPZ
] updates. 

I've the impression that BIND applies IXFR/AXFR changes to all slave
zones atomically, so that an ordinary DNS response is always based on
a single version of the zone associated with the SOA serial number,
and hence the version pointer that is carried around in bin/named/query.c.

On the other hand I think we're talking about the fact that RPZ trigger
checking in BIND9 is (or was?) not atomic with respect to concurrent
policy zone updates or changes.

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

I think I agree with that.  If the working group does not reject the
draft, I will try to add text near the 3rd and 4th paragraphs of section 5
saying implementations need not check RPZ triggers atomically with
respect to concurrent policy zone transfers.

I'd welcome suggestions for those words.

 ..............


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

Wouldn't this also be covered by  words in section 5 saying
implementations need not check RPZ triggers atomically with respect
to concurrent policy zone transfers?


Vernon Schryver    [e-mail]