>> but it's also lacking others that previous
>> releases of bind *do* have.
>
>please name them -- I haven't run across any yet and the release notes
>don't mention any either (except for one apparently cross-platform bug
>that's pretty minor)

from doc/misc/migration:

   1.1. Unimplemented Options and Changed Defaults

   BIND 9.0.0 supports most, but not all but not of the named.conf
   options of BIND 8.  Unimplemented options include those for selective
   (per-domain) forwarding, sortlists, statistics, and process limits;
   for a complete list, see doc/misc/options.  We plan to implement most
   of these in in BIND 9.1.

   If your named.conf file uses an unimplemented option, named will log a
   warning message.  A message is also logged about each option whose
   default has changed unless the option is set explicitly in named.conf.

   In particular, if you see a warning message about the default for the
   "auth-nxdomain" option having changed, you can suppress it by adding
   one of the following lines to the named.conf options { } block:

      auth-nxdomain no;    # conform to RFC1035
      auth-nxdomain yes;   # do what BIND 8 did by default

oh, and the documentation isn't finished yet.

>> grep zxfr?  i dunno.
>
>If you'd seen the proposed patches (which did actually fix the problem),
>and the very different fixes released in 8.2.2-P7, I don't think you'd
>be so happy about any of the 8.2.x code....

i never looked.  then again, i fully expect things that do all the
work that bind does to be complex and not understandable at a glance.
i have a rule of thumb that i know how to operate the tools i use,
even if i don't understand exactly how they do it.

>>  i've been running 8.2.3 betas for a long time now.
>
>and you call the v9 code less stable?  that's hilarious!  even I haven't
>tried running the 8.2.3 betas in production yet!  :-)

isc betas are usually quite stable, and the 8.2.3 code is derived from
the 8.2.2 code which also worked fine for me while i was running it.

>> last time i checked, that wasn't part of the base netbsd distribution,
>> so i don't think any threaded apps will become part of the base
>> distribution first.
>
>true enough, but something has to push the envelope....  as much as I
>dislike threads in user-land code, BINDv9 seems to have made very good
>use of them

i'm not debating the use of threads in userland or kernelland...but we
don't have them, so threaded apps are very likely not gonna get
integrated.

>> let's see...i can't build my name server because it requires a threads
>> package that i can't download and install because i need a name server
>> to get to the ftp site.  catch 22.
>
>That's totally bogus.
>
>First off NetBSD comes with a functional resolver (that you won't be
>replacing anyway) that'll get you past the hurdle, even if you have to
>point it at a cache server half way around the world to do so.
>
>Secondly you can do your package builds on a separate development
>machine (i.e. one that's already functioning autonomously) and test them
>before even installing them on the target system where they'll be used.

the point was that the base system doesn't depend on something not
installed.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."