[bind10-dev] SQL in BIND 10

[Robert Edmonds]

Michal 'vorner' Vaner wrote:
> On Mon, Jan 28, 2013 at 06:35:21PM -0500, Robert Edmonds wrote:
> > 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.
> 
> I'm not sure I understand you correctly. So you propose that instead of making
> bind10 read data from real database somehow (either to memory or on demand), we
> create our own database for DNS data with our specific needs and pretend to be
> an SQL server so people can add and remove and query the data through well-known
> protocol?

hm, sort of.  i am imagining an abstract architecture where there is a
central component that implements what might be called "the DNS data
model" which has a client-facing interface and a backend-facing
interface.  adding a new client "protocol" (DNS, SQL, HTTP, etc.)
requires only mapping the client "protocol" onto the DNS data model, and
adding support for a new backend (mysql, postgresql, leveldb,
berkeleydb, etc... there are a lot of possible backends, including one's
own custom on-disk or in-memory data stores) requires only mapping the
DNS data model onto the backend.  this is a very rigorous architecture
where the DNS server fully controls the backend data store and mutations
are only permitted through the client-facing interface so that the "DNS
data model" can verify that requests are valid and only fully conformant
changes are committed to the data store.

counterintuitively, "zone files on disk" could be both a client-facing
interface (zone files edited by admin) and a backend interface (zone
files maintained by server).  similarly "SQL" could be both a
client-facing interface (fake "SQL client" protocol) and a backend
interface (real "SQL server" data store).

this architecture depends on the data store being fully "captive" to the
DNS server.  some data stores are inherently well suited to this (e.g.,
berkeleydb, leveldb, tokyocabinet, SQLite, etc. are libraries which only
allow a single process to open the data store at a time) while other
data stores (e.g., just about any type of SQL backend except SQLite)
unfortunately permit changes to occur behind the back of the DNS server.

> I think that could work for some use cases, but that'd be definitely
> much more work.

yes, i'm primarily thinking of the subset of use cases for SQL + DNS
which might be whimsically described as, "It's a [SQL server], I know
this!" (http://www.youtube.com/watch?v=dFUlAQZB9Ng) which could be
satisfied by merely pretending to be a SQL server :)

as for it being much more work, yes, there'd be more work required up
front, like mapping every possible kind of arbitrary SQL statements onto
the DNS data model.  but think of all the advantages of treating SQL
servers as straight-forward dumb data stores rather than complicated
multi-user systems whose features have to be carefully circumvented with
triggers and access controls and stored procedures written in weird
proprietary languages.

> When I hear people want SQL, I usually imagine something like this:
>  • They have some complex provisioning system. They store everything in it, from
>    salaries to list of computers with locations, names and owners.
>  • It's all already stored in some database.
>  • There's bunch of web applications, scripts and fat GUI programs working with
>    that database.
>  • Currently, to get the data to DNS, there's a script that walks the database
>    and converts it to a master file. Then it calls some magic to force the server
>    to reload it.

well, i really hope no one is putting sensitive HR information
(salaries, etc.) anywhere near their network provisioning systems.
certainly there are a lot of IPAM systems
(http://en.wikipedia.org/wiki/IP_address_management) that store
information in SQL databases.  that sort of use case argues for a
different architecture, where the authoritative data model is in some
SQL database, and the DNS server is just a dumb translator between that
and the DNS query protocol.

> I guess the people would really like the last one to disappear and let the
> server take the data directly. Not to call anything, just change the data there.
> And changing the database is probably completely out of question due to the size
> of the rest. So they would say „Connect to server X on port Y with this name and
> password. You get a required RRs by sending the query 'SELECT x, y, z FROM a
> JOIN b ON a.m = b.n WHERE a.name = %1…'“.
> 
> It might be only my imagination, though. However, it illustrates what I mean
> when we talk about free database.

-- 
Robert Edmonds
edmonds at isc.org