1.7.3 - root zone transfer and resolving SLD of delegated TLD

[Wouter Wijngaards]

Hi Anand,

On 10/28/18 9:57 AM, Anand Buddhdev via Unbound-users wrote:
> 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.

And it turns out the code in unbound did not check for the expired zone,
but it did keep track of the expiry timer.  So I added code to give
SERVFAIL when the zone is expired.  If fallback is enabled, instead of a
SERVFAIL it fetches from the upstream.

Likely before the zone is expired the rrsigs may expiry and then the
fallback could also activate.  It also allows older serial numbers as a
zone update when the zone is expired.

Fixed the code to actually give failure for expired zones and documented
what it does.  I think discarding the zone as soon as an update fetch
fails is too fast, so I did not go that far.  But I fixed the expiry to
actually expire the zone at some point.

Best regards, Wouter

> 
> 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20181127/5658b54c/attachment.bin>