Your message dated Sun, 11 Aug 2013 13:33:35 +0000
with message-id <[email protected]>
and subject line Bug#682851: fixed in pdns-recursor 3.5.2-1
has caused the Debian Bug report #682851,
regarding pdns-recursor 3.2 responses have wrong TTL
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
682851: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682851
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
Source: pdns-recursor
Source-Version: 3.5.2-1
We believe that the bug you reported is fixed in the latest version of
pdns-recursor, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Matthijs Möhlmann <[email protected]> (supplier of updated pdns-recursor
package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.8
Date: Tue, 06 Aug 2013 21:43:01 +0200
Source: pdns-recursor
Binary: pdns-recursor pdns-recursor-dbg
Architecture: source amd64
Version: 3.5.2-1
Distribution: unstable
Urgency: low
Maintainer: Debian PowerDNS Maintainers
<[email protected]>
Changed-By: Matthijs Möhlmann <[email protected]>
Description:
pdns-recursor - PowerDNS recursor
pdns-recursor-dbg - debugging symbols for PowerDNS recursor
Closes: 649724 652833 671592 682851 697355 710048
Changes:
pdns-recursor (3.5.2-1) unstable; urgency=low
.
* New upstream version (Closes: #710048, #682851, #671592, #697355, #649724)
- Refresh patches
* Improve the patch to make pdns-recursor less chatty
* Standards-Version: 3.9.4 (no changes necessary)
* Remove pdns_hw on cleanup (Closes: #652833)
Checksums-Sha1:
a7b484cb068fb6adf986e9cf8af060241e7f6fee 2234 pdns-recursor_3.5.2-1.dsc
5c635e9c4b759d4321d208df22bd29b582775284 176447
pdns-recursor_3.5.2.orig.tar.bz2
c100f2e3bdc5f1c0adeccdc9cd846699059d2ae9 10724
pdns-recursor_3.5.2-1.debian.tar.gz
0a48213f12abcc34633e28f76cc582178144b3b1 465494 pdns-recursor_3.5.2-1_amd64.deb
84d0b3b9e72cab5d905a5553cd7d6483539a552b 5390878
pdns-recursor-dbg_3.5.2-1_amd64.deb
Checksums-Sha256:
7e8d924084505894e3c75acd6b3fb6090c341bcd45d284808c6a7f6b5022952b 2234
pdns-recursor_3.5.2-1.dsc
ffe3158ee5b3f62e927198fd44e839a01d3241a41a4e61afdca6709113c276bd 176447
pdns-recursor_3.5.2.orig.tar.bz2
d8af84597e160421422968f6247e3db5664cf19a2e341e0dbcc707543e80ea68 10724
pdns-recursor_3.5.2-1.debian.tar.gz
a46b856cfbea30755b1479c9d4d86880f5b47faebc3e77e3f2294ea1499f6514 465494
pdns-recursor_3.5.2-1_amd64.deb
288d13c598ab439e56c3b92b297ce8280f78bd9d9b0c8ef9e6d1d5d6cd2c3b6a 5390878
pdns-recursor-dbg_3.5.2-1_amd64.deb
Files:
2dd01cb473621b57057c9e86a63676ba 2234 net extra pdns-recursor_3.5.2-1.dsc
843103dccaa7f604623a5ce4ce9e4800 176447 net extra
pdns-recursor_3.5.2.orig.tar.bz2
e3c2bea15f933550303c2e99b1042907 10724 net extra
pdns-recursor_3.5.2-1.debian.tar.gz
eb377aa4ad8f22e4247bbc0b5b21d57d 465494 net extra
pdns-recursor_3.5.2-1_amd64.deb
6df64f0b1c615d550cba9d0b0ed0f8b7 5390878 debug extra
pdns-recursor-dbg_3.5.2-1_amd64.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAEBAgAGBQJSB5FnAAoJEAXuPkY28LeMjwMP/2YoF47J66chjg2QFmTTsvXi
gLL1oUhcUoDMKb/em54yZCDZP4gcFfpIfZYYcakhNz9V1HKz3hU9opxFVzP+5xMA
zS51ypdxy7agyko+s7Emd/f2przAsowiud21uiK6VG1QQEXVpb/ZifR7agbmK13X
n32PFoEPlS7UxwG+j1R3fpnyKtimgFvAcb4D+FzBtRm+kGBLSthEm330ojgDkc9X
b22oqUM4gH8lUqld7uuN+apsLQedY0bhsABnZ4kfkA37uQZwmcWiLJDXLtklGG3+
/v7yV9nswgrY+vzR+a0ls/3QOyDf31oxmodMFMY2KVdbMT1MLuucb+osWNc8AxeK
s80cTLDdqN2q78CV0DOcIr1cxzf7z8zhANuFytwQM4nYMyoRuJSOr66d3wHcQ6ll
gRvrMwSJl5XnizgTVwjKV8BtMOotXGccZb1kkCXXgTAglROo66vnqjOGIdI+7M9d
1z+n8IBOdPMZXiaolbOgB/um7W2mD3nqpOdjXoiJYoxYX5AwrKQiRXOgtSV/HCYo
bs04kl9VnMPr0wFBI1mWdq+Vk2+0PxkRyZxa9d/Frt/AzCvr4uN2cqAPQaMcyMgC
ovwU0VW7ijtebELP17xS8F+irxbSAatm7ybaT+iuMoinbGPBK8vbXmUqry5CW2aw
YtLstaom2unpXV6HC8/9
=NGbP
-----END PGP SIGNATURE-----
--- End Message ---
