[bind10-dev] datasource list vs zone list

[João Damas]

2 is OK if there is a way to generate the data sources in an atomic way, otherwise you risk loading half-baked zones

Joao

On 13 Jan 2010, at 10:28, Shane Kerr wrote:

> Michael,
> 
> On Tue, 2010-01-12 at 15:38 -0600, Michael Graff wrote:
>> On the datasource call, a topic came up that is sort of interesting.
>> Namely, how do we do the mapping from zone name to datasource?  Also,
>> can multiple DSs take a stab at an answer and say they do not handle
>> that zone, try the next one?
>> 
>> What I see happening is that data sources are configured to serve zones
>> in one of three ways:
>> 
>> (1)  Explicitly told to serve zone example.com and where to find the
>> data.  In this model, there is a zone -> datasource mapping that is
>> direct and administrator provided.
>> 
>> (2)  The data magically appears in some way, no explicit notification.
>> This is going to be a big win:  all you need to do to start serving a
>> zone is to populate a SQL database, file on a filesystem, etc.  This is
>> magic, and dynamic, and ideally requires nothing special done to BIND.
>> 
>> (3)  A combination of both:  shared database (SQL tables include zone
>> info, for instance) and to make that zone served, you need to configure
>> as well.
>> 
>> I like (1) and (2).  I dislike (3) as it seems cumbersome.
> 
> As a data point, I believe PowerDNS tries all data sources, effectively
> doing (2).
> 
> We have to support some data sources in the style of (2).
> 
> We *could* maintain a table like you presented listing explicit zones.
> But... simply going through all the data sources in a configured order
> is the most straightforward solution. I think we should implement that
> first, and then we can look at improvements later if they seem like they
> will be beneficial.
> 
> What I propose in PseudoPython: 
> 
> lookup_result = NotAuth   # maybe Refused is better, but I like NotAuth
> for source in dataSources:
>      lookup_result = source.lookup(query)
>      if lookup_result != NotAuth
>          break
> 
> We may encourage people to have 2 data sources (one in-memory) if they
> have a set of high-volume zones (assuming our caching doesn't make that
> unnecessary). And of course there will always be people in special
> circumstances who need N sources (testing, migration, general
> weirdness).
> 
> In practice the vast majority of people will have 1 data source. If we
> *do* decide to have some sort of domain lookup table, we should probably
> only use it if we have more than 1 data source.
> 
> --
> Shane
> 
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev