Hi
I have problems in v2.0.0 with the serial-policy definition as it is not working as expected.
Here is my knot.conf which I am using:
# knot.conf
server:
user: knot:knot
udp-workers: 1
tcp-workers: 1
background-workers: 1
listen: 0.0.0.0@53
listen: ::@53
log:
- target: syslog
any: debug
template:
- id: default
storage: /opt/knot
semantic-checks: on
dnssec-signing: on
kasp-db: kasp
serial-policy: increment
zone:
- domain: example.com
dnssec-signing: off
2015-08-11T18:27:33 info: configuration is valid
Using increment as serial-policy, first the serial gets incremented by 1. After that, it will stay at 1, nevertheless how many changes I make.
info: [example.com] loaded, serial 0 -> 1
info: [example.com] loaded, serial 1 -> 1
info: [example.com] loaded, serial 1 -> 1
info: [example.com] loaded, serial 1 -> 1
Using unixtime as serial-policy, the serial stays always at 0.
info: [example.com] loaded, serial 0 -> 0
info: [example.com] loaded, serial 0 -> 0
info: [example.com] loaded, serial 0 -> 0
info: [example.com] loaded, serial 0 -> 0
Am I doing it wrong?
Do you use in anyway a RTC? because I do not have it.
Regards
shadice
Has anyone used the rosedb or dnsproxy modules extensively in production?
I'm concerned about whether it would reliably scale as well as Knot does
without it. I'm evaluating knot in hopes that I can use it to offer part of
my would-be service to potentially millions of websites. I'm planning a
free usage tier would would hopefully be heavily utilized.
Regarding the specific implementation, I want to provide an authoritative
DNS server that returns predefined values based on record types/host
(rosedb). If the host/record combo conditions aren't met, proxy the request
to the original nameserver(s). After reviewing the nightly code it looks
like I'll likely need to invest a lot of time in order to support that
chained query plan.
Thank you for any feedback in advance.
-Anonymous Coward
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
