CNAME Records from Hell Just Wouldn't Go away.

[Mark_Andrews at isc.org]

> 	One of our clients had a web site off campus that went bad,
> orphaning two CNAME records of ours.
> 
> "piece of cake," I said to myself as I used nsupdate to re-write the
> aliases and point them somewhere else.
> 
> 	Not so fast.  I got a servfail on each one, apparently because
> nsupdate tried to follow the redirection and came to the dead end that
> hundreds of customers were also finding.

	You just needed to supply the zone to nsupdate.  Nsupdate only
	attempt to lookup SOA of the name in the update request if
	you fail to supply the zone.  Note: BIND 8's nsupdate does *not*
	support specifying the zone, you need to use nsupdate from BIND 9.

> 	I began using successively larger and larger hammers to fix
> it.  Finally, I had to kill the master dns, physically delete the
> CNAMES from the zone file and restart it.
> 
> 	That did work and I was able to use nsupdate to add the
> desired CNAMEs.
> 
> 	Now for our slave.  It was taking the new updates from the
> master, but the old CNAME records kept coming back until I finally took
> the big hammer to it and killed it, wiped out the whole zone file and
> restarted it.  That worked fine, but wasn't there a better way to do
> this?
 
	I suspect that you failed to remove the journal on the master
	and as the slave was using IXFR it failed to see the change.

> 	The manner of the failure was simply that the remote A records
> for the sites in question went poof! and appear to have been deleted
> from the remote dns.  I really hated doing these big things in the
> middle of a busy day so I would like to know a more elegant way since
> nsupdate got confused.  Thanks for any good suggestions.
> 
> 
> 
> Martin McCormick WB5AGZ  Stillwater, OK 
> OSU Information Technology Division Network Operations Group
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org