- knot-dns-users - lists.nic.cz

by Daniel Stirnimann

Hello I've built knot 2.0.0 and created a rpm for redhat 7 and have a problem with the knot.service systemd file. I've used the rpm SPECS and knot.conf, knot.service file from the src rpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=670057 and adapted the SPECS file slightly to get it working on redhat 7. The knot.service file has the following Service section: [Service] Type=notify ExecStart=/usr/sbin/knotd ExecReload=/usr/sbin/knotc reload Restart=on-abort ExecStartPre=/usr/sbin/knotc checkconf If I use the type "notify" and start the service (systemctl start knot) the command does not complete but stays in the foreground. After a few seconds, minutes systemd gets a timeout and terminates the service: systemd: knot.service operation timed out. Terminating. knot[32446]: info: stopping server knot[32446]: info: shutting down systemd: Failed to start Knot DNS server daemon. systemd: Unit knot.service entered failed state. I now changed the knot.service file to use type "simple" [1] and that works and resolves the problem. However, I believe to have read that type "notify" should work. Is this a bug? Daniel [1] http://www.freedesktop.org/software/systemd/man/systemd.service.html

10 let, 9 měsíců

2
2
0 0

Problems with serial-policy

by shadice＠arcor.de

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

10 let, 9 měsíců

2
1
0 0

RoseDB & DNSProxy performance in production

by iorecvsendclose

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

10 let, 9 měsíců

2
1
0 0

Reduce memory usage

by shadice＠arcor.de

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

10 let, 9 měsíců

2
1
0 0

prepare-environment

by Antti Ristimäki

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

10 let, 9 měsíců

2
1
0 0

Changes in Knot DNS repositories for Debian and Ubuntu

by Ondřej Surý

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/ --------------------------------------------

10 let, 10 měsíců

3
4
0 0

AXFR - RFC1912

by Filipe Cifali

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

10 let, 10 měsíců

5
13
0 0

Re: [knot-dns-users] AXFR - RFC1912

by Filipe Cifali

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

10 let, 10 měsíců

1
0
0 0

Knot DNS 2.0.0 (final release)

by Jan Včelák

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.cz https://www.nic.cz

10 let, 10 měsíců

7
15
0 0

Knot DNS 1.6.4 patch release

by Jan Včelák

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.xz https://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.asc https://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.cz https://www.nic.cz

10 let, 11 měsíců

1
0
0 0

Additional section

by Charles Musser

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

10 let, 11 měsíců

2
3
0 0

Knot DNS 2.0.0-rc1 (release candidate)

by Jan Včelák

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.cz https://www.nic.cz

10 let, 11 měsíců

1
0
0 0

[PATCH] kdig: Record the dnstap SocketProtocol correctly when retrying over TCP

by Robert Edmonds

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

10 let, 11 měsíců

2
1
0 0

Updating slaves

by Amar Cosic

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

11 let

3
3
0 0

Knot DNS 1.6.3 patch release

by Jan Včelák

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.xz https://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.asc https://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.cz https://www.nic.cz

11 let

3
2
0 0

Knot DNS 2.0.0-beta release

by Jan Včelák

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.xz https://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.asc https://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.cz https://www.nic.cz

11 let

2
3
0 0

Work-around for Knot's configuration syntax

by Anand Buddhdev

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

11 let, 1 měsíc

4
4
0 0

Use of recvmmsg in Knot

by Anand Buddhdev

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

11 let, 1 měsíc

2
1
0 0

key file format for nsupdate

by Andrew Stevenson

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

11 let, 2 měsíce

2
2
0 0

Short write?

by Linus Nordberg

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.

11 let, 2 měsíce

2
1
0 0

[PATCH] Add "forced generic" dump style, and kdig +generic option

by Robert Edmonds

