> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
