Hi
Knot DNS v2.0.0 reserves up to 620 MB memory on my Raspberry Pi.
But it actually uses only 0.4 % of the available 512 MB memory.
How can I limit the memory reservation/allocation to 100 MB?
Regards
shadice
Hi,
I just upgraded to Knot 2.0 from the PPA repository and noticed that the
script /usr/lib/knot/prepare-environment is still expecting the old
style configuration format and as such is not working with the new YAML
formatted configuration. As a consequence the /run/knot directory is not
chown'ed to the configured user:group and the control socket creation fails.
Cheers,
Antti
Hey all,
if you are using Knot DNS repositories for Debian and/or Ubuntu, the repositories with just 'knot' will start shipping (or already started) shipping Knot DNS 2.0. There will be no Knot DNS 2.0 packages for Debian wheezy, since we don't want to backport that many libraries. If you absolutely have to stay on Debian wheezy, please switch to Knot DNS LTS.
if you want to stay with Knot DNS LTS (1.6.x) replace the part that says /debian or /knot with /knot-lts or /knot-dns with /knot-dns-lts
The full instructions should be soon up on the webpages, but TL;DR for Knot DNS LTS:
Debian:
su -
wget -O - http://deb.knot-dns.cz/knot-lts/apt.key | apt-key add -
rm -f /etc/apt/sources.list.d/knot.list
echo "deb http://deb.knot-dns.cz/knot-lts/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/knot-lts.list
apt-get update
apt-get install knot
Ubuntu:
# remove ppa-purge ppa:cz.nic-labs
sudo add-apt-repository -r ppa:cz.nic-labs/knot-dns
sudo add-apt-repository ppa:cz.nic-labs/knot-dns-lts
sudo apt-get update
sudo apt-get install knot
Cheers,
--
Ondřej Surý -- Chief Science Officer
--------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.sury@nic.cz https://nic.cz/
--------------------------------------------
I'm migration from PowerDNS using AXFR and some of the domains fall on
Section 2.4 having CNAME on top domains.
Is there a way to ignore the warning and receive the query?
An example of troublesome domain transfer:
Jun 30 11:33:40 p-01 knot[2930]: info: [strangedomain.com] AXFR, incoming,
127.0.0.1@53: starting
Jun 30 11:33:40 p-01 knot[2930]: warning: [strangedomain.com] semantic
check, node 'strangedomain.com.' (CNAME, node contains other records than
RRSIG and NSEC/NSEC3)
Jun 30 11:33:40 p-01 knot[2930]: error: [strangedomain.com] AXFR, incoming,
127.0.0.1@53: failed (failed)
Jun 30 11:33:40 p-01 knot[2930]: error: [strangedomain.com] transfer,
failed (no active master)
I'm running on Gentoo compiling Knotd 1.6.4 from source w/ no special flags.
Thanks in advance!
--
[ ]'s
Filipe Cifali Stangler
Sure, but was a silly mistake I made,
Since I was testing on localhost over to another IP on the same machine,
all the queries where going from the Local IP to loopback (even though I
forced on the remotes flag w/ "via").
So all I had to do was actually serve everything through loopback (only
different ports) to make things work.
The debug showed the incoming query via *127.0.0.1
<http://127.0.0.1>:<randomport>*
The wrong setup I made was:
Knotd listening on 192.168.0.1:53;
PowerDNS listening on 127.0.0.1:53;
PowerDNS couldn't talk to Knotd there, so I changed to:
Knotd listening on 127.0.0.1:*53*;
PowerDNS listening on 127.0.0.1:*54*;
And then they started talking AXFR properly
Since this is only a test setup to a larger scale migration I was just
testing how AXFR performs w/ tons of data to load (250mb of zone files) and
frequent updates that I was running in the same virtual machine.
BTW, is a good practice to use the zones over tmpfs or since the knotd
already throw everything at RAM on the runtime I don't need it?
I didn't liked the load times (but I do understand the existence of knotc
and why I should not keep "restarting" knotd).
On Tue, Jul 7, 2015 at 4:34 PM, Ondřej Surý <ondrej.sury(a)nic.cz> wrote:
> Hi Filipe,
>
> could you share your findings? We would like to know what was the solution
> if another user happens to have the same problem.
>
> Feel free to share them in private if you don't want to do that publicly.
>
> Cheers,
> --
> Ondřej Surý -- Chief Science Officer
> --------------------------------------------
> CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
> Milesovska 5, 130 00 Praha 3, Czech Republic
> mailto:ondrej.sury@nic.cz https://nic.cz/
> --------------------------------------------
>
> ------------------------------
>
> *From: *"Filipe Cifali" <cifali.filipe(a)gmail.com>
> *To: *"Ondřej Surý" <ondrej.sury(a)nic.cz>
> *Cc: *knot-dns-users(a)lists.nic.cz
> *Sent: *Tuesday, July 7, 2015 9:26:03 PM
>
> *Subject: *Re: [knot-dns-users] AXFR - RFC1912
>
> Oh I made it work after debugging enough I could get the info needed.
> Without debug is very hard to understand why AXFR fails, it only returns
> "connection refused".
>
> Thanks for the attention anyway :)
>
> On Tue, Jul 7, 2015 at 3:10 PM, Ondřej Surý <ondrej.sury(a)nic.cz> wrote:
>
>> Also what does the Knot DNS logs say at debug level?
>>
>> We definitely have a user with similar setup (I'm Bccing him, so he can
>> respond at his will) - PowerDNS as a primary and Knot DNS as a secondary.
>>
>> If you are into a deeper debugging, could you capture the packets between
>> Knot secondary and PowerDNS primary?
>>
>> Cheers,
>> Ondrej
>> --
>> Ondřej Surý -- Chief Science Officer
>> --------------------------------------------
>> CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
>> Milesovska 5, 130 00 Praha 3, Czech Republic
>> mailto:ondrej.sury@nic.cz https://nic.cz/
>> --------------------------------------------
>>
>> ------------------------------
>>
>> *From: *"Filipe Cifali" <cifali.filipe(a)gmail.com>
>> *Cc: *knot-dns-users(a)lists.nic.cz
>> *Sent: *Tuesday, July 7, 2015 5:41:17 PM
>> *Subject: *Re: [knot-dns-users] AXFR - RFC1912
>>
>> Yes, w/ aa flag and all the SOA record
>>
>>
>> On Tue, Jul 7, 2015 at 12:12 PM, Jan Včelák <jan.vcelak(a)nic.cz> wrote:
>>
>>> Hello Filipe,
>>>
>>> does the PowerDNS server respond to SOA queries over TCP?
>>>
>>> $ dig +tcp @127.0.0.1 zone.name SOA
>>>
>>> Cheers,
>>>
>>> Jan
>>>
>>> On Tuesday, July 07, 2015 11:59:00 AM Filipe Cifali wrote:
>>> > Thanks, I finished fixing all the zones now, finally.
>>> >
>>> > Anyone has ever used PowerDNS as master of a Knotd slave? I'm missing
>>> > something since PowerDNS returns connection refused after the initial
>>> > transfer, like it's not responding correctly to PowerDNS.
>>> >
>>> > Since I can dig AXFR @127.0.0.1 (which has PowerDNS running) I don't
>>> see
>>> > how he can be wrong.
>>> >
>>> > I'm not sure where to go looking for the problem here.
>>> >
>>> > Best Regards,
>>> >
>>> > [ ]'s
>>> >
>>> > On Thu, Jul 2, 2015 at 8:49 AM, Jan Včelák <jan.vcelak(a)nic.cz> wrote:
>>> > > Hello Filipe,
>>> > >
>>> > > On Thursday, July 02, 2015 07:57:46 AM Filipe Cifali wrote:
>>> > > > it's only failing for the zones w/ problems w/ CNAMEs, ignoring the
>>> > > > semantic-check off on the config.
>>> > >
>>> > > I have just taken a look to make sure: This particular check is
>>> mandatory
>>> > > and
>>> > > cannot be disabled. And I'm quite sure I want to keep it that way.
>>> The
>>> > > CNAME
>>> > > in apex is not allowed. And we would have to define some behavior
>>> how to
>>> > > answer when this happens, which makes a little sense.
>>> > >
>>> > > You should rather urge your clients to fix their zones because this
>>> > > problem
>>> > > can lead to random resolution failures.
>>> > >
>>> > > Cheers,
>>> > >
>>> > > Jan
>>> > > _______________________________________________
>>> > > knot-dns-users mailing list
>>> > > knot-dns-users(a)lists.nic.cz
>>> > > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
>>>
>>> _______________________________________________
>>> knot-dns-users mailing list
>>> knot-dns-users(a)lists.nic.cz
>>> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
>>>
>>
>>
>>
>> --
>> [ ]'s
>>
>> Filipe Cifali Stangler
>>
>> _______________________________________________
>> knot-dns-users mailing list
>> knot-dns-users(a)lists.nic.cz
>> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
>>
>>
>
>
> --
> [ ]'s
>
> Filipe Cifali Stangler
>
>
--
[ ]'s
Filipe Cifali Stangler
Hello everyone!
CZ.NIC Labs just released a final version of Knot DNS 2.0.
There are only a few changes since the release candidate. The synchronization
of zone file can be now disabled; knsupdate was improved to accept TSIG
algorithm in interactive mode; and some small bugs have been resolved.
I believe you are tuned to this channel and it makes a little sense to repeat
all the new features we put into 2.0 in details. Just to sum up the most
important things:
- Knot DNS 2.0 uses new configuration format based on YAML. The new format
adds zone templates, improves remotes and ACLs specification, and in general
makes the configuration more readable. You can convert your existing 1.6
configuration using the knot1to2 utility.
- We have a new DNSSEC backend. It is based on GnuTLS instead of OpenSSL. And
it contains basic support for KASP (Key And Signature Policy). At the
moment, it can generate initial zone signing keys and perform automatic ZSK
rollover.
For more details, please, take a look at the full change log, previous
release e-mails, documentation, or just ask.
We are looking forward to your feedback, feature requests, and even bug
reports. And thank you for using Knot DNS.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/v2.0.0/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-2.0.0.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-dns/knot-2.0.0.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
Hello everyone!
On behalf of CZ.NIC Labs, I would like to announce Knot DNS 1.6.4. The patch
release contains a bunch of non-critical bug fixes and a few improvements. The
update is recommended but not necessary.
Lots of changes are related to zone transfers. We resolved a problem where an
incoming NOTIFY message was lost during ongoing transfer of the same zone. The
AA flag in AXFR/IXFR queries is no longer set as recommended by the RFC. And
in multi-master environment, if a master server is not available then the
other master servers are tried immediately without waiting a SOA retry time.
The kdig utility was also updated. A new '+generic' option causes printing of
all resource records as if they were unknown records (according to RFC 3597).
The '+noall' option now hides the TSIG section. And the Dnstap SocketProtocol
is logged correctly if there is a failover from UDP to TCP.
The zone parsing and dumping was improved as well. The zone parser can now
read TXT/SPF strings longer than 255 characters which are automatically
chopped into multiple strings. And the zone dumps will no longer print class
name with the SOA record, which unifies the behavior across all resource
record types, making the text processing of a zone file easier.
Last but not least, we have resolved two build issues: Knot DNS can be now
compiled against LibreSSL instead of OpenSSL without patching. And fast zone
parser is forcibly disabled when compiling with Clang (this is a workaround
for a bug in Clang optimizer which emits invalid code for the scanner).
Thank you for attention. You can grab the sources as usual.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/1.6/NEWS
Source archives:
https://secure.nic.cz/files/knot-dns/knot-1.6.4.tar.xzhttps://secure.nic.cz/files/knot-dns/knot-1.6.4.tar.gz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-1.6.4.tar.xz.aschttps://secure.nic.cz/files/knot-dns/knot-1.6.4.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
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
