[bind10-dev] Data source configuration

[JINMEI Tatuya / 神明達哉]

At Thu, 24 May 2012 10:38:52 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > Second, regarding the matching strategy in case we have multiple data
> > sources.
> 
> See above. I would discourage use of other than best-match unless
> people really need it and know what they are doing. But I don't
> think we should not support it.

If I understand your argument so far, the main point is this one, and,
more specifically, this:

> > The 'cache-zones' config for the 'mysql' data source example could be
> > tricky, in such cases like the underlying data source has
> > 'child.example.com' and auth gets a query for the child zone.  One
> > possible (maybe short term?) solution would be to allow only 'all' or
> > 'none'.  A more flexible solution would be that a cache at least
> > contains a complete list of zones of the underlying data source
> > in-memory, and if a lookup detects the best matching zone is not
> > in-memory but in the underlying data base, it somehow forwards the
> > query request to the real data source.
> 
> All this has a slight problem. How do we know the list of zones
> changed, to reload it? The database can be filled/modified with some
> other system (I think it is the main driving need of having a
> database in the first place, the company has some system where users
> click in the eshop and add their zone, so it goes to a database
> right away).

I believe we'll need an interface to get a list of zones for various
purposes anyway, whether or not we implement this optimization.  Also,
the problem when someone manually modify the list without the BIND 10
interface is not specific to this idea.  That applies to zone content
itself.  We'll need to either prohibit such an operation or introduce
some mechanism such as triggers with which we automatically
synchronize the BIND 10's internal state with the manual changes.
So I don't think these concerns are a fundamental showstopper.

Now, revisiting your vip.example.com example...it's a hosting
company that has this config:

'datasource': ...
  { 'type': 'mysql', ..other param, 'cache-zones': ['vip.example.com'] }

and in that mysql database there are millions of other minor
example.com. zones, maybe including child.vip.example.com.

What we'd want is to only cache vip.example.com, and no query for
that zone hits the underlying mysql database.

The first question is: what should happen for queries under
child.vip.example.com?
1. It should be answered from the vip.example.com zone via the mysql
   database.
2. It's not a supported operation.  It's the admin's responsibility
   to ensure that such a situation doesn't happen.

I thought our answer is 1 (and I guess Jelte would say so, too,
according to his comment in a similar but slightly different context),
but maybe you're thinking about 2 (perhaps as well as 1 if possible)?
This is a policy matter, and I don't think there's one single right
answer here.  We need to decided based on what we as a team think,
and, ideally, based on what our possible users want.

But let's assume we want to achieve 1 for now.  Then the second
question is how to do that:

A. Make sure the cache also contains a list of zones in-memory
B. Introduce some special matching strategy that somehow makes it
   possible
C. Maybe others, but right now I don't have other ideas

I suggested approach A above.  I'm not sure if you even wanted to
allow that, but if you did, you probably intended approach B.

I don't mind adopting approach B as long as we can achieve the goal
and it works with various methods (findZone, get iterator/updater) in
an intuitive way.  I simply didn't have an idea in this direction.

> > 'auth': { 'use-datasource-cache': true, ...}
> > 'xfrout': { 'use-datasource-cache': false, ...}
> > 'xfrin: { 'use-datasource-cache': false, ...}
> > 'ddns: { 'use-datasource-cache': false, ...}
> 
> Would things work if the user tweaks? Or would DDNS/XfrIn just break
> and XfrOut misbehave? If the second, we probably want to hardcode
> this instead of providing the options.

Right, in reality, this won't be configurable for things other than
auth at least for the initial implementation, and even never for
xfrin/ddns.  I guess xfrout could use it even today for small zones
if it doesn't want to involve database access (e.g. for reducing the
risk of read/write conflicts), though.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.