[Unbound-users] Setting TTLs via scriptable interface does not change cached ttls

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jay,

On 01/14/2013 09:31 PM, Jay Deiman wrote:
> I've written some code based on the ttl modification code here:
> 
> http://www.unbound.net/documentation/pythonmod/examples/example3.html
>
>  I'm noticing an odd behavior that seems like it may be a bug.  I
> was doing some testing and found that my responses that I get back
> from unbound for the modified TTLs seem to be correct, but the
> cached entries don't expire when the TTL reaches zero.
> 

The cache entry itself, the message, has its own TTL (usually the
minimum of the TTLs of the RRs but you broke that assumption with your
code), you are adjusting the TTL of the RRs, but not the TTL of the
message.  This is causing your strange observations.

Best regards,
   Wouter

> Here is an example.  I am setting the TTLs for google.com
> <http://google.com> to 5, instead of their default 300, seconds.
> and when I do a dig against a cold cache, this is what I get (as I
> would expect):
> 
> ================================ ; <<>> DiG 9.7.3 <<>> -p 5300
> @localhost google.com <http://google.com> ; (1 server found) ;;
> global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY,
> status: NOERROR, id: 32474 ;; flags: qr rd ra; QUERY: 1, ANSWER:
> 11, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION: ;google.com <http://google.com>.			IN	A
> 
> ;; ANSWER SECTION: google.com <http://google.com>.		5	IN	A
> 173.194.33.9 google.com <http://google.com>.		5	IN	A	173.194.33.1 
> google.com <http://google.com>.		5	IN	A	173.194.33.14 google.com
> <http://google.com>.		5	IN	A	173.194.33.3 google.com
> <http://google.com>.		5	IN	A	173.194.33.5 google.com
> <http://google.com>.		5	IN	A	173.194.33.4 google.com
> <http://google.com>.		5	IN	A	173.194.33.6 google.com
> <http://google.com>.		5	IN	A	173.194.33.7 google.com
> <http://google.com>.		5	IN	A	173.194.33.2 google.com
> <http://google.com>.		5	IN	A	173.194.33.0 google.com
> <http://google.com>.		5	IN	A	173.194.33.8
> 
> ;; Query time: 41 msec ;; SERVER: 127.0.0.1#5300(127.0.0.1) ;;
> WHEN: Mon Jan 14 12:18:30 2013 ;; MSG SIZE  rcvd: 204 
> ================================
> 
> Now, when I check again after 5 seconds:
> 
> ================================ <snip> ;; ANSWER SECTION: 
> google.com <http://google.com>.		0	IN	A	173.194.33.9 google.com
> <http://google.com>.		0	IN	A	173.194.33.1 google.com
> <http://google.com>.		0	IN	A	173.194.33.14 google.com
> <http://google.com>.		0	IN	A	173.194.33.3 google.com
> <http://google.com>.		0	IN	A	173.194.33.5 google.com
> <http://google.com>.		0	IN	A	173.194.33.4 google.com
> <http://google.com>.		0	IN	A	173.194.33.6 google.com
> <http://google.com>.		0	IN	A	173.194.33.7 google.com
> <http://google.com>.		0	IN	A	173.194.33.2 google.com
> <http://google.com>.		0	IN	A	173.194.33.0 google.com
> <http://google.com>.		0	IN	A	173.194.33.8
> 
> ;; Query time: 0 msec ;; SERVER: 127.0.0.1#5300(127.0.0.1) ;; WHEN:
> Mon Jan 14 12:19:43 2013 ;; MSG SIZE  rcvd: 204 
> ================================
> 
> Unbound continues to give this zero TTL response until the
> *original server TTL* of 300 seconds expires.  I've also tried
> using python as the first module in "module-config" with the
> invalidateQueryInCache() and storeQueryInCache() method.  It
> doesn't seem to change the behavior.
> 
> Is this a bug, as I would expect, or the expected behavior?
> 
> Thank you,
> 
> Jay Deiman
> 
> 
> 
> _______________________________________________ Unbound-users
> mailing list Unbound-users at unbound.net 
> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ9RDdAAoJEJ9vHC1+BF+NbhEQAKbzNVTaKcrLsskXyGyCwWXc
v8HjR1SJQhX1O+2+79NgnMMrW3sDeniOIHeVZjHOw1ZZnWvtMCqoeyK0/o2CBLJ7
wnfnO6t1qWa5BppLQP2Kf4qPXE7dpv53VtDmhJ5HRhC5wsZj2NgHDyoQ3OLQ/m75
kTJt6ITgOiwEodZpbwH/T8On/HXoTkdF7qSiewX2lRKV2VD7dmIvz+dOMnWQ3C6d
VThKTMg9OowItSYOGwrEOZ0wNDocztltb9OD0eMm0tukqviCg2QvVeE5Ij7tFjsE
6BvEw8kKgOhLVV/1e/jRw6fflaUZWBYgQFN46EsPiRHm9UP6MHgvxfDH0/UUPe6X
H/PvK54h/V1KAcXDxqR3CHk1d5e1Al0vjq08z2hFtPQbcD2IXgw4dr+eY04lmUQW
wWp2O7DdQGBiZ7PSZdjha0RgARTJDxAQk4ugfSMBc+vEuCvWEk2AP6JmiPR4SPMR
uWCHawlV64I1d8+QnE3DBot5mi2RN3Ec6PrN+lh0dUS1SBAmtfZhhIxKQb1XIP9Q
j0nHDPeid6lk+dEQ5t+heBnDpFv2uEQDXob7ieyK2PFXGwPR5DD7AYsPjnRyNM9m
xcS4Db85QdKv4HOq9aK1t6BOHLFuL0K18Gf0zdDgoEu8/FJiZFeLCeIVF3v6QSgW
DhFQl/+uvzdp2sMd4YnC
=L1ZU
-----END PGP SIGNATURE-----