BIND 9 dynamic update speed
brad.knowles at skynet.be
Sun Jan 26 02:27:46 UTC 2003
At 8:32 AM -0500 2003/01/25, Rob Butler wrote:
> Your paper is interesting, and your suggestions for how dynamic update speed
> could be improved are interesting as well. However another approach to
> improving update speed is to not use rfc-2136 dynamic updates at all.
> Instead move all updates outside of Bind. This has been accomplished with
> Bind-dlz. Check out http://sourceforge.net/projects/bind-dlz
There is also PowerDNS and MyDNS. PowerDNS is used as a
front-end to several different SQL databases, and is the sole
nameserver software used to handle the ccTLD ".tk" (as well as other
TLDs that are partially served by PowerDNS). MyDNS is a front-end to
MySQL, and does not appear to be quite as stable as PowerDNS, but is
another alternative to be considered.
Note that PowerDNS used to be commercial software, but had
recently been open-sourced. The company does still do commercial
consulting, support, and has a hosting operation.
See <http://www.powerdns.com/> and <http://mydns.bboy.net/>, respectively.
However, I'm not entirely convinced that this is the solution to
the problem. BIND-dlz has the benefit of using the baseline code of
BIND-9 and take advantage of all the previous work that has been
done, while making relatively minimal changes. The others are
complete re-implementations and do not re-use any of the BIND code.
However, they all take the update traffic out of the DNS, and
into some form of proprietary (or at least, non-DNS and non-standard)
I am left wondering what application you could have that could
need such a high rate of updates?
Ahh, sorry. Just read the paper. Try the test again, this time
assuming that you have clients spread around the world running a
variety of caching nameservers, many of which completely and totally
violate the RFCs by caching information forever (or, at least until
rebooted), or at least according to a mechanism and schedule of their
choosing as opposed to paying any attention whatsoever to the TTL on
The problem is that you can do whatever you want on the
server(s), and it doesn't really matter. You can't control all of
the clients out there, and they're the ones that will screw you up.
If this wasn't the case, we wouldn't have situations where 98% of all
traffic to the root nameservers is bogus.
> A variety of databases are supported, as well as the potential to support a
> variety of update / update propogation methods. Although no performance
> tests have been performed yet, there are some discussions of performance and
> update propogation on the mailing list, so be sure to check out the
> archives. An additional benefit (and the original primary goal of bind-dlz)
> is that zones can be dynamically added and removed from Bind without any
> restart / reload / reconfig. Something which is simply impossible with
I had hoped to be able to do some benchmarking of BIND-dlz for my
upcoming talk at RIPE 44, but that has not happened. Indeed, with
the explosion of various nameserver software that I have recently
discovered, I don't know if I'll ever manage to run my test suite
across all the programs I should be testing. ;-(
Brad Knowles, <brad.knowles at skynet.be>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
More information about the bind-workers