[bind10-dev] Data source configuration

[Michal 'vorner' Vaner]

Good morning

On Thu, May 24, 2012 at 10:34:17AM -0700, JINMEI Tatuya / 神明達哉 wrote:
> 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.

I agree that we want the interface to get the current list of zones.

However, I really disagree with prohibiting a modification of a database data
source. We may want to have some „captive“ database back-ends, but generally,
I understand the main motivation for having DNS in database is that anything can
modify it. We may want to require for whoever modifies the database to call a
command on Bind10 to reload, but I don't think it is something people want to
do, because then they can just have a script that generates a master file.

> 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'] }

Hmm, right, I didn't think too well about it. It would probably work the correct
way here.

> 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)?

No, I'm thinking 1 here. I don't think the admin should filter queries coming
in. I just wanted the admin not to have child.vip.example.com zone in the data
source below the In-Memory, because the query would never get that far. But if
there's no child.vip.example.com zone at all, thats satisfied.

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

Yes, you're right. I didn't see the A would solve the problem.

So, after all, I think your way would work, provided Bind10 is notified somehow
the list of zones changed in the DB.

With regards

-- 
Anyone who goes to a psychiatrist ought to have his head examined.
		-- Samuel Goldwyn

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/20120525/d4ab3ed6/attachment.bin>