Hi Bert, > Darren - do you have a sample domain that exhibits this problem right > now? > > This will help me investigate. > > Thanks!
OK. Well, you can easily see this behavior on pretty much any domain, although the behavior doesn't cause an issue except in some unusual cases. The situation I described is simply the one that results in many calls to our call center. To illustrate, on my own domain: $ dig a sol.truespace.ca @localhost ... sol.truespace.ca. 60 IN A 64.59.129.20 ... $ dig ns truespace.ca @localhost ... ;; ANSWER SECTION: truespace.ca. 93595 IN NS ns1.truespace.ca. truespace.ca. 93595 IN NS ns2.truespace.ca. ... Auth TTL is 93600. If we continue querying in the next 60 seconds, we see the TTL of all of these decrease, as expected. But when the A record expires, and we query it again, $ dig a sol.truespace.ca @localhost ... sol.truespace.ca. 60 IN A 64.59.129.20 ... $ dig ns truespace.ca @localhost ... ;; ANSWER SECTION: truespace.ca. 93598 IN NS ns1.truespace.ca. truespace.ca. 93598 IN NS ns2.truespace.ca. Note how the cache's NS TTL was "reset" due to the query of the A record. If you try this on 3.1.4, the NS records don't get recached. They would properly expire in 93600 seconds, and would eventually result in the cache contacting the SLD/registrar servers to re-get the NS records for the domain. ============================ Darren Gamble Systems Architect, Regional Services Shaw Cablesystems GP 630 - 3rd Avenue SW Calgary, Alberta, Canada T2P 4L4 (403) 781-4948 _______________________________________________ Pdns-users mailing list [email protected] http://mailman.powerdns.com/mailman/listinfo/pdns-users
