Given (for example) PostGreSQL, is there any reason why someone hasn't ported the algorithms of BIND on top of something like it? It seems to me that it ought to be possible to keep a nameserver running whilst one is doing maintenance on it...
the line of people who have asked for this would stretch out the door and into the street. bind runs from memory rather than from disk, because it has to be able to answer at wire speed for large values of "wire". we're working on a hierarchical storage system, basically a memory cache with LRU, backed by a database. we're also working on a way to load from sql databases into memory rather than always having to load from disk. it's likely that the second of those two projects will be complete a year or so before the first :-). in 8.1.2++, though, the goal is to be able to check and/or reload a zone without having to stat() all the others. for someone with 50K zones on board, this should be a huge speedup. -- Paul Vixie <paul@vix.com>
Paul Vixie wrote:
Given (for example) PostGreSQL, is there any reason why someone hasn't ported the algorithms of BIND on top of something like it? It seems to me that it ought to be possible to keep a nameserver running whilst one is doing maintenance on it...
the line of people who have asked for this would stretch out the door and into the street. bind runs from memory rather than from disk, because it has to be able to answer at wire speed for large values of "wire". we're working on a hierarchical storage system, basically a memory cache with LRU, backed by a database. we're also working on a way to load from sql databases into memory rather than always having to load from disk. it's likely that the second of those two projects will be complete a year or so before the first :-).
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. SQL (or any other kind of relational database for that matter) is clearly an overkill. --vadim
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.
How about simply using libdb.a from SleepyCat Software? It does all
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
How much space are we talking about? Disk is very cheap.
Paul A Vixie writes:
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.
Yet having the advantage that when your SQL- or other-based database fails, your nameservers don't.
On Sun, Nov 22, 1998 at 11:53:33PM -0800, Paul A Vixie wrote:
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."
_Classic_. Jon Bentley will, no doubt, put that in Programming Pearls III, if someone sends it to him. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Buy copies of The New Hackers Dictionary. The Suncoast Freenet Give them to all your friends. Tampa Bay, Florida http://www.ccil.org/jargon/ +1 813 790 7592
On Sun, Nov 22, 1998 at 10:38:52PM -0800, Paul Vixie wrote:
in 8.1.2++, though, the goal is to be able to check and/or reload a zone without having to stat() all the others. for someone with 50K zones on board, this should be a huge speedup. -- Paul Vixie <paul@vix.com>
Have you looked at SQL_Bind? I don't know how well that package scales, but it does work pretty well... http://www.seawood.org/msql_bind/ -- Steve Sobol [sjsobol@nacs.net] Part-time Support Droid [support@nacs.net] NACS Spaminator [abuse@nacs.net] Spotted on a bumper sticker: "Possum. The other white meat."
I might also add that MHSC was using PostgreSQL for a while, until we started doing some performance/capacity testing. We are looking at Oracle now. The performance might be there, but the documentation as to how to tune-in that performance, isn't. Generally, most networking RDBMS's have trouble performing at the levels required by BIND. At 10:38 PM 11/22/98 -0800, Paul Vixie wrote:
Given (for example) PostGreSQL, is there any reason why someone hasn't ported the algorithms of BIND on top of something like it? It seems to me that it ought to be possible to keep a nameserver running whilst one is doing maintenance on it...
the line of people who have asked for this would stretch out the door and into the street. bind runs from memory rather than from disk, because it has to be able to answer at wire speed for large values of "wire". we're working on a hierarchical storage system, basically a memory cache with LRU, backed by a database. we're also working on a way to load from sql databases into memory rather than always having to load from disk. it's likely that the second of those two projects will be complete a year or so before the first :-).
in 8.1.2++, though, the goal is to be able to check and/or reload a zone without having to stat() all the others. for someone with 50K zones on board, this should be a huge speedup. -- Paul Vixie <paul@vix.com>
___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: <mailto:rmeyer@mhsc.com>rmeyer@mhsc.com Internet phone: hawk.mhsc.com Personal web pages: <http://www.mhsc.com/~rmeyer>www.mhsc.com/~rmeyer Company web-site: <http://www.mhsc.com/>www.mhsc.com/ ___________________________________________ Who is John Galt? "Atlas Shrugged" - Ayn Rand
On Sun, Nov 22, 1998 at 10:38:52PM -0800, Paul Vixie wrote:
Given (for example) PostGreSQL, is there any reason why someone hasn't ported the algorithms of BIND on top of something like it? It seems to me that it ought to be possible to keep a nameserver running whilst one is doing maintenance on it...
the line of people who have asked for this would stretch out the door and into the street. bind runs from memory rather than from disk, because it has to be able to answer at wire speed for large values of "wire".
Ok; I'm there... but it seems to me that disk caching, possibly application tuned, and 3/4 of a shitload of ram should solve that problem. If you really need to serve that much DNS, you can _afford_ a 4GB Ram Alphaserver, no?
we're working on a hierarchical storage system, basically a memory cache with LRU, backed by a database. we're also working on a way to load from sql databases into memory rather than always having to load from disk. it's likely that the second of those two projects will be complete a year or so before the first :-).
Ah, got it.
in 8.1.2++, though, the goal is to be able to check and/or reload a zone without having to stat() all the others. for someone with 50K zones on board, this should be a huge speedup.
Quite so. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Buy copies of The New Hackers Dictionary. The Suncoast Freenet Give them to all your friends. Tampa Bay, Florida http://www.ccil.org/jargon/ +1 813 790 7592
Ok; I'm there... but it seems to me that disk caching, possibly application tuned, and 3/4 of a shitload of ram should solve that problem. If you really need to serve that much DNS, you can _afford_ a 4GB Ram Alphaserver, no?
Jerry Scharf once walked me through the math on .com with DNSSEC. 4 GB ... heh, heh, heh. :-) Stephen
Stephen Stuart wrote:
Ok; I'm there... but it seems to me that disk caching, possibly application tuned, and 3/4 of a shitload of ram should solve that problem. If you really need to serve that much DNS, you can _afford_ a 4GB Ram Alphaserver, no?
Jerry Scharf once walked me through the math on .com with DNSSEC.
4 GB ... heh, heh, heh. :-)
Or you can do a 50-line hack in a unix kernel and do it with a dozen cheapo PCs. Details are left as an excercise to the reader. Hint: hashing is a well-known but often overlooked trick. --vadim
participants (9)
-
Jay R. Ashworth -
jmalcolm＠uraeus.com -
jzeeff＠verio.net -
Paul A Vixie -
Paul Vixie
-
Roeland M.J. Meyer -
Stephen Stuart -
Steven J. Sobol -
Vadim Antonov