Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Vladimír Čunát
@vcunat:matrix.org
[m]
Instead of kres.type.A you can use 1.
Just as instead of [kres.type.A] you can use [1].
By the way, using the resolve function without any callback passed... is probably not very useful. Except if you want to just trigger the resolution without utilizing it.
(say, to get it into cache or inspect resolution logs)
B. Cook
@bcookatpcsd
 policy.add(match_query_type(policy.DENY_MSG("Blocked AAAA knot-resolver"), 28))
 policy.add(match_query_type(policy.DENY_MSG("Blocked HTTPS knot-resolver"), 65))
got it.. I didn't get it was a full replacement..
git-ed
@ookangzheng

I followed installation tutorial on official site with following command

wget https://secure.nic.cz/files/knot-resolver/knot-resolver-release.deb
dpkg -i knot-resolver-release.deb
apt update
apt install -y knot-resolver

But it install version 3.2.1 instead of latest version, any thought?

kresd -v -V
> Knot Resolver, version 3.2.1

# Linux Header
uname -r
> 5.9.0-5-amd64

cat knot-resolver-latest.list
> deb http://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolver-latest/Debian_Next/ /
Vladimír Čunát
@vcunat
@ookangzheng: which Debian/Ubuntu version is this?
Vladimír Čunát
@vcunat
By the Debian_Next line, your /etc/os-release should indicate Debian 12 (which hasn't been released yet), but there's never been any 3.2.1 for such a new Debian, so it seems really weird to me.
tkrizek
@tkrizek:matrix.org
[m]
I haven't added debian 11 support for knot-resolver-release yet, because the detection is a bit problematic until they officially release it. You can get around that by changing Debian_Next to Debian_11 in knot-resolver-latest.list
tkrizek
@tkrizek:matrix.org
[m]
Seems like debian 11 now ships with the right version, so I added support on our side as well and the installation process above should work for debian 11 now as well. In case you have issues with it, please paste your /etc/os-release file contents so I can investigate further
git-ed
@ookangzheng
Problem solved, cuz I’ve setup unstable branch. apt install -t unstable knot-resolver
jason long
@jlongua
Positive experience with update knot-resolver v5.4.1. Before worker concurrent would increase steadily to ~7k along with memory usage until oom kicked in. Now worker concurrent stays under 750 and kresd memory usage appears stable at 534MB. This is on vps debian 10, serving encrypted-dns, doh2, and dot. Thanks.
1 reply
Vladimír Čunát
@vcunat

does it have forwarding capabilities?

@p3lim yes: https://knot-resolver.readthedocs.io/en/stable/modules-policy.html#forwarding

Adrian L Lange
@p3lim
internal_authorative = '192.168.0.100'
internal_domain = 'example.org'
policy.add(policy.suffix(policy.STUB({internal_authorative}), policy.todnames({internal_domain})))
how do I specify the port for upstream server (internal_authoriative in this example)
Vladimír Čunát
@vcunat:matrix.org
[m]
You can't specify port.
And the target of STUB is assumed to be a resolver (non-authoritative), though I think many practical cases will work even with an authoritative server.
Adrian L Lange
@p3lim
internal_authorative = '192.168.0.100@5353' seems to work
Vladimír Čunát
@vcunat:matrix.org
[m]
Oh, right... I forgot.
It's even in the docs I linked.
Adrian L Lange
@p3lim
now I just need to figure out the rpz format so I can get my sinkhole working, but that's for tomorrow :)
Adrian L Lange
@p3lim
why do the provided systemd units use instances? they have a hard-coded config path, so even starting multiple of them they'll all use the same config and collide
tkrizek
@tkrizek:matrix.org
[m]
kresd are separate processes that don't use threads, so if you want more than 1 process, we use systemd to manage them
it shouldn't be a problem for most configurations, which issue did you run into?
Adrian L Lange
@p3lim
nah it just seems odd to me s'all
ongbh
@ongbh

Hi folks, I keep getting this when I tried to update knot-resolver on Centos 7.9.2009. I noticed that knot-libs.x86_64.3.1.1 actually contain libzscanner.so.4 instead of libzscanner.so.3. But 5.4.1 is asking for libzscanner.so.3 instead. When I was updated from 5.3.6, it works well with knot-libs.3.0.6 that come with libzscanner.so.3.

---> Package knot-libs.x86_64 0:3.1.1-cznic.1.1 will be updated
---> Package knot-libs.x86_64 0:3.1.1-1.el7 will be an update
---> Package knot-resolver.x86_64 0:5.4.1-cznic.1.1 will be updated
---> Package knot-resolver.x86_64 0:5.4.1-1.el7 will be an update
--> Processing Dependency: libknot.so.11()(64bit) for package: knot-resolver-5.4.1-1.el7.x86_64
--> Processing Dependency: libzscanner.so.3()(64bit) for package: knot-resolver-5.4.1-1.el7.x86_64
--> Finished Dependency Resolution
Error: Package: knot-resolver-5.4.1-1.el7.x86_64 (epel)
Requires: libzscanner.so.3()(64bit)
Error: Package: knot-resolver-5.4.1-1.el7.x86_64 (epel)
Requires: libknot.so.11()(64bit)

2 replies
Anthony Pahitas
@pahitas.anthony_gitlab

Hi People,

After updating from 5.3.2 to 5.4.1, I'm no longer getting statistics in the logs.

-- load modules
modules = {
    'view',
    'stats',
    'hints > iterate',
    'http'
}

-- log statistics every minute
local stat_id = event.recurrent(1 * minute, function(evid)
    log(table_print(stats.list()))
end)

-- stop printing statistics after first 10 minutes
event.after(10 * minute, function(evid)
        event.cancel(stat_id)
end)

I don't see anything obviously wrong and there's no changes documented in the upgrade guide.
Any ideas?

Thanks,
Anthony

6 replies
hatramatra
@hatramatra

Hi, I'm trying to generate an answer to a query for SRV record, similarly to the examples for the A record in the documentation. Should anything like that be doable, please?

policy.add(
        policy.suffix(
                policy.ANSWER(
                        { [kres.type.SRV] = { rdata=kres.str2dname('addc1.example.com.'), ttl=20 } }
                ), { todname('_ldap._tcp.dc._msdcs.example.com') }
        )
)

I guess the SRV record is not constructed correctly, as I'm not getting any answer back.

I miss priority, weight and port there I think.
Vladimír Čunát
@vcunat:matrix.org
[m]
Yes, the rdata is more complex than just the name.
kresd doesn't provide any real helper functions to construct rdata for most RR types.
Vladimír Čunát
@vcunat:matrix.org
[m]
There are three two-byte numbers before the name.
Priority, weight and port (in that order), if I look right.
Vladimír Čunát
@vcunat:matrix.org
[m]

I'd probably construct the rdata like

string.char(0, prio, 0, weight, 0, port) .. kres.str2dname('foo')

assuming all the three numbers are less than 256.

hatramatra
@hatramatra
This worked perfectly Vladimír! Thank you very much. Let see if I can figure out how to return several SRV answers for one query on my own. :-)
hatramatra
@hatramatra
policy.add(
        policy.suffix(
                policy.ANSWER({
                        [kres.type.SRV] = { rdata = {
                                string.char(0, 0, 0, 100, 1, 133) .. kres.str2dname('addc1.example.com.'),
                                string.char(0, 0, 0, 100, 1, 133) .. kres.str2dname('addc2.example.com.'),
                        }, ttl=20 }
                }), { todname('_ldap._tcp.dc._msdcs.example.com') }
        )
)
... returns multiple RRs.
hatramatra
@hatramatra
Morning! In the above example, is there any mechanism to return those in round robin fashion? I tried to shuffle the table with RRs, but that obviously gets executed only when rules are installed. Not for every answer.
hatramatra
@hatramatra
reorder_RR() doesn't seem to be doing anything with such answers. Perhaps shuffling entries at startup and running multiple instances get it quite close.
Vladimír Čunát
@vcunat:matrix.org
[m]
Yes, policy actions bypass the usual code-paths, so reordering is not (currently) done in this case; maybe we could change that. That startup approach should work thanks to souce-port randomization on the clients.
For SRV in particular, there's priority and weight defined in the RR, so I wouldn't expect that consumers are affected by the order though.
hatramatra
@hatramatra
Thank you Vladimír. It's not a must at all. More like a curiosity.
Anthony Pahitas
@pahitas.anthony_gitlab

