BIND 9 dynamic update speed

Brad Knowles 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) 
protocol.



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

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

	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 mailing list