>> which, while still parsable, also seems like a rather gratuitous
>> change.
>
>It's a log entry, and essentially a debugging one, for goodness sake!

no, not just a debugging one.  there are other uses for it as well.

>The more humanly readable, and the more complete, the better IMVNSHO.

right, in your opinion.  i happen not to share that opinion, and i'd
much rather trawl the data with a small script, picking out the
"interesting" bits.

for example, on my authoritative name server (which doesn't recurse at
all), queries fall into two types: those i can answer, and those i
can't.  those i can answer are obviously for zones for for which i am
authoritative.

the queries i can't answer fall into two types: recursive queries, and
non-recursive queries.  these are the interesting ones.  the recursive
ones are mostly people who just need a boot in the head to make them
see straight, or they get ignored if i have no idea who it is.  this
can also show evidence of an attack.

the non-recursive queries to a non-recursive server are more
interesting.  sometimes this is a result of someone pointing zone or
domain at my server without telling me.  this usually warrants the
boot, but then i typically tweak my name server (depending on who it
is) and start serving the zone.  in the other case of a non-recursive
query to a non-recursive server that can't answer from the data it
has, is also probably evidence of an attack.

given the query volume, i'd rather not do this by hand or visually.

>> that's still a cycle of "try to start", "try to fix", "try to start",
>> that most people would not like to deal with.
>
>I can supply fixed templates for the config files, etc., if anyone wants
>to use them!  ;-)
>
>(FYI I include full templates for all the RFC 1918 reverse zones too)

like that's hard...  8-P

>> >Worse though is that some of those features are crucial for some uses.
>> >For example the "host-statistics" option allows the operator of a
>> >recursive caching nameserver to determine where any records in the cache
>> >were learned from (and when).
>> 
>> yeah.  like that.  is that gone, too?  i didn't have to remove that
>> one to get bind9 to start, but i'd be dismayed to learn that it didn't
>> do anything any more.
>
>"rndc dumpb" and be dismayed.

bleah.

>.... and if you read the logs on startup you'll see something like:
>
>Nov 16 20:35:39 myhost named[7274]: /etc/named.conf:23: option 'host-statistics' is not implemented

i see no such error message, but i also see that the data is missing.
i wonder where the error went...

>> >I consider the full "check-names" feature set quite critical for
>> >production use too.
>> 
>> i've never used that.
>
>never say never.  (you can't turn it off now for zone files, FYI, but I
>can't turn it on for responses and slave files -- we both lose :-)

right, so i have to make my zonefiles conformant (as i always have)
but i also get to forward the garbage that you send me, regardless of
how bad it looks (well...to a degree).  that sounds like the old tenet
of "be liberal in what you accept, but conservative in what you send".

>> templates that require people to fill in keys.  which most people
>> would rather not deal with.  considering, though, that the named
>> script in rc.d would have to be rewritten somewhat anyway, i suppose
>> an "automated build" of rndc.conf could be stuffed in at that point.
>
>Yes, templates can, almost by definition, be automatically filled out.
>I've just been too lazy to script it myself.

actually, since we have a /dev/random, the use of rndc-confgen isn't
all that bad.

>(hmmmm.... I wonder if the key has to be generated in the recommended
>way, or will any approximately format-conforming string of random
>characters serve as a shared key?)

i think it has to have *some* sort of internal order to the bits.

>> whereas i haven't really looked at the bind9 code (except insofar as i
>> noticed it was totally different; a fact that i fully expected), but i
>> haven't had much trouble being the bind8 source to my will.
>
>you must be a lot more lenient on the code you work with than I am.  :-)

no, i've just worked with a lot of different code bases.  i can tell
bad code when i see it, and the bind code doesn't strike me as all
that bad.

>> >I'm most interested in what might be done to update the resolver library
>> >code....  (especially since bugs in that code that were discovered and
>> >documented and fixed by some folks about five years ago weren't fixed in
>> >NetBSD until just the other day (yes I know I should have been keeping
>> >my eyes open for such things too))
>> 
>> off the top of my head, i suppose symbol renaming would be the easiest
>> way to go, so that the updated bind4 api/abi could be kept in place
>> for backwards compat reasons, but so that newer applications would get
>> the bind9 routines.  but that's just me.
>
>I don't think it's that simple, though others have looked at this a lot
>more closely than I have....

we'll see.

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