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

Re: [knot-dns-users] Question about "views" and "RPZ"

by Marek Vavruša

Hey Jake, yes it does, RPZ is supported for views as is any other policy. There's an example of setting RPZ for a source-address subnet view in the documentation: http://knot-resolver.readthedocs.io/en/latest/modules.html#id3 Cheers, Marek > Does KnotDNS Resolver support the use of different RPZ's per-view? > > Looking to create a DNS setup that allows recursion to two separate > groups, one using one RPZ setup, the other using another. > > Is this possible with Knot? > > Thanks, > -jake > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users >

10 let

1
0
0 0

Kernel Connection Multiplexor

by Robert Edmonds

Hi, Linux 4.6 was just released, and it includes a new feature called "Kernel Connection Multiplexor": http://kernelnewbies.org/Linux_4.6#head-d86a7a8affd7cefef85fff400e39403718b… 1.5. Kernel Connection Multiplexor, a facility for accelerating application layer protocols This release adds Kernel Connection Multiplexor (KCM), a facility that provides a message-based interface over TCP for accelerating application layer protocols. The motivation for this is based on the observation that although TCP is byte stream transport protocol with no concept of message boundaries, a common use case is to implement a framed application layer protocol running over TCP. Most TCP stacks offer byte stream API for applications, which places the burden of message delineation, message I/O operation atomicity, and load balancing in the application. With KCM an application can efficiently send and receive application protocol messages over TCP using a datagram interface. The kernel provides necessary assurances that messages are sent and received atomically. This relieves much of the burden applications have in mapping a message based protocol onto the TCP stream. KCM also make application layer messages a unit of work in the kernel for the purposes of steerng and scheduling, which in turn allows a simpler networking model in multithreaded applications. In order to delineate message in a TCP stream for receive in KCM, the kernel implements a message parser based on BPF, which parses application layer messages and returns a message length. Nearly all binary application protocols are parseable in this manner, so KCM should be applicable across a wide range of applications. DNS-over-TCP is definitely amenable to this scheme, since messages are framed with a 2-byte message length value. It also sounds like it can be combined with recvmmsg(): Q: What about the problem of a connections with very slow rate of incoming data? As a result your application can get storms of very short reads. And it actually happens a lot with connection from mobile devices and it is a problem for servers handling a lot of connections. A: The storm of short reads will occur regardless of whether KCM is used or not. KCM does have one advantage in this scenario though, it will only wake up the application when a full message has been received, not for each packet that makes up part of a bigger messages. If a bunch of small messages are received, the application can receive messages in batches using recvmmsg. Maybe this could help speed up a DNS server, or even improve resistance against slowloris style TCP attacks. -- Robert Edmonds edmonds(a)debian.org

10 let

2
2
0 0

Question about "views" and "RPZ"

by elsif

Does KnotDNS Resolver support the use of different RPZ's per-view? Looking to create a DNS setup that allows recursion to two separate groups, one using one RPZ setup, the other using another. Is this possible with Knot? Thanks, -jake

10 let

1
0
0 0

systemd integration on Centos 7

by Matthew Pounsett

I'm building my own RPM for Knot 2.2.0 on Centos 7 due to the fact that the system version is still 1.x. I'm building it with systemd integration, and I've borrowed the systemd service file from the Fedora RPM. I'm having issues at startup, though. I'm wondering if it's related to the use of 'Type=notify', since knot seems to be running, but then after a delay of 30 seconds systemd decides it has failed and kills it. I'm attaching useful bits below. Any thoughts on the cause? My service file is: [Unit] Description=Knot DNS server daemon [Service] Type=notify ExecStart=/usr/sbin/knotd ExecReload=/usr/sbin/knotc reload Restart=on-abort ExecStartPre=/usr/sbin/knotc conf-check # Breaks daemon reload #CapabilityBoundingSet=cap_net_bind_service cap_setuid cap_setgid [Install] WantedBy=multi-user.target And this is what knot is reporting at startup: ● knot.service - Knot DNS Server Loaded: loaded (/etc/systemd/system/knot.service; disabled; vendor preset: disabled) Active: failed (Result: timeout) since Thu 2016-05-12 19:52:34 UTC; 3min 19s ago Process: 5875 ExecStart=/usr/sbin/knotd (code=exited, status=0/SUCCESS) May 12 19:51:04 master01.test.conundrum.com knotd[5875]: 2016-05-12T19:51:04 info: starting server May 12 19:51:04 master01.test.conundrum.com knotd[5875]: 2016-05-12T19:51:04 info: server started in the foreground, PID 5875 May 12 19:51:04 master01.test.conundrum.com knotd[5875]: 2016-05-12T19:51:04 info: control, binding to '/var/run/knot/knot.sock' May 12 19:52:34 master01.test.conundrum.com systemd[1]: knot.service start operation timed out. Terminating. May 12 19:52:34 master01.test.conundrum.com knotd[5875]: 2016-05-12T19:52:34 info: stopping server May 12 19:52:34 master01.test.conundrum.com knotd[5875]: 2016-05-12T19:52:34 info: updating zone timers database May 12 19:52:34 master01.test.conundrum.com systemd[1]: Failed to start Knot DNS Server. May 12 19:52:34 master01.test.conundrum.com systemd[1]: Unit knot.service entered failed state. May 12 19:52:34 master01.test.conundrum.com systemd[1]: knot.service failed. May 12 19:52:34 master01.test.conundrum.com knotd[5875]: 2016-05-12T19:52:34 info: shutting down And finally, the config report from building the package: knot 2.2.0 Target: linux-gnu x86_64 Compiler: gcc -std=gnu99 CFLAGS: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -DNDEBUG -Wno-unused -Wall -Werror=format-security -Werror=implicit -fpredictive-commoning LIBS: -lcap-ng -ldl -lpthread -lm -Wl,-z,relro LibURCU: -lurcu GnuTLS: -lgnutls -lnettle -I/usr/include/p11-kit-1 Jansson: -ljansson Libedit: -ledit -ltinfo -I/usr/include/editline LMDB: shared -llmdb Sanitizer: LibFuzzer: no Prefix: /usr Run dir: /var/run/knot Storage dir: /var/lib/knot Config dir: /etc/knot Configuration DB mapsize: 500 MiB Timers DB mapsize: 100 MiB Knot DNS libraries: yes Knot DNS daemon: yes Knot DNS utils: yes Knot DNS documentation: yes Use SO_REUSEPORT: yes Fast zone parser: yes Utilities with IDN: yes Systemd integration: yes Dnstap support: yes Code coverage: no Bash completions: no PKCS 11 support: no

10 let

2
2
0 0

Fedora23 knot 2.2.0 issue in knot.service

by Brad Garrison

I've just upgraded to 2.2.0 and noticed that knot failed to start. Upon inspection, I found that: /usr/lib/systemd/system/knot.service had the following line: ExecStartPre=/usr/sbin/knotc checkconf I think this is an error. I had to modify it to: ExecStartPre=/usr/sbin/knotc conf-check and then reimport the knot.conf file to get knot to start successfully.

10 let

2
1
0 0

Knot DNS 2.2.0 release

by Jan Včelak

Hello everyone! Knot DNS 2.2.0 by CZ.NIC Labs has been just released! This release brings only a few new features, but it contains a bunch of important bugs fixes and many significant changes under the hood. Let's start with the bug fixes and improvements: - We have resolved build dependency issues on FreeBSD. And we have fixed a problem when detecting PKCS #11 support in GnuTLS. - Some bugs related to Dnstap were resolved as well. The logging module now correctly sets query/response message type. And kdig properly uses the remote address when showing the capture. - The global instances of query modules were not executed for queries hitting existing zones. This problem is fixed in the new release. - We have enabled execution of semantic checks after IXFR to unify the behavior with AXFR. Also the logging of messages related to transfers was improved a little bit. - The DNSSEC signing produces correct NSEC/NSEC3 bitmap for delegations where a glue record has the same name as the delegated zone. - We have added some fixes hopefully improving compatibility with PKCS #11 devices. The most significant change is that the generated keys are marked as sensitive. It makes perfect sense and some devices (e.g. Luna SA) actually require this attribute to be set. - The configuration transaction is not aborted when some consistency check fails. This is particularly useful, if you make a typo when changing the server configuration with knotc. We have also eliminated an incorrect error when the last zone was being removed from the server. - There are also some bug fixes and improvements in the utilities. The keymgr utility should provide more sensible error messages, new consistency checks were added, and some commands were extended a little bit. The kdig utility now properly handles AXFR responses containing only the SOA record in the first message. And kdig will also use a local resolver if the resolv.conf file is empty. - The zone event scheduler was improved. And we hope that it will speed up the event lookup if you have many many zones. And finally the new features: - We have added RRL white listing. This allows to exempt some clients from rate limiting, for example your monitoring hosts. See the rate-limit-whitelist configuration option for details. - We have added support for URI (RFC 7553) and CAA (RFC 6844) resource record types. - The knotc utility now supports interactive mode with command line editing, tab completion, and history. Just start knotc without any command and give it a try. - And the server has a new control interface we will be extending in the future. The knotc utility already uses this interface. And we also have a simple Python binding for this interface. We are definitely looking for some feedback. That's all folks. Thank you for using Knot DNS. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/2.2/NEWS Source archive: https://secure.nic.cz/files/knot-dns/knot-2.2.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.2.0.tar.xz.asc Cheers, 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, 1 měsíc

