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
Hello Knot DNS users!
We would like to inform you about a change in Knot DNS behaviour in
versions 3.0.0 and 3.0.1. These two versions don't allow sharing of TCP
ports between programs, including other knotd instances (SO_REUSEADDR
isn't set). While this behaviour is better from point of view of
security, the downside of it is that when restarting a knotd daemon,
binding to a TCP port may fail after a restart if the restart is
immediate. In such a case, an error is logged and Knot starts its
operation on other configured ports only.
To verify that all TCP ports have been bound successfully after Knot
restart, please always check the log for possible errors. Such errors
would be close to the initial message about Knot DNS starting.
Since there was a complaint about this change, we plan to re-enable TCP
ports reuse in future releases. We also ponder making knotd exit if it
fails to bind to any of configured TCP ports. We would like hear from
you whether such a behaviour is what you, users, want best. Please, let
us know if you prefer this or a different solution.
With regards,
David Vašek
CZ.NIC
