RR ttl in dump_cache

Unbound
1

Hello.

I noticed the (relatively) new dump_cache/load_cache
commands of unbound-control, and started experimenting.

And immediately come across an.. issue. The TTL for
each RR is expressed as time-to-live since "now", it
is not an expiration time. For this reason it's not
possible to save the cache and load it back on restart
for example, because ttl in that case will be invalid.

I wonder if it's a good idea to use absolute expire
time in place of TTL in dump/load_cache format. If
nothing else, prefixing the field with an equal sign
will do the trick (=1234567 to mean absolute time,
1234567 - current - to mean ttl as it is now).

And in general, do people use dump/load_cache to
start with?

Thanks!

/mjt

2

Hi Michael,

I noticed the (relatively) new dump_cache/load_cache
commands of unbound-control, and started experimenting.

And immediately come across an.. issue. The TTL for
each RR is expressed as time-to-live since "now", it
is not an expiration time. For this reason it's not
possible to save the cache and load it back on restart
for example, because ttl in that case will be invalid.

Yes at the same time the problem but also the reason
people do it.

I wonder if it's a good idea to use absolute expire
time in place of TTL in dump/load_cache format. If
nothing else, prefixing the field with an equal sign
will do the trick (=1234567 to mean absolute time,
1234567 - current - to mean ttl as it is now).

And in general, do people use dump/load_cache to
start with?

Well they want to dump to examine contents.
Want to load to 'hot-start' the cache. So that the
resolver starts with a full cache. For that to work
the TTLs have to make the data 'valid'.

I guess that the time of the dump could be stored.
And the readback could make items that used to be valid,
but are now expired, have a TTL of 10-30 seconds (random)
spreading the work to refresh the entries.

Best regards,
   Wouter