I've got a mess

[Bill Larson]

On Apr 15, 2004, at 6:56 PM, Michael Barber wrote:

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

>> 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.

Looking through "DNS & BIND", the change requiring this $TTL came in 
BIND-8.2.  Before 8-2, the information in the SOA was used.

What version of BIND-8 are you running?

This world writable directory is a security issue that should not 
impact your providing DNS information - unless someone decides to do a 
"delete *.*" while in this directory.

> 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.

Sorry, absolute brain lock on my part.

The TTL value specified in the SOA record is used for ***negative**** 
caching results.  This means that if someone queried for a foo.bar name 
in the bar zone and foo.bar did not exist, then the negative response, 
i.e. there is no foo.bar, would be cached for the period of time 
specified in the SOA record for the bar zone.

>> 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.

Please make sure that you distinguish between your configuration file 
("named.cnf" under the Windows version of BIND?) and the zone files 
which contain the resource records for the zones that you are 
responsible for.  I think that there is some confusion here.

>> 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.

Generally, the defaults values are reasonable.  I'd suggest setting 
these only if there is a specific problem that you need to address.  
Otherwise let named use it's defaults.

I have specified the "transfer-source", but only on a machine that had 
multiple interfaces and I needed to insure that the transfers took 
place using the correct interface.  Setting "transfers-in" can be 
necessary if too many zone transfers are occurring at the same time - 
it throttles the server.

>>> 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.

Is your slave configured to get the zones from the master?  Remember 
that the DNS protocol itself does not distinguish between master and 
slave servers, this is information that you need to explicitly 
configure into your servers.  If you do not tell the slave what the IP 
address is of the master, then it won't have any idea who to send a 
zone transfer request to.

On your slave you should have something like the following in your 
named.cnf file:

	zone "xyz.example" {
		type slave;
		masters { 192.168.1.1; };
		file "db.xyz";
	};

You must specify the IP address for the master server in the 
configuration for the slave.  If you do not, you will never be able to 
contact the master for the zone transfers.  Also, make sure that on the 
slave you haven't defined the zone to be a master.  If you do this, 
then you will have to manually transfer the zone to the slave.

Also, are you sure that your slave CAN get this zone transfer from the 
master?  There may be blocks somewhere that will prevent the slave from 
getting a zone transfer from the master.  On the slave you should 
always be able to run:

	dig @master_ip_addr zone_name axfr

If you can't, then there must be something that is blocking these 
transfers.  It could be configuration, but it could also be the network 
architecture (firewalls).

You may seriously want to consider posting your configuration files 
such that the people that you are asking for help can see the whole 
picture rather than little bits and pieces.  I know that this is a 
"management" issue and some management doesn't consider letting this 
information out to be acceptable.  But, this is also the same 
management that has paying customers complain that what they are paying 
for isn't working.  You can "sanitize" the information, but if you make 
it too clean you may also loose the errors that are causing your 
problems.

Also, since you have identified that comcity.com is one of the zones 
that you are responsible for, I played around a little looking at this 
zone.  Make the that the NS records for this zone are correct.  You 
have "ns.comcity.com" at 207.168.174.130 defined, which seems to be 
functioning.  You also have a "ns2.comcity.com" at 209.10.62.39, which 
although running a DNS server, does not appear to be authoritative for 
your "comcity.com" zone.  This problem on ns2 could be caused by 
either; not being configured at all for this zone, or there is a 
problem loading this zone.

Bill Larson