9 Zář
2021
9 Zář
'21
12:42
Hi,
I'm having trouble reading the documentation for Lua modules, is it
possible to issue multiple recursive queries and await all of the
results?
What I'm trying to achieve is a CNAME glue-zone, d.example.com, that
searches in several other zones (phy.example.com, vm.example.com,
ad.example.com, etc) and returns a CNAME record into the one with the
highest priority (configurable, probably just a list) that does not
reply with a NXDOMAIN.
I'd like to do all the recursions in parallel, to keep users as happy
as possible.
Configuration might look something like this:
local zones = {
["d.example.com"] = {
"phy.example.com",
"vm.example.com",
"ad.example.com"
},
["vm.example.com"] = {
"vmware.vm.example.com",
"hyperv.vm.example.com"
}
}
/Erik
() ascii ribbon - against html e-mail
/\ arc.pasp.de - against proprietary attachments
9 Zář
9 Zář
13:02
Hello.
On 09/09/2021 12.42, Elipsion wrote:
is it possible to issue multiple recursive queries and
await all of the
results?
No, unfortunately the "resolving engine" currently does not support this
kind of concurrency. For one client request, only the last unfinished
sub-request is active and can issue queries to upstream. After it
finishes, the previous one can continue, but they can't query in
parallel. (Different requests from clients are processed in parallel,
of course.)
The capability certainly is on a long-term wishlist, but I don't expect
it anytime soon.
--Vladimir
13:14
Hi,
Thanks so much for the quick response,
Do you have any pointers for non-concurrent multi-issue code? Eg.
examples or other modules that do this?
From what I understand from the documentation there
would need to be
multiple consume-passes, that are also behaving like producers.
Or should the produce stage just issue all of the requests and the
consumer parse all of the replies?
/Erik
() ascii ribbon - against html e-mail
/\ arc.pasp.de - against proprietary attachments
On Thu, 9 Sept 2021 at 13:02, Vladimír Čunát <vladimir.cunat(a)nic.cz> wrote:
Hello.
On 09/09/2021 12.42, Elipsion wrote:
is it possible to issue multiple recursive
queries and await all of the
results?
No, unfortunately the "resolving engine" currently does not support this
kind of concurrency. For one client request, only the last unfinished
sub-request is active and can issue queries to upstream. After it
finishes, the previous one can continue, but they can't query in
parallel. (Different requests from clients are processed in parallel,
of course.)
The capability certainly is on a long-term wishlist, but I don't expect
it anytime soon.
--Vladimir
14 Zář
14 Zář
12:09
On 09/09/2021 13.14, Elipsion wrote:
Thanks so much for the quick response,
Do you have any pointers for non-concurrent multi-issue code? Eg.
examples or other modules that do this?
From what I understand from the documentation there would need to be
multiple consume-passes, that are also behaving like producers.
Or should the produce stage just issue all of the requests and the
consumer parse all of the replies?
Well, the "iterate" built-in module also does something a bit similar
(in one mode); otherwise there's nothing really similar.
A produce phase can only create one query for upstream; then it's sent
and the corresponding reply is consumed. As long as things are not
marked as finished, new produce phase will happen again. Theoretically
sub-requests (child kr_query) could be used, but their behavior is
currently hard-coded for certain QTYPEs, so I wouldn't recommend trying
that.
Even so, I don't think any way will be easy, as you're likely to be
"fighting" with the iterator and maybe other parts. Right now kresd
just isn't designed with _these_ kinds of modifications in mind. To
avoid the clashes, it might be easiest to put a module ordered before
iterate and replace the non-existence in packets by a CNAME to the next
name to try - and let iterator and other modules continue on that.
--Vladimir
14:00
Thanks for elaborating!
In the end I went with PowerDNS and cqueues instead.
/Erik
() ascii ribbon - against html e-mail
/\ arc.pasp.de - against proprietary attachments
On Tue, 14 Sept 2021 at 12:09, Vladimír Čunát <vladimir.cunat(a)nic.cz> wrote:
On 09/09/2021 13.14, Elipsion wrote:
Thanks so much for the quick response,
Do you have any pointers for non-concurrent multi-issue code? Eg.
examples or other modules that do this?
From what I understand from the documentation there would need to be
multiple consume-passes, that are also behaving like producers.
Or should the produce stage just issue all of the requests and the
consumer parse all of the replies?
Well, the "iterate" built-in module also does something a bit similar
(in one mode); otherwise there's nothing really similar.
A produce phase can only create one query for upstream; then it's sent
and the corresponding reply is consumed. As long as things are not
marked as finished, new produce phase will happen again. Theoretically
sub-requests (child kr_query) could be used, but their behavior is
currently hard-coded for certain QTYPEs, so I wouldn't recommend trying
that.
Even so, I don't think any way will be easy, as you're likely to be
"fighting" with the iterator and maybe other parts. Right now kresd
just isn't designed with _these_ kinds of modifications in mind. To
avoid the clashes, it might be easiest to put a module ordered before
iterate and replace the non-existence in packets by a CNAME to the next
name to try - and let iterator and other modules continue on that.
--Vladimir
962
days inactive
967
days old
knot-resolver-users@lists.nic.cz
4 comments
2 participants
participants (2)
-
Elipsion -
Vladimír Čunát