[bind10-dev] SQL in BIND 10

[JINMEI Tatuya / 神明達哉]

At Tue, 29 Jan 2013 14:47:02 -0500,
Robert Edmonds <edmonds at isc.org> wrote:

> 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.

If I understand it correctly, our current architecture is pretty close
to this concept, although, probably not that abstracted but rather
keeping (especially SQL-variant) database systems as backend:

- The "client-facing" interface (for DNS) receives a request in the
  form of <qname, qtype>, runs all DNS-specific complicated using
  the "backend-facing" interface to retrieve underlying data, and
  returns the result in the form of an RRset object (with some
  additional information)
- The "backend-facing" interface basically has straightforward
  semantics to retrieve data from the backend or update data in the
  backend with simple text-based semantics.  It doesn't rely on any
  DNS specific knowledge, and mostly rely on primitive exact match
  semantics.  The interface does not rely on the concept of SQL
  either; the "DNS data model" layer and backend interact through a
  tuple of strings (or a list of such tuples) with abstracted concept
  of operations such as "get", "add", "delete".

So, for example, a DNS RR is a tuple of 4 strings:
<name, type, ttl, rdata>.  If the "DNS data model" receives a request for
"example.com/SOA" via the "client-facing" interface, it asks the
backend for all tuples whose "name" field is "example.com." (after
identifying the "zone", but I'm skipping that part for brevity).
The backend somehow identifies it, whether through SQL queries or some
other magic, and returns the matched tuples:
<"example.com.", "SOA", "3600", "ns.example.com. ...">
<"example.com.", "NS", "3600", "ns.example.com.">
<"example.com.", "RRSIG", "3600", "SOA ...">
<"example.com.", "RRSIG", "3600", "NS ...">
...
then the "DNS data model" layer constructs RRsets corresponding to
these (handling errors; the string may not necessarily be valid
textual representation of the corresponding DNS concepts), identifies
the RRsets that match the request from the "client" layer based on the
DNS protocol, and returns it.

The abstraction level is probably immature, but I believe it's not so
fundamentally difficult to refine it to be fully generic.

Of course, there are some really tricky cases such as getting DNSSEC
proofs, which would require more advanced capabilities for the
backend.

Performance will be another issue.  Depending on the expected
performance in terms of (client) query throughput, the generic
interface may be too slow, and usual optimization technique such as
caching may or may not be suitable depending on the expected
requirement.

If we had infinite amount of development resource, we could probably
support all imaginable cases (I believe each single case isn't that
difficult).  But since that's not the case, we need to figure out
which scenario(s) is most important and focus on it.  Hence my
repeated question: what people want to do with SQL (or DB in general)
backend for DNS?

---
JINMEI, Tatuya