Disable caching for stub zones

Unbound
1

Hi

I'm running unbound 1.4.22 (AD) and looking for a way to disable caching
for all or some stub zones, as these zones are served by nsd (AA) on the
same machine:

server:
    private-domain: "example.net."
    private-domain: "example.com."

    private-address: "10.1.0.0/16"
    local-zone: "1.10.in-addr.arpa." transparent
    domain-insecure: "1.10.in-addr.arpa." #remove after dnssec is enabled

    private-address: "10.2.0.0/16"
    local-zone: "2.10.in-addr.arpa." transparent
    domain-insecure: "2.10.in-addr.arpa." #remove after dnssec is enabled

    domain-insecure: "example.com." #remove after dnssec is enabled
    domain-insecure: "example.net." #remove after dnssec is enabled

stub-zone:
    name: "example.net."
    stub-addr: 127.0.0.1@54

stub-zone:
    name: "example.com."
    stub-addr: 127.0.0.1@54

stub-zone:
    name: "1.10.in-addr.arpa."
    stub-addr: 127.0.0.1@54

stub-zone:
    name: "2.10.in-addr.arpa."
    stub-addr: 127.0.0.1@54

forward-zone:
    name: "."
    forward-addr: 10.1.0.42

I found that I can evict the cache for the stub zones by running the
following commands wie cron every minute or so

unbound-control flush_zone example.net.
unbound-control flush_zone example.com.
unbound-control flush_zone 1.10.in-addr.arpa.
unbound-control flush_zone 2.10.in-addr.arpa.

Is there a better way to prevent unbound of caching these zones in the
first place or to reduce the cache time for these zones?

Regards
    Alex

2

Hi,

I'm running unbound 1.4.22 (AD) and looking for a way to disable caching
for all or some stub zones, as these zones are served by nsd (AA) on the
same machine:

...

I found that I can evict the cache for the stub zones by running the
following commands wie cron every minute or so

unbound-control flush_zone example.net.
unbound-control flush_zone example.com.
unbound-control flush_zone 1.10.in-addr.arpa.
unbound-control flush_zone 2.10.in-addr.arpa.

Is there a better way to prevent unbound of caching these zones in the
first place or to reduce the cache time for these zones?

You can of course reduce the TTL as you see fit, but I don't understand what problem you are trying to solve. I.e. I get that the stubs refer to zones served by NSD on the same machine, but how is caching of that a problem?

Regards,

Johan

3

Hi

I'm running unbound 1.4.22 (AD) and looking for a way to disable caching
for all or some stub zones, as these zones are served by nsd (AA) on the
same machine:

...

I found that I can evict the cache for the stub zones by running the
following commands wie cron every minute or so

unbound-control flush_zone example.net.
unbound-control flush_zone example.com.
unbound-control flush_zone 1.10.in-addr.arpa.
unbound-control flush_zone 2.10.in-addr.arpa.

Is there a better way to prevent unbound of caching these zones in the
first place or to reduce the cache time for these zones?

You can of course reduce the TTL as you see fit, but I don't
understand what problem you are trying to solve. I.e. I get that the
stubs refer to zones served by NSD on the same machine, but how is
caching of that a problem?

I had/have the problem that DNS entries and reverse entries do change
often and unbound serves the outdated records.

Regards,
    Alex

4

Wouldn't the solution be to set an appropriate TTL on those records? Unbound likely isn't the only place those records will be cached, they'll be cached client-side as well by most modern clients.

5

This is my view also.

The TTL is a promise of sorts: when the zone owner publishes a piece of information with an associated TTL he is promising not to change the data within that period so that caching will work.

If the zone owner changes data more frequently than the TTL he has selected himself then the problem is clearly in the publishing end and not in the recursive server end.

Regards,

Johan

6

Hi

Wouldn't the solution be to set an appropriate TTL on those records?
Unbound likely isn't the only place those records will be cached,
they'll be cached client-side as well by most modern clients.

The TTL is a promise of sorts: when the zone owner publishes a piece
of information with an associated TTL he is promising not to change
the data within that period so that caching will work. If the zone
owner changes data more frequently than the TTL he has selected
himself then the problem is clearly in the publishing end and not in
the recursive server end.

Thanks for your input. I'll address the problem as you have recommended
by lowering the TTL in the original zones.

thx
    Alex