Date: Tue, 17 Jul 2001 12:24:28 +0200 From: Len Conrad <LConrad@Go2France.com> To: freebsd-hackers@freebsd.org Subject: Re: Weird named problem - IN A for nameservers being lost! Message-ID: <5.1.0.14.0.20010717120221.03aa6ec8@mail.Go2France.com> In-Reply-To: <200107170045.f6H0j8N33016@earth.backplane.com> References: <5.1.0.14.0.20010622153827.02fa0da0@mail.Go2France.com> <5.1.0.14.0.20010622153827.02fa0da0@mail.Go2France.com> <5.1.0.14.0.20010623185802.04051eb0@mail.Go2France.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> If you look at the cache dumps and dig output below, you can clearly > see the timeout for fuji.jamcracker.com is less then the timeout > for jamcracker.com AFTER we've looked up other elements for fuji, > which means that when it timed out, that IN A record will be gone. > But that IN A record is the IP address for the NS. So when it times > out, the jamcracker entry is left there with no NS records whatsoever. If a resolver needs the ip for an hostname, it looks it up. If the A has expired earlier than the NS, so what? The resolver queries anew for the A of the NS hostname. Itīs available at the authoritative NS, a much more credible source than a cache which can be poisoned. > I believe what is happening is that something is looking up other > records for fuji, and this is replacing the original glue record with > the real IN A record sounds like a good idea, no? Turn on query logging to try to see that "something" ? >, but also changing the timeouts somehow and > causing fuji's record to timeout early. Thereīs no requirement that NS and A records have the same TTL, is there? Thereīs no requirement for a referral to even include glue, either. > This has occured with several mail destinations, not just > jamcracker. I went through jamcrackers whole DNS hierarchy and > everything is setup > properly, including all the timeouts (they are all set to 3600 seconds). > > Has anyone else seen this? Anyone know what is going on here? All BIND8 machines should be running in "anti-cache-poisoning" mode, ie, with option for recursion off or restricted to trusted ipīs AND "fetch-glue no;". Both are required to defend against cache poisoning. This should equate to the compile option NOADDITIONAL, I think. In BIND9, there is no option for "fetch-glue no". It is the hard-wired default. btw, about 30% of internet nameservers are have poisonable caches. btw, the people at Men&Mice have tried to work with MS about this since NT4 DNS and W2K DNS are both poisonable out of the box, contrary to MSīs intentions for W2K DNS, requiring a registry hack to fix. You might run with "fetch-glue no" and restricted recursion to see if it helps with your unequal timeouts and the apparent re-fetching of "real" glue. Sorry, Iīve come into this thread a little late. Len http://MenAndMice.com/DNS-training http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.1.0.14.0.20010717120221.03aa6ec8>