[nsd-users] NSD doing 3 IXFR queries in rapid succession

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Anand,

Yes treating the refresh timer the same as a notify is what is
happening.  Searching thoroughly for an answer is what is intended,
and that includes trying multiple times, and to every master.  That
behaviour is the same as for Unbound, which also attempts to find
information at every server available, and several attempts.

So, doing multiple queries in succession when searching for
information is not something I want to change.  However, adding logic
to act differently to save those queries in the case of a refresh
timer to not sound really worthwhile to me, either.

Best regards, Wouter

On 15/01/16 16:24, Anand Buddhdev wrote:
> Hi Wouter (and any other users)
> 
> Have you had a chance to think about my thoughts (repeated below) 
> about NSD's refresh strategy?
> 
> Anand
> 
> On 04/01/16 15:59, Anand Buddhdev wrote:
> 
>> On 04/01/16 14:09, W.C.A. Wijngaards wrote:
> 
>> Hi Wouter,
> 
>>> NSD wants to fetch an update for the zone.  The server does not
>>>  provide one.  NSD tries all masters several times to find the
>>>  update. This is where this server sees multiple requests.
> 
>> This is the part that does not make sense. When the SOA refresh 
>> timer expires, NSD should of course try and update the zone. 
>> However, I think *one* query against *one* master should be 
>> enough.
> 
>> I do not think that sending 3 queries in rapid succession to the 
>> same master is beneficial. If a master does not have a newer
>> copy of the zone now, it is unlikely to have a newer copy just a
>> few milliseconds later. If I have 4 masters configured for a
>> zone, NSD is making 12 TCP connections in total, just to try and
>> update *one* zone. Then, it moves on to the next zone. This is
>> rather wasteful, don't you think? A slave that has a large number
>> of zones is going to end up making far too many queries for
>> refreshing these zones (well, at least 3 times as many).
> 
>> I think the correct behaviour should be that when the SOA refresh
>>  timer expires, NSD should try to refresh the zone from one of
>> the configured masters, and if the serial number hasn't changed,
>> then accept that, and move on to other tasks.
> 
>> In the case of a NOTIFY message, a slightly different behaviour
>> is desirable. NSD should attempt to refresh the zone from the
>> master that sent it the NOTIFY message (because it is almost
>> certain to have a newer copy of the zone), and if that fails,
>> then try the other masters, once each. Here, I define failure as
>> one of:
> 
>> 1. Same serial number (instead of an expected newer serial) 2. 
>> REFUSED 3. SERVFAIL 4. Timeout
> 
>>> The reason for fetching it may be the SOA refresh timer or a 
>>> NOTIFY.
> 
>>> Load balancers, and the server may be in the process of loading
>>>  the data, so the third query may return a different result. 
>>> Also, the code, currently, just retries in the face of no
>>> result, which makes for simpler code.
> 
>> The case of multiple masters behind a load balancer is rare. I 
>> would even go as far as to say that it is not a good
>> configuration, because it confuses the hell out of a client
>> attempting to refresh zones from the master(s).
> 
>> Have you actually had any reports of people running master
>> servers behind load balancers, and asking for slaves to try
>> refresh 3 times?
> 
>> None of the alternative servers I know of (BIND, Knot, YADIFA)
>> try to refresh a zone with multiple queries and connections.
> 
>> Regards, Anand _______________________________________________ 
>> nsd-users mailing list nsd-users at NLnetLabs.nl 
>> http://open.nlnetlabs.nl/mailman/listinfo/nsd-users
> 
> _______________________________________________ nsd-users mailing
> list nsd-users at NLnetLabs.nl 
> http://open.nlnetlabs.nl/mailman/listinfo/nsd-users
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWnJ5lAAoJEJ9vHC1+BF+N9zYP/1duRlPySunkCT0jE1SSjeuy
+KBZkyhYkgoY7BJfakRUTs6eCXh/IPxq/Eubje9y22i0fBlvWBqeghMQQ1/D38ys
XIg6A1VFwKkOvllEA/CKvdrKIFfy5f2Fsu/J/atb2HujiJTXEFfq+8SjNCdgu4b0
7NPt+7rQOC82k9zDI5bgHCRYbCa5TzX4d0C7pep5sDvjRKUqfHCnrE+7mCGzoseR
mcEeHv8yaJzGQ2glckAvwXIc6XjvdKgVg8dDbQ6uIEWKkUeQH6NU746ZVQ/vCB/N
/Cc7dVN8Lq1lqq4Je4ziBpYy+KWjGacIXQ30oq2kkUSJK6iyORSIYEdjE3VTsbVM
1V8wpZwn06Nviog83zl47MMM8Ce6F89u6a6CT/fK0XnhqJie+ljIFDLXaOCmHzZy
JchJbmv2ThRevIHtsDpjjIqQ+9vIaAhUDchWN27fbz5tjwHI3cxc81BOi75SxEfd
AKkjtfAf9WdndN5nPqPKiJ7SUmCAcRU/ufPeyrFr2Pr9NtGiTCpojsSHloVgOxKb
Z6At4CpEsGiHzrMvKWWvod7fzhlyo3q2ow0NBPza9alR7U2dBzNcb57aj3xDktRW
Yj1MOFv9pGYGaWEZcaeXpXzSl74zFy5WNrFbCiIm07/7/gtE12OR0kPlrHnMj540
krYo/UeW8i2WZ9uZMmVn
=cMLE
-----END PGP SIGNATURE-----