Hi All,

Is there a way to respond to an A request with a CNAME?
I'm trying to figure out if I can create an RPZ to answer with a CNAME?

So far I've only been able to respond with a 'fake' IP:

policy.add(policy.rpz(policy.ANSWER({ [kres.type.CNAME] = { rdata=kres.str2ip('127.0.0.1'), ttl=300 } }), '/etc/knot-resolver/blocklist.rpz'))

From the KR documentation on RPZs, it would appear that fake CNAMEs are not supported.

Thanks, Anthony

Vladimír Čunát
@vcunat:matrix.org
[m]
There's no good way, I think. The main problem is that even if a policy rule generated a CNAME, the answers from policy are final, i.e. the target of the CNAME would not be followed.
5 replies
rooxan33
@rooxan33:matrix.org
[m]
Good evening everyone, I keep getting some query timeouts for various (presumably high latency) Chinese hosts - specifically with DNSPOD (*.dnsv5.com). Any possible solution to this issue? Didn't find any mention of this in the docu, but pardon me if I missed it. Thank you very much.
rooxan33
@rooxan33:matrix.org
[m]
Here is also the debug-level log - https://www.pastebin.cz/en/p/JmfvAyz
Vladimír Čunát
@vcunat:matrix.org
[m]

In your case the servers didn't reply over UDP, and TCP connections also failed (grep _TIMEOUT). The same for some other servers like when looking up pool.ntp.org or some facebook stuff, but not for some other names 🤷

I'd think there was some problem on IP layer, perhaps not close to the kresd machine itself, maybe a temporary issue.

rooxan33
@rooxan33:matrix.org
[m]
Ah I see, I totally haven't noticed the FB stuff. DNSPOD just happened to be the common denominator for two different, geographically separated nodes running practically the same kresd config and not being able to resolve. Is there anything else I can investigate to find out more?
Vladimír Čunát
@vcunat:matrix.org
[m]
If it persists, I'd first investigate IP-layer reachability to those IP addresses, probably ping and traceroute (or mtr) tools. Well if they're not reachable, you could let your ISP find the cause.
rooxan33
@rooxan33:matrix.org
[m]
Thank you, Vladimir. I will try to investigate more. So far I fail to find a viable explanation, ping and traceroute to all listed authoritative nameservers seems fine and I only have this issue on the two nodes in Europe (in separate countries on separate AS) that I'm running. Can't replicate these issues on the US and APAC nodes.