Propagation of DNS Changes

[Mathias Körber]

> I recently discovered an error in the DNS on my server (which is the
> master for my ip domain) that involved the A record for my ftp.
>=20
> I corrected this, and restarted named (8.2.2-p5), only to remember I
> had forgotten to update the date+serial number.

You mean the serial#. There is no date per se in the DNS SOA record.
True, one of the most common comventions is to use the date and a =
2-digit
counter as the serial# (YYYMMSScc).

>=20
> So I went back in, changed the date+serial #, and restarted named.
That should ok, as long as your new serial# (is the whole integer)
is greater than your old one (the one your secondary nameserver should
have).

>=20
> This last step happened several days ago. However, when I do an
> nslookup on my backup ISP account (earthlink.net), ftp resolves to my
> primary ip address, rather than the hosting service I use. If I do the
> nslookup but require the use of my own server, I get the correct
> answer (i.e., ftp maps to the ftp hosting service).

So could you post here
	a) your domainname !
	b) the nameservers involved
	c) the result of an SOA query for your domain to BOTH nameservers

>=20
> Have I screwed something up here by "iterating" the DNS changes and
> neglecting to update the date+serial # info until the very end? If so,
> how do I fix it?

Likely NOT, but there could be problems if yyou have inadventently made =
the
serial# very large (larger than fits into a long integer!).

There are few other causes that could prohibit the secondary from =
transferring the
zone successfully

a) The serial# on your primary is smaller or equal to the one the =
secondary still has
b) You have a typo (syntax error etc) in your primary's zonefile for =
your domain. The
   primary will load the zone (except the problematic entry) but NOT =
become authoritative
   for the zone and as such refuse to transfer it out.
   You should
	check whether your primary NS answers authorittively to an SOA query =
for your domain
		$ dig mydomain.soa @myprimary
	=09
	 check whether the reply includes an 'aa' flag. If not, your primary is
	 not authoritative for the zone. Check the logfiles (syslog, usually =
/var/log/messages
	 or similar, unless you have redirected logging to somewhere else)
	 and see whether BIND logs any problem on restart/reload.

c) You have a firewall which prohibits the secondary from
	a) performing a serial# query (if UDP port 53 is blocked)
	b) performing the zonetransfer itself (if TCP port 53 is blocked)
   BOTH these ports should be open

d) you have denied zonetransfers from your secondary nameserver in your =
named.conf
   file( maybe you have configured=20
=09
	options {
		[...]
		allow-transfer { none; };=20
		[...]
		};

or

	zone "yourdomain" {
		[...]
		allow-transfer { none; };
		[...];
		};

You should add the IP address of your secondary nameserver in the =
allow-transfer
clause to permit it to obtain a copy of your zone.

I hope this helps. WIth more information posted, people here can help
much better than this !

Mathias

>=20
> Thanx in advance for any help and/or advice!
>=20
> - Mark
>=20
>=20