Hello,
could you please help me with knot resolver configuration in the case when I
need to redirect each variation for the domain to some address.
e.g.
www.example.com, m.example.com, domain.example.com ...
like wildcard record
*.example.com 10.0.0.50
In my configuration is it handeled by file with static records
-- load static records
hints.add_hosts('/etc/knot-resolver/static_records.txt')
which contains address to be redirected and the domain.
10.0.0.50 1xbet.com
10.0.0.50 thelotter.com
10.0.0.50 webmoneycasino.com
10.0.0.50 betworld.com
10.0.0.50 bosscasino.eu
10.0.0.50 sportingbull.com
But I´m not able to handle the correct syntax for a wildcard domain
redirection.
Best regards,
--
Smil Milan Jeskyňka Kazatel
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.
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
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
Hello,
I'd like to have output of socat commands in my shell script.
Currently, I log in to socat by using, for example:
socat - UNIX-CONNECT:/run/knot-resolver/control/1
There, I can issue cache.stats() and read it.
How can I have output these commands in shell script?
Appreciate your help.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Dear Knot Resolver users,
we would like to inform you about certain changes in upcoming Knot Resolver 5.2.0:
- - Users of Control sockets API need to terminate each command sent to resolver with newline character (ASCII \n). Correct usage: "cache.stats()\n". Newline terminated commands are accepted by all resolver versions >= 1.0.0.
- - Human readable output from Control sockets is not stable and changes from time to time. Users who need machine readable output for scripts should use Lua function "tojson()" to convert Lua values into standard JSON format instead of attempting to parse the human readable output. For example API call "tojson(cache.stats())\n" will return JSON string with "cache.stats()" results represented as dictionary. Function "tojson()" is available in all resolver versions >= 1.0.0.
- - DoH served with http module DNS-over-HTTP (DoH) will be marked as legacy and won’t receive any more bugfixes. A more reliable and scalable DoH module will be available instead. The new DoH module will only support HTTP/2 over TLS.
- - New releases since October 2020 will contain changes for DNS Flag Day 2020. Please double-check your firewall, it has to allow DNS traffic on UDP and also TCP port 53. See https://dnsflagday.net/2020/ for more information.
This text with links to further documentation can be found here:
https://knot-resolver.readthedocs.io/en/latest/upgrading.html#upcoming-chan…
We plan to use the same URL to publish planned changes in not-yet-released versions.
To make our version numbers easier to understand we have documented how we version new releases:
https://knot-resolver.readthedocs.io/en/latest/NEWS.html#version-numbering
Feedback is more than welcome. Do not hesitate to reach out on the usual channels:
https://www.knot-resolver.cz/support/
- --
Petr Špaček @ CZ.NIC
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAl9+9kcACgkQzo3WoaUK
IeR7Jg/5AT4QLP1ZJBR8Vkoa5DirCnTBrBx3GPkiW+hVEXZPl55AXWMu54i9ZTuY
4R38+I1PypAM924n5xk98AaX7iRbISVZ87kOEfeJOKR2tzB8TiYwzufl2Y3PUYo8
IlazzcUyNFcQw4ARE3BqiQF6DLKl/s8U812XMEUlRdryE7lURWVEJyo711XNLPPy
6PWuGpsNboMR2V6z/7yrX/i+/0XGpxoSL8S9Fv4hQrOJB3c0lIZNSfaj23GywDao
ZgkqlxwBgPkOGAhSIq3r5Xqitl9fTh2Gb1565Lrbj+4OY5WbL8YqaNArZMp3poUD
T2QCH1bUypa0EP+smzdcriuFDWwl3L0zwODsnH2ofLAnosWeGfxtHXHI5W7rwskF
gAAZJJe+UhxSeBzwr01r6YwZbDYlHiDA9+AkGkYGjYwQmfLCTftXRhlqmJ3BvpeR
Nr97D8lSuct9XugIN2pUJfR1cVIr40ViiO3TG4m2eL2dHExELB4OOf/ZCOTX5dQk
KJuQSspz5zQvVFWZZh17L6iT9WUdgwmi0TkvR8aMmPlr75vokFvioQMAOHfHgGtq
7s10W9TtRGX5o9ioHtTLrDaqEC/0P79bMTVU5HCap1dSCzgk1AYXtUDu4AVc0pWC
Aui8tih9ykESC8rPUaEBc6wpR3wgKSPclfIWgiJira4xB8eRCUs=
=9lwy
-----END PGP SIGNATURE-----
