[bind10-dev] SQL in BIND 10

[JINMEI Tatuya / 神明達哉]

At Wed, 6 Feb 2013 22:03:55 -0500,
Stephen Frost <sfrost at snowman.net> wrote:

> > If this is the (or at least one) major use case of database backend,
> > our next step should be to implement a much simpler DB-client layer
> > that (at least initially) focuses on getting data, and probably
> > excluding DNSSEC related features.  
> 
> I can certainly see handling the 'simple' cases first but DNSSEC needs
> to absolutely be supported in the 'near-term' too.  PowerDNS does this
> but they've had to make some not-entirely-friendly changes between
> releases.  It would certainly be good to learn from their experiences
> (though, from what I've seen so far, there's definitely DNSSEC-smart
> folks here, so hopefully we can avoid any pitfalls). 

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

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?

> > The user will configure that layer
> > with the type of DB and DB-specific parameters such as DB/table name
> > and user/password, and a template of SQL sentence(s) to retrieve
> > necessary data to handle DNS queries.
> 
> 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?

> > One other thing I'm interested in about this mode of operation is
> > expected response performance.  [...]
> 
> As mentioned, people are already using PowerDNS as a hidden master with
> bind slaves on the edge.  That's certainly one model for how to address
> response performance.  That said, I'd like to see bind10 and PG work
> together to achieve the best performance they can and possibly even
> drive each other to be better.  It might be necessary to have a cacheing
> system directly in the bind10 system which talks to the SQL backend, but
> our time would likely be better spent on things like getting full DNSSEC
> working first.

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.

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

Thanks,

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.