How about simply using libdb.a from SleepyCat Software? It does all cacheing and can be used with threads. And it also makes dynamic updates a breeze.
I've been talking to Keith about this since before DB was first released. There are some reasons owing to key semantics why we can't just use DB: unless we stored the fully qualified domain name in the key of every RR, there's no "find parent" operation. This is because there's no small integer "object ID" to use when one DB object has to reference another. You just have to instantiate its key, and the choice is therefore a fully qualified key (deadly for space reasons) or an application-generated object ID (deadly for performance reasons). Bob Halley once expressed our #1 rule about DNS implementation designs as "if you have an idea you think will work, multiply everything you know by six million and think about it again." We know that we need zones larger than virtual memory. We would have used DB if we could have. We will continue talking to Keith and Margo about it; they're as interested in this as we are.
SQL (or any other kind of relational database for that matter) is clearly an overkill.
If your DNS is not part of an infrastructure data management system, then that is a true statement. However, many larger sites integrate their DNS with their existing database systems so that there can be a single source of authentic data for the Entreprise. At this moment, they have to do this by exporting their zones into text files that BIND can read. Suboptimal.