[bind10-dev] datasource list vs zone list

[Michael Graff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

However, this means that the list of zones served becomes something of a
bi-directional handshake.  In BIND 9, we have a zone table which points
to a zone database.  In BIND 10, we may have to have a "catch-all" or
"pattern" match type, and then let the DS itself decide if it wants to
serve that zone's data.  We may need more than one DS to try to serve a
given zone.

Here is what I imagine us doing:

  ZONE_NAME     DS_ID
  flame.org         1
  isc.org           2
  sns.isc.org       3
  example.com       4
  example.net       4
  example.org       4
  <anything else>   5
  <anything else>   6

Here, we have what could be in-memory databases (IDs 1, 2, 3),
programatically generated content (4) using some sort of load balancer
data, and SQL (5) and flat-file filesystem based (6).

In this, ID 4 knows which zones it serves because it will only get
queries for those three domains.  Type 5 and 6 may respond "don't serve
this zone" to fall through to the next match.

It may even be possible to simplify our code by implementing "we don't
serve this zone" as an explicit entry that matches anything, and always
is last on the list.  Then our search logic always gets an answer
without special cases.  Hmm.

The thing about this is that the <anything else> would frequently be
called.  Would we need to cache these so we knew faster which one to
use?  How much would it matter I wonder?  Would this optimization be
pushed lower, or should the lower level tell us what zones it serves and
update this master list should the contents change?

I'm inclined to say we always just ask, just as I described above.  This
lookup table can be made fast.  For non-matches it would be 2 table
lookups and up to 2 calls into two different DSs.  For explicit matches,
it's one lookup (for, say, isc.org in that example table.)

- --Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktM69wACgkQ+NNi0s9NRJ2fVwCgnv1QLmLAdvGlesZev2Lu5YaC
u0gAoLFVt4OsyfwdlOeD8gbO2atwohP2
=KJwJ
-----END PGP SIGNATURE-----