Setting TTLs via scriptable interface does not change cached ttls

Unbound
1

I’ve written some code based on the ttl modification code here:

[http://www.unbound.net/documentation/pythonmod/examples/example3.html](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.

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
2

Hi Jay,

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

3

So, is the only way to modify the TTL of the stored message to
instantiate a new DNSMessage and use that as my response, which has a
massive performance penalty, or is there another way?

Thanks,

Jay