[bind10-dev] multi-class config (Re: Data source configuration)

[Michal 'vorner' Vaner]

Hello

On Wed, May 23, 2012 at 11:47:22PM -0700, JINMEI Tatuya / 神明達哉 wrote:
> The concept shown in the wiki
> (http://bind10.isc.org/wiki/datasrc_config) seems reasonable (except
> that in my revised model we wouldn't have 'match-order'), but I'd make

Yes, the idea behind the proposal is orthogonal to the syntax of one class
data source configuration, so the corresponding thing would be inside.

> it one step more generalized: define them as views.
> 
> While I understand excessive generalization is dangerous especially
> when we don't have much time, views seemed to be highly desired at
> least according to general user inputs.  And, at least if we only
> define a view as a specific set of data sources for a specific RR
> class, the design/implementation cost wouldn't be much different from
> the view-less model.

I'm not really convinced it is an advantage, because:
 • I suspect users don't ask for views because they want to serve multiple
   classes. If we show them this, we may easily get a response of form „Hey, you
   got it all wrong, these are not the views are want at all! What were you
   thinking?“
 • We don't yet have a clear idea of what we want to do with views. As we
   discussed it previously, I think we seem to have at least two proposals:
   ◦ We define some ACL-ish matching and separate data source configurations.
     This is probably more limited than the original Bind9 views and does not
     solve some things, like resolver running on the same port as the
     authoritative server. On the other hand, it very well matches what you
     propose here, so what you propose could naturally be extended into
     something like these views. But I'd still argue about the syntax a little
     bit, there (see below).
   ◦ We have a receptionist with some generic-enough matching rules. Then there
     are several components, which could include several auths with different
     configurations. This is, I think, more flexible approach and solves even
     several other problems (the resolver, all the problematic asynchronous
     handling of several sockets gets gathered to a single place, we would get
     rid of the stupid forwarding of requests from auth to XfrOut/DDNS, which
     would make the SOA+XfrOut over the same connection work, and it would stop
     requiring running auth for XfrOut or DDNS server only). But then, the
     configuration would naturally be somewhat different from this.

> Specifically, if we define a multi-class config using views, it would
> look like this:
> 
> 'dns-view': [
>   {
>     'class': 'IN',
>     'datasource': [
>       { 'type': 'sqlite3', 'file': 'zones.sqlite3',
>         'cache-zones': 'all'
>       }
>     ]
>   },
>   {
>     'class': 'CH',
>     'datasource': [
>       { 'type': 'static' }
>     ]
>   }
> ]

Also, to the syntax. I'm not sure I like it being a list. If the goal is to
split by class only, then we probably want the named set. If we want to have a
generic matching, we should use the ACL framework we have, to allow any kind of
matching. Then we could have several datasource configurations defined
somewhere, under names, and the ACL „targets“ could be the names of the
datasources to fall into.

With regards

-- 
No one is to look like a sock, understand?
			-- Archchancellor Ridcully

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/20120524/3cd63622/attachment-0001.bin>