Would anyone be interested in doing some testing if I ported the Bind 8
SQL patches to Bind 9?
Just FYI:
I might point out that BIND version 9 comes with a Postgres/SQL sample "simple database interface" driver that permits the storage of DNS zone data in a Postgres/SQL database. Zone data is extracted from the database per query (the data does not need to be extracted and BIND reloaded). If the DNS load is too high to support SQL queries on a per-DNS query basis, using a stealth primary would most likely work.
Rgds,
-drc
I'll take a look at that. It might be a good idea to make it modular, if
it isn't already modular[0], so that people could create "plugins" that
work with other databases. Personally, I'm going to see how much work is
involved in porting the code to MySQL, since I don't use Postgres.
[0] I imagine the chances are good that it's already modular, but I
haven't really had a chance to look at Bind 9 yet. I have to get it
installed on a development box and do a little testing before I am
comfortable enough to do anything with it.
work with other databases. Personally, I'm going to see how much work is
involved in porting the code to MySQL, since I don't use Postgres.
Both are good, MySQL is single threaded and perfect for most web
applications. Postgres is multi threaded and significantly faster,
especially if you use a persistent connection.
BerkleyDB is also pretty incredible, but sometimes cryptic to work with.
You may want to discover Sybase 11.0.3, which is free for Linux even
in commercial production applications. Incredible lookup speed
on large databases..
For a DNS server: Ram is cheap.
Last thing I learned about doing database driven DNS:
Keep multiple versions of code and data handy. You may induce
a glitch that instead of fubaring a single domain/record,
blows the whole server in nanoseconds. My tertiary server
is several iterations behind my primary and secondary for this reason.
> work with other databases. Personally, I'm going to see how much work is
> involved in porting the code to MySQL, since I don't use Postgres.Both are good, MySQL is single threaded and perfect for most web
applications.
wrong, mysql is multi-threaded.
Postgres is multi threaded and significantly faster,
especially if you use a persistent connection.
BerkleyDB is also pretty incredible, but sometimes cryptic to work with.
You may want to discover Sybase 11.0.3, which is free for Linux even
in commercial production applications. Incredible lookup speed
on large databases..For a DNS server: Ram is cheap.
ram is cheap anyway 
I suspect that mike got confused between threads and transactions.
MySQL should for all intents and purposes be considered comparable to
CDB when it comes to data and updates, while postgresql is more suited
to applications where data integrity is required over a complex, multi
table transaction.
OTOH While not have tried it, I am getting slowly attracted to djbdns from
reading the online docs. Going from SQL -> CDB looks like a nice way
to go, but it is not quite real time - but close enough for me.