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

[Anand Buddhdev]

-----BEGIN PGP SIGNED MESSAGE-----
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?

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

iQIcBAEBCAAGBQJWmQ8SAAoJEBXgoyUMySoF4XUQALK+VXhRBheJfRGXqtbSoNV4
P1k7PMS+dcl4rPlY2GRC/xfKrSjEkfMZ3Y04+hO8rx+vaGb6mwLCmRhE0jGPWXpS
cH3gjuQXI5dHdd7T6/bTVv3Vnc0eOgxna7ArF3N/3EXC/+CPwW7XMONqESUbDd4v
0bzg528nbMN3Rx0VmJFSR3VobffiLRwhWy/Ta8mAVrmnrSXEoUk++9EASOVHVEtZ
kS7rXY0+q/mK7JsVtch+HsmNkMB2XAA/ROUPRClkiJ6mhsNRt7AADuJxwpv7DV0F
UrzQ2Wjzay8B/s58uID9HAaI0MJluAxh6WjIjW16hmVULqSWM9DMxdh2PtCRGLVw
nIchrzOTB+7VkYtjlVf9BItKzFvfbXqSk1XByjons3j/wjgGKUWbCYxVGiK9YLro
R7x9UtR30TqbQ+zBTLd80dNq9TiYwNWiHyLrvyhvO1zttG+KTmZMbpb26tF2OqOx
LS7o+ef62P3Z9shBOXAWE9g2k+M3bBKG2mzTl1zuc8YJ5nOBKqmnFEO+IJZRlS9W
sMmtMqbb9XUr5BvjJ8Bl7EHLzWyLTjZuGm4habqcQ82uSmU+aY0DUTCxWCi5g1E5
05Ojx4Lz3ycP+QGBmsPusaBbc79wQSWMwCADgTrL+a6L63kADa2i9Oyk0wRxGNc9
d1dRFcoc5fQXQ+dsC8wK
=2LjS
-----END PGP SIGNATURE-----