I've got a mess

Fri Apr 16 00:56:39 UTC 2004

Thanks Bill...

A few more Questions and Comments interspersed....if you get a chance.

> DNS & BIND is now on it's fourth edition, published in 2001.  Your 1992
> edition was the first edition and is really too old for much use
> anymore.

> NEW INFO - the "DNS on Windows NT" book is now out of print.  Browse
> some of the Windows admin books at your local bookstore and I'm sure
> that you will find something reasonable.

I'm going there tommarrow morning....got to get to the baby sitter now.

> The zone files are fully compatible between versions of BIND.
> Actually, this was required by the RFC which defines DNS.  All of the
> resource records, SOA, NS, MX, A, TXT, etc., will move from one DNS
> server to another, regardless of BIND version, or really even software
> developer.  There is one exception to this though.  The current
> versions of BIND use a "$TTL" declaration at the beginning of the zone
> file to specify the actual minimum TTL for the resource records.  The
> old "minimum TTL" specified in the SOA record is now used for
> specifying the cached lifetime for the records.  If this "$TTL" isn't
> specified, you will get a warning when you start up the named process.

My zone files do not have a $TTL at the top and I don't see that causing any
warning.  The only warning I see is: directory G:\\bind is world-writable
and nothing we can do makes this go away even when that path is read-only
for domain admins.

I don't understand the difference between  "cached lifetime for the records"
and "minimum TTL for the recorce records"...they sound the same.  There is
also a TTL value in front of every SOA record, A record, etc.

> The configuration files, although similar, are NOT the same.  You
> should be able to migrate the old configuration fairly quickly, but
> there definitely be some work involved.

I don't have the original zone files only what has already been "partially"
migrated so I need to work with what I have.

> The current version of BIND is BIND-9.2.3, which is also different from
> BIND-8.  As this is really the current version, you might want to
> consider implementing your new systems with this rather than BIND-8.

I don't want to add an another unknown at this point.  An minor upgrade
later on seems like a much easier think to do what I get this working again.

> Finally, although I have been working with DNS and BIND since the
> middle '80s, I've never seen version 2 of BIND.  I started out with
> something like BIND-4.5 or 4.6, which are now really ancient.  I
> suspect that you are thinking of the Microsoft DNS server software.

Not 2...sorry.... ;)
should be 4.9.5

> Can't help you much here.  I'm still running under Unix (actually MacOS
> X) and do my editing with "vi".  If you want to edit the files quickly,
> "vi" will do it very quickly and easily.  But, learning the vi editor
> is NOT easy itself.  So, good luck here.

There are some editors like textpad and a few others...but I'm really
surprised that no-one has not created a wysiwig editor for DNS files by
now..????  I think these other editors will work but the question is how do
you search or update the serial #.  Whats the trick ---even with VI?

> The "named.conf" file will NOT automatically update itself on slaves as
> zones are added to the master.  I think that the previous person had
> some definite confusion with this.
>
> Now, I believe that the Windows DNS server does identify all zones on
> the master to the slaves.  But this isn't a BIND issue anymore, it
> belongs to Microsoft and Windows.

I didn't think so.  I'm running Bind 8 on windows but not Windows
DNS...don't know nothing windows dns at all about that at all.  We started
with BindNT before there was any other DNS on windows.

> These lines specify:
>
> named-xfer The full path of the named-xfer application which is used
> to pull zones from a master server
> transfer-source The source IP address that all zone transfers will
> originate from
> max-transfer-time-in The maximum time that will be allowed for a zone
> transfer
> to complete
> transfer-format The format that zone transfers will use while going
> over the
> network.  "one-answer" is the safest, but least efficient.
> transfers-in The number of simultaneous zone transfers that the
> named process running on the server will allow at one time
>
> Note that all of these identify how zone transfers will be handled by
> the DNS server.  It doesn't say anything about identifying what zones
> are out there that can be transfered.

Yes.  Should these really be specified or will they default to logical
choices without inclusion?  I've seen named-xfer and transfer-source only.
I'm worried that specifying these values may actually be breaking things.

> > 4.  My secondary is taking a long time to update from the master....
> > its
> > the
> > 604800  that is affecting that right?
> >
> > 1800 IN SOA ns.comcity.com. webmaster.comcity.com. (
> >   2004041306 43200 7200 604800 1800 )
>
> Slow updates, assuming that NOTIFY isn't used, is controlled by the
> refresh value specified in the SOA record.  This refresh value is the
> SECOND value in the parentheses not second from last.  Your refresh is
> 43200 seconds, or 12 hours.  Under a worst case, your slaves could take
> up to 24 hours to sync with the master, but something closer to twelve
> hours is what you should expect.  Is this the "long time" that you are
> referring to?

No...I'm looking at updated zone files in the master that have not updated
in over 7 days.  I had to manually copy the zone files over and reload the
secondary (slave) to fix this.  But, it could have been that the master
ns.comcity.com whois record had not been updated and so the secondary had no
authoritative DNS to pull from.  From that earlier Email I think that was
fouling things up badly.  The old ns.comcity.com running bind 4.9.5 was at
209.66.93.2 and the new master is at 207.168.174.130.  Eventhough
ns.comcity.com was correctly pointing to 207.168.174.130 in the zone for
comcity.com...the whois record was still at 209.66.93.2.  When I saw someone
else post about that....it looked awfully suspicious as to what was going on
here and I checked and sure enough it was.

I'm not sure...so many things are messed up its hard to figure out where to
start.

Thanks again
Michael

> Bill Larson
>