1
0
0 0

Statistics

by Roger Murray

Hey, I was wondering if any work has been done on a statistics module for Knot DNS? I have read the mailing list and saw the conversation between Daniel and Julian, but haven’t seen anything on the list since then and I don’t see anything the documentation. Best regards, /rog

10 let, 1 měsíc

3
3
0 0

knot resolver with knot1 daemon

by Josef Karliak

Good morning, it is able to run knot resolver daemon with knot 1.6.x ? Thanks and best regards J.Karliak -- Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a DomainKeys/DKIM (s ADSP) a implementaci DMARC. 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 implementation of the DMARC. If you've problem with sending emails to me, start using email origin methods mentioned above. Thank you.

10 let, 1 měsíc

2
1
0 0

SIGSEGV of knot 2.1.1 on opensuse 13.2 x64 after add secure keystore hsm

by Josef Karliak

Good morning, I run knot2 on opensuse, configuration was migrated from 1.6. to 2.1.1, I run step by step configuration by manual to keymgr and after command : "keymgr policy add secure keystore hsm" I get a message: celer:/var/lib/knot/kasp # keymgr policy add secure keystore hsm Policy with given name alredy exists. Neoprávněný přístup do paměti (SIGSEGV) (core dumped [obraz paměti uložen]) Previos command was keymgr keystore add hsm backend pkcs11 config "pkcs11:token=knot;pin-value=4587 libsofthsm2.so" and was successfull. On the testing "server" with knot all works fine, testing server is opensuse 42.1 x64. Problem is on opensuse 13.2 x64 There is a core dump in the attachment. In the /var/log/messages were complains to libc: Apr 11 10:25:49 celer kernel: [7927072.584757] keymgr[13591]: segfault at 7fff18000000 ip 00007f3f59c20ca4 sp 00007fff18064f18 error 4 in libc-2.19.so[7f3f59ba5000+19e000] For sure I made upgrade of glib by zypper, but no success. Any ideas ? Thanks and best regards J.Karliak -- Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a DomainKeys/DKIM (s ADSP) a implementaci DMARC. 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 implementation of the DMARC. If you've problem with sending emails to me, start using email origin methods mentioned above. Thank you.

10 let, 1 měsíc

2
1
0 0

preserve case in labels?

by Gert Doering

