Can anyone from Bluecat comment on the factors that went into the implementation choices for local RPZ zones?
Rather than managing actions record-by-record in an RPZ, Integrity writes out a default policy for each zone in the named.conf (and then writes all the records’s (“response policy items” in BAM parlance) rdata as “CNAME .” in the zone file.)
This means ALL response policy items in a given response policy (zone) have the same action. If you want a different action, you have to create a different response policy - and BIND has an upper limit of 64 RPZs. So essentially I can only have 64 unique responses via local RPZ under Integrity.
RPZ itself (natively, in BIND) is much more flexible. For any given RPZ I can have thousands of records in them each with their own unique action. So if I have a one-off DNS zone or particular FQDN I want to override resolution for, I don’t have a burn one of my 64 available zones to do so, as Integrity is forcing us to do - I just place the record in an existing RPZ with the desired action. Competing products in the DDI space allow for record-by-record action definition within an RPZ.
Why has Bluecat hamstrung RPZ flexibility by forcing the default policy override in named.conf for each RPZ? Or am I missing something fundamental?

