A caching and zone refresh problem with Unbound
Like many people, we have internal resolving DNS servers that everyone's laptops and so on are supposed to use for their DNS. These used to run Bind and now run Unbound, mostly because OpenBSD switched which nameservers they like. Also like many people, we have a collection of internal zones and internal zone views, which are managed from a private internal master DNS server. This has led to a problem with our Unbound setup that we actually don't know how to solve.
When we make an update to internal DNS and reload the private master
with it, we want this to be reflected on the resolving DNS servers
essentially immediately so that people see the DNS change right away.
In the days when we ran Bind on the resolving servers, this was easy;
we configured the resolving Bind to be a secondary for our internal
zones and set the master up with
also-notify entries for it. When
the master detected a zone change, it sent notifications out and the
resolving Bind immediately loaded the new data. Done.
It's not clear how to achieve something like this with Unbound.
Unbound doesn't listen to
NOTIFY messages and do anything with
them (although it's listed as a TODO item in the source code).
While you can force an incredibly low TTL on DNS records so that
the new DNS information will be seen within a minute or two, this
setting is global; you can't apply it to just some zones, like say
your own, and leave everything else cached as normal. In theory
we could set absurdly low TTLs on everything in the internal views
on the private master, which would propagate through to Unbound.
In practice, how the internal views are build makes this infeasible;
it would be a major change in what is a delicate tangle of a complex
(With low TTLs there's also the issue of cached negative entries, since we're often adding names that didn't exist before but may have been looked up to see that nope, there is no such hostname.)
Unbound can be told to flush specific zones via
and in theory this works remotely (if you configure it explicitly,
among other things). In practice I have a number of qualms about
this approach, even if it's scripted, and Unbound's documentation
explicitly says that flushing zones is a slow operation.
Given that Unbound explicitly doesn't support
NOTIFY yet, there's
probably no real good solution to this. That's sometimes how it
(We have what I'm going to call a workaround that we currently feel we can live with, but I'm not going to tell you what it is because it's not really an appealing one.)