On 28/10/2018 09:29, A. Schulze via Unbound-users wrote: Hi Andreas,
> # https://unbound.nlnetlabs.nl/pipermail/unbound-users/2018-May/005268.html > auth-zone: > name: "in-addr.arpa." > for-downstream: no > for-upstream: yes > fallback-enabled: yes > master: f.in-addr-servers.arpa. > zonefile: "auth-zones/in-addr.arpa" > > auth-zone: > name: "ip6.arpa." > for-downstream: no > for-upstream: yes > fallback-enabled: yes > master: f.ip6-servers.arpa. > zonefile: "auth-zones/ip6.arpa" > > suggestions/comments welcome ... I notice that for these 2 zones, you've only listed one master. If this master is unavailable, or stops providing XFR, I don't know how unbound behaves, and what its failure mode is. The unbound.conf man page doesn't describe what happens in this condition. If unbound just waits like a regular secondary, then it may be several hours or days until the zone expires (based on SOA timers), and your copy of unbound will be using old data. This is where unbound needs improvement, with 2 things: 1. document very clearly what unbound's behaviour is when all masters of a zone become unavailable; and 2. if unbound really behaves like a regular secondary and waits for the zone to expire based on the SOA record, then it's a poor choice. IMHO, when unbound is unable to refresh a zone, it should immediately discard it, and do normal recursive lookups for it. This would be far more resilient. And all of this should be documented in the man page. I often find that manuals are very good at describing how to configure things, but they don't tell the operator what to expect and what to do when things go wrong. We operators end up learning the hard way. Regards, Aannd
