[bind10-dev] SQL in BIND 10

[Stephen Frost]

JINMEI,

* JINMEI Tatuya / 神明達哉 (jinmei at isc.org) wrote:
> One thing I'm not sure about the support for DNSSEC in the
> "open-schema SQL backend" model is that where the RRSIGs are stored
> and maintained.  

It could likely be done in either place, but at least in PowerDNS, they
support having that data be in the open schema backend.

> When we say "BIND 10 w/ SQL support is integrated
> with a user's provisioning system", I assume the original data for the
> eventual DNS RRs are maintained in that "provisioning system"
> (whatever it is specifically).  But such original data may not even be
> in the form of RRs but something like pairs of <host name, IP
> address>, (which will become AAAA or A RRs in the DNS world), let
> alone DNSSEC-signed.

Sure, it could be in most anything- the point is to allow the user to
define how bind10 can get that data.  Clearly, we'll need/want to have
at least one example of that which does things "the right way".

> I've not closely looked into the DNSSEC support of PowerDNS, but my
> preliminary understanding is that signatures are not in the user
> database but generated and maintained either in-memory or in some
> "captive" storage.  Is that what people would expect when they want to
> support DNSSEC with their own provisioning system?  Or are they
> willing to maintain DNSSEC related data in the own system?

My gut feeling is that the preference would be for that data be able to
be in the backend, to allow them to maintain it.  If it doesn't exist in
the backend database, there's no hope for them to have any direct
control over it.  It'd certainly be good to provide a way to 'help' them
maintain it, if they want.  I don't believe that it has to be something
that's fully managed in an ongoing way in bind10.  Certainly, whatever
is 'simplest' is the first order of business.

> > Right.  That said- we need to be careful with the template system.  One
> > of the issues with PowerDNS is that they've implemented their own
> > DB-independent templating system which is structured in such a way that
> > it's essentially impossible to use SQL prepared queries with it.  We
> > definitely don't want to repeat that.
> 
> Hmm, I'm not sure what this means...could you be more specific?

In PowerDNS, they have a system that looks more-or-less like this:

Config file has SQL statements with variables in it such as '%d'.
The backend code has a single piece of code that grabs the config file
entries and then runs it through parameter substitution and the result
is a complete text string.  That text string is then sent to the SQL
backend (whichever one is used).  One of the big problems with this
setup is that it precludes using prepared statements because the
SQL-related code never gets the parameters independently of the text
string.  It's not easy for the PowerDNS folks to fix that, however, as
the API to the SQL backends doesn't pass through the necessary
information and I'm sure they don't want to run the risk of breaking
existing applications by changing the logic that puts together the query
that is sent to the backend.

> Okay, from this I guess very high performance such as over 10Kqps is
> not crucial for such users and/or performance under intentional
> attacks is not a big concern.

Agreed.

> Depending on what it exactly means (see above), "full DNSSEC" may not
> be very difficult, btw.  The SQL-independent layer is already fully
> capable of DNSSEC for query processing, so the remaining question is
> how/where to maintain the keys and signatures, and how to get DNSSEC
> related data from the user database (the latter could also be tricky
> because with DNSSEC a simple exact match isn't sufficient).

Glad to hear that it might not be too bad.  It certainly looks like
bind10 has a lot of the interface already in place to allow for
pluggable SQL libraries.  I've been looking through your branch at what
changes were made and I have to admit that it looks like more than I
would expect, but that may be just because I'm not very familiar with
the code.

	Thanks,

		Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130212/b68b4b08/attachment.bin>