Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!cis.ohio-state.edu!karl_kleinpaste From: karl_kleinpaste@cis.ohio-state.edu Newsgroups: comp.protocols.tcp-ip.domains Subject: Re: DNS glue records and BIND 4.8 Message-ID: Date: 1 Oct 90 13:40:38 GMT References: <5652@munnari.oz.au> Sender: news@tut.cis.ohio-state.edu Organization: Ohio State Computer Science Lines: 32 kre@cs.mu.oz.au writes: I believe that the only way to kill this is to shut down every nameserver from which you might conceivably ever have your address returned to you, purge their caches, and backup zone files that contain the bad address, and then restart them all (affectively simultaneously). It may not be necessary to be quite that drastic. One person here (in the osc.edu domain) had a problem with a nameserver host having "CNAME and other data" problems percolating around. The person responsible for osc.edu did the following things: [1] Change all "secondary" lines in in named.boot to primaries, that is, lie about your status for all your secondaries. [2] Edit all zone files (including those secondaries for about which you will now be lying) to remove the bogus RRs. [3] Run in this configuration for a while. "A while" was something like a week, long enough to make sure that the min TTL of any data that anyone else has is guaranteed to be gone. During this time, named will not accept the bogus A RRs from elsewhere for some reason. [4] Update all locally-maintained primary zone files for a more recent serial number, even if no data in the zone file has changed. Change the primaries back to secondaries. Restart named. This apparently worked to get rid of the "CNAME and other data" problems for oscsuna.osc.edu. I tried it once to get fid of a bogon 128.146.6.150 A RR for giza.cis.ohio-state.edu that has been percolating around the Internet for 2 years, but seem to have botched the job -- I think I forgot to update one zone's serial number and as a result, it has come back to haunt me again. I'll have to try it again soon. --karl