If you query dnscache for a domain SOA, it will follow any currently
cached NS records, and then turn around and cache the response. Or at
least it appears to be something along those lines. It could just be
erroneously resetting the TTL.
See the example below for what I'm referring to. Even if I were to move
the domain integra.net to a new provider, and the root servers were
appropriately updated, I could keep my dnscache returning the wrong
answers indefinitely as long as two conditions are met:
1. The old DNS servers respond authoritatively
2. I query dnscache prior to TTL expiration on the NS records asking for
the domain SOA.
Demo:
> dnsqr ns integra.net
2 integra.net:
81 bytes, 1+2+0+0 records, response, noerror
query: 2 integra.net
answer: integra.net 7164 NS ns.integraonline.com
answer: integra.net 7164 NS ns2.integraonline.com
> dnsqr soa integra.net
6 integra.net:
96 bytes, 1+1+0+0 records, response, noerror
query: 6 integra.net
answer: integra.net 7200 SOA ns.integraonline.com
hostmaster.integraonline.com 2005050500 3600 1800 604800 86400
> dnsqr ns integra.net
2 integra.net:
81 bytes, 1+2+0+0 records, response, noerror
query: 2 integra.net
answer: integra.net 7199 NS ns.integraonline.com
answer: integra.net 7199 NS ns2.integraonline.com
This is not dramatically bad behavior, but the bigger we get, the more
often a customer of ours experiences it. Do we have to forcibly clear the
cache periodically to keep it from happening? That's a solution I would
consider for BIND ;-).
Regards,
Dave
|