notify rejected in unbound 1.16.3

[Peter Hessler]

Hi George,

Yup, that did it, thanks!

Since there is already some magic around primary: (for allow-notify:)
would it make sense for unbound to also do a magic in access-control:,
but possibly only if there is not an explicit ACL for those address(es)?

-peter


On 2022 Nov 08 (Tue) at 13:04:34 +0100 (+0100), George (Yorgos) Thessalonikefs via Unbound-users wrote:
:Hi Peter,
:
:ACL (also) comes before NOTIFY processing.
:Make sure that the nameserver addresses are not denied (the default) by
:Unbound.
:
:Something like:
:    server:
:        access-control: <IP address> allow
:
:or
:    server:
:        access-control: <IP address> refuse_non_local
:
:should work.
:The latter will make sure to not allow recursion for the <IP address>.
:
:Best regards,
:-- Yorgos
:
:On 08/11/2022 10:26, Peter Hessler via Unbound-users wrote:
:> Hi All,
:> 
:> I'm running unbound 1.16.3 as included in OpenBSD 7.2, and wanted to cache
:> a public zone on it.  It is a caching resolver for a busy[1] website and
:> since I use lots of dns entries in my configuration I want to have a
:> local copy of the zone already in the cache.
:> 
:> I added this stanza to my working configuration:
:> 
:> auth-zone:
:>      name: "example.com"
:>      primary: "ns.example.org"
:> #    allow-notify: "ns.example.org"
:>      fallback-enabled: yes
:>      for-downstream: no
:>      for-upstream: yes
:> 
:> and configured my primary auth server to allow AXFR and send NOTIFYs to
:> this system.  When I start unbound, it does an AXFR properly so it has
:> the data.  However, when i send a NOTIFY I immediately get back a
:> rejected message.  I've verified that the IP addresses are correct, and
:> even though it should automatically allow the primary to send notifies
:> I've tried with manually added allow-notify entries for both the
:> dual-stack hostname and for the raw IP address of the sending server.
:> 
:> Am I holding it wrong?
:> 
:> -peter
:> 
:> [1] Busy is subjective, but the logs scroll by faster than I can read
:> them.
:> 

-- 
Beware of bugs in the above code; I have only proved it correct, not
tried it.
		-- Donald Knuth