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
