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

9 let, 12 měsíců

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

9 let, 12 měsíců

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

9 let, 12 měsíců

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

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

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, 2 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, 3 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, 3 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, 4 měsíce

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, 4 měsíce

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users