auth-zones and DNS NOTIFY

[W.C.A. Wijngaards]

Hi Harry,

On 24/06/18 20:20, Harry Schmalzbauer wrote:
> 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.

Thank you for the bugreport.  I have fixed the code, so that I does not
stop the probe when a master replies with the current serial.  Instead,
it'll continue and probe the masters, until one has an update.  If all
of them respond with the current serial, it assumes it is up to date and
waits (the SOA timer).

The first master that gets a query is the same master that sent the
NOTIFY.  After that it should scan them in order they appeared in config.

(The code is in the repository, pick up services/authzone.c and
services/authzone.h if you want to have the update).

Best regards, Wouter


>>
>> But unfortunately unbound stops probe/xfer-attempts if the fisrt
>> master selected/probed doesn't return a higher serial than the NOTIFY
>> posted.
>> 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?
>>
>> Thanks,
>>
>> -harry
>>
>> 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?
>>


-------------- 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/20180626/5d6debf4/attachment.bin>