[bind10-dev] SQL in BIND 10

[Stephen Frost]

* JINMEI Tatuya / 神明達哉 (jinmei at isc.org) 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). 

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

> One other thing I'm interested in about this mode of operation is
> expected response performance.  I guess it's not difficult to achieve
> a few thousands of qps even without any caching within the DNS server,
> but if the required performance is higher than that level, we'll need
> something more sophisticated.  And, depending on the background reason
> for the performance requirement, usual approaches like caching may not
> be a good solution.  For example, if the concern is resiliency to DoS
> attacks, caching won't be really effective because it should be pretty
> easy for the attacker to attach the cache itself.

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.

> Do you have any idea about this point, either from what other users
> wanted or from what you'd expect yourself?

There is some expectation/assumption of a cacheing system because
everyone "knows" that going all the way back to the SQL server will be
"slow".  However, I don't think anyone would seriously complain if it
isn't available immediately and, from a PG point of view, I'm hopeful we
can make it performant for many, if not most, cases.

	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/20130206/a9aad1ca/attachment.bin>