Hello,
we are facing the issue with "Too many transactions" during configuring
knot via knotc - we are using confdb. We are using Python3 worker and
popen function to knotc socket.
This is the log from the Python worker:
[2020-12-07 08:58:13,001] [INFO] adding zone xxxxxxxx
[2020-12-07 08:58:13,016] [ERROR] [event worker.job] Exception in job
'dns.add_zone'
Traceback (most recent call last):
......
ACK Exception: error running command: 'conf-begin'
retcode: 1
out: error: (too many transactions)
Is there any limitation for number of open transactions and are we able
to increase it? Is it possible to see, how many open transactions there
are now?
I can't see any message in the log file, is it possible to log
conf-begin requests? Or are there any other ways, how to determine and
guard the situation?
Many thanks for your help
--
Zdeněk Nový
Linux administrator
ACTIVE 24, s.r.o.
Sokolovská 394/17 186 00 Praha 8
Web: http://www.active24.cz
Hello,
I'm trying to remove the slave node from the master Knot, result code is
0, but no change happen. There is no information in the log file. Can
you please help me, why does it happen?
# knotc conf-get template[default].notify
> template[default].notify = 1 2 3 4 5 6 7 8 9
# knotc conf-begin
> OK
# knotc conf-set -b template[default].notify 1 2 4 5 6 7 8 9
> OK
# knotc conf-diff
(no output)
# knotc conf-get template[default].notify
> template[default].notify = 1 2 3 4 5 6 7 8 9
Thanks for your help.
--
Zdeněk Nový
Linux administrator
ACTIVE 24, s.r.o.
Sokolovská 394/17 186 00 Praha 8
Web: http://www.active24.cz
Hello,
as I plan to migrate an existing DNS setup to Knot, not only for deploying DNSSEC but also for synthesizing some records using mod-synthrecord, I am not sure as how to setup online signing when having multiple public authoritative name servers. My uncertainty is, if it is necessary to give them the same ZSKs and do the key rollover from the outside, or if the chain of trust isn't severed when they generate their own ZSKs based from a common KSK or even their distinct KSKs, and therefore provide different signatures.
Best regards and thanks,
Nils
--
Nils Trampel
GPG: 0x012BADD8
Dear!
We are learning about the Knot DNS to apply to our DNS Authoritative Secondary. However, we are wondering about the query log, i have read the document of DNS Knot Software (Knot DNS Documentation Release 2.9.4/ 8.3 dnstap – Dnstap traffic logging), query log of Knot DNS cannot get directly like BIND9, query log can get by dnstap tool.
For Knot DNS Software, we cannot get log query continuosly and directly to the current syslog server, since raw log need to capture and then read after stop capture.
I wanna to know how to get the query log continously when using Knot DNS or softwares of your DNS and other DNS of organizations have already applied. Can you share with us and help us to deploy Knot DNS to our DNS Authoritative Secondary.
Best Regards,
Vũ Thị Hoàn
=================================================
DNS & VNIX - Trung tâm Internet Việt Nam
Mobile: +84 916 961 631
Email: hoanvt(a)vnnic.vn
Hi,
the doc says that changing the policy algorithm field will trigger an
algorithm rollover. Is there anything else one must consider or is the
algorithm rollover done fully automated like the normal rollovers?
Thanks,
Thomas
Hi,
I need to generate keys of algorithm 7. But I receive this error:
# keymgr example generate algorithm=rsasha1-nsec3-sha1 size=2048 ksk=yes
Unknown algorithm: rsasha1-nsec3-sha1
Error (invalid parameter)
I'm using the latest version of knot. Do I get something wrong here? It
you be supported, right?
Thanks
Thomas
Ahoj,
I've searched through the archives and read documentation+RFCs to
no avail, so I hope you can help out.
I run the authoritative DNS servers for an associative ISP in
Barcelona (eXO.cat), and we are running them in FreeBSD using Knot
DNS (2.9.5, but .6 and .7's changelogs do not point to a similar
issue being solved).
We have since then gotten a few reports from different parties of
"DNS issues", I am reasonably sure to have pinpointed this down to
badly configured DNS resolvers, but our weight is really too tiny
to force any change; and the doubt remains as to whether or not
this is on us. Without access to the resolvers it's also a tad
tricky for us to reproduce.
Things do work beautifully with pretty much all of the internet.
This appears to be related to:
https://tools.ietf.org/html/rfc7873#section-5.2.3
(sometimes in connection with 5.2.4)
Maybe someone with more experience and running at a larger scale
has pointers on this topic.
Specifically, I have observed:
Case A:
1. (Probably Bind) Resolver contacts Knot DNS with Client Cookie
and old Server Cookie
2. Knot DNS responds BADCOOKIE with the provided Client Cookie,
Old Server Cookie, and adds the new server cookie.
3. Resolver contacts Knot DNS with the same Client Cookie and old
Server Cokie
4. 2 and 3 repeat for a long time.
5. Domains end up not resolving.
Case B:
https://github.com/matrix-org/synapse/issues/8581
Their supplier says the DNS server "replies with BADCOOKIE to UDP
queries", as if that were a bad thing; but from reading RFC7873, I
understand that it is expected documented behaviour and the client
ought to try again with the given Server Cookie.
They say: "AIUI the resolver does retry, but again receives a
BADCOOKIE response."
I sadly don't have the tcpdump for those, but it could be just
like case A again.
These are the relevant bits from the config:
server:
rundir: "/var/run/knot"
user: knot:knot
listen: [ 0.0.0.0@53, ::@53 ]
log:
- target: syslog
any: info
statistics:
append: off
database:
storage: "/var/db/knot"
mod-cookies:
- id: default
badcookie-slip: 1
mod-rrl:
- id: default
rate-limit: 200 # Requests per second
template:
- id: default
storage: "/var/db/knot/primary"
semantic-checks: on
disable-any: on
serial-policy: dateserial
file: "%s.zone"
global-module: mod-cookies/default
global-module: mod-rrl/default
global-module: mod-stats
- id: secondary
storage: "/var/db/knot/secondary"
semantic-checks: on
disable-any: on
serial-policy: dateserial
file: "%s.zone"
module: mod-cookies/default
module: mod-rrl/default
module: mod-stats
- id: signed
storage: "/var/db/knot/primary"
dnssec-signing: on
zonefile-load: difference
semantic-checks: on
disable-any: on
serial-policy: dateserial
file: "%s.zone"
module: mod-cookies/default
module: mod-rrl/default
module: mod-stats
We are not using anycast clusters or anything like that.
A quick solution would be to disable cookies or to experiment with
noudp, but that's something we'd like to avoid.
The name servers in question are:
- ns3.exo.cat
- ns4.exo.cat
- ns1.unchat.cat (not association, but identical setup)
All tests I've ran against the servers and the associated domains
(e.g. exo.cat + unchat.cat) appear to be fine.
There is an odd one with https://dnsviz.net/d/unchat.cat/dnssec/,
but other tests like
https://www.zonemaster.net/result/d530cb253298b56c do not report
any issues.
Thank you in advance for any pointers you may have (and for Knot
DNS!),
--
Evilham
Hallo everybody,
this is just a little remark concerning the 'knot' upgrade from 2.9.x to
3.0.x.
The 'update-owner-name' in the 'acl' section of the configuration file
can now be either the FQDN (with trailing dot) or a relative name to the
zone, while it used to be a domain name before (without obligatory dot
at the end). The documentation was updated correctly:
Doc for 2.9:
acl
- id: owner_type_rule
action: update
update-type: [A, AAAA, MX] # Updates are only allowed to update
records of the specified types
update-owner: name # The allowed owners are specified by the list
on the next line
update-owner-name: [a.example.com, b.example.com, c.example.com]
update-owner-match: equal # The owners of records in an update
must be exactly equal to the names in the list
Doc for 3.0:
acl
- id: owner_type_rule
action: update
update-type: [A, AAAA, MX] # Updates are only allowed to update records
of the specified types
update-owner: name # The allowed owners are specified by the list on the
next line
update-owner-name: [a, b.example.com.] # Non-FQDN names are relative to
the effective zone name
update-owner-match: equal # The owners of records in an update must be
exactly equal to the names in the list
However; I did not notice the subtle change and was struggling for a
while to bring the dynamic zone update into a working state again .
Maybe, this saves a little time to someone else.
Regards and thanks for a great piece of software,
Oto Stefan
