auth-zones and DNS NOTIFY
list.unbound at omnilan.de
Sun Jun 24 18:20:01 UTC 2018
Am 23.06.2018 um 20:26 schrieb Harry Schmalzbauer via Unbound-users:
> Am 17.04.2018 um 15:26 schrieb W.C.A. Wijngaards via Unbound-users:
>> Hi Harry,
>> Yes, DNS NOTIFY is implemented in the current code repo version. You
>> can specify additional sources with allow-notify.
> Dear all, Wouter,
> sorry for bringing it up again, but I'm having real-world problems
> with this nice new auth-zone: and allow-notify: feature ;-)
> My auth-zone: has two master: definitions.
> It seems that the second defintion is probed first, when a NOTIFY
> comes in (at least if the NOTIFY is not from one of the master);
> haven't verified/falsified, neither by code inspection nor by testing
> beyond lowest level yet. As long as it's a static and documented
> behaviour everything is fine.
> But unfortunately unbound stops probe/xfer-attempts if the fisrt
> master selected/probed doesn't return a higher serial than the NOTIFY
> If the NOTIFY matched a allow-notify: definition (not coming from [one
> of] the master), it should continue and probe the second (etc.) master
> I think. Whether it's sensible to also probe all masters in case the
> NOTIFY came from one of them is beyond my consideration scope atm.
> But in case the NOTIFY came from non-master, the circumstance/decision
> (allow-notify:) itself legitimates probing all masters in case the
> first responded with not higher serail than NOTIFY posted, imho.
Sorry for this stupid and misleading serial comparing confusion:
It's not about probe-serial not higher than NOTIFY serial, but
probe-serial beeing _lower_ than NOTIFY.
Just a mis-explanation, the problem itself should be explained
correctly, I hope. Just the comparing I wrote is nonsense (since NOTIFY
sends the new serial, which in case of multi-master backends, ins't
replicated yet, so the probe-return is _lower_, not equal – sorry).
> Real world: ActiveDirectory e.g. or any other multi-master backend
> which needs more than 1 ms to replicate upstream.
> What do oyu think?
> P.S.: I still have another severe problem with auth-zone: and CNAME
> RRs. As soon as I keep for-downstream: yes, CNAMEs pointing to other
> zones aren't resolved, although unbound is authoritative for the(se)
> other zone(s) too!
> That's unique to unbound afaik.
> Is this really intended by design?
More information about the Unbound-users