List all configured domains of an Auth Server?

[Michal 'vorner' Vaner]

Good morning

On Fri, Mar 22, 2013 at 07:27:17PM +0100, Konstantin Agouros wrote:
> In playing with cache zones I found something odd today:
> 
> in IN[0] I have two zones, after setting cache-enable to true (for a perfomance test) and adding one of the zones to cache-zones
> I got the result the a query to the other zone gave me a 'refused'. Is this intended?

It is not completely intended in the meaning we would prefer it that way. But it
is consequence of how the cache works, it is known (and documented).

If the cache is enabled, we don't look into the underlying database. That would
be slow and we want to avoid that with the cache. So only the cache is used
instead. But if you don't load the other zone, it's not there, so the server
thinks it doesn't exist.

In future, we want to have the server detect all the zones in the database and
load them all unless it is told otherwise.

If you want to answer one zone from the cache and queries to other zones from
the database, you can still do that, with something like (writing from memory,
might contain mistakes):

datasources/IN[0] = {
  'type': 'Sqlite3',
  'cache-enabled': true,
  'cache-zones': ['cached.zone'],
  'params': '/path/to/db'
}

datasources/IN[1] = {
  'type': 'Sqlite3',
  'cache-enabled': false,
  'params': '/path/to/db'
}

So, you have the same data source twice, once with cache, once without. If it is
not found in the cache, the query falls through to the next data source. Now,
without cache, it looks into the database.

With regards

-- 
You can't have everything... where would you put it?
    -- Steven Wright

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-users/attachments/20130325/c519f2ab/attachment.bin>