1.7.3 - root zone transfer and resolving SLD of delegated TLD

[Anand Buddhdev]

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