Hi, we're using knot DNS (2.0.2) on one of our primaries, to balance out "BIND is used everywhere". So far, we're quite happy, but today I got a complaint from our hostmaster team - triggered by a warning from DENIC that "our SOA records are inconsistent". Turns out they are, if you look at uppercase/lowercase... $ dig +short @ns.space.net space.net soa ns.space.net. hostmaster.space.net. 2016040601 28800 3600 864000 1800 $ dig +short @ns3.dns.space.net space.net soa ns.Space.Net. hostmaster.Space.Net. 2016040601 28800 3600 864000 1800 first one is knot, second is BIND, and the "mixed case" spelling is what the zone master (hidden primary) is distributing. (I understand that DNS is not case-significant, but we're using upper case in DNS labels because we like it that way...) Looking at labels inside the zone (dig axfr) shows that knot is lowercasing *everything*, not only the SOA records. So, I started looking whether there is a switch that can change knot's behaviour to just leave the labels alone, and do not lowercase everything. Google did not find anything, neither did "man knotd" or "man knot.conf". So, is there a hidden switch or compile-time feature to achieve this? thanks in advance, Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

10 let, 1 měsíc

4
11
0 0

Concurrent Update

by masoud hematpour

Hello to all, I tried to look a little bit to the codes but can I ask how concurrent update is avoided? I mean RCU is used to avoid concurrent read and write. But how concurrent update is avoided? Thank you! masoud

10 let, 1 měsíc

2
1
0 0

knot 2 do not load zone after migrated from 1.6

by Josef Karliak

Good morning, I've migrated to knot2, configuration file was migrated by knot1to2 tool. Knot 2 loads, but to not load my DNSSEC signed zone (NSEC, not NSEC3). Knot2 is installed from suse dns server repo, version "knot2-2.1.1-1.1.x86_64". Error message: Apr 7 08:57:39 celer knotd[21676]: info: reloading configuration file '/etc/knot/knot.conf' Apr 7 08:57:39 celer knotd[21676]: info: configuration reloaded Apr 7 08:57:39 celer knotd[21676]: info: [domain.cz] zone loader, semantic check, completed Apr 7 08:57:39 celer knotd[21676]: error: [domain.cz] DNSSEC, failed to initialize (not found) Apr 7 08:57:39 celer knotd[21676]: error: [domain.cz] failed to store changes into journal (not found) Apr 7 08:57:39 celer knotd[21676]: error: [domain.cz] zone event 'load' failed (not found) Part of the configuration file: ... ... template: - id: "default" storage: "/var/lib/knot" zone: - domain: "domain.cz." file: "domain.cz" notify: "slave" acl: "acl_slave" semantic-checks: "on" ixfr-from-differences: "on" max-journal-size: "1073741824" dnssec-signing: "on" kasp-db: "/var/lib/knot/domain.cz.keys" ... ... Directory "/var/lib/knot/domain.cz.keys" contains zone private and public keys. What did I missed ? Thanks and best regards J.Karliak -- Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a DomainKeys/DKIM (s ADSP) a implementaci DMARC. 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 implementation of the DMARC. If you've problem with sending emails to me, start using email origin methods mentioned above. Thank you.

10 let, 1 měsíc

3
8
0 0

notify question

by Brett

I'm fairly new to knot so this may be a strange question that I am just not quite getting the config for notify somewhere. I have this in my config: remotes { dnsp61 { address 192.168.1.173; } } zones { storage "/var/lib/knot"; dnssec-keydir "keys"; dnssec-enable off; brettcarr.uk { file "brettcarr.uk"; xfr-in dnsp61; # define 'master' for this zone notify-in dnsp61; # also allow NOTIFY from 'master' } The zone axfr's at startup no problems. The master (dnsp61) is sending notifies to the knot server (192.168.1.170) as you can see from tcpdump output below 18:24:55.310553 IP 192.168.1.173.42438 > 192.168.1.170.domain: 27743 notify [b2&3=0x2400] [1a] SOA? brettcarr.uk. (89) but the knot server is not reacting to the notify. Am I missing something? TIA -- Brett

10 let, 2 měsíce

2
2
0 0

Knot 2.x Installation instructions

by Volker Janzen

Hi, I tried to install Knot 2.x deb on Debian Jessie. Following the instructions for Knot 2.x, I got Knot 1.6 installed. Any advice how to install Knot 2 deb on Jessie? Regards Volker

10 let, 2 měsíce

2
4
0 0

[PATCH] rrset-dump: Use generic text representation for LOC with version != 0

by Robert Edmonds

LOC records are special. The first octet of a LOC record is a version number. According to RFC 1876: VERSION Version number of the representation. This must be zero. Implementations are required to check this field and make no assumptions about the format of unrecognized versions. This means that if a LOC record's VERSION field is not zero, the RR cannot be presented in the canonical presentation format, but it is still a valid wire-format RR. Currently, kdig prints a warning message "can't print whole section" and a LOC record with a blank RDATA when it attempts to dump a LOC record with a non-zero VERSION field. This commit modifies the version check in wire_loc_to_str() to fall back to the generic presentation format if the VERSION field is not 0. This particular case is even explicitly described as a use case for the generic presentation format in RFC 3597: Using the generic representation for the RDATA of an RR of known type can also be useful in the case of an RR type where the text format varies depending on a version, protocol, or similar field (or several) embedded in the RDATA when such a field has a value for which no text format is known, e.g., a LOC RR [RFC1876] with a VERSION other than 0. --- src/libknot/rrset-dump.c | 95 +++++++++++++++++++++++++----------------------- 1 file changed, 49 insertions(+), 46 deletions(-) diff --git a/src/libknot/rrset-dump.c b/src/libknot/rrset-dump.c index c71eae1..ffdd825 100644 --- a/src/libknot/rrset-dump.c +++ b/src/libknot/rrset-dump.c @@ -508,6 +508,47 @@ static void wire_len_data_encode_to_str(rrset_dump_params_t *p, p->ret = 0; } +static void wire_unknown_to_str(rrset_dump_params_t *p) +{ + int ret; + size_t in_len = p->in_max; + size_t out_len = 0; + + // Write unknown length header. + if (in_len > 0) { + ret = snprintf(p->out, p->out_max, "\\# %zu ", in_len); + } else { + ret = snprintf(p->out, p->out_max, "\\# 0"); + } + if (ret <= 0 || (size_t)ret >= p->out_max) { + return; + } + out_len = ret; + + // Fill in output. + p->out += out_len; + p->out_max -= out_len; + p->total += out_len; + + // Write hex data if any. + if (in_len > 0) { + // If wrap mode wrap line. + if (p->style->wrap) { + dump_string(p, BLOCK_INDENT); + if (p->ret != 0) { + return; + } + } + + wire_data_encode_to_str(p, &hex_encode, &hex_encode_alloc); + if (p->ret != 0) { + return; + } + } + + p->ret = 0; +} + static void wire_text_to_str(rrset_dump_params_t *p) { // First byte is string length. @@ -938,6 +979,14 @@ static void wire_loc_to_str(rrset_dump_params_t *p) // Read values. wire_ctx_t wire = wire_ctx_init_const(p->in, p->in_max); uint8_t version = wire_ctx_read_u8(&wire); + + // Version check. + if (version != 0) { + wire_unknown_to_str(p); + return; + } + + // Continue to read values. uint8_t size_w = wire_ctx_read_u8(&wire); uint8_t hpre_w = wire_ctx_read_u8(&wire); uint8_t vpre_w = wire_ctx_read_u8(&wire); @@ -953,11 +1002,6 @@ static void wire_loc_to_str(rrset_dump_params_t *p) p->in += wire_ctx_offset(&wire); p->in_max = wire_ctx_available(&wire); - // Version check. - if (version != 0) { - return; - } - // Latitude calculation. char lat_mark; uint32_t lat; @@ -1210,47 +1254,6 @@ static void wire_tsig_rcode_to_str(rrset_dump_params_t *p) p->ret = 0; } -static void wire_unknown_to_str(rrset_dump_params_t *p) -{ - int ret; - size_t in_len = p->in_max; - size_t out_len = 0; - - // Write unknown length header. - if (in_len > 0) { - ret = snprintf(p->out, p->out_max, "\\# %zu ", in_len); - } else { - ret = snprintf(p->out, p->out_max, "\\# 0"); - } - if (ret <= 0 || (size_t)ret >= p->out_max) { - return; - } - out_len = ret; - - // Fill in output. - p->out += out_len; - p->out_max -= out_len; - p->total += out_len; - - // Write hex data if any. - if (in_len > 0) { - // If wrap mode wrap line. - if (p->style->wrap) { - dump_string(p, BLOCK_INDENT); - if (p->ret != 0) { - return; - } - } - - wire_data_encode_to_str(p, &hex_encode, &hex_encode_alloc); - if (p->ret != 0) { - return; - } - } - - p->ret = 0; -} - static size_t dnskey_len(const uint8_t *rdata, const size_t rdata_len) { -- 2.7.0

10 let, 2 měsíce

2
1
0 0

Rate limiting

by John Bond

Hello All, Are there any rrl parameters similar to the following in bind. * nxdomains-per-second * referrals-per-second Thanks John

10 let, 2 měsíce

2
1
0 0

DNSTAP socket problem

by Matthew Pounsett

Hi .. I'm trying out the dnstap support in Knot, and I seem to have an issue getting it to write to a socket instead of a file. If I give it a file to write to, things seem to work as expected. When I write to a socket, the socket file is not created, and there don't appear to be any errors. Have I got something wrong? My very basic config and startup log is included below. --- server: rundir: /home/matt/etc/knot user: matt:staff listen: 0.0.0.0@5353 log: - target: /home/matt/etc/knot/logfile server: info zone: info any: info mod-dnstap: - id: capture_all sink: unix:/home/matt/etc/knot/capture.tap template: - id: default storage: /home/matt/etc/knot/zones kasp-db: /home/matt/etc/knot/kasp module: mod-dnstap/capture_all zone: - domain: myzone.test dnssec-signing: on --- 2016-02-23T18:09:47 info: Knot DNS 2.1.1 starting 2016-02-23T18:09:47 info: binding to interface '0.0.0.0@5353' 2016-02-23T18:09:47 info: changing GID to '60' 2016-02-23T18:09:47 info: changing UID to '1001' 2016-02-23T18:09:47 info: PID stored in '/home/matt/etc/knot/knot.pid' 2016-02-23T18:09:47 info: changed directory to / 2016-02-23T18:09:47 info: loading 1 zones 2016-02-23T18:09:47 info: [myzone.test] zone will be loaded, serial 0 2016-02-23T18:09:47 info: starting server 2016-02-23T18:09:47 info: [myzone.test] DNSSEC, loaded key, tag 26654, algorithm 8, KSK yes, ZSK no, public no, active no 2016-02-23T18:09:47 info: [myzone.test] DNSSEC, loaded key, tag 7468, algorithm 8, KSK no, ZSK yes, public yes, active yes 2016-02-23T18:09:47 info: [myzone.test] DNSSEC, loaded key, tag 20456, algorithm 8, KSK yes, ZSK no, public yes, active yes 2016-02-23T18:09:47 info: [myzone.test] DNSSEC, signing started 2016-02-23T18:09:47 info: [myzone.test] DNSSEC, zone is up-to-date 2016-02-23T18:09:47 info: [myzone.test] DNSSEC, next signing on 2016-02-29T23:43:54 2016-02-23T18:09:47 info: [myzone.test] loaded, serial 0 -> 2016022209 2016-02-23T18:09:47 info: server started as a daemon, PID 26600 2016-02-23T18:09:47 info: remote control, binding to '/home/matt/etc/knot/knot.sock' 2016-02-23T18:11:07 info: remote control, received command 'stop' 2016-02-23T18:11:07 info: stopping server 2016-02-23T18:11:07 info: updating zone timers database 2016-02-23T18:11:07 info: shutting down

10 let, 3 měsíce

2
3
0 0

Knot Zone Check

by Daniel Stirnimann

Dear all, knotc has a zone-check command. Is there a tool which can validate a zone file directly? I see that you have a DNS library which can load a zone file very fast (https://github.com/vavrusa/luajit-kdns). However this is missing the zone checker/validator. The stand alone zone check command line tool I was looking for would also verify DNSSEC signatures. Something like dnssec-verify (BIND). Daniel

10 let, 3 měsíce

3
2
0 0

Knot DNS 2.1.1 patch release

by Jan Včelak

Hello everyone. Knot DNS 2.1.1 by CZ.NIC Labs has been just declared stable. It mostly contains bug fixes. The update is highly recommended as some of the problems are quite critical. - We have resolved the problem with source address selection for UDP messages when the server is configured to listen on all available addresses (i.e., 0.0.0.0 or ::0). Prior to this release and depending on the networking configuration, the server could choose a wrong source address. - Duplicate private keys can be now imported into the KASP database. This is practical if you have the same signing key in the legacy format and share the key between multiple domains. Prior to this release, sharing the key was possible only with some hacks. - We have resolved a problem with duplicate NSEC record which had been returned for Wildcard No Data answers. In the new version, the record is inserted into the response only once. - We have fixed a possible server crash, which could happen during an incoming zone transfer when a server reload is requested. - The fix of a crash with many configured interfaces and threads was included in the previous release. However the fix was incomplete. We have found another related problems which are addressed in the new version. Thank you for the feedback and bug reports. And we are looking forward to hear back from you. :-) The sources are available on our server as usual. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.1.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.1.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.1.1.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, 3 měsíce

2
1
0 0

Knot DNS 1.6.7 patch release

by Jan Včelak

Hello folks. CZ.NIC Labs just released Knot DNS 1.6.7. This patch release contains only a few improvements. Upgrade is not necessary but advised. - The server newly logs the change in the zone serial after IXFR transfers. Prior to this release, information about serial was logged only for AXFR transfers. This modification unifies the logging behavior. - We have added the 'timer-db' configuration option, which allows relocation of zone timer database. This is useful if you run multiple daemon instances sharing the same zone storage directory. - The RRL implementation newly supports zero value for the 'rate-limit-slip' option. With this setting, all responses for a flow exceeding the configured limit will be dropped. - The documentation for RRL was extended to include information about expected operational impact of various settings. As you can see, the changes are rather small. We will continue in this trend with the LTS version of Knot DNS. If you run Knot DNS 1.6 and look for a new features and improvements, please consider an early upgrade to Knot DNS 2.x. The sources are available on our server 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.7.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.6.7.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.7.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.7.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, 3 měsíce

2
1
0 0

next week releases

by Jan Včelak

Hello list, this is just a quick note that we plan to do an ordinary bug fix release of Knot DNS 1.6.7 and Knot DNS 2.1.1 the next week. As for 2.1.1, we did some changes in the networking code and we want to make sure that everything is working correctly. If you can help us with testing we would be very happy. The tarball with sources for testing is available on our server: https://secure.nic.cz/files/knot-dns/knot-2.1.1-test.tar.xz Thank you. Cheers, Jan

10 let, 3 měsíce

2
4
0 0

Troubles compiling Knot 2.1

by Bruno Pagani

Hi, I’m trying to compile Knot 2.1, but it fails. Here is the error part: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../src -include ../../src/config.h -I./shared -I./lib -I./lib/dnssec -I../../src -I/usr/include/p11-kit-1 -fvisibility=hidden -D_FORTIFY_SOURCE=2 -march=native -O2 -pipe -fstack-protector-strong -fstack-check -Wall -Werror=format-security -Werror=implicit -fpredictive-commoning -MT lib/event/action/libdnssec_la-initial_key.lo -MD -MP -MF lib/event/action/.deps/libdnssec_la-initial_key.Tpo -c lib/event/action/initial_key.c -fPIC -DPIC -o lib/event/action/.libs/libdnssec_la-initial_key.o lib/binary.c: In function 'base64_decode_raw': lib/binary.c:47:2: warning: statement with no effect [-Wunused-value] nettle_len dst_size = dst_max_size; ^ lib/binary.c:47:13: error: expected ';' before 'dst_size' nettle_len dst_size = dst_max_size; ^ lib/binary.c:48:50: error: 'dst_size' undeclared (first use in this function) int result = nettle_base64_decode_update(&ctx, &dst_size, dst, src_len, src); ^ lib/binary.c:48:50: note: each undeclared identifier is reported only once for each function it appears in lib/binary.c:54:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ I suppose this has to do with the flags used on my system (Arch Linux) ? Thanks, Bruno

10 let, 3 měsíce

4
6
0 0

IP source on IPv6

by Alarig Le Lay

Hi, I’ve installed knot 2.0.2 on one of my server. It’s configured with three IPv6 and I manage their reliability with some source-specifi routing: alarig@bulbizarre ~ $ ip -6 route list | grep default default from 2001:470:1f13:138:715d:2fa0:b591:532f via fe80::20d:b9ff:fe3a:1fa1 dev eth0 metric 1024 default from 2a00:5881:4008:400::1 dev tun0 metric 1024 default from 2a01:240:fe00:82af:764f:b47e:d131:85e4 via fe80::20d:b9ff:fe3a:1fa1 dev eth0 metric 1024 default via fe80::20d:b9ff:fe3a:1fa1 dev eth0 metric 4 It works fine as I can ping those three IP from the same machine at the same moment. But, knot don’t take care of this and answer with the “nearest” IPv6 (like the IP source is calculated when you have several ones). bulbizarre ~ # tcpdump -i any host mc.swordarmor.fr 23:13:07.276493 IP6 2001:41d0:a:27e4::1.52203 > florizarre.swordarmor.fr.domain: 59831+ SOA? swordarmor.fr. (31) 23:13:07.276647 IP6 bulbizarre.swordarmor.fr.domain > 2001:41d0:a:27e4::1.52203: 59831*- 1/0/0 SOA (86) You can see that knot answer with 2001:470:1f13:138:715d:2fa0:b591:532f, which is the one chosen if I’m the initiator of the connection. Indeed, it works with my IRCd: 23:14:17.684155 IP6 2001:41d0:a:27e4::1.36490 > florizarre.swordarmor.fr.6697: Flags [P.], seq 53:106, ack 106, win 331, options [nop,nop,TS val 4047617704 ecr 1587664633], length 53 23:14:17.684301 IP6 florizarre.swordarmor.fr.6697 > 2001:41d0:a:27e4::1.36490: Flags [P.], seq 106:211, ack 106, win 240, options [nop,nop,TS val 1587724598 ecr 4047617704], length 105 23:14:22.555891 IP6 2001:41d0:a:27e4::1.34822 > bulbizarre.swordarmor.fr.6697: Flags [P.], seq 1:62, ack 61, win 331, options [nop,nop,TS val 4047618922 ecr 1587729432], length 61 23:14:22.555928 IP6 bulbizarre.swordarmor.fr.6697 > 2001:41d0:a:27e4::1.34822: Flags [.], ack 62, win 274, options [nop,nop,TS val 1587729469 ecr 4047618922], length 0 Is it a known bug? -- alarig

10 let, 4 měsíce

2
3
0 0

Knot Ubuntu update

by Volker Janzen

Hi, I did a "apt-get upgrade" on my Knot node. The package update fails with "Failed to initialize default key store (unknown error -13)." Can anyone tell me what that means? root@localhost:~# knotd --version knotd (Knot DNS), version 2.1.0 root@localhost:~# ps aux | grep knot knot 30048 0.0 0.6 1245236 6400 ? Ssl 16:08 0:00 /usr/sbin/knotd -d -c /etc/knot/knot.conf root@localhost:~# /etc/init.d/knot restart * Restarting Knot DNS server knotd [ OK ] root@localhost:~# ps aux | grep knot knot 30115 0.0 0.6 1245224 6200 ? Ssl 16:09 0:00 /usr/sbin/knotd -d -c /etc/knot/knot.conf root@localhost:~# apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] Setting up knot (2.1.0-2+trusty+2) ... * Starting Knot DNS server knotd [ OK ] Failed to initialize default key store (unknown error -13). dpkg: error processing package knot (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: knot E: Sub-process /usr/bin/dpkg returned an error code (1) root@localhost:~# ps aux | grep knot knot 30115 0.0 0.6 1245236 6360 ? Ssl 16:09 0:00 /usr/sbin/knotd -d -c /etc/knot/knot.conf Kind regards, Volker

10 let, 4 měsíce

2
4
0 0

dynamically add/delete zones on the fly?

by Mark Jeftovic

Hi, is there any way to dynamically add/delete zones on-the-fly other than to rebuild your master config and reload? Thx - mark

10 let, 4 měsíce

5
6
0 0

Knot 2.1.0-rc1

by Bastien Durel

Hello, Knot 2.1.0-rc1 made its way to the debian repository. I installed it as part of today's upgrade, but it seems to not like my configuration : For each zone I got these messages : 2016-01-14T10:07:00 error: [durel.org] DNSSEC, failed to initialize (invalid parameter) 2016-01-14T10:07:00 error: [durel.org] failed to store changes into journal (invalid parameter) 2016-01-14T10:07:00 error: [durel.org] zone load failed (invalid parameter) I log zone events up to notice level. my default template is : template: - id: "default" storage: "/var/lib/knot/external" ixfr-from-differences: "on" dnssec-signing: "on" kasp-db: "keys" serial-policy: "increment" And this zone is defined as : - domain: "durel.org." file: "durel.org" notify: "corrin" acl: "acl_corrin" Which is this "invalid parameter ?" Thanks, -- Bastien

10 let, 4 měsíce

2
4
0 0

Knot DNS 2.1.0 (final release)

by Jan Včelák

Hello everyone. I'm glad to tell you that Knot DNS 2.1.0 by CZ.NIC Labs was just released. Thank you for the feedback on the release candidate. I believe we have addressed all the issues and bug reports we have received. Let me just quickly summarize the news in the 2.1.0 you already know about: SO_REUSEPORT support, binary configuration database, PKCS #11 support in DNSSEC, zone file name formatters, configurable location for timer database, experimental module for online signing, and many other improvements. If you are interested in details, please, see the 2.1.0-rc1 announcement. And now finally, we are getting to the news in the final release: - We have resolved the problem with the server crashing when configured with a high number of interfaces and threads. This problem started to affect more people because of the introduction of the SO_REUSEPORT support which causes a higher allocation of file descriptors. - We have changed the '%s' zone file name formatter behavior for the root zone. In the release candidate, the trailing dot was skipped for all zones except for the root zone. In 2.1.0, the trailing dot is skipped even for the root zone. The root zone therefore expands to an empty string. This should make your Ansible templates less hacky. - The keymgr now supports KASP database upgrade. So if you have initialized the database with Knot DNS 2.0, please, run 'keymgr init' in the KASP directory to avoid DNSSEC 'invalid parameter' errors. The command is idempotent, it won't rewrite your existing settings. - We have removed the possibility to run knotc over a network socket. The interface allows altering the configuration and possibly sensitive content (e.g. TSIG keys) could appear on the network in plain text. We are working on some better configuration interface which will (among other things) guarantee confidentiality. - We have also fixed a problem with slave zone bootstrapping when the server launches and the slave zone fails to load from a zone file. In this case, an immediate zone transfer is scheduled. Prior to this release, the transfer had to be initiated manually by knotc. Thank you for reading so far. Hopefully I haven't forgotten about anything important. And as always, we are here for you to answer any questions. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.1.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.1.0.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.1.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, 4 měsíce

1
0
0 0

script to export config from knot 1.x to 2.x

by Josef Karliak

Good morning, do somebody (or knot dns) have script to migrate from knot dns 1.6 to knot 2.x version ? Thanks and best regards J.Karliak -- Ma domena pouziva zabezpeceni a kontrolu SPF (www.openspf.org) a DomainKeys/DKIM (s ADSP) a implementaci DMARC. 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 implementation of the DMARC. If you've problem with sending emails to me, start using email origin methods mentioned above. Thank you.

10 let, 4 měsíce

3
2
0 0

Manage zonefile directory in git

by Tobias Brunner

Hi everyone, I'd like to manage the directory holding all the zonefiles in git to have a workflow like "git push -> webhook -> zonefiles git pull -> knotc reload". With Knot versions <2 this was working great because Knot did not change anything in this directory. But when using Knot 2.x with DNSSEC enabled, Knot rewrites the zonefiles of DNSSEC enabled zones, creates a timers subdirectory and puts some *.db files into the zones directory. Are there any configuration parameters to change this behaviour? So that the timers subdirectory is created outside the directory holding zonefiles (preferably configurable), the *.db files are also written into a dedicated directory and signed zonefiles are saved into a different subdirectory. Or are there any proposals how I could manage the zonefiles directory with git when using Knot 2.x with DNSSEC enabled? Thanks a lot for all input. Cheers and happy new year! Tobias

10 let, 4 měsíce

6
9
0 0

Knot Puppet module now 2.x ready

by Tobias Brunner

Hi all, The Knot Puppet module is now fully Knot 2.x compatible. It can be found on Puppet forge: https://forge.puppetlabs.com/tobru/knot Any feedback and all pull requests are highly appreciated. Cheers, Tobias

10 let, 5 měsíců

1
0
0 0

Knot DNS 2.1.0-rc1 (release candidate)

by Jan Včelák

Hello everyone! Have you been good this year? CZ.NIC Labs just released a Christmas present for all Knot DNS users — a new and shiny release candidate. This version contains a bunch of new features, quite a lot of improvements and also some bug fixes. Let's start with the features: - If you run Linux, you will get a higher packet throughput for UDP thanks to the SO_REUSEPORT socket option. In some cases, we have seen 100% packet rate increase. - As an alternative to the textual configuration file, we now support a binary configuration database. This is primarily intended for users with many zones who need to reconfigure their servers quickly. For this purpose, the knotc utility adds new conf-* commands, which can be used to query and modify the server configuration on-the-fly. - DNSSEC newly implements an interface to access cryptographic tokens via the PKCS #11. This means, that you can store the private key material for DNSSEC keys more securely than before. - We have also included an experimental module for DNSSEC online signing. This can be used for instance with the other modules synthesizing records on-the-fly. As for various improvements: - The zone file name can now include formatters, which will be later substituted. For example, if you have many zones and want to sort them into directories based on their TLD, you can use '%l[0]/%s.zone' as the 'file' config option, and the zone 'example.com' will be loaded from '$storage/com/example.com.zone'. - We have added the 'timer-db' option to customize path to the database with persistent zone timers. This is useful if you have multiple knotd instances sharing a zone storage directory. - After the recent DDoS attacks, we have improved the RRL documentation to include details about the effect of the individual rate-limit-slip configuration values. We also made this option to accept zero value which will make the server drop all responses exceeding the limit. - Other small changes in the server include improved networking code so we can better handle connection timeouts. The ACL failures are now logged. And some of the critical configuration values are cached for better performance. - The kdig utility now prints a warning instead of failing with an error when a TSIG validation failure is encountered. - We've also performed some cleanup of the support libraries: libknot, libzscanner, and libdnssec. So if you are developing your own DNS application, take a look at these. And that's it. Please, refer to the documentation for more information. And if something is not clear, just ask on the mailing list and we will try to clarify any ambiguities. You will find your present under our Christmas tree. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.1.0-rc1/NEWS Source tarball: https://secure.nic.cz/files/knot-dns/knot-2.1.0-rc1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.1.0-rc1.tar.xz.asc On behalf of our development team, I wish you a merry Christmas and happy New Year. 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, 5 měsíců

1
1
0 0

Knot DNS 1.6.6 and 2.0.2 (security patch release)

by Jan Včelák

Hello everyone. CZ.NIC Labs just released two security patch version of Knot DNS. Knot DNS 2.0.2 - We have recently extended our fuzzy-testing tool set by a new LibFuzzer tool, which lead to a discovery of a bug in the packet parser. A specially crafted packet with malformed NAPTR record can trigger an out-of-bound read, possibly leading to the knotd daemon crash. The new version fixes this bug. Knot DNS 1.6.6 - The 1.6 packet processing code contained the same issue in NAPTR parsing which was present in the 2.0. However, existing code paths to its occurrence were different. We are not aware of any possibility to remotely crash the server daemon at the moment. - The updated version also fixes systemd server startup notifications. - We have included the rosedb module, which has already been distributed as a separate tarball for a few releases. Users of rosedb should switch to the main releases. If you are a Knot DNS 2.0 user, we highly recommend to updated to version 2.0.2 because it is possible to cause a denial of service remotely. If you are a Knot DNS 1.6 user, we suggest to update to the latest release even though the fixed problems are not as critical as in the 2.0 branch. The sources are available as usual. Full changelogs: https://gitlab.labs.nic.cz/labs/knot/raw/v1.6.6/NEWS https://gitlab.labs.nic.cz/labs/knot/raw/v2.0.2/NEWS Tarballs: https://secure.nic.cz/files/knot-dns/knot-1.6.6.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.0.2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.6.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-2.0.2.tar.xz.asc Best regards! And thank you for using Knot DNS. 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, 6 měsíců

2
2
0 0

[Knot-Resolver] "I yielded, not you" issue

by Florian Maury

Hi everyone, While working on my Knot-Resolver (kr) module, I came to think that the current YIELD mechanism for layers will not work properly, if multiple YIELD-enabled modules are loaded simultaneously. My understanding of how the current YIELD system works is as follows. A layer receives the current state through ((knot_layer_t*) ctx)->state. The current state can be modified by previous layers returned value. When a layer returns a YIELD state, the chain of responsability, maintained by the lib/resolve.c:ITERATE_LAYERS macro is broken (break;) and the resolution plan is evaluated once more to handle the tail element of the rplan. Once the rplan popped up all rplan_pushed queries, then the query that yielded is once more the last element of the rplan stack. This element is then evaluated, calling once more all layers, starting with the first layer. This time, the state that is provided to the layers is YIELD, except if a layer returns another value instead of returning the state as is. A layer could behave differently, based on whether it receives a YIELD state or not as "input state". This is, in fact, what is provided as example in the documentation: >>> consume = function (state, req, answer) answer = kres.pkt_t(answer) if state == kres.YIELD then print('continuing yielded layer') return kres.DONE else if answer:qtype() == kres.type.NS then req = kres.request_t(req) local qry = req:push(answer:qname(), kres.type.SOA, kres.class.IN) qry.flags = kres.query.AWAIT_CUT print('planned SOA query, yielding') return kres.YIELD end return state end end <<< The issue, I think, is that a module has no way of knowing whether it is the one that yielded or not. Let's say I have three module, A, B, and C. B and C can yield, and A only returns YIELD, when it receives YIELD as input state. On the first evaluation, A and B returns DONE. C yields. Then on the second evaluation, A returns YIELD, because it does not handle this state and only passes it along. B receives the YIELD from A. B, as said above, may yield in some cases. B will therefore handle the YIELD, and do his "YIELD" actions, ignoring the fact that the module that actually yielded was C. I suppose B and C could define flags to be capable of remembering whether they yielded on this query or not. Unfortunately, there is currently no framework to ensure uniqueness of these flags. Sadly, this email does not come up with a proposed solution. I'm only sharing a thought about what I think could be an issue. What is your take on this? Have I missed something or misunderstood how the yield state works? Thank you. Cheers, Florian

10 let, 6 měsíců

2
3
0 0

Re: [knot-dns-users] knot 1.4.4 and problem with journal size - zone not loaded

by Daniel Salzman

Hi, You can try setting https://www.knot-dns.cz/docs/1.6/singlehtml/index.html#ixfr-fslimit or simply deleting the journal file corresponding to the ajetaci.cz zone. Dan > > Good morning, > where is problem with zone ? > Error : > journal size is too small to fit the changes. > > Knot is owner of this directory. > > After loading zone I found that record on some line in the zone file is > invalid, I deleted it, increased serial and after reloading zone I could > not set it UP > > > Log records about the zone: > Nov 9 08:22:14 celer knot[20407]: Semantic checks completed for > zone=ajetaci.cz. > Nov 9 08:22:14 celer knot[20407]: Zone 'ajetaci.cz.' loaded (serial > 2015110901) > Nov 9 08:22:14 celer knot[20407]: DNSSEC: Zone ajetaci.cz. - Signing > started... > Nov 9 08:22:14 celer knot[20407]: DNSSEC: Zone ajetaci.cz. - - Key is > valid, tag 36256, file Kajetaci.cz.+005+36256.private, KSK, active, public > Nov 9 08:22:14 celer knot[20407]: DNSSEC: Zone ajetaci.cz. - - Key is > valid, tag 11937, file Kajetaci.cz.+005+11937.private, ZSK, active, public > Nov 9 08:22:14 celer knot[20407]: DNSSEC: Zone ajetaci.cz. - - Key is > valid, tag 5300, file Kajetaci.cz.+007+05300.private, ZSK, active, public > Nov 9 08:22:14 celer knot[20407]: DNSSEC: Zone ajetaci.cz. - - Key is > valid, tag 58830, file Kajetaci.cz.+007+58830.private, KSK, active, public > Nov 9 08:22:14 celer knot[20407]: [error] Zone 'ajetaci.cz.' journal size > is too small to fit the changes. > Nov 9 08:22:14 celer knot[20407]: Loaded 2 out of 3 zones. > Nov 9 08:22:14 celer knot[20407]: [warning] Not all the zones were loaded. > > > Any ideas ? > Thanks and best regards > J.

10 let, 6 měsíců

4
4
0 0

*****SPAM***** knot 1.4.4 and problem with journal size - zone not loaded

by Josef Karliak

Spam detection software, running on the system "mail.nic.cz", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Good morning, where is problem with zone ? Error : journal size is too small to fit the changes. Knot is owner of this directory. After loading zone I found that record on some line in the zone file is invalid, I deleted it, increased serial and after reloading zone I could not set it UP [...] Content analysis details: (5.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.8 DKIM_ADSP_ALL No valid author signature, domain signs all mail -0.0 SPF_PASS SPF: sender matches SPF record 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4973] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 3.0 RDNS_NONE Delivered to internal network by a host with no rDNS 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid

10 let, 6 měsíců

1
0
0 0

[Knot-Resolver] Modules meddling with the NS selection feature request

by Florian Maury

Hi everyone, While I was working on my Knot-Resolver (kr) module, I wondered how I could be able to ratelimit the trafic toward specific nameservers or influence the NS selection algorithm, in general. Unfortunately, the current NS election algorithm that is present in the lib/resolve.c driver and in lib/nsrep.c does not allow a module to register a layer to influence the NS selection. Is there any plan to add event listeners to influence NS selection, for instance by giving layers the opportunity to "congregate" and return a modifier, a lot like the "favour" IPv6 modifier/variable that is done in lib/nsrep.c:eval_addr_set? Thanks. Cheers, Florian

10 let, 6 měsíců

1
0
0 0

[Knot-Resolver] Async module unloading and cleanup event idea

by Florian Maury

Hi everyone, While working on a Knot-Resolver (kr) C module, I stumbled on a limitation of the current way layers are loaded and unloaded. My understanding is that, currently, C modules are loaded via a dlopen call, and then a callback "moduleName_init" symbol is searched and called. On unloading, a symbol "moduleName_deinit" is searched and called, and upon completion of the deinit function, a dlclose call is made to unload the module from memory. This occurs in lib/modules.c. As it happens, my C module provides callbacks (cb) for several layer hooks. Some of these cb perform potentially long-lived I/O operations. Since functions are not supposed to take a lot of CPU time, in order to maintain kr responsiveness and with respect to the event-oriented design, I chose to embrace libuv and use the uv_* functions to perform these I/O operations. This means I inserted in the uv_default_loop several cb for network or filesystem events. These cb need to be called for some operations to be successfully completed. Think about SQL commit statements and whatnot. Currently when a user wants to stop the daemon, the "graceful" procedure is to call quit() on the CLI. This procedure calls uv_stop on the uv_default_loop, thus stopping abruptly all registered cb from being ever called again. Then, modules are unloaded one by one. These unloading calls to moduleName_deinit can be blocking because no service requires responsiveness anymore. On the other hand, if a module is shutdown during normal operations, for instance, via a call to "modules.unload" from the CLI, the unloading procedure cannot perform blocking actions without generating a negative impact on the overall responsiveness. The problem is that it cannot perform non-blocking actions either because as soon as the deinit function returns, the code for the non-blocking actions "to wrap up" currently registered callbacks in the uv_default_loop is removed from memory. To solve this problem, I would suggest creating a cleanup event, sent to modules that should be unloaded. A module receiving a call to its handler for this event would be expected to wrap it up ASAP. It would, however not be expected to have completed everything at handler return time. The sender of the cleanup event could then register a uv_idle handler that would call the deinit function. The deinit function would then be in charge of ensuring the module no longer have any event handler registered in the uv loop. If no cb are present in the loop, it would return a status code allowing the caller to dlclose the module. With this approach, calling the "graceful" quit procedure would then send a cleanup event to all modules, including iterate, cache, etc. uv_stop would not need to be called anymore because the idle handler would be able to know that no handler are in the uv_loop except itself: it would then unregister itself and the uv_run call would terminate spontaneously. What is your take on this issue? Do you think the proposed solution would be acceptable? Would it work with all kind of modules (I'm thinking about the lua and go modules)? I, sadly, currently have no code to do this. I just thought it might be useful to document this on the mailing list and share ideas about it. Thank you. Cheers, Florian

10 let, 6 měsíců

1
0
0 0

[Knot-Resolver] kr_zonecut_find_cached seemingly incorrect result

by Florian Maury

Hi everyone, I have been recently working on a Knot-Resolver (kr) module for some research work. This led me to push new queries into the resolution plan, wait for the answer and then resume the "standard" kr-spooled queries. Once all queries are resolved, when my finish module callback (cb) is invoked, I write down some statistics that were collected throughout the various queries. Among the thing that I write down, I inspect some data in the cache, including zonecuts. I discovered that some information returned by lib/zonecut.c:kr_zonecut_find_cached were different from what I expected. I am not sure if this is because my call to kr_zonecut_find_cached is incorrect, if I messed up some kr internal logic or if I stumbled on a bug. Here follows a made-up domain name tree similar to what made me stumbled on this issue, what I thought should be returned by kr_zonecut_find_cached, and what is actually returned. The original query qname is example.com.. Example.com. is delegated to a company owning example.net, a DNS reseller providing DNS hosting for its clients. example.com. is gluelessly delegated to ns1.example.net. and ns2.example.net.. example.net. is gluelessly delegated from net. to srv1.some-famous-registrar.net. and srv2.some-famous-registrar.net.. some-famous-registrar.net. is also delegated from net. to srv1.some-famous-registrar.net. and srv2.some-famous-registrar.net. thus using a glued delegation. When I call kr_zonecut_find_cached in my module finish cb, with a "name" param whose value is srv1.some-famous-registrar.net., I expected the cut out-param to be filled with a kr_zonecut structure with a "name" equal to some-famous-registrar.net. and a nsset equal to srv1.some-famous-registrar.net.|srv2.some-famous-registrar.net. Unfortunately, cut->name values net., which is of course incorrect, since some-famous-registrar is a delegated name. My call to kr_zonecut_find_cached is using a kr_cache_txn structure created by the finish cb, using the cache in ((knot_layer_t*) ctx)->((kr_request*) data)->ctx->cache. It may also be worth noting that I use "false" for the secured param of the kr_zonecut_find_cached call. If this is indeed a bug, my guess would be that example.com. delegation leads kr to ask to net. nameservers for the delegation information for example.net.. net. nameservers answer that the delegation to example.net. is through srv1.some-famous-registrar.net.|srv2.some-famous-registrar.net.. At the same time, net. nameservers also provide the *glues* for srv1.some-famous-registrar.net. and srv2.some-famous-registrar.net., since the net. zone contains non-authoritative IP address records for these names for the glued delegation of some-famous-registrar.net. This could make kr to believe that net. is "authoritative" in some way for srv1.some-famous-registrar.net. and therefore to think that the some-famous-registrar.net is not a delegated zone. It is however possible that I completely crashed kr zonecut logic with the additional queries that I pushed from time to time, though. Does that ring a bell to anyone? What would be, according to you, the next step I should take to better understand what is going on? Thanks for your help! Cheers, Florian

10 let, 6 měsíců

1
0
0 0

Dynamic Update

by Ulrich Wisser

Hi! Just a short feedback. Today I got the latest source from git and it compiled on my Raspberry Pi. The Dynamic Update "bug" or incompatibility is fixed. Thanks for all your help! And thanks for fixing it so fast! /Ulrich -- Ulrich Wisser ulrich(a)wisser.se

10 let, 7 měsíců

1
0
0 0

subscription

by Yves Bovard

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Community A I am a Knot DNS user, I would like to subscribe to your mailing list. How can I do that? Best regards Yves Bovard - -- SWITCH - -------------------------- Yves Bovard, Security Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 16 31 yves.bovard(a)switch.ch, http://www.switch.ch -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJWJNm7AAoJEOgRvbd1sr4QoV8QAK//5Hio41UtP56JWvnBxyLo gmQRXZrD2Q6B97e0OfvFA2CLnmmKfmQwHniCWG4prgktdtsiwLscWFhBdTGk4OW9 0w9VHWc+Jvl3gDv18kmGaN9azMsoqiZ6ws3CsnEq/WdObR0a0KwJHuy3yJBJleXz NpUN58qp+kaPQ46a0o2WKgAtDpilg30tWX2k2gLPXlNfu7IGPkmp+sXrPwWFtim5 CZHeDFfPYCWlaD8Lw1VC/7u8dKUMk4yYE35ioXlMxt2Xgdeagu70ZW9EyC7Xx4EZ iPFDKdvxRpBljhc8YchXSldkg4rqtsQwE4h4Q07s7RAv/tkZKxAllodtiRtFC/TP oVQ4QUjFcbUKC5dUWCQnGVbyyzBVgdWsBnhhQKiuM1477dwKe2ugMFNvIGo7GqAJ 3HDqL+L1FteBbW9iBvHN3XRcXk4bdKBm2MvbJ3KN6SptvM7n85jhLNIV+Tao+UGP uVi3+f4KC9m2H9D7GnIjsWZQkxCfAo0di1RYG9L57wOIm/cCJYbn90nDm7sAvomb hxRAdJYCTM+xVvlhoiANqcXll9MS4yZTD5KhZR5DgZpCoJPbatxbEy3l3r9ZTFYb Xh3+plCk67mYClcbIo7Ln5+kWJMLKObTcSvHaApWJiMhrbU3eKoXNMZE+w90NSOW wcgyCg0F+VtwoN+EVWXv =9ZJL -----END PGP SIGNATURE-----

10 let, 7 měsíců

2
1
0 0

knot 1.6 an non-locl interfaces

by Peter Hudec

Hi, I need to listen on inteface which may not be present at start time. I want to ask if there is a way to enable non-local interface bind on KnotDNS 1.6. The version 2.X supports this feature, but thos version os nt available for CentOS /as I read in maliling list archive and seen the build for EPEL/. best regards Peter Hudec -- *Peter Hudec* Infraštruktúrny architekt phudec(a)cnc.sk <mailto:phduec@cnc.sk> *CNC, a.s.* Borská 6, 841 04 Bratislava Recepcia: +421 2 35 000 100 Mobil:+421 905 997 203 *www.cnc.sk* <http:///www.cnc.sk>

10 let, 7 měsíců

2
4
0 0

DDNS with python

by Ulrich Wisser

Hi! In the last few days I have tried a new service for DDNS, nsupdate.info. I have some problems with the service and I have been able to reproduce the problem in a small sample script. The attached script does update my bind9 instance but reports SERVFAIL for Knot. Unfortunately I still have not been able to get Knot to write more extensive log entries. The script uses the Python dns library from Nominum. This is the output of the script (first update to bind then to knot) $ python example.py performing add for name ddns.example.com and origin example.com with rdtype A and ipaddr 2.3.4.5 performing add for name ddns.example.com and origin example.com with rdtype A and ipaddr 2.3.4.5 DNS error [SERVFAIL] performing add for name ddns.example.com and origin example.com with rdtype A and ipaddr 2.3.4.5 Knot didn't log anything at all. (Any hints for that config would be welcome.) Bind did log the following Oct 5 21:07:49 localhost named[23792]: client beef::cafe#59322/key example.com: updating zone 'example.com/IN': adding an RR at ' ddns.example.com.' A Some error in the script? Could someone point me to a working script? Any hints are welcome! Kind regards from Stockholm Ulrich -- Ulrich Wisser ulrich(a)wisser.se

10 let, 7 měsíců

4
13
0 0

Knot DNS 2.0.1 patch release

by Jan Včelák

Hello everyone! CZ.NIC Labs just released Knot DNS 2.0.1. There is a lot of bug fixes, new features, and improvements since the final release. Let's start with the bug fixes: - The 2.0.1 received all the relevant bug fixes included in the 1.6.5. Namely fix for expired zones reloading, fix for race-condition in event scheduling, fix for NSEC proofs with zones containing lots of delegations, fix for TC flag setting in RRL slipped answers, fix for root label compression, and fix for journald logging without systemd. - The old version was incorrectly following CNAME when queried for the NSEC record. This is fixed in the new version. - There was a bug in the code planning DNSSEC resigning. The code hadn't considered expiration of DNSKEY RRSIGs and therefore these signatures could have had expired. This problem is resolved now. - Binding to an unavailable IPv6 address was broken on Linux (IP_FREEBIND). When the daemon was started before the network was fully up, the daemon failed to bind IPv6 addresses. This problem is fixed as well. - The knotc utility entered an infinite loop when the zonestatus or memstats command was executed for an individual zone. This shouldn't happen any more. - The dnsproxy module was not working properly as we have changed the request processing code without updating the module. This has been addressed. - There was a problem with parsing time stamps in the DNSSEC KASP database when compiled against the uClibc standard C library (e.g., in Alpine Linux). The parsing has been rewritten to work in strict POSIX environment. - We have fixed multiple problems related to endianness. We have eliminated compilation warnings on OpenBSD related to endian conversion functions. The multi-value config options parsing didn't work on big-endian machines. And we also added detection of the Nettle library version, because the version 3 changed the Base64 decoding API incompatibly. As for the new features: - The keymgr utility now supports 'zone key ds' command to retrieve DS records for a key. And also 'tsig generate' command to generate TSIG key in the format accepted by Knot DNS. - We have added module scoping. So the modules can be configured either to process all queries received by the server. Or their scope is limited to individual zones. - The 'include' config directive supports file name globbing. So you can import multiple files at once (e.g., include: conf.d/*.conf). - Same as in the 1.6.5, the 2.0.1 supports the 'request-edns-option' config option allowing to add custom EDNS0 options into the DNS queries initiated by the server. And at last but not least, the improvements: - We have decided to remove NS record from the Authority section for NOERROR responses. We used to put these records there because BIND and NSD did it. But these records are not required by any RFC and just increase the size of the response. - The persistent zone timers are written only on server shutdown for better startup performance. - The change of TTL over DDNS is now allowed without removing the existing records. - We have reviewed the documentation and fixed a couple of grammar mistakes, updated some sections, and improved formatting a little bit. - The yparser and zscanner header files are now installed. As you may see, we are not lagging behind. This list is quite long for a patch release. And we have much more up in our sleeve. Thank you for reading this far. And we are looking forward to your feedback. Full changelog: https://gitlab.labs.nic.cz/labs/knot/raw/v2.0.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-2.0.1.tar.xz GPG signature: https://secure.nic.cz/files/knot-dns/knot-2.0.1.tar.xz.asc Cheers, 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, 8 měsíců

4
6
0 0

Knot on Raspberry Pi (armhf)

by Ulrich Wisser

Hello! I have tried to get the latest version of Knot running on my Raspberry Pi 2. Unfortunately does Raspian only have packages for an old version. I updated my Pi to debian jessie. There is actually a version of Raspian based on jessie. That version of Raspian does come with slightly newer packages, but still not up to date. So I compiled my own version. 2.1.0-dev Everything works fine until the moment I try to start knotd. IT will crash with a segfault. I did recompile with --enable-debug but I do not get any debug output in syslog. I did run with gdb and got the following information SYSLOG: Sep 16 22:36:57 localhost knotd[3522]: info: Knot DNS 2.1.0-dev starting Sep 16 22:36:57 localhost knotd[3522]: info: binding to interface '2001:470:28:193::53@53' Sep 16 22:36:57 localhost knotd[3522]: info: configured 1 zones Sep 16 22:36:57 localhost knotd[3522]: info: changing GID to '1003' Sep 16 22:36:57 localhost knotd[3522]: info: changing UID to '1002' Sep 16 22:36:57 localhost knotd[3522]: info: loading zones Sep 16 22:36:57 localhost knotd[3522]: info: [example.com] zone will be loaded, serial 0 Sep 16 22:36:57 localhost knotd[3522]: info: starting server GDB: [New Thread 0x50baa200 (LWP 3526)] [New Thread 0x50aaa200 (LWP 3527)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x50baa200 (LWP 3526)] scanner_process (scanner=0x50978008) at knot/zone/zonefile.c:152 152 if (zc->ret != KNOT_EOK) { (gdb) bt #0 scanner_process (scanner=0x50978008) at knot/zone/zonefile.c:152 #1 0x76d80a14 in ?? () from /usr/lib/arm-linux-gnueabihf/libzscanner.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) l 147 148 /*! \brief Creates RR from parser input, passes it to handling function. */ 149 static void scanner_process(zs_scanner_t *scanner) 150 { 151 zcreator_t *zc = scanner->data; 152 if (zc->ret != KNOT_EOK) { 153 scanner->stop = true; 154 return; 155 } 156 (gdb) It seems that the scanner thread is somehow missing. But why? Anybody with experience with knot on armhf? /Ulrich -- Ulrich Wisser ulrich(a)wisser.se

10 let, 8 měsíců

2
1
0 0

Knot 2.0.1 debian 8 (jessie) builds

by Petr Jediný

Hello, are there any plans to publish latest builds (2.0.1) for jessie? The most current package I can find is knot_2.0.0-1+0~bpo80+1_amd64.deb. Regards, PJ

10 let, 8 měsíců

2
1
0 0

Knot DNS 1.6.5 patch release

by Jan Včelák

Hello list. Today, CZ.NIC Labs releases Knot DNS 1.6.5. This patch release contains quite a lot of non-critical bug fixes and some minor improvements. Everyone is advised to upgrade. Let's go through the fixed bugs quickly: - The server no longer loads expired zones on 'knotc reload' and server startup. - We have fixed a rare race-condition in the event scheduling code. The race caused that events for some zones were significantly delayed. (We were reported that the server is occasionally ignoring notify messages for random zones when the server is receiving many notifies. We believe this bug was the cause and the problem should no longer appear.) - There was a bug in the NSEC proofs construction. When the zone contained many delegations, the NSEC proving non-existence of a covering wildcard was incorrect. The problem is fixed now. - The TC flag was not set correctly for RRL slipped answers. This problem is resolved as well. - We have disabled domain name compression for the root label '.' because it caused negative compression and some client implementations (like Go DNS) might have problem decoding these answers. - The server is now checking whether it is executed in the systemd enviroment before using journald as a sink for log messages. Also the systemd library detection at a build time was improved. - We have also eliminated compilation warnings in endian-conversion functions on OpenBSD. And as for the new features: - The persistent timers are now written to the on-disk database only on server shutdown. This change was done mainly to improve startup and reload performance. - The 'max-conn-idle', 'max-conn-handshake', 'max-conn-reply', and 'notify-timeout' config options now accept time units specification (e.g., one can use 2m instead of 120). - We have added 'request-edns-option' config option, which allows inserting custom EDNS0 options into all queries initiated by the server. And that's all folks. I would like to thank everyone involved in making this release, especially bug reporters. We are looking forward to your feedback. The sources are available 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.5.tar.xz https://secure.nic.cz/files/knot-dns/knot-1.6.5.tar.gz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.6.5.tar.xz.asc https://secure.nic.cz/files/knot-dns/knot-1.6.5.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, 9 měsíců

2
2
0 0

Refreshing DNSKEY RRset signatures

by Antti Ristimäki

Hi, I'm running Knot 2.0.0 and automatically signing my zone with manual key management policy. When I manually refreshed the signatures by running "knotc signzone <zone>", all the signatures were refreshed as expected, except the DNSKEY RRset, whose signature remained untouched. I thought this wouldn't be a big deal, as Knot would probably automatically refresh DNSKEY RRset signature when about 1/10 of its lifetime will be remaining. However, when I now look at "knotc zonestatus", it shows that the next resigning is scheduled far beyond the exipration of the DNSKEY RRset signature. So, is my DNSKEY RRset signature going to be expired or is DNSKEY handled in some special way so that it will be eventually refreshed before expiring? My current DNSKEY RRSIG will expire at 20150828172101: nxdomain.fi. 600 IN RRSIG DNSKEY 8 2 600 20150828172101 20150729172101 61894 nxdomain.fi. qQJm..... But the next resigning is scheduled on 2015-09-14: nxdomain.fi. type=master | serial=2015081708 | DNSSEC resign in 647h56m43s | automatic DNSSEC, resigning at: 2015-09-14T02:26:59 Thanks, Antti

10 let, 9 měsíců

2
1
0 0

first time install got failed

by Ken Peng

Hi, My system is debian 6.0 (yes I know it's out of date). When I installed knot from source following the document, I got failed as below. How can I get continued? thanks. $ autoreconf -i -f libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' configure.ac:35: error: possibly undefined macro: AC_SUBST If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:93: error: possibly undefined macro: AS_IF configure.ac:102: error: possibly undefined macro: AC_MSG_WARN configure.ac:122: error: possibly undefined macro: AC_DEFINE configure.ac:163: error: possibly undefined macro: AC_MSG_ERROR configure.ac:251: error: possibly undefined macro: AC_SEARCH_LIBS autoreconf: /usr/bin/autoconf failed with exit status: 1

10 let, 9 měsíců

2
8
0 0

More fine-grained ACLs

by Matthias-Christian Ott

Network renumbering requires that A and AAAA RRs are directly or indirectly (DHCP) updated. This in turn requires dynamic DNS updates (RFC 2136). Although Knot DNS allows dynamic updates, it is not really prepared to securely handle this scenario. Knot DNS can either allow an address or key to update RRs in a zone via ACLs which is not fine-grained enough to useful for this purpose because it is questionable from a security perspective (under a certain threat model etc.). Assume that example.com uses dynamic DNS updates to update A and AAAA RRs to be prepared to renumber its network. If example.com uses a DHCP server to update the RRs, it suffices to take over the DHCP server of example.com to update any RRs in the zone of example.com, including NS, MX, TLSA and SSHFP RRs. If every host of example.com updates its own A and AAAA RRs directly and indirectly via a DHCP server, the problem is still the same, even if you move every hostname in a separate zone, for example it suffices to take over the webserver that serves example.com to change the MX RRs of example.com. With more fine-grained ACLs the problem would not exist. Currently ACLs consist of a subject (address and key), operation (transfer, notify, update, control) and object (zone). I think it would suffice to extend the object of an ACL to a triple (zone, name, type) similar to dynamic update policies in BIND. Perhaps it would also be useful to be able to use wildcards and negation. Are there any plans to extend the ACL mechanism in this way? Regards, Matthias-Christian

10 let, 9 měsíců

2
1
0 0

Keymgr broken?

by shadice＠arcor.de

Hi Is keymgr broken or what am I doing wrong? /knot# mkdir kasp /knot# cd kasp /knot/kasp# keymgr init /knot/kasp# keymgr zone add example.com policy none /knot/kasp# keymgr zone key generate example.com algorithm rsasha256 size 2048 ksk id 36b49807bcdf448c5034cf37688b99616760529c keytag 24400 knot/kasp# keymgr zone key generate example.com algorithm rsasha256 size 1024 Cannot retrieve zone from KASP (malformed config value). Regards, shadice

10 let, 9 měsíců

2
2
0 0

knot 2.0.0 and systemd type notify

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, 10 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, 11 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

11 let

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, 1 měsíc

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, 1 měsíc

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, 3 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, 3 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, 3 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, 4 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, 5 měsíců

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, 6 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, 6 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, 7 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, 7 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, 7 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, 7 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, 7 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, 8 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, 8 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, 8 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, 8 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