I think this is a documentation issue and/or a feature request. The
symptom is, I have a master, two slaves, and leaf nodes, all running
unbound. The slaves fail to download new zonefiles upon updates. The
auth-zone section on the slaves, after (successful) workarounds, goes
Workaround #1: By reading the source code I discovered that unbound (as
a slave) can make AXFR/IXFR queries to retrieve a zone but (as master)
cannot respond to them. This corresponds to my experience when I had
Bind running on the master. Doing the URL thing got the zonefiles
coming in. I wish the documentation had been a little clearer on this
point. And I'd like to up-vote the feature request to add AXFR/IXFR
responses, so unbound can be a complete DNS server solution.
Workaround #2: One of the DNSSEC tutorials had a great photo of a
chicken looking at an egg. Initially my URL was
"https://jacinth.cft.ca.us:1447/unbound-master/cft.zone". But the 'A'
and AAAA records for Jacinth are in the zonefile that unbound is trying
to download. Thus the download didn't happen. I realized that
Jacinth's webserver is restricted to the internal net and VPNs, so I
could just switch to http://IPADDR/. Now it's downloading. I think
it would be helpful to warn users in the man page about this chicken
and egg issue.
How about a feature request: make a generic pair of commands:
local-data-hint: "name TTL type value" and hint-file: "zonefile-name".
This would have the same effect as root-hints, and in fact could replace
that command (except for the backward compatibility issue), but it could
be used in any context, specifically auth-zone: (and forward-zone:?)
Then the hostname in the url: and other parameters could be given
alphabetically, making the config file more rmaintainable.
The text was updated successfully, but these errors were encountered:
Thank you for the description on making this work.
I had not realized that we need warnings to avoid circular lookup dependencies on the name used to look up the data. Using a plain IP address is the best solution. It is better than the hint solution you suggest. (And also what we suggest users of NSD, our authoritative DNS server, to use for configuration.) Otherwise you end up relying on the DNS infrastructure to be up in order to make the DNS infrastructure work, but with a plain IP address this dependency is not there, and thus, in the network, the services can come on-line independent of the other parts.
AXFR/IXFR service would be a nice feature, but I'll close this as a documentation bugreport. If you really need it, we have NSD, a server that does authoritative only service. And it provides AXFR (but not IXFR) service for zones. And also sends NOTIFY messages to downstream servers so that they fetch the data.
By the way, unbound is capable of receiving NOTIFY messages to make it fetch from the url (or from the master) if you want that. It can be triggered by shell script with something like eg. dig +opcode=notify or ldns-notify, or with notify: or also-notify configuration statements.
On 2020-01-06 07:44, Wouter Wijngaards wrote:
If you really need it, we have NSD, a server
that does authoritative only service. And it provides AXFR (but not
IXFR) service for zones. And also sends NOTIFY messages to downstream
servers so that they fetch the data.
Thanks for your suggestions. NSD looks very cool. I'm impressed that
it's been adopted by several root and TLD servers, and with your
detailed audit of differences from Bind-9. However I still need a
recursive and validating local server on the master site, so I think
I'll stick with Unbound with HTTP (URL) distribution of the updated zone
files, and ldns-notify.
I can see that the goals for Unbound and NSD are very different.
However, it's remotely possible that the internal data storage trees
might be sufficiently similar that the AXFR/IXFR code from NSD could be
extracted into a shared library and used also in Unbound. Also, while
generating a AXFR response is simple but prolix, if you have thousands
or millions of zones in your TLD server, the IXFR would be a whole lot
less resource-intensive for the recipient. It might be worthwhile to
implement IXFR just to help out the TLD deployments.
Also my "enterprise" is very small, but the possiblity of using Unbound
on the master site (as well as the slaves and the leaf nodes) with
traditional propagation by AXFR/IXFR, would really attract IT managers
to adopt Unbound throughout the enterprise.
Using a plain IP
address is the best solution. It is better than the hint solution you
suggest. (snip) Otherwise you end up relying
on the DNS infrastructure to be up in order to make the DNS
Here's a problem: Suppose I use TLS in the URL with an IP; how do I
specify the target's name for Server Name Indication? (Or is the #name
suffix for that purpose rather than for recognizing the peer?) I don't
actually need TLS because the whole data path is under my control and
the payload is public record anyway, but that's not true for everyone.
I assume that with a hint, the various records (A, AAAA, NS) stay in the
cache and the server is allowed to use them, but as soon as DNS
infrastructure is alive enough to answer a query successfully, the hint
is overwritten with the answer. With a hint the configuration or
included file has to be kept up to date with the referent's IP, but only
in one record, and the FQDN can then be used freely in multiple