30 Dub
2021
30 Dub
'21
5:05
Hello,
We operate recursive resolvers in our network in AWS and from within
the AWS network there are certain authoritative nameservers that block
large swaths of the AWS IP range, causing resolution to fail for us.
So I'm attempting to write a module that will handle failures reaching
external resolvers and retry the query by forwarding it to a major
resolver like cloudflare DNS. We push a ton of DNS query traffic so we
do not want to simply forward to a public resolver, we only want to
forward if recursion doesn't work for some reason.
I've poured through the documentation and source code and tried to
hook a variety of places, but I can't seem to find a good spot to hook
the request failure. The finish layer allows me to hook the SERVFAIL,
but by then it is too late to do anything. Using a simple policy, I
was actually able to do something close by calling ensure_answer(),
clearing the answer, setting the same forwarding flags as the forward
policy, and then calling ensure_answer() again and I could see the
query getting sent to cloudflare, so it seems like this is possible,
but at the policy level it's too early to know if a query will result
in a SERVFAIL.
Could anyone point me in the right direction here?
Thank you!
Paul
16:37
Hi Vladimir,
Yes, this is all packets being dropped to their nameserver IP addresses, so
no response at all on either UDP or TCP.
Thanks,
Paul
On Fri, Apr 30, 2021, 4:40 AM Vladimír Čunát <vladimir.cunat(a)nic.cz> wrote:
Hello.
On 4/30/21 5:05 AM, Paul Furtado wrote:
there are certain authoritative nameservers that
block
large swaths of the AWS IP range, causing resolution to fail for us.
What kind of blocking is this? Not replying at all?
--Vladimir
3 Kvě
3 Kvě
11:58
OK, so this thing has two parts:
1. when to trigger the fallback
2. switching to forwarding mode itself
Yes, this is all packets being dropped to their
nameserver IP
addresses, so no response at all on either UDP or TCP.
1: for the trigger I'd
suggest reusing the logic from our serve_stale
module, as that one is (also) meant as fallback in case upstream servers
don't reply, and the reason for not replying doesn't seem to matter here.
2: the current server-selection code does not count on being switched
mid-request, but I hacked around that and I suspect it will work
reasonably reliably... at least until we make some significant
server-selection code change in farther future. (note: the way I wrote
it requires knot-resolver >= 5.3.0)
Overall, this seemed OK on my quick test:
-- add to normal config, typically in /etc/knot-resolver/kresd.conf
modules.load('fallback')
and then a separate module file:
-- in /var/lib/knot-resolver/kres_modules/fallback.lua (lua load path is somewhat
customizable, too)
local M = {}
-- Default settings; action: probably works just with FORWARD/TLS_FORWARD.
M.timeout = 1 * sec
M.action = policy.FORWARD({'1.1.1.1', '1.0.0.1'})
local ffi = require('ffi')
ffi.cdef("void kr_server_selection_init(struct kr_query *qry);")
M.layer = {}
function M.layer.produce(state, req, pkt)
local qry = req:current()
if qry.flags.FORWARD then return end -- we've switched already
local now = ffi.C.kr_now()
local deadline = qry.creation_time_mono + M.timeout
if now > deadline or qry.flags.NO_NS_FOUND then
if verbose() then
log('[ ][fall] => no reachable NS, using fallback action')
end
M.action(state, req)
-- Hacky: we need to reset the server-selection state,
-- so that forwarding mode can start.
-- Fortunately context is on kr_request mempool, so we can leak it.
ffi.C.kr_server_selection_init(qry);
end
end
return M
--Vladimir
1098
days inactive
1101
days old
knot-resolver-users@lists.nic.cz
3 comments
2 participants
participants (2)
-
Paul Furtado -
Vladimír Čunát