[bind10-dev] SQL in BIND 10

[Shane Kerr]

All,

tl;dr version: 

* Please let us know your specific BIND 10 SQL use cases.

* We want to define the difference between "captive" and "free" schemas
  for BIND 10 SQL

Full version:

We had a discussion at the last BIND 10 team call about SQL.

We decided that we actually need to figure out what we need out of SQL.

Jinmei is always very keen on understanding the user requirements for
SQL. As I see it, everybody tells us they want SQL, but nobody tells us
exactly what that means. I think there are 3 different use cases:

1. SQL brings instant startup and low memory use for either lots of
   zones or many zones.

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.

3. Your boss spent $1.5 million on expensive SQL licenses, and there is
   a corporate mandate to use that SQL server for everything. ;)

In the first case, we can have what we call a "captive" SQL server.
This means that we can have a rigid schema, and also encode things in
DBA-unfriendly ways (like putting RDATA in as BLOBs rather than VARCHAR
values, or encoding name).

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.

I think the next step is to delve a little more deeply into these
differences and document them.

Cheers,

--
Shane