[Pkg-pdns-maintainers] Bug#682851: pdns-recursor 3.2 responses have wrong TTL

Thu Jul 26 09:49:22 UTC 2012

Package: pdns-recursor
Version: 3.2-4

There seems to be a bug in the packetcache of pdns-recursor 3.2 where the TTL stays the same.

Here is an example. The TTL is the same with each request:

; <<>> DiG 9.7.3 <<>> @127.0.0.1 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48277
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         86400   IN      CNAME   www.l.google.com.
www.l.google.com.       300     IN      A       173.194.67.147
www.l.google.com.       300     IN      A       173.194.67.104
www.l.google.com.       300     IN      A       173.194.67.105
www.l.google.com.       300     IN      A       173.194.67.103
www.l.google.com.       300     IN      A       173.194.67.106
www.l.google.com.       300     IN      A       173.194.67.99

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 26 11:20:04 2012
;; MSG SIZE  rcvd: 148

; <<>> DiG 9.7.3 <<>> @127.0.0.1 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8655
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         86400   IN      CNAME   www.l.google.com.
www.l.google.com.       300     IN      A       173.194.67.147
www.l.google.com.       300     IN      A       173.194.67.104
www.l.google.com.       300     IN      A       173.194.67.105
www.l.google.com.       300     IN      A       173.194.67.103
www.l.google.com.       300     IN      A       173.194.67.106
www.l.google.com.       300     IN      A       173.194.67.99

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 26 11:20:05 2012
;; MSG SIZE  rcvd: 148

; <<>> DiG 9.7.3 <<>> @127.0.0.1 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57214
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         86400   IN      CNAME   www.l.google.com.
www.l.google.com.       300     IN      A       173.194.67.147
www.l.google.com.       300     IN      A       173.194.67.104
www.l.google.com.       300     IN      A       173.194.67.105
www.l.google.com.       300     IN      A       173.194.67.103
www.l.google.com.       300     IN      A       173.194.67.106
www.l.google.com.       300     IN      A       173.194.67.99

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 26 11:20:06 2012
;; MSG SIZE  rcvd: 148

If you add disable-packetcache=true to /etc/powerdns/recursor.conf then you can see the normal behaviour.

Not lowering the TTL will for example mean users visiting websites at IP-addresses where they used to be but aren't anymore.

The TTL sent by PowerDNS recursor can cause the TTL to be off by a maximum of up to almost 2 times the original TTL.

Some websites have a TTL of 1 week, so after a DNS-change was made the system administrator would normally wait one week before
doing the final change. A week later the user could still be visiting the wrong IP-address/site.

Not all DNS-clients have a cache, but for example every Windows version by default since at least Windows 2000 does have that.

Even more likely mailserver software also looks at the TTL when caching, they could end up sending mail to the wrong IP-address
too.

The normal TTL-behaviour is pretty basic DNS requirement. So this seems to me like an important bug.

I've tested this on a fresh install of Debian stable in the flavors of i386 and amd64.

I've also checked, the previous version (3.1.7.2) of PowerDNS recursor does not have this problem. The newer version (3.3) does
not have this problem.

The versions were downloaded from:
http://downloads.powerdns.com/releases/

I also checked that it wasn't caused by a Debian patch.

I believe this change might be the fix:

"The packet cache, which has 'ready to use' packets containing answers, now artificially ages the ready to use packets. Code in commit 1630."

http://doc.powerdns.com/changelog.html#changelog-recursor-3-3

This is the patch of the commit:

http://wiki.powerdns.com/trac/changeset/1630

It however did not apply cleanly to the code base, probably because it depends on other changes.

I haven't had the time to look at it further to see if that is the fix.

This is the whole patch between 3.2 and 3.3 (the patch between 3.1 and 3.2 is a lot bigger):

http://wiki.powerdns.com/trac/changeset?old_path=%2F&old=1540&new_path=%2F&new=1722+

I might have time later today or this week.

Hope this is helpful.