- knot-resolver-users - lists.nic.cz

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.2.1 has been released! Improvements ------------ - doh2: send Cache-Control header with TTL (#617, !1095) Bugfixes -------- - fix map() command on 32-bit platforms; regressed in 5.2.0 (!1093) - doh2: restrict endpoints to doh and dns-query (#636, !1104) - renumber: map to correct subnet when using multiple rules (!1107) Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.2.1/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.2.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.2.1.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.2.1/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

4 roky

1
0
0 0

Not able to resolve all domains successfully

by Mike Michalakis

I’ve setup knot-resolver and it working for the best part. However, I’ve found that a specific external domain that is important to us isn’t able to resolve successfully. I’m not sure if there might be other domain with the same problem. Any suggestions would be awesome. “MTN.com” [root@localhost ~]# whois mtn.com Domain Name: MTN.COM Registry Domain ID: 63727_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.lexsynergy.com Registrar URL: http://www.lexsynergy.com Updated Date: 2020-01-21T23:41:38Z Creation Date: 1993-02-19T05:00:00Z Registry Expiry Date: 2021-02-20T05:00:00Z Registrar: LEXSYNERGY LIMITED Registrar IANA ID: 1466 Registrar Abuse Contact Email: abuse(a)lexsynergy.com Registrar Abuse Contact Phone: +442031370459 Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Name Server: NS1.IAFRICA.COM Name Server: NS2.IAFRICA.COM DNSSEC: unsigned URL of the ICANN Whois I [root@localhost ~]# dig mtn.com ; <<>> DiG 9.11.13-RedHat-9.11.13-6.el8_2.1 <<>> mtn.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44242 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;mtn.com. IN A ;; Query time: 2810 msec ;; SERVER: 172.24.5.131#53(172.24.5.131) ;; WHEN: Sun Nov 15 06:53:23 EET 2020 ;; MSG SIZE rcvd: 36 [root@localhost ~]# [root@localhost ~]# dig @8.8.8.8 mtn.com ; <<>> DiG 9.11.13-RedHat-9.11.13-6.el8_2.1 <<>> @8.8.8.8 mtn.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21571 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;mtn.com. IN A ;; ANSWER SECTION: mtn.com. 1389 IN A 192.0.66.2 ;; Query time: 64 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sun Nov 15 06:54:18 EET 2020 ;; MSG SIZE rcvd: 52 [root@localhost ~]# Rrds, Mike

4 roky, 1 měsíc

2
1
0 0

Is it possible to use the resolver on more than just Linux?

by Chris

The knot-resolver documentation only appears to support Linux. Any plans to make the resolver available, or useful on systems other than Linux? While I could put Linux in a VM, or BE, and use the resolver from there. It wouldn't really be very effective. Any insight to using this on any of the BSD's would be greatly appreciated (I'm currently using unbound along side knot authoritative). Thanks! --Chris

4 roky, 1 měsíc

2
1
0 0

blacklist.rpz

by Mike Michalakis

Hi, I’ve stumbled across knot-resolver because I have an issue with my current DNS solution. What is the best way to block a large number of domains. I’ve trying to work with the below by it’s not functioning Part of /etc/knot-resolver/kresd.conf -- Domain Blocking policy.add( policy.rpz(policy.DENY_MSG('domain blocked by your IT department'),'/etc/knot-resolver/blacklist.rpz', true)) policy.add ( policy.rpz(policy.DENY, '/etc/knot-resolver/blacklist.rpz')) /etc/knot-resolver/backlist.rpz 007bets.com, Rrds, Mike

4 roky, 1 měsíc

1
1
0 0

blacklist.rpz

by Mike Michalakis

Hi, I’ve stumbled across knot-resolver because I have an issue with my current DNS solution. What is the best way to block a large number of domains. I’ve trying to work with the below by it’s not functioning Part of /etc/knot-resolver/kresd.conf -- Domain Blocking policy.add( policy.rpz(policy.DENY_MSG('domain blocked by your IT department'),'/etc/knot-resolver/blacklist.rpz', true)) policy.add ( policy.rpz(policy.DENY, '/etc/knot-resolver/blacklist.rpz')) /etc/knot-resolver/backlist.rpz 007bets.com, Rrds, Mike

4 roky, 1 měsíc

1
0
0 0

knot-resolver 5.2.0 - metrics issue - map() error while connecting to control socket

by Petr Kyselák

Hello, recently we upgraded from 5.1 to 5.2 few servers (CentOS7 and Raspbian) and all seems to be working fine, but I can see on (yes I know, not recommend and supported) rasbian issue with metrics and in the log I can issue this error: Nov 13 10:21:33 dns-cache-2 kresd[15232]: map() error while connecting to control socket /run/knot-resolver/control/H#003: socket:connect: No such file or directory (ignoring this socket) Nov 13 10:21:33 dns-cache-2 kresd[15232]: map() error while connecting to control socket /run/knot-resolver/control/H: socket:connect: No such file or directory (ignoring this socket) Nov 13 10:21:33 dns-cache-2 kresd[15232]: map() error while connecting to control socket /run/knot-resolver/control/: socket:connect: Connection refused (ignoring this socket) the error is triggered by opening "ip:8453/metrics" and it show almost empty response: # TYPE resolver_latency histogram resolver_latency_count 0.000000 resolver_latency_sum 0.000000 root@dns-cache-2:/# apt -qq list knot* --installed knot-resolver-module-http/unknown,now 5.2.0-1 all [installed] knot-resolver-release/unknown,now 1.7-1 all [installed] knot-resolver/unknown,now 5.2.0-1 armhf [installed] root@dns-cache-2:/# root@dns-cache-2:/# uname -a Linux dns-cache-2 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux Could it be a bug or something related to mix armv7l and armhf? I know of the limitation as we discussed this setup on raspberry some time ago. I just want to share my experience as it can be useful and if you will have any tip I will appreciate it.

4 roky, 1 měsíc

4
6
0 0

Knot Resolver 5.2.0

by Tomas Krizek

Dear Knot Resolver users, Knot Resolver 5.2.0 has been released! One of the notable features is a new DNS-over-HTTTPS implementation which is more scalable and stable than the old one. It also has less dependencies and simpler configuration. Another new feature is experimental eXpress Data Path (XDP) support for UDP. With support from both the network card and the kernel, it can provide superior performance and lower latency for UDP answers. Some of the improvements and bugfixes required a few backward incompatible changes, mainly regarding control sockets or module API. Please refer to our upgrading guide for details: https://knot-resolver.readthedocs.io/en/v5.2.0/upgrading.html#to-5-2 Improvements ------------ - doh2: add native C module for DNS-over-HTTPS (#600, !997) - xdp: add server-side XDP support for higher UDP performance (#533, !1083) - lower default EDNS buffer size to 1232 bytes (#538, #300, !920); see https://dnsflagday.net/2020/ - net: split the EDNS buffer size into upstream and downstream (!1026) - lua-http doh: answer to /dns-query endpoint as well as /doh (!1069) - improve resiliency against UDP fragmentation attacks (disable PMTUD) (!1061) - ta_update: warn if there are differences between statically configured keys and upstream (#251, !1051) - human readable output in interactive mode was improved (!1020) - doc: generate info page (!1079) - packaging: improve sysusers and tmpfiles support (!1080) Bugfixes -------- - avoid an assert() error in stash_rrset() (!1072) - fix emergency cache locking bug introduced in 5.1.3 (!1078) - migrate map() command to control sockets; fix systemd integration (!1000) - fix crash when sending back errors over control socket (!1000) - fix SERVFAIL while processing forwarded CNAME to a sibling zone (#614, !1070) Incompatible changes -------------------- - see upgrading guide: https://knot-resolver.readthedocs.io/en/v5.2.0/upgrading.html#to-5-2 - minor changes in module API - control socket API commands have to be terminated by "\n" - graphite: default prefix now contains instance identifier (!1000) - build: meson >= 0.49 is required (!1082) - planned changes in future versions: https://knot-resolver.readthedocs.io/en/v5.2.0/upgrading.html#upcoming-chan… Full changelog: https://gitlab.nic.cz/knot/knot-resolver/raw/v5.2.0/NEWS Sources: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.2.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-resolver/knot-resolver-5.2.0.tar.xz.asc Documentation: https://knot-resolver.readthedocs.io/en/v5.2.0/ -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869

4 roky, 1 měsíc

1
0
0 0

5.2.0 - release date - fix SERVFAIL in *FORWARD modes with certain CNAME setup

by Petr Kyselák

Hello team, most probably we hit the issue !1070 "fix SERVFAIL in *FORWARD modes with certain CNAME setup" and I would like to ask when we can expect release of knot-resolver 5.2.0 (with the fix) or if there will be "hot fix" in 5.1.x? example of affected domain: www.action.foundation.total Thank you.

4 roky, 2 měsíce

2
2
0 0

[PATCH 0/2] Generate Info manual

by Simon South

These two patches modify Knot Resolver's build process to check for Texinfo utilities during configuration and, if they're found, to build and install documentation in Info format (the standard for GNU distributions such as Guix[0]) as well as HTML. (If the Texinfo utilities aren't found, the build works as before.) The first patch implements these changes and additionally updates the manual to list Texinfo as an optional dependency. The second patch isn't required but genericizes a few references within the manual to documentation in specific formats, in the interest of readability. Note I've left unchanged the "build-html-doc" ref-ID to help ensure external links to the documentation continue to function. [0] https://guix.gnu.org/ ---------- With these patches applied you'll find makeinfo generates a large number of warnings of the form knotresolver.texi:11811: warning: @anchor should not appear in @deffn These warnings are harmless but result from the way Breathe processes C declarations. It generates output with this structure (here for the "kr_request_selected" macro): <desc_signature ids="c.kr_request_selected" is_multiline="True"> <desc_signature_line add_permalink="True" xml:space="preserve"> <target ids="resolve_8h_1a9ba8c6cef807cdf580e3249675a2589c" names="resolve_8h_1a9ba8c6cef807cdf580e3249675a2589c"></target> <desc_name xml:space="preserve">kr_request_selected</desc_name> <desc_parameterlist xml:space="preserve"> <desc_parameter noemph="True" xml:space="preserve"><emphasis>req</emphasis></desc_parameter> </desc_parameterlist> </desc_signature_line> </desc_signature> The issue is the "target" node's being placed within desc_signature_line. I assume this is done for convenience when generating HTML, but it also leads to this Texinfo output: @deffn {Define} @anchor{lib resolve_8h_1a9ba8c6cef807cdf580e3249675a2589c}@anchor{25f}kr_request_selected (req) which is invalid, since (as the warning says) @anchor is not supposed to appear within @deffn. Sphinx's Texinfo writer doesn't account for this, since there's no way (that I can see) for normal ReST input to generate a "target" tag in this position. However it's not clear Breathe is at fault here either, since I can't find anything that defines where target is allowed to appear or which tags desc_signature_line is meant to contain. A straightforward approach to fixing this is implemented by this patch to Sphinx, which causes its Texinfo writer to reorder target nodes embedded within function descriptions: diff --git a/sphinx/writers/texinfo.py b/sphinx/writers/texinfo.py index 5ad2831dd..bd76acdc3 100644 --- a/sphinx/writers/texinfo.py +++ b/sphinx/writers/texinfo.py @@ -1383,6 +1383,11 @@ class TexinfoTranslator(SphinxTranslator): if objtype != 'describe': for id in node.get('ids'): self.add_anchor(id, node) + # embedded anchors need to go in front + for n in node.traverse(nodes.target, include_self=False): + if isinstance(n, nodes.target): + n.walkabout(self) + n.parent.remove(n) # use the full name of the objtype for the category try: domain = self.builder.env.get_domain(node.parent['domain']) However, whether this is the correct approach or if a fix would better be applied to Breathe isn't clear to me. Engaging with the community of either project means signing up for services I'd rather not use, so there's little I can do to carry this forward. Perhaps someone else is interested? --- Simon South simon(a)simonsouth.net Simon South (2): doc: generate Info manual doc: use non-format-specific references to documentation doc/build.rst | 11 +++++++---- doc/meson.build | 7 +++++++ scripts/install-doc-info.sh | 8 ++++++++ scripts/make-doc.sh | 6 ++++++ 4 files changed, 28 insertions(+), 4 deletions(-) create mode 100644 scripts/install-doc-info.sh -- 2.28.0

4 roky, 2 měsíce

2
13
0 0

Unable to resolve some domains

by Balakrishnan Balasubramanian

Hi, I am using knot-resolver with default configuration in arch linux. I am not able to resolve some domains (like costco.ca). It works fine with other resolvers like cloudflare/google. Is there way to debug this? Thanks, Bala

4 roky, 2 měsíce

3
8
0 0

2024

2023

2022

2021

2020

2019

2018

knot-resolver-users