Hi,
We've been running Knot 1.6.3 as a slave server and it's been working well. However, I notice that a "dig" against this slave for a domain does not return an "ADDITIONAL" section, but the same query against another slave that runs BIND does return one. I couldn't find any Knot configuration directive that would control this. Is there something I missed or additional configuration needed elsewhere to make the ADDITIONAL info available?
Thanks,
Chuck
Hello list!
The first release candidate of Knot DNS 2.0 by CZ.NIC Labs is available.
The most significant changes since 2.0.0-beta are related to the server
configuration. We have renamed a few configuration options for the sake of
consistency and intuitiveness. And we have significantly improved the way how
remotes and ACLs are defined.
In prior version, each remote was assigned just one address, which led to
quite long configuration files. The updated version allows specification of
multiple addresses (and multiple TSIG keys), making the configuration file
shorter and more readable.
We have also added a basic support for zone file name patterns. At the moment,
you can use the '%s' pattern in the template/file configuration option and the
pattern will be substituted by a zone name. We would like to add another
patterns in future. Feel free to let us know which patterns you would find
useful.
The 2.0.0-rc1 version also contains all bug fixes and improvements, which are
included in the upcoming 1.6.4 stable release.
And the icing on the cake is Bash and ZSH completion scripts for keymgr.
Please, give the release candidate a try. We are looking forward to your
feedback and bug reports. And as always, thank you for using Knot DNS.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/v2.0.0-rc1/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-2.0.0-rc1.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-dns/knot-2.0.0-rc1.tar.xz.asc
Best Regards,
Jan
--
Jan Včelák, Knot DNS
CZ.NIC Labs https://www.knot-dns.cz
--------------------------------------------
Milešovská 5, 130 00 Praha 3, Czech Republic
WWW: https://labs.nic.czhttps://www.nic.cz
Previously, kdig's write_dnstap() function passed net->srv->ai_protocol
as dt_message_fill()'s 'protocol' parameter, but net->srv->ai_protocol
is not actually guaranteed to be the socket protocol used for the
query/response.
When kdig's process_query_packet() retries over TCP, it only sets
net->socktype to SOCK_STREAM in an already initialized net_t and calls
itself. The addrinfo's in the net_t aren't updated, so they have the
original values from the first invocation of process_query_packet(),
i.e., the lookup that occurred over UDP. However, net->socktype is
actually what controls whether TCP or UDP is ultimately used in
net_connect().
Instead of passing net->srv->ai_protocol to dt_message_fill(), map
net->socktype to an IPPROTO_* value. (Which is what kdig does elsewhere
via get_sockname(), which is why the formatted output written to stdout
at the same time, e.g. "127.0.0.1@53(TCP)" doesn't have a similiar bug.)
---
src/utils/kdig/kdig_exec.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/utils/kdig/kdig_exec.c b/src/utils/kdig/kdig_exec.c
index b91a958..1f6a64d 100644
--- a/src/utils/kdig/kdig_exec.c
+++ b/src/utils/kdig/kdig_exec.c
@@ -44,6 +44,7 @@ static int write_dnstap(dt_writer_t *writer,
Dnstap__Message msg;
Dnstap__Message__Type msg_type;
int ret;
+ int protocol = 0;
if (writer == NULL) {
return KNOT_EOK;
@@ -54,8 +55,14 @@ static int write_dnstap(dt_writer_t *writer,
msg_type = is_response ? DNSTAP__MESSAGE__TYPE__TOOL_RESPONSE
: DNSTAP__MESSAGE__TYPE__TOOL_QUERY;
+ if (net->socktype == SOCK_DGRAM) {
+ protocol = IPPROTO_UDP;
+ } else if (net->socktype == SOCK_STREAM) {
+ protocol = IPPROTO_TCP;
+ }
+
ret = dt_message_fill(&msg, msg_type, net->local_info->ai_addr,
- net->srv->ai_addr, net->srv->ai_protocol,
+ net->srv->ai_addr, protocol,
wire, wire_len, qtime, rtime);
if (ret != KNOT_EOK) {
return ret;
--
2.1.4
Hello list,
anyone can point me to documentation or manual what is right way to update
slaves. What I want to is when I change record X on master that slaves also
pick that change without me manualy have to do this.
My configuration is OK as on initial zone transfers slaves got data/zones
OK.
I tried
knotc reload
knotc flush
knotc refresh
and restarting knotc service.
On all this there was nothing in syslog and slaves are not updating
ty.
--
Amar Ćosić
amar.cosic(a)gmail.com
amar(a)amar.ba
Hello list,
CZ.NIC Labs just released Knot DNS 1.6.3. This patch release contains a few
rather serious bug fixes and some minor improvements. Update is highly
recommended.
When performing our internal benchmarking, we discovered a serious performance
drop for large NSEC-signed zones (not NSEC3). In construction of NSEC proofs
for NXDOMAIN responses, the server got into a loop possibly causing iteration
over all domain names in the zone. The problem was present in Knot DNS since
the beginning of the project. We are sorry for not noticing this earlier.
The new version also handles TCP short-writes properly. Prior to this fix,
sending a response over TCP could fail if the socket send buffer was small
(e.g., in default configuration on FreeBSD). In addition, if the buffers are
too small, we increase their size on server initialization to make fast-path
processing more likely.
We also fixed possible out-of-bound memory accesses revealed by American Fuzzy
Lop fuzzer. One such an access was in the zone parser (long domain names in
zone origin) and two in the packet parser (TSIG with empty RDATA and malformed
NAPTR).
As for the improvements: The zone parser now supports CDS and CDNSKEY RR
types, the documentation now includes default values for TCP config options,
and more detailed message is emitted when a zone reload fails.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/blob/v1.6.3/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.6.3.tar.xzhttps://secure.nic.cz/files/knot-dns/knot-1.6.3.tar.gz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-1.6.3.tar.xz.aschttps://secure.nic.cz/files/knot-dns/knot-1.6.3.tar.gz.asc
Best Regards,
Jan
--
Jan Včelák, Knot DNS
CZ.NIC Labs https://www.knot-dns.cz
--------------------------------------------
Milešovská 5, 130 00 Praha 3, Czech Republic
WWW: https://labs.nic.czhttps://www.nic.cz
Hello everyone!
Today, CZ.NIC Labs releases Knot DNS 2.0.0-beta.
We finally managed to complete, stabilize, and document all new features of
the upcoming Knot DNS version. We are aware of some glitches in this release,
however we think that it is ready to be tested by a wider audience.
There are two key features of Knot DNS 2.0:
# New DNSSEC implementation
I wrote quite a lot about the new DNSSEC in the 1.99.1 release announcement.
Since then, only a few things changed. There was a bug in the ZSK rotation
algorithm. The old DNSKEY was removed too soon possibly breaking the
validation. This problem is resolved now. The keymgr utility has a new manual
page. And the documentation was updated to reflect all changes.
# New configuration format
This change is quite significant for the future development of Knot DNS. And
it will affect everyone using the software.
We decided to switch from a custom configuration format to YAML. Internally,
the configuration is stored in a binary database (LMDB). At the moment, you
won't probably notice anything about the database. However we are working on a
new interface, which will allow making changes into the configuration without
a full server reload. If you have Knot DNS with thousands of zones, you will
benefit this for sure.
We don't support full YAML specification, but there is a certain level of
compatibility. We plan to extend the support so you can generate the config
from your favorite scripting language.
Some configuration options (and configuration sections) were renamed.
We changed the concept how the incoming and outgoing connections are
configured. We split 'remotes' to 'remote' and 'acl'. 'remote' defines target
for outgoing connection (zone transfer source, notification target). And 'acl'
defines rules for accepting connections initiated by a remote client (outgoing
transfer, incoming notification, and incoming update).
At the moment, only one address can be specified for each 'remote' or 'acl'.
In addition, we removed 'groups' as it was complicating the implementation. We
are aware that the current state is not ideal. And we are looking for feedback
and suggestions from the community.
We are not just removing and changing things - we added support for zone
templates, which is something a lot of our users asked for. A template allows
you to configure options shared among multiple zones. A change in the template
affects all zones, which use the template.
To convert the configuration from the 1.6 to the 2.0 format, the knot1to2 tool
is provided. The tool doesn't support conversion for answering modules (e.g.
synth_record), but should handle anything else. Please, review the
configuration after performing the automatic conversion.
That's all, folks! Please, give it a try. Experiment with the new DNSSEC and
play around with the new configuration. And most importantly, let us know what
do you think.
Thank you for using Knot DNS!
Sources:
https://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.tar.xzhttps://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.tar.gz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.tar.xz.aschttps://secure.nic.cz/files/knot-dns/knot-2.0.0-beta.tar.gz.asc
Best Regards,
Jan
--
Jan Včelák, Knot DNS
CZ.NIC Labs https://www.knot-dns.cz
--------------------------------------------
Milešovská 5, 130 00 Praha 3, Czech Republic
WWW: https://labs.nic.czhttps://www.nic.cz
I'm generating my Knot's config from a Jinja2 template, and I'm having a
problem with one thing. For example, if I have a list of elements,
[e1,e2,e3,e4], and I want to generate a "groups" config for these based
on a condition, and I do:
groups {
mygroup {
{% for x in list %}
{% if condition %}
{{ x }},
{% endif %}
{% endfor %}
}
However, this results in a syntax error, because the last element ends
with a comma, and then there's a closing bracket.
I tried to insert the comma conditionally, by checking to see if it was
the last element, but this can also fail if the last element didn't
match the condition.
So I thought about this ugly hack:
groups {
mygroup {
{% for x in list %}
{% if condition %}
,{{ x }}
{% endif %}
{% endfor %}
}
Notice that I have the comma *before* each element. This results in an
opening brace, a comma, and then the other elements. My supposition is
that Knot's syntax parser is okay with this, because it just sees a null
first element. If I check this with knotc's "checkconf", it says the
syntax is okay.
Can I safely use such a config?
Regards,
Anand
Dear Knot developers,
In Knot 1.6.3, is it safe to leave out the "interfaces" section of the
config on a multi-homed server? Will Knot enumerate all the addresses on
the host and bind to them, or will it bind to 0.0.0.0 and ::?
Secondly, if bound to 0.0.0.0 and ::, will Knot use recvmmsg correctly
and set the source address in UDP reply packets to the address the query
was sent to?
Regards,
Anand
Hi,
I am trying to use nsupdate from knot 1.6.1. I have generated key files using dnssec-keygen from BIND 9.9.5. i.e.
dnssec-keygen -a HMAC-MD5 -b 256 -n HOST -C host.example.com
Whenever I try to use the files with nsupdate -k <file> though I get:
; Error: failed to read key file: public key file is invalid
I have also tried without the “-C” to dnssec-keygen.
Are there different flags I need? Or does someone have an example of the file format required?
Thanks,
Andrew
Hi,
I'm looking at knot-1.6.1 after have experienced failure with sending
AXFR after a zone grew due to enabling DNSSEC, adding a lot of records.
I don't know much about iovecs, but isn't this a short write?
--8<---------------cut here---------------start------------->8---
libknot/internal/errcode.h:
enum knot_error {
...
KNOT_ECONNREFUSED = -ECONNREFUSED,
...
KNOT_ERROR_MIN = -1000,
...
KNOT_ERROR = KNOT_ERROR_MIN,
...
KNOT_ECONN,
...
};
libknot/internal/net.c:
int tcp_send_msg(int fd, const uint8_t *msg, size_t msglen)
{
...
int total_len = iov[0].iov_len + iov[1].iov_len;
int sent = writev(fd, iov, 2);
if (sent != total_len) {
return KNOT_ECONN;
}
...
}
knot/server/tcp-handler.c:
tcp_handle()
{
...
while (state & (NS_PROC_FULL|NS_PROC_FAIL)) {
uint16_t tx_len = tx->iov_len;
state = knot_process_out(tx->iov_base, &tx_len, &tcp->query_ctx);
/* If it has response, send it. */
if (tx_len > 0) {
if (tcp_send_msg(fd, tx->iov_base, tx_len) != tx_len) {
ret = KNOT_ECONNREFUSED;
break;
}
}
}
...
}
--8<---------------cut here---------------end--------------->8---
Happy to file a bug report if that's a more proper way of reporting
bugs.
