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

Anand Buddhdev anandb at ripe.net
Fri Jan 15 15:24:02 UTC 2016

Hash: SHA256

Hi Wouter (and any other users)

Have you had a chance to think about my thoughts (repeated below)
about NSD's refresh strategy?


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 
>> 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
Comment: GPGTools - http://gpgtools.org


More information about the nsd-users mailing list