Slave not downloading new zonefile upon update

[jimc-leones]

Version: unbound-1.9.6 from OpenSuSE Tumbleweed

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
like this:

auth-zone:
name: "cft.ca.us."
master: 192.9.200.193
url: "http://192.9.200.193/unbound-master/cft.zone"
zonefile: "/var/lib/unbound/slave/cft.zone"

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.

[wcawijngaards]

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.

Best regards, Wouter

[jimc-leones]

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 infrastructure work,

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 configuration parameters.

…

-- James F. Carter Email: jimc@jfcarter.net Web: http://www.math.ucla.edu/~jimc (q.v. for PGP key)

[spirillen]

Hi @jimc-leones I didn't read your entire post (tldr;) but i noticed this part

However I still need a recursive and validating local server on the master site

How you been looking at www.powerdns.com by @ahupowerdns @Habbie ?

PS: Sorry for mentions competitors from a different repo/project, but the end result should be the measurement tools, In the same manor that I recommends Unbound despite i use the recursor myself 😄