[Pdns-users] Possible bug observed in PowerDNS Recursor 3.2.1

[Dave Sparro]

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