bind 8.2.1

[Skip Montanaro]

    Jim> Well the $TTL directive is explained in doc/rfc/rfc2308 and
    Jim> doc/html/master.html, so you can't have spent much/any time reading
    Jim> the documentation. 

As I mentioned, I checked the CHANGES and README files.  Having installed
lots of source packages, they are, in my experience, the most reasonable
places for a person upgrading the package to look for gotchas when
upgrading.  The docs are delivered separately.  I suspect I'm not the only
person who only downloaded the source.  (In fact, I didn't download the
source originally.  I inherited a running bind 8.2.1 system and discovered
the TTL error messages in its log files.)  I suspect there are many people
out there who get bind from vendors, whether it's from Sun, HP or off a
Linux CD.  Not everyone is going to have all the src, doc and change bits
available.

    Jim> And the CHANGES file does say "RFC 2308 support added". Presumably
    Jim> that's not enough to prompt people to go and read that RFC even
    Jim> though it's included in the doc tarball. There's also a reference
    Jim> to $TTL in the 8.2.1 src/README. Maybe you overlooked that or
    Jim> didn't think it was worth further investigation too?

I looked specifically for "TTL" in both the src/README and src/CHANGES
file.  In src/README it says:

    $TTL now accepts symbolic time values (such as "$TTL 1h30m").

In src/CHANGES it says:

    641. [feature]	$TTL now takes TTLs of the form 1w6d7h32m20s.
    619. [protocol]	don't refresh TTL's from delegation information.
    604. [bug]		fix a bug in the handling of $TTL's absence.
    523. [feature]	mark lame servers as such and don't use them for NTTL.
    511. [bug]		$TTL warning test was wrong.
    485. [bug]		do not complain about default TTLs unless a master.
    214. [bug]		the clarification TTL changes (see change 145 below)
			set the SOA minimum field to zero if the MSB was set.
			The server now leaves the SOA RR alone, but sets
			z_minimum to zero if the MSB is set.
    146. [func]		if an RR set in a reply differed from an RR set in
			the cache only in the TTL, we would not update the
			TTL of the RR set in the cache.  We now update this
			TTL to that of the reply RR set if the reply RR set's
			TTL is greater.
    145. [func]		follow the direction of the clarification draft and
			treat TTLs as unsigned 32-bit integers, with a
			maximum value of 2^31 - 1.  TTLs greater than the
			maximum will be converted to 0.  A warning will
			be issued if this conversion occurs while loading
			a master zone or during inbound zone transfer.

In my mind, none of those comments seem to suggest a TTL line is now
required, except possibly 485, and that only because I know what I'm looking
for after the fact.  None of them say anything clear like, "Without a $TTL
record before the SOA record of the zone file, bind will log a 'No default
TTL' message."

In the README file, five RFCs are mentioned: 2308, 2181, 2065, 2136 and
1996.  None of the comments associated with them mention anything about
$TTL.  I'm sure there are many other RFCs that pertain to bind.  I don't
think it's reasonable to expect every network administrator to be intimately
familiar with all these RFCs.  RFCs aren't necessarily written for people to
use as documentation anyway.  They are written with language that is meant
to be as precise as possible to allow implementors to create interoperable
software.

    Jim> Oh, and if you think the documentation is deficient in some way,
    Jim> I'm sure the ISC would welcome any release notes or stuff like that
    Jim> if you cared to write them.

I posted a note to bind-users at isc.org.  I trust someone there reads this
mailing list.  I will be happy to post a short note to the bind-bugs at isc.org
mailing list as well, if that's what's required.  Of the locations listed in
the "Kits, Questions, Comments, and Bug Reports" section of the src/README
file, that seems to be the most appropriate place to post such a suggestion
(if bind-users isn't the right place).  Let me know if there's someplace
better.

Why are people getting so hot under the collar about this?  I feel somehow
like you people are shooting the messenger here.  I made what I thought was
a reasonable comment: If lots of people have problems with the same thing,
perhaps that specific problem could be addressed in the documentation.  If
nothing else, that might reduce the frequency of these requests posted to
the list.

Skip Montanaro | http://www.mojam.com/
skip at mojam.com | http://www.musi-cal.com/
847-971-7098   | Python: Programming the way Guido indented...