[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bind9-users
Subject:    RE: BIND 9 dynamic update speed
From:       andreas.pappas () bt ! com
Date:       2003-01-27 18:39:24
[Download RAW message or body]



Thank you all very much for your replies. I have looked at your links and
found the info very very useful. As I understand, there is some effort in
optimising the performance of DNS wrt. update speed but I couldn't find what
the state of the art is. However, I must admit that Bind-dlz is a great idea
but may need to comply with standardised security mechanisms in order to be
viable (does it support TSIG ?). 

The idea behind these enquries is that moving towards a more dynamic
(future)environment governed by mobility, context-awareness and rapidly
changing information, DNS could play a significant role apart from (almost
just) name resolution. But in order to do this it should be able to cope
with the rate of change of such information.

I am currently looking into these issues from an architectural/networking
perspective and would be glad to know that other people as well have a
similar view on the future of DNS.

I know, Brad, that my tests were run in ideal scenarios but I'm sure these
can be recreated in the real world, maybe not on a global scale but on
well-behaved networks (i.e. complying to standards).

Andreas


> -----Original Message-----
> From: Brad Knowles [mailto:brad.knowles@skynet.be]
> Sent: Sunday, January 26, 2003 02:28
> To: Rob Butler
> Cc: Pappas,A,Andreas,DVA2M C; bind9-users@isc.org; 
> bind9-workers@isc.org
> Subject: Re: BIND 9 dynamic update speed
> 
> 
> 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@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(+++)
> 

[prev in list] [next in list] [prev in thread] [next in thread]