On 24/09/2021 14.29, Günther J. Niederwimmer wrote:
> I mean my cert and key are are equipped with "standard" rights ?
>
> Knot-resolver can't handle it ?
It does not run under "root" user or group (by default), so in your
settings it won't be able to read them.
--Vladimir
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
Hello,
it seems that Knot Resolver doesn't responde for DNS ANY queries or it does?
Unable to found how to set it up in documentaction.
Thank you for you help
Michal
Hello,
it seems that Knot Resolver doesn't responde for DNS ANY queries or it does?
Unable to found how to set it up in documentaction.
Thank you for your help
Michal
Dear Knot Resolver users,
Knot Resolver 5.4.0 has been released! It comes with improved logging
facilities and new debugging options.
Improvements
------------
- fine grained logging and syslog support (!1181)
- expose HTTP headers for processing DoH requests (!1165)
- improve assertion mechanism for debugging (!1146)
- support apkg tool for packaging workflow (!1178)
- support Knot DNS 3.1 (!1192, !1194)
Bugfixes
--------
- trust_anchors.set_insecure: improve precision (#673, !1177)
- plug memory leaks related to TCP (!1182)
- policy.FLAGS: fix not applying properly in edge cases (!1179)
- fix a crash with older libuv inside timer processing (!1195)
Incompatible changes
--------------------
- see upgrading guide:
https://knot-resolver.readthedocs.io/en/stable/upgrading.html#to-5-4
- legacy DoH implementation configuration in net.listen() was renamed
from kind="doh" to kind="doh_legacy" (!1180)
Full changelog:
https://gitlab.nic.cz/knot/knot-resolver/raw/v5.4.0/NEWS
Sources:
https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-resolver/knot-resolver-5.4.0.tar.xz.asc
Documentation:
https://knot-resolver.readthedocs.io/en/v5.4.0/
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
Hello all,
I've recently switched from the unbound resolver
to the knot resolver for all outgoing name resolution on
one of my FreeBSD servers. It all works pretty much as
expected. With one problem; initializing and terminating
kresd isn't possible w/o adding some external scripting.
Given that the BSDs don't come w/systemd. Are there any
plans to better support the sysv init system in the knot
resolver?
Thanks in advance for any hints/pointers/solutions. :-)
--Chris
Hi,
I recently stumbled about the following issue with postfix:
DANE TLSA lookup problem: Host or domain name not found. Name service
error for name=_25._tcp.smtp-relay-in-s1.neusta.de type=TLSA: Host not
found, try again
Postfix uses knot-resolver and I found [1] as a possible similar issue
with unbound.
I would like to test if the issue persists with disabled qname
minimization, but it seems to be no configurale option.
Kind Regards
Bjoern
[1]
http://postfix.1071664.n5.nabble.com/Mail-deferred-TLSA-lookup-error-td1074…
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