Hi,
I've setup knot to AXFR 24 zones from our MS domain controllers but
three zones fail mysteriously. After enabling debug logging
knot adds additional line with the reason - 'trailing data'.
In the pcap file created with tcpdump I see that our server starts to
send TCP resets in the middle of the transfer.
Each time resets are sent after downloading approximately the same
amount of data, this amount differ for each zone (81kb for one, 49kb for
the second).
I am able to download the zone with dig or kdig. We also have a
different server with powerdns which is able to download the zones
without problems.
I've also tried to setup different server (with bind9) serving one of
the zones and have knot to download it from there. It worked just fine.
I can send the log file snippet (with zone name and ip addresses) as
well as the pcap file off the record.
Could you, please, help me with solving this problem?
Thank you,
Petr Baloun
Je dobré vědět, že tento e-mail a přílohy jsou důvěrné. Pokud spolu jednáme o uzavření obchodu, vyhrazujeme si právo naše jednání kdykoli ukončit. Pro fanoušky právní mluvy - vylučujeme tím ustanovení občanského zákoníku o předsmluvní odpovědnosti. Pravidla o tom, kdo u nás a jak vystupuje za společnost a kdo může co a jak podepsat naleznete zde<https://onas.seznam.cz/cz/podpisovy-rad-cz.html>
You should know that this e-mail and its attachments are confidential. If we are negotiating on the conclusion of a transaction, we reserve the right to terminate the negotiations at any time. For fans of legalese—we hereby exclude the provisions of the Civil Code on pre-contractual liability. The rules about who and how may act for the company and what are the signing procedures can be found here<https://onas.seznam.cz/cz/podpisovy-rad-cz.html>.
Hi,
I noticed that when using e.g the GeoIP module to return a CNAME, that
CNAME does not get resolved, even if it is within the instances
authority. That forces the client/recursor to issue another request.
Perusing the code for a while, I noticed that there is a rather simple
way to achieve this: the GeoIP module, if the result is a CNAME, _could_
set `qdata->name` to the CNAME target and return
`KNOT_IN_STATE_FOLLOW` instead of `KNOT_IN_STATE_HIT`.
While that does seem to work, I am not so sure if it might constitute an
abuse of interfaces. Returning `KNOT_IN_STATE_FOLLOW` seems legit, but I
wasn't so sure about modifying `qdata` (specifically, in the context of
a module).
As such, I would be interested if this has ever come up before, what
possible approaches might look like, what you think of the above one,
and if tackling this problem is of interest at all. If I have a better
understanding and there is a good approach to this, I'd be happy to
submit a patch.
Thanks a lot,
Conrad
Hello,
OS: CentOS 7.6
Knot: knot-2.9.3-1.el7.x86_64
I am trying to run knot DNS using maxmind GeoIP and it works well.
Now I also want it to be able to do weighted on those answers.
E.g. If country US, it will provide 3 answers and those will be weighted.
Is that correct and possible?
Thanks
Avinash
Dear KNOT team,
We're now considering an update on our zone signer and KNOT DNS seems to be a good choice.
I looked through your documentation and do not see the performace data about signing big zones.
When the zone has about 10 millions entries , how long will it take for KNOT DNS to sign it completely?
I'll appreciate it if you can give me a feedback.
Best Regards!
Gao
Hi,
I try to use knot 2.9.2 on a Raspiberry Pi 2 with 1Gb of RAM under Arch Linux.
When I enable DNSSec (ecdsap256sha256 algorithm), I got
mars 01 16:09:05 exegol knotd[3438]: error: [aeris.eu.org.] DNSSEC, failed to
initialize (not enough memory)
mars 01 16:09:05 exegol knotd[3438]: error: [aeris.eu.org.] zone event 'load'
failed (not enough memory)
mars 01 16:09:05 exegol knotd[3438]: error: [xxx.eu.org.] DNSSEC, failed to
initialize (not enough memory)
mars 01 16:09:05 exegol knotd[3438]: error: [xxx.eu.org.] zone event 'load'
failed (not enough memory)
mars 01 16:09:05 exegol knotd[3438]: error: [imirhil.fr.] DNSSEC, failed to
initialize (not enough memory)
mars 01 16:09:05 exegol knotd[3438]: error: [imirhil.fr.] zone event 'load'
failed (not enough memory)
Those 3 zones are quite damned small (286, 19 & 16 lines), 2 containing only
minimalistic entries (1 SOA, 2 NS, 3 CAA, 2 CNAME & 1 TLSA).
I try to activate zones one at a time, loading the 16 lines zone is ok but
loading the 19 lines one too generate the same "not enough memory" for both
zones. Loading only the 19 lines zone is ok.
I don't understand how DNSSec requires so many memory to not be able to load
such small zones.
When zones are loaded without DNSSec, knot memory is under 80MB.
How I can trace the memory usage of Knot to understand why this behavior?
Is there any way to restrict Knot memory to be able to load such zones?
Regards,
--
aeris
Individual crypto-terrorist group self-radicalized on the digital Internet
https://imirhil.fr/
Protect your privacy, encrypt your communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/
Hello,
I have a problem with a new, small IPv6 reverse zone
It's a small zone, configured like this :
zone:
- domain: "a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa."
file: "a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa"
notify: "corrin"
acl: "acl_corrin"
dnssec-signing: "off"
module: mod-synthrecord/revovh2
There is data in the journal :
root@arrakeen:/var/lib/knot/external# knotc zone-read
a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa
[a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.]
a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa. 2560 SOA ns.geekwu.org.
hostmaster.a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa. 1580234956 16384
2048 1048576 2560
[a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.]
a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa. 259200 NS ns.geekwu.org.
[a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.]
a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa. 259200 NS ns4.geekwu.org.
[a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.]
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.
3600 PTR imperium.geekwu.org.
[a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.]
2.2.1.0.0.0.0.0.0.0.0.0.1.0.0.0.a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.
3600 PTR git.geekwu.org.
[a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.]
a.2.a.2.0.0.0.0.0.0.0.0.1.0.0.0.a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.
3600 PTR corrin.geekwu.org.
But if I change anything (like adding another host), on knotc reload I
get this error :
knotd[21892]: error: [a.8.1.a.8.0.0.0.0.d.1.4.1.0.0.2.ip6.arpa.] zone
event 'load' failed (malformed data)
I've purged the zone with zone-purge, replaced the zone file with a copy
of the dump, and got a new record on reload, but further edits fails the
same way
I'm using knot 2.9.2-1~cz.nic~buster1 for deb.knot-dns.cz/knot-latest
Do you have an idea on what's going on ?
Thanks,
--
Bastien Durel
Hi all,
I migrated from bind to knot. Everything works fine, except rrl.
I "translated" the bind config
rate-limit {
responses-per-second 5;
window 5;
};
to
mod-rrl:
- id: default
rate-limit: 5
slip: 2 # Every other response slips
template:
- id: default
storage: "/etc/knot/zones"
timer-db: "/var/lib/knot/timers"
semantic-checks: on
global-module: mod-rrl/default
But the limiting doesn't work. I testet with
for i in {1..20}; \
do dig @ns +short +tries=1 +time=1 mydomain.de a; \
done
And got 20 answers quickly.
Any ideas what's wrong here?
(I'm unsing ver 2.7.6 @Debian 10)
Best regards,
Thomas.
Hello,
I'm new to that list. Using NSD + DNSSEC + key rotation for many years.
Now I like to check if and how KNOT's auto keyrotaton can safe me from my ugly script foo...
https://lists.nic.cz/pipermail/knot-dns-users/2019-November/001721.html
JP Mens mention "I'm rolling the KSK every five minutes for testing"
instead I reinvent the wheel: could one post the relevant settings?
Thanks,
Andreas
