[Pdns-users] Some PowerDNS Recursor oddities

[bert hubert]

On Mon, May 15, 2006 at 03:51:25PM -0600, Darren Gamble wrote:

> We've been testing out the PowerDNS Recursor daemon (3.1pre2, installed
> via the i386 Linux rpm), and just wanted to report on a couple of minor
> problems.  We're otherwise quite happy with how well the software held up
> in the lab.

Good to hear!

> We noted that, in some situations, the daemon doesn't update its TTL
> values for a record.  For example, for the zone "truespace.ca" that we
> made some changes to for this testing, you'll note the CIRA (.ca) servers
> have 2D TTL values for the ns1 and ns2 NS records, but the TTL on the
> authoritative servers themselves is 1H.  The first query for these records
> returns the 1H TTL, but, subsequent queries show that the 2D TTL values
> are the ones cached.  We added a third NS record (ns3) to help illustrate
> this.

Interesting coincidence. The IETF DNS mailinglist DNSOP has been discussing
this exact issue for the past few weeks:
http://www.mail-archive.com/dnsop@lists.uoregon.edu/msg01185.html

If I understand correctly, it is unclear what the 'best' behaviour is, and
the IETF people are pondering writing a document about it.

It is not considered an interesting problem as it does not cause problems
either way. 

> We am not sure if this behavior is still considered compliant, but, it
> would certainly generate complaints from hosters who lowered their TTLs
> for a migration, among other situations.  PowerDNS is the only DNS caching

Well, depending on this behaviour is not supported by the RFCs. The reason
PowerDNS does not lower its TTL is because believing the newer lower TTLs
causes worse resolving behaviour in the common case, where nobody is
migrating.

I'm pretty sure that the strategy you describe to migrate to new servers by
using NS records with low TTL does not in fact work very well - DNS records
are cached for far longer than that in practice.

You also do not control the exact value in the cache of recursors, as they
are free to believe the data sent by the registry. No further query might
even be made to the authoritative servers.

> caching an NS record).  Comments?  Working as designed, or is this an
> issue?

It hasn't come up yet. We do note that ISPs notice that PowerDNS noticeably
improves responsivity for their customers. One of our customers is tested
regularly by a benchmarking company that works for consumer magazines, they
noted they rose many places in the 'dns quality' measurement. 

DNS is all about making choices, sadly, there is no single 'right' way. My
gut feeling is that believing the often ridiculously low and inconsistent NS
records in domain zones over those in the registry would hurt more than
help. And it would not even really help the people that try to benefit from
it during migration.

Let me know if it is important to you. PowerDNS does pick up additional
nameservers from lower zones btw.

> Also, we noted that when the daemon is started with "fork", the init
> script is unable to stop the daemon.  This appears to be because the
> daemon always calls rec_control using the default socket, but, the sockets
> are actually named pdns_recursor.controlsocket.<pid> for the two processes
> when forked.  We am not sure if this is best resolved by changing the init
> script or changing rec_control.

This is known and we're still pondering the best solution. The 'non plus
ultra' solution would be to have a proxy running in the parent pdns recursor
but this is not entirely trivial.

> Please let us know!  And, good job with the product!

Glad you like it! I hope it fits your needs.

Kind regards,

bert hubert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services