On 8/4/2010 6:36 AM, Nuno Nunes wrote:
Hello all,
I've gone through the last few months of the ML, up until the
announcement of the release of 3.2.1, and didn't find any reference to
this bug I'm apparently seeing, so I'm reporting this to you all for
help.
I work at an ISP where we have a number of servers running PowerDNS
Resolver 3.2.1 as our customer-facing resolvers.
We have had this setup for a few months now and sometimes a weird thing
happens (and no, I can't reproduce it in any deterministic way and it
only happens sometimes): when the TTL for a record of a given zone
expires and a new request comes in for it, some of the caches on the
farm go out and get the new information, but some others just seem to
ignore the TTL and stick with the old data forever.
This is most notable when a zone changes name servers and the owner of
the zone comes complaining to us that we still have the old data, even
after the appropriate amount of time has elapsed for it to have been
refreshed (and on these cases we typically observe this behaviour on NS
records, but we have observed it on A records also, for example).
I see this all the time on BIND resolvers. The keys to the situation are:
* Domain's old NS records have a relatively long TTL (from old auth.
servers)
* Domain owner changes auth. servers with registrar
* Domain owner does NOT update data on old auth. servers. (they're now
serving stale data, but authoritatively)
Since the domain owner is your ISP customer, you get get queries for the
domain relatively often, so your recursive servers rely on the cached NS
records for the domain (the ones that point to the auth. server serving
stale data). I think that BIND resets the TTL when the recursive
server sees NS records in the authority section of a response. Maybe
PowerDNS is doing this as well?
I generally advise the domian owner to have the domain removed from the
old auth. server.
--
Dave
_______________________________________________
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users
