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

[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

10 let, 5 měsíců

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

10 let, 5 měsíců

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

10 let, 5 měsíců

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

10 let, 6 měsíců

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

10 let, 6 měsíců

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

10 let, 6 měsíců

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

10 let, 7 měsíců

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?

10 let, 7 měsíců

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

10 let, 7 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.

10 let, 8 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

10 let, 8 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

10 let, 8 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

10 let, 8 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

10 let, 9 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

10 let, 9 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

10 let, 9 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

10 let, 9 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.

10 let, 9 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

10 let, 10 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?

10 let, 10 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?

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

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

10 let, 10 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!

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

10 let, 10 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.

10 let, 10 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.

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

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

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

10 let, 11 měsíců

1
0
0 0

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

by Ondřej Surý

Could you please flush your DNS cache (deb.knot-dns.cz should point to sophie.nic.cz now) and try again? The debarchive got broken and I couldn't fix it, so it has been replaced by reprepro. In case you can't flush your caches, please just temporarily change deb.knot-dns.cz to sophie.nic.cz. Also the repository is now signed: # wget -O - http://deb.knot-dns.cz/debian/apt.key | apt-key add - Full instructions can be found here: http://deb.knot-dns.cz/debian/README.txt Ondrej -- 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

10 let, 11 měsíců

1
0
0 0

problem with debian repository

by Peter Hudec

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. http://deb.knot-dns.cz/debian/dists/wheezy/main/binary-amd64/Packages http://deb.knot-dns.cz/debian/dists/wheezy/main/binary-i386/Packages http://deb.knot-dns.cz/debian/dists/wheezy/main/source/Sources .... I tested only wheezy distribution release. best regards Peter Hudec

10 let, 11 měsíců

3
2
0 0

Knot DNS 1.5.2 bugfix release

by Jan Kadlec

Hello list! Today, Knot DNS version 1.5.2 has been released by CZ.NIC Labs. This is a bugfix release. Unfortunately, while doing some internal testing, we've found a remote vulnerability that can crash the server. So far, we've had no reports that would suggest that someone else has discovered this vulnerability, but it is important all users upgrade as soon as possible. CVE for this vulnerability is CVE-2014-0486. We've also included a couple more fixes: Knot was refusing AXFR-style IXFR transfers, meaning these transfers had to be sent twice. Further, Knot was not properly escaping the hash character in domain names when saving the text zone file. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.2.tar.xz.asc Again, we advise all users to upgrade immediately. We are truly sorry for any inconvenience caused by this. 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

10 let, 11 měsíců

2
1
0 0

knot init in Debian

by Zdeněk Zámečník

I have following issue with Knot: when I try to stop it by command /etc/init.d/knot stop then the daemon is still running. If i run command knotc stop then it's stopped but immediately run again. If I kill it by command kill, it's the same... As I found the /etc/init.d/knot is not working at all and Knot is probably run during boot by /etc/init/knot.conf and I'm not able to control it. The "unkillable" proccess is named /usr/sbin/knotd -c /etc/knot/knot.conf My environment: Debian 7 AMD64, OpenVZ container, kernel 2.6.32-openvz-042stab092.2-amd64, Knot 1.5.0-1 I tried to install Knot on another older machine where is Debian 7 too but upgraded from 6 and it's KVM virtual machine. There it works correctly via init.d script and the proccess is named /usr/sbin/knotd *-d* -c /etc/knot/knot.conf Do you have an idea why it's working on older machine correctly and on the second with OpenVZ not? Thanks for any help. Zdenek Z.

10 let, 11 měsíců

6
10
0 0

multimaster docs?

by Nicolás Reynolds

hi, i see knot 1.5.0 has multimaster support but i can't find more info/docs on this, can you point me to it? -- D

10 let, 11 měsíců

3
3
0 0

Knot and systemd

by Anand Buddhdev

Hello Knot folk, I'm building Knot RPM packages for use on CentOS 7, and I have to write systemd unit files. Before I write anything, I'd love to hear from others who may already have done such work, to learn from it. Let me describe my ideas. On my existing Knot servers running on CentOS 6 with upstart, I have 2 upstart scripts, viz. knot.conf, and knot-instance.conf. The knot.conf upstart script looks in /etc/knot for .conf files, and for each one, runs knot-instance with the config file as a parameter. This way, a simple "start knot" will start all instances. In systemd, there is better support for instances, so I want to create a knot@.service template unit, and a knot.target target unit. Then, I can create new instances with "systemctl enable knot(a)conf1.conf" and "systemctl enable knot(a)conf2.conf". Finally, running "systemctl start knot.target" should start all configured instances. Does this sound reasonable? I would also like to know about Knot's built-in support for systemd. I can't find any documentation about it. Could one of the devs please describe what Knot actually does if it's compiled with systemd support? Would you mind adding this information to the online documentation? Regards, Anand

10 let, 12 měsíců

2
3
0 0

Knot DNS 1.5.1 release

by Jan Kadlec

Hello list! Today, CZ.NIC Labs are releasing Knot DNS version 1.5.1! Let's discuss bugfixes first. Most notably, we've fixed a bug in automatic DNSSEC signing: domain names in RDATA were not lowercased before signing, resulting in bogus signatures. Other interesting bugfixes include proper handling of DDNS prerequisites and some TSIG and EDNS corner cases. As for the new features, we've added a basic support for logging using systemd journal. At the moment, log messages related to zone have the ZONE field set, which means that you can easily filter log messages based on zone name criteria. We plan to add more fields in the future to allow more fine-grained filtering. We're looking forward to your suggestions in this area. Moreover, we've improved DDNS performance for large zones by grouping incoming updates together and executing them as a bulk. This partially mitigates problems with RCU and copying the zone structure, but dynamic updates' running time is still proportional to size of the zone and not to the size of the actual updates. Improving this is one of our top priorities, and code in this release will help us to do so. Finally, we've improved and unified format of logging messages. Most notable, each logging message concerning a zone is now prepended with [zone name]. If you parse the output of log files, be sure to update your scripts. Further, we now enforce a more strict policy for DNSSEC signing keys: at least one active pair of KSK and ZSK keys of the same algorithm must be present at all times, or Knot will refuse to sign the zone. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.1/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.1.tar.xz.asc Be sure to let us know if you run into any problems. Have a nice day 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

10 let, 12 měsíců

1
0
0 0

workflow for zone signing on master

by chrysn

hello, i'm operating a small hidden master server (four zones spread out to two external NS servers), and want to introduce dnssec. so far, i have kept my zone files in /etc under version control, but now knot starts overwriting them, which is kind of important because of the serial number increments, but also removes file structure, and comments and generally messes with the changelog. i could not quite infer from the documentation what the recommended work flow is in this situation: * will things work if i just make the zone files read-only for bind? * should i keep the original files separate and copy them over to the knot-writable destinations for each refresh? if yes, can that be automated from within knot? in either case, i have to take care of the serial numbers. my current numbering scheme (YYYYMMDDXX with year, month, day and per-day number) produces sufficiently few automated changes that incrementing by 10 each time i edit the unsigned file on one deay would work, but what is best practice there? best regards chrysn ps. please keep me in cc when replying, as i'm not subscribed to the list. -- There's always a bigger fish. -- Qui-Gon Jinn

11 let, 1 měsíc

4
4
0 0

Knot DNS 1.5.0 final release

by Jan Kadlec

Hello Knot DNS users! After two release candidates, CZ.NIC Labs proudly release Knot DNS 1.5.0 final. This new version differs greatly from the old 1.4 branch - we've rewritten quite a big portion of our code, and we've built a foundation for next cool features to come. But you've probably read about the changes in 1.5.0 in the previous release messages, so here's just a brief list of improvements that are visible to users: Optional query modules (currently we have dnstap and response synthesization modules implemented), lower memory footprint and improved zone events handling (for those of you with problems with zone expiring, 1.5.0 should not have this problem). We've also done a lot of under-the-hood changes, with lots of refactoring and massive code reductions. Apart from all this, we've been very busy writing tests - our current test code coverage is around 75 percent. Here are the changes we've made from 1.5.0-rc2: Features: - DDNS forwarding reimplemented Improvements: - Transfer sizes logged in bytes if needed - Logging outgoing NOTIFY messages - Logging unauthorized incoming NOTIFYs Bugfixes: - Zone flush planning after bootstrap - Incorrect incoming AXFR message sizes - DDNS signing changes were freed too soon, with possibility of stale data - knotc remote control key handling Changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.0.tar.xz.asc We've done all we could to test Knot DNS 1.5.0 on our end, now it's time you gave it a try! We hope you'll be as happy with it as we are. Today's thanks for bug reports go to Anand Buddhdev and Motomu Utsumi. Have a nice day 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, 1 měsíc

1
0
0 0

Re: [knot-dns-users] Two hidden masters - sending notifications to public slaves.

by Ondřej Surý

Hi Maren, you should turn the explicit notification both in bind and knot. For Knot use "notify-out <slave1> <slave2>;" + "xfr-out <slave1> <slave2>;" See the documentation: https://www.knot-dns.cz/static/documentation/html/configuration.html#master… For Bind use "notify explicit;" + "also-notify;", see: http://www.zytrax.com/books/dns/ch7/xfer.html#notify Ondrej -- 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: "Maren S. Leizaola" <leizaola(a)udr.hk.com> > To: knot-dns-users(a)lists.nic.cz > Sent: Monday, July 7, 2014 1:32:52 PM > Subject: [knot-dns-users] Two hidden masters - sending notifications to public slaves. > Hi, > > We are setting up to do zone generations of two separate hidden masters > which will take turns on the zone generation. > > Public/visible DNS servers "should" get notifies from both servers and > select the one with the with the highest serial number. > > I am planning to run bind on one server and knot on the other. On bind i > have the issue that it would not send notifies to the name servers until > I turned on "notify-soa yes;". However I realise that his will only > notify one single DNS server and introduces a single point of failure. > > Does Knot have any issues sending the notifies. How do I go about > getting this done? > > Regards, > Maren > > _______________________________________________ > 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, 1 měsíc

4
5
0 0

Problem with expiring zones - new stable version

by Jakub Stollmann

Hello, after upgrading to new stable version 1.4.7 we noticed a problem with zones, which are expiring (i've seen some bugfix -expiration timer). It happened second time now, and i think its happening every week (7days). Zones, which expired are selected randomly, count of expired zones is ~8. expired zones are listed like this: somezone.net. type=slave | serial=0 | bootstrap idle | After manually refreshing zone everything works fine. TTL is 86400 - 1 day We are using knot as slave dns. Bind9 is master. Thanks for some advices. Jakub

11 let, 1 měsíc

2
1
0 0

Random source port for incoming NOTIFY

by Gonzalo Muñoz

Hello everybody, We're currently testing Knot for a slave server with a BIND master, and we've noticed that NOTIFY messages from this master are not being processed by Knot. As I understand, BIND uses a random source port for NOTIFY messages, as a precaution against attacks. Also, if I understand correctly, when I add a remote master to a zone in Knot, if I don't specify a port for it then it defaults to 53- This leads me to believe that Knot is rejecting NOTIFY messages from the BIND master, because they come from an unexpected, random port. Is this correct? Can this situation be rectified to allow NOTIFY messages from random ports? Thank you very much in advance. Gonzalo Muñoz NIC Chile

11 let, 1 měsíc

3
4
0 0

Two hidden masters - sending notifications to public slaves.

by Maren S. Leizaola

Hi, We are setting up to do zone generations of two separate hidden masters which will take turns on the zone generation. Public/visible DNS servers "should" get notifies from both servers and select the one with the with the highest serial number. I am planning to run bind on one server and knot on the other. On bind i have the issue that it would not send notifies to the name servers until I turned on "notify-soa yes;". However I realise that his will only notify one single DNS server and introduces a single point of failure. Does Knot have any issues sending the notifies. How do I go about getting this done? Regards, Maren

11 let, 1 měsíc

1
0
0 0

Knot DNS 1.4.7 patch & 1.5.0-rc2 releases

by Jan Kadlec

Hello list! Today we release two new versions of Knot DNS: 1.4.7 patch release and a second release candidate of 1.5.0: 1.4.7 patch release fixes few minor issues and one major one, here they are in the order of their importance: - Assertion failure when serializing NAPTR records - this error can pop up with DDNS and transfers, regular queries are safe. - Knot could send mismatched IXFRs with automatic DNSSEC enabled. - Some DDNS corner cases were not handled properly. - Slave zone EXPIRE timer could be improperly set. - Zone semantic checks gave some false positive warnings. The NAPTR assertion failure is quite serious, so we recommend all users to update. We sincerely apologize for this. Hopefully all the code reduction and refactoring we did will pay off and versions 1.5 and beyond will see fewer patch releases. Changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.7/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.7.tar.xz.asc 1.5.0 second release candidate contains two new features: - edns-client-subnet support for kdig, see https://gitlab.labs.nic.cz/labs/knot/issues/252 for more info - Asynchronous startup is now configurable (config option "asynchronous-start"). Two minor improvements: - Faster zone reload. - Text zone files are no longer written to disk right after bootstrap, but are flushed in accordance with the "zonefile-sync" config option. And the following bugfixes: - Knot did not close connection with remote during transfer when the remote replied with SERVFAIL. - Knot was giving wrong log message during IXFR -> AXFR fallbacks. - Some zone events were not handled properly during reloads. We encourage everyone to give the second release candidate a try and send us as much feedback as possible :) Changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.5.0-rc2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.5.0-rc2.tar.xz.asc We'd like to thank Anand Buddhdev, Alex Massover and Bastien Durel for feedback and bug reports. Have a nice day 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, 2 měsíce

1
0
0 0

Parallel dynamic DNS updates

by Alex Massover

Hello, I'm trying to understand if Knot can solve our performance problem with big scale dynamic DNS deployment. Currently we use BIND and the performance of Dynamic Updates is insufficient for our requirements. Doing some research I understood that BIND processes updates sequentially and can't really benefit from SMP. I understand how RCU allows parallel reads with updates. But reads is not an issue in our deployment. My question is, does Knot able to process multiple updates in parallel (and not sequentially) and provide a better scale for _updates_? As far as I understand it depends on data structure hierarchy implemented in Knot. -- Alex Massover | Telefónica Digital Architect M +972-54-2279512 alex(a)jajah.com<mailto:alex@jajah.com>

11 let, 2 měsíce

3
7
0 0

Knot 1.4.6 Aborted on NAPTR ddns update

by Alex Massover

Hello, We have Knot 1.4.6 on CentOS installation. When doing NAPTR ddns update, like this: nsupdate > server x.x.x.x > update add 3.1.1.1.1.1.1.1.1.2.7.9.9.our.domain.com. 172800 NAPTR 1 1 "u" "E2U+sip" "!^.*$!sip:123@freeswitch.org!" . > send ; Communication with server failed: timed out It fails with: knotd: libknot/rrset.c:1703: rrset_serialize: Assertion `size_one == rr_size' failed. Aborted No issues with ddns updates with TXT records. -- Alex Massover | Telefónica Digital Architect M +972-54-2279512 alex(a)jajah.com<mailto:alex@jajah.com>

11 let, 2 měsíce

2
2
0 0

Re: [knot-dns-users] Master-slave replication

by Bastien Durel

Le samedi 14 juin 2014 à 00:10 +0200, Jan Kadlec a écrit : > Hello, > one more thought: Could you please check your master log file for this > warning message: (log for category: zones and severity: warning has to > be enabled) "Zone file for '...' changed, but serial didn't - won't > create changesets."? This happens when you change the zone, but the > serial remains the same. > Note that Knot will change the serial when automatic DNSSEC is enabled, > so before creating the zone file in the script, you have to get the > current serial from server and increment that serial. Updating your zone > files using this approach might help you, but it is nevertheless a bug. Hello, I had this warning sometimes. I edit my zone files with emacs in zone mode, so the serial is auto-incrementing, but I have to save it twice to pass over the dnssec auto-increment. I put a check in my makefiles to ensure the old serial is lower than the new one. Look like it works with that, here was my mistake :) Thanks a lot ! Regards, -- Bastien Durel <bastien+knot(a)durel.org>

11 let, 2 měsíce

1
0
0 0

Master-slave replication

by Bastien Durel

Hello I have some zones in 2 knots in a master-slave relation When I update zones in master, there are replications issues in slave: - sometime changed records are duplicated (old and new value) - sometime removed records persists - sometime the RRSIG records are duplicated (old and new value) I often have to erase slave zones and to restart knot to get correct zone. I update master zone via makefiles that re-create (unsigned) zone files and then reload knot via knotc What is my mistake ? Regards, -- Bastien

11 let, 2 měsíce

2
3
0 0

Re: [knot-dns-users] Parking page with a large number of zones pointing the the same file.

by Ondřej Surý

Hi Maren, it would never be the 'same' zone file, since you have different full labels (foo.example.net is different from foo.example.com) per zone after loading them into the memory. I would suggest that this use case scenario would be best served by some new query processing dynamic module[1] that you would configure for all those zones and that would always respond with the same data. 1. See the Knot DNS 1.5.0rc1 release notes and documentation Ondrej -- 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: "Maren S. Leizaola" <leizaola(a)udr.hk.com> > To: knot-dns-users(a)lists.nic.cz > Sent: Thursday, June 12, 2014 7:50:02 PM > Subject: [knot-dns-users] Parking page with a large number of zones pointing the the same file. > Hello, > I would like to know what the memory allocation/usage > would be like if say I point 1M zones to the same zone file. > > Will it allocate memory for each of the zones or can it just allocate > memory once as it is the same zone file ? > > Regards, > Maren. > _______________________________________________ > 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, 2 měsíce

2
1
0 0

Parking page with a large number of zones pointing the the same file.

by Maren S. Leizaola

Hello, I would like to know what the memory allocation/usage would be like if say I point 1M zones to the same zone file. Will it allocate memory for each of the zones or can it just allocate memory once as it is the same zone file ? Regards, Maren.

11 let, 2 měsíce

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users