[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    Re: Can't Kill old Address
From:       cis.ohio-state.edu!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!nucsrl!eecs.nwu.e
Date:       1992-05-11 15:06:26
[Download RAW message or body]

In article <1992May8.191602.28127@zia.aoc.nrao.edu>, pgreen@zia.aoc.nrao.edu (Philip Green) writes:
|> A few months ago we migrated from a Class C address to a Class B
|> address. The local name server changed only its address, the 
|> old address is no longer used. The problem is both the new
|> and old address are returned when any of our name servers are
|> queried. Can anyone tell me whats happening? 

This sounds a lot like a problem we had recently.  We moved one of our
servers from one subnet to another, and changed its A record accordingly.
But the old A record continued to linger for months.  We made sure that
the A record was changed on the primary (this machine is in fact the
primary for many zones under nwu.edu) AND we made sure that the glue record
on the parent primary server (the one for nwu.edu) was also changed.
That's the first thing to check:  make sure that all your parent servers
have changed their glue records for your server.

But even after all that the old A record stil lingered.  I believe that
the problem was that it would hang around in all the servers' caches.
Whenever someone asked for information pertaining to one of the zones,
all the A records for the server that were in the cache would get sent,
and the receiving server would once again cache the information.  If you
killed and restarted a server it would soon get the old A record from
another server.  For the secondaries I would kill, remove the secondary
information stored on disk (the "bak" files that named writes to save 
the secondary zones), then restart it.  But soon the record would 
reappear, probably coming from some other secondary's, or even the
primary's, cache.  I also suspect that the primary was letting its cache
get "reinfected" with the bogus record with information from the secondaries.

What I finally did to make it go away was to kill ALL the servers---
the primary and all the secondaries---at the same time, remove all 
the secondary information (all the "bak" files) then restart all the
servers.  This made it go away.

I think of this problem as the "sticky glue record".  I know I haven't
explained it very well.  I'm also puzzled as to why such drastic measures
were necessary to make the sticky record go away.  

		William LeFebvre
		Computing Facilities Manager and Analyst
		Department of Electrical Engineering and Computer Science
		Northwestern University
		<phil@eecs.nwu.edu>

[prev in list] [next in list] [prev in thread] [next in thread]