[bind10-dev] SQL in BIND 10

[Robert Edmonds]

Shane Kerr wrote:
> [...]
> 2. Users want to insert data directly into an SQL database, or read the
>    value there, from other applications, and have it be the same as the
>    DNS view of the world.
> [...]
> In the second case, we need to be more flexible, perhaps only
> specifying a VIEW (in the SQL sense, not the BIND sense) or even a set
> of queries.
> 
> There are a number of issues with a flexible schema:
> 
> * In order to properly update the DNS, you should update related
>   fields, for example the SOA needs to change when the zone contents
>   change.
> 
> * If we want to support IXFR then zone history needs to be maintained.
> 
> * External events - such as NOTIFY - should be triggered based on
>   updated zone contents.
> 
> * Some operations - such as getting NSEC records - require sorted
>   zones, and in order for these to be retrieved properly they need to
>   be encoded somehow.
> 
> There are surely a few more issues, but this gives the general idea.
> 
> We may be able to provide helper functions for these, or simply have
> the database configuration define which features are supported. If we
> want to be sexy we can try to use TRIGGER and stored procedures to keep
> data synchronized automatically - although at that point we start to
> run into code duplication issues.

hey, this might sound crazy, but does that second use case strictly
require that there be a really existing SQL server being used as the
backing store, or does it only require that the _interface_ of a SQL
server be provided?  what if the DNS data model were somehow mapped onto
some subset of, say, the mysql client protocol?  if you had such a
mapping layer from SQL client -> DNS for "flexible" use cases, your
backing store could then be any "captive" data store that could support
the DNS data model... including a SQL server.  in other words, treat SQL
servers as data stores, and SQL clients as clients speaking a weird
RPC protocol.

-- 
Robert Edmonds
edmonds at isc.org