[bind10-dev] Idea for simple (but limited) views

[Michal 'vorner' Vaner]

Hello

We all agree that implementing the full views is probably a lot of work and will
take plenty of time. That's mostly because the views are overgeneral and allow
you to do quite anything and probably even more. I'm not saying we don't want to
do that eventually, but there seems to be not enough time for everything lately
:-(.

But if we restricted ourself to just one scenario ‒ providing different zones
for different clients, there's an easy solution (I'd guess something like 2 or 3
tickets would do it, once we switch to the newer configuration in all the
XfrIn/XfrOut/ZoneMgr…).

The idea is, we won't provide different zones to the different clients, but
different data sources. They can contain different zones or just the same zones
with different content. It is possible to have multiple copies of the sqlite3
data source and if that would be deemed too heavyweight, I have a proposal for
that below.

So, we already can have multiple data sources in the list. We take the first one
that matches to answer the query. So, let's put a (kind of) ACL on each of the
data sources. They would not have DROP and REJECT as with queries, but something
like:

SKIP::
  Don't look into this data source when looking for the matching zone. Continue
  with the next data source.
CONSIDER::
  Look into this data source as usual. If the zone is found, good, return it. If
  not, continue in the client list to the next data source.
FORCE::
  Look into this data source. If the zone is found, good, return it. If not,
  return „not found“ and don't continue.

I even might write some dirty experimental code during some weekend (because I
discovered I'd have some use for returning different A addresses for my own
resolver than to the outside world, was thinking how to do it properly with
signed A records and thought how to do it easiest. So this is what I came up
with and it seemed not too hacky to consider as real solution).


Now, about the problem about having several databases. Well, let's have a
virtual „filter“ data source. That one would take another data source as a
parameter. When a request for a zone would come, it would look into the filters
it has, decide if it wants to answer or not (or how to mangle the zone origin,
optionally) ‒ the filters could be implemented as kind of ACLs too, with just
rules matching the zone name and targets like „YES“ „NO“ and „Mangle to
<new-zone-origin>“. The rest of the operations would be just delegated to the
data source.

We could just reference other data source as the slave one by name, and have an
„always SKIP“ ACL on that one (and, optionally, put it at the end). So several
filter ones could use the same one and possibly same memory cache.

The first part is the important one, the second just optimisation.

So, what do you think about that? Do you see any obvious problem?

With regards

-- 
The cost of living is going up, and the chance of living is going down.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130612/1e2c1668/attachment.bin>