This patch adds a new "forced generic" dump style which dumps resource record types and data in the generic RFC 3597 representation format, even for known resource record types. A corresponding +generic option to kdig enables this dump style. Generic representation format is very handy when dealing with older DNS software that may not support a new resource record type, or with systems where it is more convenient to use the generic format even with known types. It is also a nice debugging / educational feature. (No need to fire up Wireshark.) --- man/kdig.1.in | 3 +++ src/libknot/rrset-dump.c | 10 +++++++++- src/libknot/rrset-dump.h | 2 ++ src/utils/kdig/kdig_params.c | 13 +++++++++++++ 4 files changed, 27 insertions(+), 1 deletion(-) diff --git a/man/kdig.1.in b/man/kdig.1.in index 4772e27..b6f2286 100644 --- a/man/kdig.1.in +++ b/man/kdig.1.in @@ -178,6 +178,9 @@ Use EDNS version (default is 0). Disable IDN transformation to ASCII and vice versa. IDNA2003 support depends on libidn availability during project building! .TP +.BR +generic +Use the generic representation format when printing resource record types and data. +.TP .BI +client= SUBN Set EDNS client subnet SUBN=IP/prefix. .TP diff --git a/src/libknot/rrset-dump.c b/src/libknot/rrset-dump.c index dd4625d..2f503c1 100644 --- a/src/libknot/rrset-dump.c +++ b/src/libknot/rrset-dump.c @@ -1774,6 +1774,10 @@ int knot_rrset_txt_dump_data(const knot_rrset_t *rrset, return ret; } + if (style->generic) { + return dump_unknown(&p); + } + switch (rrset->type) { case KNOT_RRTYPE_A: ret = dump_a(&p); @@ -1941,7 +1945,11 @@ int knot_rrset_txt_dump_header(const knot_rrset_t *rrset, } // Dump rrset type. - if (knot_rrtype_to_string(rrset->type, buf, sizeof(buf)) < 0) { + if (style->generic) { + if (snprintf(buf, sizeof(buf), "TYPE%u", rrset->type) < 0) { + return KNOT_ESPACE; + } + } else if (knot_rrtype_to_string(rrset->type, buf, sizeof(buf)) < 0) { return KNOT_ESPACE; } if (rrset->rrs.rr_count > 0) { diff --git a/src/libknot/rrset-dump.h b/src/libknot/rrset-dump.h index 4519159..e44cca3 100644 --- a/src/libknot/rrset-dump.h +++ b/src/libknot/rrset-dump.h @@ -46,6 +46,8 @@ typedef struct { bool human_ttl; /*!< Format timestamp as YYYYMMDDHHmmSS. */ bool human_tmstamp; + /*!< Force generic data representation. */ + bool generic; /*!< ASCII string to IDN string transformation callback. */ void (*ascii_to_idn)(char **name); } knot_dump_style_t; diff --git a/src/utils/kdig/kdig_params.c b/src/utils/kdig/kdig_params.c index ec7ec9f..6fafb22 100644 --- a/src/utils/kdig/kdig_params.c +++ b/src/utils/kdig/kdig_params.c @@ -54,6 +54,7 @@ static const style_t DEFAULT_STYLE_DIG = { .empty_ttl = false, .human_ttl = false, .human_tmstamp = true, + .generic = false, .ascii_to_idn = name_to_idn }, .show_query = false, @@ -551,6 +552,15 @@ static int opt_noidn(const char *arg, void *query) return KNOT_EOK; } +static int opt_generic(const char *arg, void *query) +{ + query_t *q = query; + + q->style.style.generic = true; + + return KNOT_EOK; +} + static int opt_nsid(const char *arg, void *query) { query_t *q = query; @@ -805,6 +815,8 @@ static const param_t kdig_opts2[] = { /* "idn" doesn't work since it must be called before query creation. */ { "noidn", ARG_NONE, opt_noidn }, + { "generic", ARG_NONE, opt_generic }, + { "client", ARG_REQUIRED, opt_client }, { "time", ARG_REQUIRED, opt_time }, @@ -1363,6 +1375,7 @@ static void kdig_help(void) " +[no]nsid Request NSID.\n" " +[no]edns=N Use EDNS (=version).\n" " +noidn Disable IDN transformation.\n" + " +generic Use generic representation format.\n" " +client=SUBN Set EDNS client subnet IP/prefix.\n" " +time=T Set wait for reply interval in seconds.\n" " +retry=N Set number of retries.\n" -- 2.1.4

11 let, 2 měsíce

2
1
0 0

Statistics

by Julian Brost

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, does Knot have a feature like "rndc stats" in BIND or "nsd-control stats" that allows you to get some statistics about how many queries were handled and what their result were (like SERVFAIL etc.)? Julian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU8zytAAoJECLcYT6QIdBtLg8P/2wF5gwHQigZ5dI5S2pztM0C ryKAV5h6mqSuO91S+qA7IAP3GpAlzs5GrNYW9kGXspo+w9mwb/D5+mNhDSOGyoW9 iItT16TATzwpNK89Gw2uRhVJ2BhYTuQTmrp3WwAYHAe6wYGOQdBtZoel5UzSrm5e I//3DFgmpGHSwITRcxOBl2MYhRpHEhiBQdUjk2MmTcy/L3GF1HMlY2oHuy4sFZk+ lL6x9N/NX/6K5OspF8p8eoNQ7LIBIA6OKNhz08SdsAKSe1F76pL+FPnb8iQUC6Ao EXkdeFftxOxocL+TTSpAhqEF86IXvRsiNSic8wjYXt9blsMcOAJQFNgU25Bs5+IV u8EtZgcusq5SbHD0Dp5wYkNV4BYYmjU2omzjxMtqV4MFZG9V8XFlXbfVwC64fsUe YfYjvK071EK2hVHTrui637tnS8uEcTJa0X8lpCEgYsy+6/EGyQ3H/8eyu77jZT57 yeZnfG4Ai/QrgS6w3jEu3+uk+kwds2wYHqHbIIw3o0GQ8awQ0kPC6tKg0dXI7aFN tlYBM0mycQv3hFSk7x6jxJ1UPWVxdIOrNg8Vgg8FsgWnXu+JHJJxEV7uoj5DogTJ PaSFOQccTrVoa1vwJgiHLmOALdY/5FDb9cddN1GBgj2wqcUkS/hR8tSRNXkLShhX BTijrkJTR8qeiEEFgthp =bPR2 -----END PGP SIGNATURE-----

11 let, 2 měsíce

2
1
0 0

Knot DNS 1.6.2 patch release

by Jan Včelák

Hello everyone, on behalf of CZ.NIC Labs, I would like to announce Knot DNS 1.6.2. The patch release contains one new feature and a few small bug fixes. With the new version, a number of concurrent TCP clients connected to the server can be limited. The limit is set using the 'max-tcp-clients' configuration option in the 'system' section. Purpose of this setting is to avoid resource exhaustion when the server is under a load. And the default value for the option is 100. When the limit is hit, new connections are not being accepted for a few seconds. Active connections are not affected. Please note, that we have also slightly lowered defaults for TCP idling timeouts. As for the bug fixes: A possible file descriptor leak when terminating inactive TCP clients was fixed. Scheduled events for zones switched from slave mode to master mode are handled correctly. And compilation of Dnstap features on FreeBSD works now. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.6.2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.2.tar.gz.asc Thank you for using Knot DNS. 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.cz https://www.nic.cz

11 let, 2 měsíce

2
2
0 0

Knot DNS 1.99.1 (preview of DNSSEC with KASP)

by Jan Včelák

Hello everyone! After months of keeping our secrets, we would like to share with you a preview of a new DNSSEC implementation in Knot DNS. The new DNSSEC will be one of the key features for the upcoming Knot DNS 2.0. If you are watching our source repository, you may have noticed a tag v1.99.0 appearing silently at the end of 2014. At that time, Knot DNS was already using the newly implemented DNSSEC, but the only visible change was a different key format. And internally, GnuTLS/Nettle was replaced OpenSSL for cryptographic operations. Today, CZ.NIC Labs releases Knot DNS 1.99.1. The next step towards the 2.0. Knot DNS 1.99.1 adds initial support for DNSSEC KASP (Key And Signature Policy). This is our vision of real-world DNSSEC deployment. Essentially, you define a policy (used algorithm, key sizes, key lifetime, signature lifetime, etc.) and the server will do the heavy lifting. It will generate keys and publish/roll them correctly, so you don't have to compute and set timing meta-data on private keys manually. At the moment, the KASP support is quite limited: Single algorithm, single KSK, and single ZSK can be specified in the policy. The server is able to generate initial keys and perform ZSK rollovers (key pre-publish method). More features are coming soon. A documentation on KASP [1] is currently available on the project wiki, including the reference manual for a new management utility keymgr [2]. [1] https://gitlab.labs.nic.cz/labs/knot/wikis/kasp-setup [2] https://gitlab.labs.nic.cz/labs/knot/wikis/kasp-keymgr-reference Source archives are available as usual: https://secure.nic.cz/files/knot-dns/knot-1.99.1.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.99.1.tar.gz Please note, that Knot DNS 1.99.1 is not ready to replace Knot DNS 1.6.x. We are looking forward to hear some feedback from you. And we are happy to answer all your questions and concerns. 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.cz https://www.nic.cz

11 let, 2 měsíce

5
14
0 0

DNSSEC and slave zones?

by Jan-Piet Mens

Good evening, I don't seem to be able to configure Knot 1.6.1 to sign a zone it slaves in: example.com { file "/usr/local/etc/knot/aa/example.com.zone"; xfr-in home; dnssec-keydir "/usr/local/etc/knot/aa"; dnssec-enable on; } If I omit the two 'dnssec-*' parameters, the zone is slaved in. Adding them, however, results in no transfer; log shows: notice: [example.com] automatic DNSSEC signing enabled, disabling incoming XFRs Is it currently possible with Knot to sign a slaved zone? Regards, -JP

11 let, 3 měsíce

2
1
0 0

Re: [knot-dns-users] Converting from PowerDNS to KnotDNS on Active Realtime AnyCast DNS Network

by Leo

Hi, > How would one go about converting from PowerDNS to KnotDNS on an active > realtime AnyCast DNS network with maximum seamless efficiency or minimal temporary > disruption of services to existing DNS users? > If it's truly anycast it should only be easier, I would simply: - stop announcing the anycasted prefix at node #1 - once you see no queries anymore: convert and test - after finishing: switch on routing - repeat untill node #last Unless you have bizarre performance complications, above would be more safe than converting an active node. Did I maybe misunderstand the question? Or did you mean: "how to convert from pdns with a transactional SQL backend to a conventional DNS setup with Knot" ..? Leo

11 let, 3 měsíce

1
0
0 0

Knot DNS and IN NS records

by Eugene Bolshakoff

Hello All, I've decided to use Knot DNS as secondary nameserver for my local zone. I have several subnets connected via VPN and they have their own nameservers. So, there are records in my zone zu-gw.vpn.mithril. 3600 IN A 172.19.0.6 zu.mithril. 3600 IN NS zu-gw.vpn.mithril. and I want to resolve domain in zu.mithril: BIND (master): # dig @tessa.mithril melissa.zu.mithril ; <<>> DiG 9.8.3-P4 <<>> @tessa.mithril melissa.zu.mithril ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7626 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;melissa.zu.mithril. IN A ;; ANSWER SECTION: melissa.zu.mithril. 0 IN A 172.19.3.1 ;; AUTHORITY SECTION: zu.mithril. 3600 IN NS zu-gw.vpn.mithril. ;; ADDITIONAL SECTION: zu-gw.vpn.mithril. 3600 IN A 172.19.0.6 ;; Query time: 143 msec ;; SERVER: 172.19.37.1#53(172.19.37.1) ;; WHEN: Wed Jan 14 19:24:27 2015 ;; MSG SIZE rcvd: 92 KNOT (secondary): # dig @mira.mithril melissa.zu.mithril ; <<>> DiG 9.8.3-P4 <<>> @mira.mithril melissa.zu.mithril ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10182 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;melissa.zu.mithril. IN A ;; AUTHORITY SECTION: zu.mithril. 3600 IN NS zu-gw.vpn.mithril. ;; ADDITIONAL SECTION: zu-gw.vpn.mithril. 3600 IN A 172.19.0.6 ;; Query time: 0 msec ;; SERVER: 172.19.38.2#53(172.19.38.2) ;; WHEN: Wed Jan 14 19:24:51 2015 ;; MSG SIZE rcvd: 76 I understand that it's happening because of recursion in bind, but how can I solve this problem in knot? -- With best regards, Eugene Bolshakoff

11 let, 4 měsíce

2
1
0 0

Converting from PowerDNS to KnotDNS on Active Realtime AnyCast DNS Network

by Ret Law

How would one go about converting from PowerDNS to KnotDNS on an active realtime AnyCast DNS network with maximum seamless efficiency or minimal temporary disruption of services to existing DNS users?

11 let, 4 měsíce

3
2
0 0

Knot DNS v1.6.1 release

by Jan Kadlec

Hello list! Today, CZ.NIC Labs are releasing a new version of Knot DNS. This release introduces a new feature and fixes few bugs. The new feature is a support for Single Type Signing Scheme in automatic DNSSEC implementation. As far as bugfixes are concerned, we've fixed a couple of problems with IXFR/DDNS journal file. Most importantly, it was sometimes not respecting its file size limit (ixfr-fslimit configuration option). We've also fixed incompatibility with OpenSSL 0.9.8. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.6.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.1.tar.xz.asc There are not many changes in this release, but those of your who use IXFR or DDNS should definitely upgrade. Regards and thanks for using Knot DNS, Jan -- Jan Kadlec, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

11 let, 4 měsíce

6
7
0 0

Knot 1.6.1 and journal size tuning

by Anand Buddhdev

Hi Knot developers, I've now installed version 1.6.1 on some servers, and I'm observing some journal related issues, and I have questions about them. First off, here's one issue: 2014-12-15T06:00:56 info: [203.in-addr.arpa] NOTIFY, incoming, 193.0.0.198@53535: received serial 3006121318 2014-12-15T06:00:56 info: [203.in-addr.arpa] refresh, outgoing, 193.0.0.198@53: master has newer serial 3006121317 -> 3006121318 2014-12-15T06:00:56 info: [203.in-addr.arpa] IXFR, incoming, 193.0.0.198@53: starting 2014-12-15T06:00:57 warning: [203.in-addr.arpa] IXFR, incoming, 193.0.0.198@53: failed to write changes to journal (not enough space provided) 2014-12-15T06:00:58 notice: [203.in-addr.arpa] IXFR, incoming, 193.0.0.198@53: fallback to AXFR 2014-12-15T06:00:58 info: [203.in-addr.arpa] AXFR, incoming, 193.0.0.198@53: starting 2014-12-15T06:00:59 info: [203.in-addr.arpa] AXFR, incoming, 193.0.0.198@53: finished, serial 3006121317 -> 3006121318, 0.65 seconds, 171 messages, 7960312 bytes So it looks like the IXFR is too big, and won't fit into the journal, and Knot is falling back to AXFR. When I requested this IXFR by hand, I got: $ dig ixfr=3006121317 203.in-addr.arpa @193.0.0.198 ... ... ;; XFR size: 121779 records (messages 170, bytes 7963389) The size of the IXFR in bytes is below the configured file size limit (10M), but I suspect that 7963389 bytes probably take up more room in the journal, so Knot can't write into it, and is falling back to AXFR. Are you able to tell me (approximately of course), how much disk space is required for a given number of bytes of IXFR? This will help me tune the setting of ixfr-fslimit to avoid this unnecessary fallback to AXFR.

11 let, 5 měsíců

3
2
0 0

Knot 1.6.1 and full journal

by Anand Buddhdev

Hi Knot developers, I have another question about journals. I've noticed that for one zone, the journal size is 9M (with my configured limit at 10M). Now, I see this each time in the logs: 2014-12-15T07:56:02 notice: [103.in-addr.arpa] journal is full, flushing 2014-12-15T08:13:09 notice: [103.in-addr.arpa] journal is full, flushing 2014-12-15T08:16:35 notice: [103.in-addr.arpa] journal is full, flushing 2014-12-15T08:20:27 notice: [103.in-addr.arpa] journal is full, flushing It looks like once a journal is close to the maximum size, then it just remains at that size, with the result that each time an IXFR comes in, and overflows the journal, Knot wants to flush the changes to disk immediately. Does Knot discard old records from the journal at this point? Anand

11 let, 5 měsíců

3
2
0 0

zlib dependency

by Matthias-Christian Ott

Knot DNS depends on zlib to calculate Adler-32 checksums. A comment in crc.h states that it “should be removed”. I want to use knsupdate on OpenWRT and would also like to remove the dependency. Unfortunately, there is no single library that provides only Adler-32 checksums and every examined software either relies on zlib or its bundled implementation of varying quality and speed. Other projects seem to use CRC32C because there is an instruction to calculate it in the SSE4.2 instruction set. But again there is no library that only implements only CRC32C checksums. Switching to CRC32C would also make the journal format incompatible. I'm inclined to just copy the reference implementation from RFC 1950 for my purposes but wanted to check with the upstream maintainers whether there are any plans or ideas. It would also be nice if the configure script would have an option to not include and compile unused functionality from libknot and libzscanner to minimize binaries sizes. - Matthias-Christian

11 let, 5 měsíců

3
4
0 0

failed (connection refused)

by Eric Kom

Good day All, Please I got a connection refused when trying to setup a master and slave on the same network. THIS IS AN EXTRACT FROM MY MASTER KNOT.CONF remotes { masterOnKnot { address 41.134.2.2@53; } slaveOnKnot { address 41.134.2.3@53; } } zones { storage "/var/lib/knot"; metropolitanbuntu.co.za { file "/var/lib/knot/db.metropolitanbuntu.co.za"; xfr-out slaveOnKnot; notify-out slaveOnKnot; } } root@ns1:~# knotc reload OK root@ns1:~# grep knot /var/log/syslog Nov 27 07:10:41 ns1 knotd[469]: error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@50151: failed to start (not allowed) Nov 27 07:10:41 ns1 knotd[469]: 2014-11-27T07:10:41 error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@50151: failed to start (not allowed) Nov 27 08:08:09 ns1 knotd[469]: error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@49111: failed to start (not allowed) Nov 27 08:08:09 ns1 knotd[469]: 2014-11-27T08:08:09 error: [metropolitanbuntu.co.za] IXFR, outgoing, 41.134.194.89@49111: failed to start (not allowed) Nov 27 09:27:33 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 09:27:33 ns1 knotd[469]: info: reloading configuration Nov 27 09:27:34 ns1 knotd[469]: info: configuration reloaded Nov 27 09:27:34 ns1 knotd[469]: info: [metropolitanbuntu.co.za] loaded, serial 2014102701 -> 2014112700 Nov 27 09:27:34 ns1 knotd[469]: warning: [metropolitanbuntu.co.za] NOTIFY, outgoing, 41.134.2.3@53: failed (connection refused) Nov 27 09:29:46 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 09:29:46 ns1 knotd[469]: info: reloading configuration Nov 27 09:29:47 ns1 knotd[469]: info: configuration reloaded Nov 27 10:13:37 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 10:13:37 ns1 knotd[469]: info: reloading configuration Nov 27 10:13:37 ns1 knotd[469]: info: configuration reloaded Nov 27 10:14:15 ns1 knotd[469]: info: remote control, received command 'reload' Nov 27 10:14:15 ns1 knotd[469]: info: reloading configuration Nov 27 10:14:15 ns1 knotd[469]: info: configuration reloaded Nov 27 10:14:15 ns1 knotd[469]: info: [metropolitanbuntu.co.za] loaded, serial 2014112700 -> 2014112701 Nov 27 10:14:15 ns1 knotd[469]: warning: [metropolitanbuntu.co.za] NOTIFY, outgoing, 41.134.2.3@53: failed (connection refused) THIS IS AN EXTRACT FROM MY SLAVE KNOT.CONF remotes { masterOnKnot { address 41.134.2.2@53; } slaveOnKnot { address 41.134.2.3@53; } } zones { # This is a default directory to place slave zone files, journals etc. # default: ${localstatedir}/lib/knot, configured with --with-storage # storage "/var/lib/knot"; # # # Example slave zone metropolitanbuntu.co.za { file "/var/lib/knot/db.metropolitanbuntu.co.za"; xfr-in masterOnKnot; notify-in masterOnKnot; } } root@ns2:~# knotc reload OK root@ns2:~# grep knot /var/log/syslog Nov 27 08:28:15 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@10548: unauthorized request Nov 27 08:28:15 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@13456: unauthorized request Nov 27 08:28:15 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@60566: unauthorized request Nov 27 08:47:30 ns2 knotd[397]: notice: [metropolitanbuntu.co.za] NOTIFY, incoming, 41.134.194.89@54094: unauthorized request Nov 27 09:28:36 ns2 knotd[397]: info: remote control, received command 'reload' Nov 27 09:28:36 ns2 knotd[397]: info: reloading configuration Nov 27 09:28:36 ns2 knotd[397]: info: [metropolitanbuntu.co.za] zone will be bootstrapped, serial 0 Nov 27 09:28:36 ns2 knotd[397]: info: configuration reloaded Nov 27 09:28:36 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:28:36 ns2 knotd[397]: 2014-11-27T09:28:36 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:01 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:01 ns2 knotd[397]: 2014-11-27T09:29:01 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:54 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:29:54 ns2 knotd[397]: 2014-11-27T09:29:54 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:30:02 ns2 knotd[397]: info: remote control, received command 'reload' Nov 27 09:30:02 ns2 knotd[397]: info: reloading configuration Nov 27 09:30:02 ns2 knotd[397]: info: configuration reloaded Nov 27 09:31:49 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:31:49 ns2 knotd[397]: 2014-11-27T09:31:49 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:31:56 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:31:56 ns2 knotd[397]: 2014-11-27T09:31:56 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:32:34 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:32:34 ns2 knotd[397]: 2014-11-27T09:32:34 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:34:15 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:34:15 ns2 knotd[397]: 2014-11-27T09:34:15 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:37:59 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:37:59 ns2 knotd[397]: 2014-11-27T09:37:59 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:45:29 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 09:45:29 ns2 knotd[397]: 2014-11-27T09:45:29 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 10:00:45 ns2 knotd[397]: error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 10:00:45 ns2 knotd[397]: 2014-11-27T10:00:45 error: [metropolitanbuntu.co.za] AXFR, incoming, 41.134.2.2@53: failed (connection refused) Nov 27 10:14:26 ns2 knotd[397]: info: remote control, received command 'reload' Nov 27 10:14:26 ns2 knotd[397]: info: reloading configuration Nov 27 10:14:26 ns2 knotd[397]: info: configuration reloaded -- -- Kind Regards Eric Kom Senior IT Manager - Metropolitan Schools _________________________________________ / You are scrupulously honest, frank, and \ | straightforward. Therefore you have few | \ friends. / ----------------------------------------- \ \ .--. |o_o | |:_/ | // \ \ (| Kom | ) /'\_ _/`\ \___)=(___/ 2 Hennie Van Till, White River, 1240 Tel: 013 750 2255 | Fax: 013 750 0105 | Cell: 078 879 1334 erickom(a)kom.za.net | erickom(a)metropolitancollege.co.za www.kom.za.net | www.kom.za.org | www.erickom.co.za Key fingerprint: 513E E91A C243 3020 8735 09BB 2DBC 5AD7 A9DA 1EF5

11 let, 5 měsíců

3
4
0 0

When will you remove the limitation that a zone be signed by a KSK and ZSK ?

by Olafur Gudmundsson

In your documentation you say: Single-Type Signing Scheme is not supported. I only want to sign with a single key in some cases, i.e. there is no value in having the split as updating my parent is easy. Olafur

11 let, 6 měsíců

2
2
0 0

Rhel 6.3 RPM ?

by Lynch Davis

I am looking around for an rpm deployment since I have a "hardened" box that I wanted to install this on. Was going to try to build my own, but it looks like libucru is not readily available for the this distribution either. help or links? Thanks, Lynch

11 let, 6 měsíců

2
1
0 0

synchronized processing for specific RR Type

by Lynch Davis

Hi - I was reading on the faq about zone events serialization. Has this feature been implemented? I am experimenting with a processing that would require this feature, and if I could simply add a query processor and specify serialization, a majority of my problem (I think) would be solved. I have yet to explore the full feature set of the query_processor to know if this is a correct statement, but I am hopefull. Thanks, Lynch

11 let, 6 měsíců

2
1
0 0

Knot DNS 1.6.0 (final release)

by Jan Včelák

Hello everyone! CZ.NIC Labs proudly presents the final release of Knot DNS 1.6.0. This version also becomes an LTS (Long-term support) version of the Knot DNS software. We added two more bugfixes on top of the features covered by the previous e-mails announcing the release candidates. And as this is the final release, let's highlight the most important changes: The only new feature in Knot 1.6.0 is 'persistent zone timers'. The refresh, expire, and flush zone timers are now stored in file-backed database. Thus, the state of the timers survives a complete restart of the server. (Please note that the feature is optional and requires the LMDB library.) The processing of letter case in RDATA domain names was modified: In most cases, the names are converted to lower-case letters. The exception are RR types, which are treated case-sensitively in DNSSEC. With this change, some Knot DNS internals were simplified and also problems with invalid signatures issued by Knot DNS for mixed-case RR sets should be gone. A few minor bugs in EDNS processing were resolved. And since the -rc2, we fixed forced zone retransfer (knotc refresh -f <zone>), which got broken at some point during 1.5 development. And we also corrected slave zone expiration, when the master is responding to SOA queries but refusing the transfer. We would like to thank Anand Buddhdev for helping us in testing the release candidates and also for reporting the last two bugs. Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.0.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.0.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.0.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.0.tar.xz.asc Best regards, Jan -- Jan Včelák, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

11 let, 6 měsíců

3
4
0 0

How to allow certain hosts to do AXFR?

by Rainer Duffner

Hi, is it possible to allow certain IPs to AXFR all zones? I need this for our helpdesk, so they can send zonefiles to customers etc. I don’t want knot to send ixfrs etc. to these IPs.

11 let, 6 měsíců

3
2
0 0

KNOT zone file

by Eric Kom

Hi all, I'm new on KNOT, and has been running BIND for many years now and would like to set up another master server to serve the domain metropolitanbuntu.co.za on a different network based on Debian and Knot. The Knot-DNS server its running fine: root@ns1:/etc/knot# knotc status OK The metropolitanbuntu.co.za zone was defined in the knot.conf file, just simple definition: zones { # This is a default directory to place slave zone files, journals etc. # default: ${localstatedir}/lib/knot, configured with --with-storage storage "/var/lib/knot"; # # Example master zone # example.com { # file "/etc/knot/example.com.zone"; # xfr-out slave0; # notify-out slave0; # } # # Example slave zone # example.net { # file "/var/lib/knot/example.net.zone # xfr-in master0; # notify-in master0; # } metropolitanbuntu.co.za { file "/var/lib/knot/metropolitanbuntu.co.za.zone"; } } After ran: root@ns1:/etc/knot# knotc -c knot.conf reload OK And checked the Syslog: root@ns1:/etc/knot# grep knot /var/log/syslog Oct 18 09:33:23 ns1 knotd[414]: info: remote control, received command 'refresh' Oct 18 09:33:47 ns1 knotd[414]: info: remote control, received command 'reload' Oct 18 09:33:47 ns1 knotd[414]: info: reloading configuration Oct 18 09:33:47 ns1 knotd[414]: info: [metropolitanbuntu.co.za] zone is up-to-date, serial 0 Oct 18 09:33:47 ns1 knotd[414]: info: configuration reloaded Oct 18 09:42:24 ns1 knotd[414]: info: remote control, received command 'status' Oct 18 09:45:03 ns1 knotd[414]: info: remote control, received command 'reload' Oct 18 09:45:03 ns1 knotd[414]: info: reloading configuration Oct 18 09:45:03 ns1 knotd[414]: info: [metropolitanbuntu.co.za] zone is up-to-date, serial 0 Oct 18 09:45:03 ns1 knotd[414]: info: configuration reloaded The metropolitanbuntu.co.za zone look up to date. My question is: its the zone file looks like the BIND one? do I have to create it, may be I missed the zone declaration in the Knot manual? It is possible to do the master to master replication from BIND to KNOT? Thanks for your support. -- -- Kind Regards Eric Kom Senior IT Manager - Metropolitan Schools _________________________________________ / You are scrupulously honest, frank, and \ | straightforward. Therefore you have few | \ friends. / ----------------------------------------- \ \ .--. |o_o | |:_/ | // \ \ (| Kom | ) /'\_ _/`\ \___)=(___/ 2 Hennie Van Till, White River, 1240 Tel: 013 750 2255 | Fax: 013 750 0105 | Cell: 078 879 1334 erickom(a)kom.za.net | erickom(a)metropolitancollege.co.za www.kom.za.net | www.kom.za.org | www.erickom.co.za Key fingerprint: 513E E91A C243 3020 8735 09BB 2DBC 5AD7 A9DA 1EF5

11 let, 6 měsíců

2
3
0 0

Subject: how to assign multiple addresses for one zone?

by Junyoung Park

Hi! I have a question to configure knot dns for split-dns server. (only master , no slaves) If my router have two interfaces, eth0 (connected with ISP) and eth1 (internal private). About same zone (ex. example.com), i want to responses different ways for eth0, eth1. (ex. eth0, www.example.com -> read /etc/knot/external.example.zone, eth1, www.example.com -> /etc/knot/internal.example.zone) How can i configure it?

11 let, 6 měsíců

5
4
0 0

DNSSEC and Zone files

by dptrash＠arcor.de

I have DNSSEC in knot-dns activated. It always signs my file and it is very difficult to change my zone file with the dnssec stuff inside. Is it possible, to keep the zone file clean and it creates a .signed file for dnssec?

11 let, 7 měsíců

2
1
0 0

Knot DNS 1.6.0-rc2 (release candidate)

by Jan Včelák

Hello list! The second release candidate of Knot DNS 1.6.0 by CZ.NIC Labs is here! The update contains just a few changes, which improve the new persistent slave zones timers feature. The database for the zone timers was being opened before the privileges were dropped and UID/GID changed. As a result, the database could not be reopened after invoking the "knotc reload" command and updated timers could not be written into the database. This problem is resolved now. If you are updating from -rc1, you will need to fix the database ownership to match your knotd user. We also increased the maximal size of the database from 10 MB to 100 MB. This should be enough for thousands of slave zones. And finally, we improved a logging of errors related to database operations. If you have a time to try the new release candidate, please, do so. The final release will probably slip a few days, but it is still scheduled for the next week. Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc2.tar.xz Have a nice weekend! Best regards, Jan, CZ.NIC Labs

11 let, 7 měsíců

1
0
0 0

Knot DNS 1.6.0-rc1 (release candidate)

by Jan Včelák

Hello everyone! Today, CZ.NIC Labs presents the first release candidate of Knot DNS 1.6.0. This comes quite soon after the release of the 1.5.3, which took place about a month ago. For this time, we were really conservative about inclusion of new features. We want to maintain Knot DNS 1.6.0 as a stable version and we intend to provide bug fixes for this release for a longer period of time. The 1.6.0 brings just one new feature - persistent timers for slave zones: The server stores zone expire, refresh, and flush timers in the file-backed database. The timers are written whenever they change and are recovered when the server is started. As a result, the timers will survive a full server restart. The persistent timers feature is an optional feature and depends on the LMDB library. Please, make sure the library is available at the build time and check the output of the 'configure' script, if you want to use this feature. We also modified domain names letter-case handling in RDATA. Previously, we preserved letter case of domain names in RDATA fields. With the 1.6.0, the domain names are converted to lower-case letters, unless the RR type is "new" and should be handled case-sensitively for compatibility with old servers. We believe that this approach is RFC-compliant. The letter case handling modification allowed us to simplify the DNSSEC signing code a little bit and also resolved problems with invalid signatures issued by Knot DNS for some mixed-case RR sets. All the other changes are various small bug fixes. Please, give Knot DNS 1.6.0-rc1 a try and report any troubles you encounter. We are looking forward to your feedback. If everything goes well, we plan to release the final version at the beginning of the next week. Sources: https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.6.0-rc1.tar.xz Best regards, Jan, CZ.NIC Labs

11 let, 7 měsíců

1
0
0 0

Feature requests

by josten＠no-io.net

Hey everyone, I have a production Knot DNS setup; there are two features that I believe would make it even better than what it is now. * Under the zones section a way to just "push" all master zones to slaves; the slaves should just accept any zone from a verified master in the slaves knot.conf. * The ability to just load zones from disk without explicitly stating the zone in knot.conf. For example in /var/lib/knot/example.com.zone; Knot DNS automatically loads the example.com.zone without it being identified in the knot.conf under the zone section. Of course it should do checks (like it does now) before loading the zone, and then gracefully fail and log to the logging mechanism. Other than that; awesome DNS server!

11 let, 7 měsíců

2
1
0 0

[PATCH] dnstap: Fix ProtobufCBufferSimple usage that is incorrect as of protobuf-c 1.0.0

by Robert Edmonds

protobuf-c 1.0.0 added a new 'allocator' field to ProtobufCBufferSimple that controls memory allocation, which must be NULL in order to request the default system allocator. Allocating ProtobufCBufferSimple objects on the stack without zeroing the entire object can result in protobuf-c's memory allocation functions dereferencing a garbage pointer. Note that the use of the zero initializer in this instance generates a warning on some gcc versions: dnstap.c: In function 'dt_pack': dnstap.c:26:2: warning: missing braces around initializer [-Wmissing-braces] ProtobufCBufferSimple sbuf = {0}; ^ dnstap.c:26:2: warning: (near initialization for 'sbuf.base') [-Wmissing-braces] This warning is spurious and was fixed recently: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=211289 --- src/dnstap/dnstap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/dnstap/dnstap.c b/src/dnstap/dnstap.c index 41d42e7..cf3770c 100644 --- a/src/dnstap/dnstap.c +++ b/src/dnstap/dnstap.c @@ -23,7 +23,7 @@ uint8_t* dt_pack(const Dnstap__Dnstap *d, uint8_t **buf, size_t *sz) { - ProtobufCBufferSimple sbuf; + ProtobufCBufferSimple sbuf = {0}; sbuf.base.append = protobuf_c_buffer_simple_append; sbuf.len = 0; -- 2.0.0

11 let, 7 měsíců

2
1
0 0

knot-1.4.4-49.1.i586 on opensuse 12.2 and automatic resign zone not approved ?

by Josef Karliak

Good afternoon, I made a change in our zone, changed serial of the zone and reload the zone. When I check the syslog, I saw some complains, that the signatures was out of date. For example: Sep 26 11:31:17 slimak knot[22992]: [warning] Semantic warning in node: slimak.fnhk.cz.: RRSIG: Expired signature! Record type: A. Sep 26 11:31:17 slimak knot[22992]: [warning] Semantic warning in node: slimak.fnhk.cz.: RRSIG: Expired signature! Record type: AAAA. Sep 26 11:31:17 slimak knot[22992]: [warning] Semantic warning in node: slimak.fnhk.cz.: RRSIG: Expired signature! Record type: NSEC. This happens for all records in the zone. Last change was 11.8.2014, knot signed it and planned resign to 7.9.2014: Aug 11 13:39:10 slimak knot[22992]: Semantic checks completed for zone=fnhk.cz. Aug 11 13:39:10 slimak knot[22992]: Zone 'fnhk.cz.' reloaded (serial 2014081101) Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Signing started... Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 64431, file Kfnhk.cz.+005+64431.private, ZSK, active, public Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 26812, file Kfnhk.cz.+005+26812.private, KSK, active, public Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Successfully signed. Aug 11 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz.: Next signing planned on 2014-09-07T11:39:10. Aug 11 13:39:10 slimak knot[22992]: Loaded 5 out of 5 zones. Aug 11 13:39:10 slimak knot[22992]: Applied differences of 'fnhk.cz.' to zonefile. Aug 11 13:39:10 slimak knot[22992]: Configuration reloaded. Aug 11 13:39:10 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.115.171@53': Query issued (serial 2014081102). Aug 11 13:39:10 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.123.91@53': Query issued (serial 2014081102). Aug 11 13:39:10 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '89.248.244.34@53': Query issued (serial 2014081102). on 7.9.2014 the zone was resigned automatically: Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Signing zone... Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 64431, file Kfnhk.cz.+005+64431.private, ZSK, active, public Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - - Key is valid, tag 26812, file Kfnhk.cz.+005+26812.private, KSK, active, public Sep 7 13:39:10 slimak knot[22992]: DNSSEC: Zone fnhk.cz. - Successfully signed. Sep 7 13:39:11 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.115.171@53': Query issued (serial 2014081103). Sep 7 13:39:11 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '195.113.123.91@53': Query issued (serial 2014081103). Sep 7 13:39:11 slimak knot[22992]: NOTIFY of 'fnhk.cz.' to '89.248.244.34@53': Query issued (serial 2014081103). Sep 7 13:39:11 slimak knot[22992]: DNSSEC: Zone fnhk.cz.: Next signing planned on 2014-10-04T11:39:10. Sep 7 13:39:11 slimak knot[22992]: Outgoing IXFR of 'fnhk.cz.' to '195.113.115.171@47363': Started (serial 2014081102 -> 2014081103). Sep 7 13:39:11 slimak knot[22992]: Outgoing IXFR of 'fnhk.cz.' to '195.113.115.171@47363': Serial 2014081102 -> 2014081103. Sep 7 13:39:11 slimak knot[22992]: Outgoing IXFR of 'fnhk.cz.' to '195.113.115.171@47363': Finished in 0.01s. And after today's changes knot told me that the signatures was out of date. I've this similar version of knot on my own server, there is no problem Any ideas ? Thanks and best regards J.Karliak -- Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a DomainKeys/DKIM (with ADSP) . Pokud mate problemy s dorucenim emailu, zacnete pouzivat metody overeni puvody emailu zminene vyse. Dekuji. My domain use SPF (www.openspf.org) and DomainKeys/DKIM (with ADSP) policy and check. If you've problem with sending emails to me, start using email origin methods mentioned above. Thank you. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

11 let, 7 měsíců

2
2
0 0

Problem with CNAME in uppercase

by Didier ALBENQUE

Hi, I am currently testing knot and I have found a problem when CNAME are in uppercase. My primary server is running with BIND. I have these two declarations : myserver IN A 10.1.1.1 myserver-alias IN CNAME MYSERVER On the knot secondary server, after zone transfer, all seems ok : myserver.mydomain.fr. 900 A 10.1.1.1 myserver-alias.mydomain.fr. 900 CNAME MYSERVER.mydomain.fr. But when I ask knot for myserver-alias, I have a NXDOMAIN response (tcpdump output below) : 17:00:29.718834 IP dns-client.38146 > knot-server.domain: 4787+ A? myserver-alias.mydomain.fr. (43) 17:00:29.719011 IP knot-server.domain > dns-client.38146: 4787 NXDomain*- 1/1/0 CNAME MYSERVER.mydomain.fr. (123) 17:00:29.719555 IP dns-client.54520 > knot-server.domain: 2945+ A? myserver-alias.mydomain.fr.mydomain.fr. (54) 17:00:29.719637 IP knot-server.domain > dns-client.54520: 2945 NXDomain*- 0/1/0 (111) Tested with knot 1.5.1 and 1.5.2 Best regards, -- Didier ALBENQUE SG/SDSI/BSE Architecte technique Le café est un breuvage qui fait dormir, quand on n'en prend pas. Alphonse Allais ---------------------------------------------------------------------- Merci de nous aider à préserver l'environnement en n'imprimant ce courriel et les documents joints que si nécessaire.

11 let, 7 měsíců

2
2
0 0

Debian archive signing key, available over https?

by Andreas Olsson

Greetings Regarding the gpg key used to sign http://deb.knot-dns.cz/debian/. Any chance that that key could be available for downloaded by way of https://, or perhaps just have its fingerprinted listed on https://www.knot-dns.cz/pages/download.html? While the https:// CA model is far from perfect it'd still like to think it being a step up compared to regular http://, and at the same time a lot easier to document than the process of following the signatures in a gpg web of trust. // Andreas

11 let, 7 měsíců

2
2
0 0

Knot DNS v1.5.3 bugfix release

by Jan Kadlec

Hello list! CZ.NIC Labs are releasing a new version of Knot DNS today. This release fixes a regression that got introduced in the 1.5.2 release. This bug was causing Knot slaves to crash when receiving some specific IXFRs (more info: https://gitlab.labs.nic.cz/labs/knot/issues/294). Users that use Knot DNS as a slave should definitely upgrade. We've also added fixes for other issues we've recently discovered. Among those fixes are a fix to a very rare synchronization error during server reload (https://gitlab.labs.nic.cz/labs/knot/issues/296) and a fix to make dynamic query modules work properly with DNSSEC (https://gitlab.labs.nic.cz/labs/knot/issues/295). Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.3.tar.xz.asc We apologize for two bugfix releases in such a short time, please be assured that we're expanding our tests and we'll also be changing our release policy to try to prevent any future regressions. Special thanks for bug reports go to Anand Buddhdev and Bastien Durel. Regards and thanks for using Knot DNS, Jan -- Jan Kadlec, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

11 let, 8 měsíců

1
0
0 0

Re: [knot-dns-users] problem with debian repository

by Ondřej Surý

JFTR I did push the 1.5.2 to wheezy-backports directly since 1.5.2 contains a remote vulnerability, so it's available there - see https://tracker.debian.org/knot Cheers, -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ ------------------------------------------- ----- Original Message ----- > From: "Leoš Bitto" <leos.bitto(a)gmail.com> > To: knot-dns-users(a)lists.nic.cz > Sent: Tuesday, September 9, 2014 12:06:45 PM > Subject: Re: [knot-dns-users] problem with debian repository > On Tue, Sep 9, 2014 at 9:14 AM, Ondřej Caletka <ondrej.caletka(a)gmail.com> wrote: >> Dne 22.8.2014 09:52, Peter Hudec napsal(a): >>> Hi, >>> >>> this mail is directed for debian repository maintainers. >>> >>> The debian repository is not working properly, the Packages(.gz) and >>> Sources(.gz) files are empty. >>> >> >> I'm observing same problem. However, I've noticed that latest version of >> Knot is available in official wheezy-backports tree. >> > > http://deb.knot-dns.cz/debian/dists/wheezy/ does not work for me, too. > However I do not agree with the availability in the official > wheezy-backports > (http://ftp.cz.debian.org/debian/dists/wheezy-backports/ in my case) - > the previous version 1.5.1 was not there until the last week, and the > current version 1.5.2 is not there at all (which might actually be a > good thing due to https://gitlab.labs.nic.cz/labs/knot/issues/294). > > > Leoš Bitto > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

11 let, 8 měsíců

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users