dnsdist: pass pool instead of servers list to ServerPolicy.policy()

[gjherbiet]

Hello,

I have defined two disjoint pools of server: the default pool and the stateful pool.

I redirect part of the incoming DNS traffic to the stateful pull (e.g. based on client source IP) using addAction(NetmaskGroupRule(...), PoolAction('stateful')).

I am now trying to build a custom Lua server policy, as follows:

1. If the traffic is intended to the stateful pool, use a hash of the client source IP to select an up-and-running server in the stateful pool;
2. If traffic is intended to the default pool or there is no up-and-running server in the stateful pool, use the leastOutstanding policy on the default pool.

I can create a list of up-and-running servers in the stateful pool and select a server based on client source IP (using the djb2 hash:

upServers = {}
for i,server in pairs(getPoolServers('stateful')) do
	if (server:isUp() == true) then
		upServers[i] = server
	end
end

hash = 5381
for c in dq.remoteaddr:toString():gmatch('.') do
	hash = (bit.lshift(hash, 5) + hash) + string.byte(c)
end
server = upServers[(hash % #upServers) + 1]

However, it is really complex to determine whether the traffic is intended for the stateful or the default pool.

As only the list of servers is passed to ServerPolicy.policy(), this would imply to:

1. get the list of all existing pools
2. for each pool, get the list of servers in the pool
3. test if the list of servers in the pool is identical to the list of servers passed to ServerPolicy.policy()

As Lua doesn't seem to have a proper array comparison function, we are already down to three nested loops (high order of computational complexity).

Hence my suggestion to pass a reference to the pool (instead of the servers list) for the current incoming query to ServerPolicy.policy(). This would allow to solve the aforementioned elegantly, and the getting the list of servers could also be available using getPoolServers().

To maintain backward compatibility, maybe this could require a new ServerPolicy.policyFromPool() method, along with new setServerPolicyFromPool* functions.

I am also interested in any other solution that may make this suggestion irrelevant while still fulfilling my objective ;-)

[rgacogne]

I'm pretty sure I'm missing something, but couldn't you:

• assign the leastOutstanding policy to the default pool
• use PoolAvailableRule to route your traffic to the default pool if there is no server available in the stateful one
• define a custom load-balancing policy and assign it to the stateful pool

[gjherbiet]

It's not like I have extensively browsed the dnsdist documentation, but I indeed just missed the setPoolServerPolicy() and setPoolServerPolicyLua() functions...

Those functions, with the PoolAvailableRule() selector make everything cleaner and easier!

For the record, here is my implementation:

-- Define your servers and pools
-- newServer(...)
-- [...]

-- Redirect all traffic to the default pool when the stateful pool is not available
addAction(NotRule(PoolAvailableRule('stateful')), PoolAction(''))

-- Redirect specific subnets to the stateful pool
addAction(NetmaskGroupRule({...}), PoolAction('stateful'))

-- Custom server policy using remote address hash
function remoteaddrHash(servers, dq)
	-- Create a list of up-and-running servers
	upServers = {}
	for i,server in pairs(servers) do
		if (server:isUp() == true) then
			upServers[i] = server
		end
	end
	-- Select up-and-running server based on djb2 hash of remote address
	hash = 5381
	for c in dq.remoteaddr:toString():gmatch('.') do
		hash = (bit.lshift(hash, 5) + hash) + string.byte(c)
	end
	return upServers[(hash % #upServers) + 1]
end

-- Set default server policy
setServerPolicy(leastOutstanding)
-- Set specific policy for stateful pool
setPoolServerPolicyLua('raddrhashed', remoteaddrHash, 'stateful')

[rgacogne]

Nice, thank you for sharing this 👍
I indeed wrongly assumed earlier you were aware of the existence of the setPoolServerPolicy... functions, sorry about that!

[gjherbiet]

If the remoteaddrHash function and associated raddrhashed policy (named for consistency with the built-in policies) are of interest, feel free to "promote" them to built-in.