knot-dns-users

knot-dns-users@lists.nic.cz

4 participants
707 discussions

by Jan-Piet Mens

Hello! after reading and rereading the documentation (release 2.9) section on automatic KSK management, and rereading it again, I finally understood the part which says "the user shall propagate [the DS] to the parent". In particular due to the log entry info: DS check, outgoing, remote 127.0.0.1@53, KSK submission attempt: negative and the phrasing of the "submission:" configuration stanza, I thought Knot would attempt to do so itself via dynamic update. I think I was injecting too much wishful thinking into the text. :) Now to my two questions: Is it envisioned to have Knot launch an executable in order to perform the submission? I'm thinking along the lines of Knot running at every `check-interval': ./ds-submitter zone "<cds>" "<cdnskey>" upon which the ds-submitter program could (e.g. via RFC2136) add DS RRset to the parent zone. Might be nice to have ... (I did see the bit about journald and using that to trigger DS submission, but using journald frightens me a bit.) I notice that a dynamic update on 2.9 logs info: [zone.] DDNS, processing 1 updates is there any way to get more details logged (what the update actually was)? My configuration contains: log: - target: syslog server: debug control: debug zone: debug any: debug Thank you. -JP

5 let

Knot DNS 2.9.1 release

by daniel.salzman＠nic.cz

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.9.1! This version primarily fixes some issues relating zone updates or compatibility with previous versions. It's recommended to update from 2.9.0. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.9.1/NEWS Source code: https://secure.nic.cz/files/knot-dns/knot-2.9.1.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.9.1.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.9/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

5 let

KASP sharing

by Bastien Durel

Hello, Is KASP directory sharing possible between different knot instances ? (I have a "public" instance and a "private" one, with internal addresses, using different storage: directories, but the same kasp-db:) The internal one sometimes returns invalid DNSSEC data for non-existant names until I restart it. Is it to be expected in this setup ? Thanks, -- Bastien

5 let

slave strange behaviour

by Bastien Durel

Hello. I found another strange behaviour on my slave : it kept old RRSIG's for SOA entries. I fixed it by running zone-purge, then zone-retransfer ; <<>> DiG 9.11.5-P1-1~bpo9+1-Debian <<>> +dnssec @87.98.180.13 caa www.geekwu.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12546 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 19, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;www.geekwu.org. IN CAA ;; AUTHORITY SECTION: geekwu.org. 86400 IN SOA ns.geekwu.org. hostmaster.geekwu.org. 2019101730 3600 1200 2419200 10000 geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054714 20181104041714 54076 geekwu.org. 8b6lzlyI1fZUxwtCt9GHsRu1Ist1CtDFm+NifSTTESoMK3XAnW8gyZzp UIEmNiIRKdYnze+FsW+oEw4hm9pkW/lwgIls3tBvLKCwRseUwrj5jIbh rPK9fYuWM0RP1HBj geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054719 20181104041719 54076 geekwu.org. uoRZZ4jV2jaubsH7W3VIpIdu9iVKYnz9q+GpNHSnEDv4Mt5JcVnLChLk /eeRKSK9U7h8yFSOmxdcTBIyITlbGGBeeVbZFdQYsSshpN1Fa7YME9JU ttr5tISHoPnHlM2y geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054723 20181104041723 54076 geekwu.org. /2EY2DNqeX0GqK0eDcg3dFIqgH0346fP1XuIHM3oswRMnFMtCEDuD325 jpqByKlOkl4Edlv/GyJlJXohrdlWyTzE2xCM6ad2ordYHu0eCO8npfEi OOPc2HhtBYQUM+TU geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054727 20181104041727 54076 geekwu.org. OwfeorMdvR3Q4XvkSfNxruYJfcPRPIhsnDrrYk41L1gIYMRwEfapO/Te tza5M07CGx0rQPvFejXHRr7vzlatxvI9k9Vqrs12CR1q7ak+NVhxcM53 syCJVN/z8iKu5uYV geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054731 20181104041731 54076 geekwu.org. DpyZ6MCWuEA025ghGRJBISd0Lp7qXWb3R27+R/+FWnIytoLrIIzgRLI5 TEojx/k6hlbwFszH024T5CP5vQ1WXjIVyF9ZwNjseJ+skZgPx5ySzqrI R8WXgdpKYi4+SrYs geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054738 20181104041738 54076 geekwu.org. nNr2vNwLQSlDE7UXQWxGCiTTKb3wyx5VSzhoB8W8ovkSD9EHbcAr3QuP cR3ICASDhnWySB4NEB7i+qncT90+JEccuxvT8fBCoMHJtMy0YjNqsTLd tOOSitLogl4h8the geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054741 20181104041741 54076 geekwu.org. /28OcE9l7MXN9wKl2vpI5fxNpu6Ia1i4ku3V61Pix2JPKKJ4YhYG1BDw aBnpncgso71CiJyVz1Rsp1X50V6tGdibtP/ckRdqvl9f+W+KeCvcrcaS 8u4a5BjeqDFokrfY geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054743 20181104041743 54076 geekwu.org. GA4eFm1u4jxa+Jhu4vWa+UoucY7OES/8bKxkaIMte0AsC7bPovWdS8Qx 6zrrS9u1PEXS4dDy+PeCxPQFSefaPfiEY44J8JILTaf4OfiL+ij7RI2m MrN1e428veGFFfrY geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054746 20181104041746 54076 geekwu.org. MnF6nqK/UV+Q68Lf6mV80E4FcClEARc9gclqH4jP0gaxco/DpqGhWEgG yKM/E8ePIPOaUyRqdoiRKfWS2xcQExhqbeS+orcUjKx04BxDbp8rpCFG lRhR+QLEO4SpTrKo geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181118054749 20181104041749 54076 geekwu.org. MygQqAnclUn//WxI3gi04Fjkcim/7C4rusz0pj0RXOwl5yAQZMj5gFl7 v5WtUdxbysOhGiiJeHHpWWepD46E2DIlpAp/vKC8hw/DGNRSk6gT6cWl UqylhEIgKrekqVb4 geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181125063021 20181111050021 54076 geekwu.org. h1vHar/cdzpfTbVPhP6UW11aW6pB+1sfagKMBIPDif8mDjvLOP1KsTvI LuAUUNHaQgcYaoYwc9MrSQ+/se6CweK80B+O7pk+GFSWfqygyHhEvHZt YOHX183eKtYyjFix geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181125063028 20181111050028 54076 geekwu.org. hDTZuOOKCCWEYlWApA/g+RdSOKxfEGmttto8/BwUNYGBs/2dHziAIQlD y4SQh2ST1crUeHOTL7d8o+naqbt2lT7pMNqrUQy6XXYdVZ4gQ6aIjVkG Yi7kRgdG8Nksm31N geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20181213181717 20181129164717 63974 geekwu.org. 6BspV1velFjzJQqmGejOSyV6A9NOg3n486/mAx4llB4d+S1KF3j7dzzX TmMalQN2QufP7NDCVaV4kmtoOgUwS/XcfAQeDJ/b5/bYNa1ERf/tV6bJ 3Z4by5PlXdqoPte5 geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20190113191717 20181230174717 21289 geekwu.org. 2+WLMBHmrc2hygRoGtZbtgxikv6aHRv5xDg07nKldKKk/oR9l2GtjpUt yaMtgu+x/5Uk02eCwea+Vs41wq7BfzcZlL5SNqud9vFqCWAH3izikfLL mngKO3HHBvzxmqgy geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20190213201717 20190130184717 63065 geekwu.org. 8xL2eX4atI6Z+CxwZaF4cwGmNKXY389Qsnz9qZZkXdGcnmzYct5UVBl1 LM0bR/e3D5ZCAhdFR8NynhUKPwCKaSgivjzKNmLunqDFUJgM/4fZFAP8 pXce50jpYXVMBmhm geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20190316211717 20190302194717 19071 geekwu.org. FdHJKayUYfLsXu9ct9Mfvo1nVRei8xExluWbOfD9wbe/ZDqFQKyBvWKr hMrdUvSgCQ52iaTWl88cdPtho8YgGXRC+qse5rzqK+9toKbFryg/jFAX 18xJSYrntilYJm1u geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20190416221717 20190402204717 14519 geekwu.org. kIBe1/zzEbX09gKk0R6MbAicxfoGjL1ojWvR/8oQBdld1yVtyMtLWKic NhkellgCaXIb7cluj/SAUQC2lr9tJxZp31oG+DhQBAG2arQAVtphxJ0p yUwD7klvUweJM49Y geekwu.org. 86400 IN RRSIG SOA 14 2 86400 20191109090028 20191026073028 47945 geekwu.org. 9tmNQt48ZT3aTV/WkcfPpLQ3/3rpKXaDlasT9+EnRyniLrLuuHgQtRfw uxvJpillbGVn15uy9aoMDADV9K5DfdaNOgskK1v3QYgMpGtao+soydi/ Y9MyfDFUQNmSUIKD Therefore, let's encrypt checks failed when querying it with "detail": "DNS problem: SERVFAIL looking up CAA for arrakeen.geekwu.org" ; I guess their validating resolver did not picked the correct RRSIG, and failed to validate. If you want to investigate, I have another zone which have the same problem, and a bit more time before certificate expiration, for which I can provide details, journal, etc. Regards, -- Bastien Durel

5 let

no usable master

by Bastien Durel

Hello, I have a problem with a knot slave instance, which does not refresh anymore. When doing a retransfer, I have a "no usable master" error, with this error log: oct. 21 11:02:16 corrin knotd[32453]: info: [geekwu.org.] control, received command 'zone-retransfer' oct. 21 11:02:16 corrin knotd[32453]: 2019-10-21T11:02:16 info: [geekwu.org.] control, received command 'zone-retransfer' oct. 21 11:02:17 corrin knotd[32453]: info: [geekwu.org.] AXFR, incoming, remote 10.42.42.6@53, starting oct. 21 11:02:17 corrin knotd[32453]: 2019-10-21T11:02:17 info: [geekwu.org.] AXFR, incoming, remote 10.42.42.6@53, starting oct. 21 11:02:18 corrin knotd[32453]: debug: [geekwu.org.] refresh, remote master, address 10.42.42.6@53, failed (connection reset) oct. 21 11:02:18 corrin knotd[32453]: 2019-10-21T11:02:18 debug: [geekwu.org.] refresh, remote master, address 10.42.42.6@53, failed (connection reset) oct. 21 11:02:18 corrin knotd[32453]: 2019-10-21T11:02:18 warning: [geekwu.org.] refresh, remote master not usable oct. 21 11:02:18 corrin knotd[32453]: 2019-10-21T11:02:18 error: [geekwu.org.] refresh, failed (no usable master) oct. 21 11:02:18 corrin knotd[32453]: warning: [geekwu.org.] refresh, remote master not usable oct. 21 11:02:18 corrin knotd[32453]: error: [geekwu.org.] refresh, failed (no usable master) On master, I have this error log: oct. 21 11:02:16 arrakeen knotd[20289]: info: [geekwu.org.] AXFR, outgoing, remote 10.120.42.42@33435, started, serial 2019100808 oct. 21 11:02:16 arrakeen knotd[20289]: 2019-10-21T11:02:16 info: [geekwu.org.] AXFR, outgoing, remote 10.120.42.42@33435, started, serial 2019100808 oct. 21 11:02:16 arrakeen knotd[20289]: debug: TCP, send, address 10.120.42.42@33435 (connection timeout) oct. 21 11:02:16 arrakeen knotd[20289]: 2019-10-21T11:02:16 debug: TCP, send, address 10.120.42.42@33435 (connection timeout) tcpdump shows a TCP connection from 10.120.42.42 to 10.42.42.6, which is closed with a TCP FIN by 10.42.42.6 after 1.2s Do you have hints about that ? Thanks, -- Bastien Durel

5 let, 1 měsíc

[2.9] DDNS failure

by Bastien Durel

Hello, Since I upgraded to 2.9 (2.9.0-1~cz.nic~buster1), DDNS update fails: oct. 14 11:10:25 arrakeen knotd[15543]: info: [durel.org.] DDNS, processing 1 updates oct. 14 11:10:25 arrakeen knotd[15543]: error: [durel.org.] DNSSEC, failed to fix NSEC3 chain (invalid parameter) oct. 14 11:10:25 arrakeen knotd[15543]: 2019-10-14T11:10:25 error: [durel.org.] DNSSEC, failed to fix NSEC3 chain (invalid parameter) oct. 14 11:10:25 arrakeen knotd[15543]: 2019-10-14T11:10:25 error: [durel.org.] DDNS, processing failed (invalid parameter) oct. 14 11:10:25 arrakeen knotd[15543]: error: [durel.org.] DDNS, processing failed (invalid parameter) DDNS are generated with knsupdate: knsupdate -k /etc/letsencrypt.sh/hooks/tsig.key $file Is there a config change that can explain that ? Thanks, -- Bastien Durel

5 let, 1 měsíc

KSK automated rollover: New KSK generation

by Sakirnth (BFH)

Hello, I am using knot version 2.7 with automated keyrollover for DNSSEC. I am trying to understand the rollover process so that I can exactly predict when a rollover is in progress. So far I have understood this: KSK (1) [created and published] ---(progapagtion delay + DNSKEY TTL)--> KSK (1) [ready] ---(submitted in parent zone)--> ---((KSK-TTL) - (DNSKEY TTL + propagation delay + DS parent TTL + x))-> KSK (2) [created and published] KSK (2) [ready] ---(submitted in parent zone)--> KSK (1) [retire-active], KSK (2) [active] ---(propagation delay + DNSKEY TTL)-> KSK (1) [removed] My observartions during the rollover: Knot configuration: DNSKEY-TTL: 12h Propagation-delay: 2h Zone TTL default: 1h KSK-lifetime: 3d ZSK lifetime: 0 Parent configuration: DS-TTL on parent: 1h KSK (1) [created and published] ---(progapagtion delay + DNSKEY TTL)--> KSK (1) [ready] ---(submitted in parent zone)--> ---((3d) - (12h + 2h + 1h + x))-> KSK (2) [created and published] KSK (2) [ready] ---(submitted in parent zone)--> KSK (1) [retire-active], KSK (2) [active] ---(2h + 12h)-> KSK (1) [removed] The new key was created 19 hours before the KSK-lifetime ends. When I substract DNSKEY TTL, propagation delay and DS parent TTL its still 4 hours too early. Somebody knows why? References: https://www.knot-dns.cz/docs/2.7/html/reference.html https://tools.ietf.org/html/rfc6781.html#section-4.1.2 Thanks and Cheers, Sakirnth

5 let, 1 měsíc

Re: [knot-dns-users] 2.9.0 fails to start after upgrade

by Lukáš Kocourek

So problem is solved for me, I've tried to start with just one zone which didn’t helped, but removing journal did. Many thanks to Daniel Salzman for kind help, maybe he will post some other details after analyzing our journal records. -- Lukas Kocourek > On 2019-10-15, at 12:27, knot-dns-users-request(a)lists.nic.cz wrote: > > Message: 5 > Date: Tue, 15 Oct 2019 11:56:26 +0200 > From: Lukáš Kocourek <kocour(a)direcat.net> > To: knot-dns-users(a)lists.nic.cz > Subject: [knot-dns-users] 2.9.0 fails to start after upgrade > Message-ID: <110451DC-3CC1-419D-9066-EF784FDDAC00(a)direcat.net> > Content-Type: text/plain; charset=utf-8 > > Hi, > > I’ve upgraded from 2.8.4 to 2.9.0 (Ubuntu 18.04, using ppa:cz.nic-labs/knot-dns-latest) and now knotd fail to start. > After dispatching "service knot start" command knotd process immediately goes to 100% CPU and after 3 minutes it’s killed by systemd because "Start operation timed out”. > > Here log from service start... > > Oct 15 11:37:04 ns1-u18 knotc[4972]: Configuration is valid > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: Knot DNS 2.9.0 starting > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loaded configuration file '/etc/knot/knot.conf' > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: using reuseport for UDP > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface X.X.X.X@53 > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface ::@53 > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loading 199 zones > > [cut] - info that all zones will be loaded > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: [xxx.yyy.] zone will be loaded > [/cut] > > Oct 15 11:37:04 ns1-u18 knotd[4984]: info: starting server > Oct 15 11:38:34 ns1-u18 systemd[1]: knot.service: Start operation timed out. Terminating. > Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: State 'stop-sigterm' timed out. Killing. > Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Killing process 4984 (knotd) with signal SIGKILL. > Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Main process exited, code=killed, status=9/KILL > Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Failed with result 'timeout'. > > Any advice what to do? > > Thank very much > > -- > Lukas Kocourek > > > > ------------------------------ > > Message: 6 > Date: Tue, 15 Oct 2019 12:27:34 +0200 > From: Daniel Salzman <daniel.salzman(a)nic.cz> > To: knot-dns-users(a)lists.nic.cz > Subject: Re: [knot-dns-users] 2.9.0 fails to start after upgrade > Message-ID: <99813b76-c350-442f-35c7-2447cb07acce(a)nic.cz> > Content-Type: text/plain; charset=utf-8 > > Hi Lukáš, > > Could you try to temporarily disable some zones? We have no idea at the moment :-( > > Would it be possible to show me a snippet of your configuration? > > Daniel > > On 10/15/19 11:56 AM, Lukáš Kocourek wrote: >> Hi, >> >> I’ve upgraded from 2.8.4 to 2.9.0 (Ubuntu 18.04, using ppa:cz.nic-labs/knot-dns-latest) and now knotd fail to start. >> After dispatching "service knot start" command knotd process immediately goes to 100% CPU and after 3 minutes it’s killed by systemd because "Start operation timed out”. >> >> Here log from service start... >> >> Oct 15 11:37:04 ns1-u18 knotc[4972]: Configuration is valid >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: Knot DNS 2.9.0 starting >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loaded configuration file '/etc/knot/knot.conf' >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: using reuseport for UDP >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface X.X.X.X@53 >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface ::@53 >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loading 199 zones >> >> [cut] - info that all zones will be loaded >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: [xxx.yyy.] zone will be loaded >> [/cut] >> >> Oct 15 11:37:04 ns1-u18 knotd[4984]: info: starting server >> Oct 15 11:38:34 ns1-u18 systemd[1]: knot.service: Start operation timed out. Terminating. >> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: State 'stop-sigterm' timed out. Killing. >> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Killing process 4984 (knotd) with signal SIGKILL. >> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Main process exited, code=killed, status=9/KILL >> Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Failed with result 'timeout'. >> >> Any advice what to do? >> >> Thank very much >> >> -- >> Lukas Kocourek >>

5 let, 1 měsíc

2.9.0 fails to start after upgrade

by Lukáš Kocourek

Hi, I’ve upgraded from 2.8.4 to 2.9.0 (Ubuntu 18.04, using ppa:cz.nic-labs/knot-dns-latest) and now knotd fail to start. After dispatching "service knot start" command knotd process immediately goes to 100% CPU and after 3 minutes it’s killed by systemd because "Start operation timed out”. Here log from service start... Oct 15 11:37:04 ns1-u18 knotc[4972]: Configuration is valid Oct 15 11:37:04 ns1-u18 knotd[4984]: info: Knot DNS 2.9.0 starting Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loaded configuration file '/etc/knot/knot.conf' Oct 15 11:37:04 ns1-u18 knotd[4984]: info: using reuseport for UDP Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface X.X.X.X@53 Oct 15 11:37:04 ns1-u18 knotd[4984]: info: binding to interface ::@53 Oct 15 11:37:04 ns1-u18 knotd[4984]: info: loading 199 zones [cut] - info that all zones will be loaded Oct 15 11:37:04 ns1-u18 knotd[4984]: info: [xxx.yyy.] zone will be loaded [/cut] Oct 15 11:37:04 ns1-u18 knotd[4984]: info: starting server Oct 15 11:38:34 ns1-u18 systemd[1]: knot.service: Start operation timed out. Terminating. Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: State 'stop-sigterm' timed out. Killing. Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Killing process 4984 (knotd) with signal SIGKILL. Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Main process exited, code=killed, status=9/KILL Oct 15 11:40:04 ns1-u18 systemd[1]: knot.service: Failed with result 'timeout'. Any advice what to do? Thank very much -- Lukas Kocourek

5 let, 1 měsíc

Knot DNS 2.9.0 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.9.0! This powerful version is full of new features, improvements, and code cleanups. Please, look at the changelog. Also note that today Knot DNS 2.7 reached its End-of-life and in the following days the official repositories will be upgraded to reflect currently supported versions (current stable -> 2.9.0, previous stable -> 2.8.4). Special thanks go to Christian Petrasch, Manuel Domke, and Jürgen Geinitz for their continuous testing! Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/raw/v2.9.0/NEWS Benchmark: https://www.knot-dns.cz/benchmark/ Source code: https://secure.nic.cz/files/knot-dns/knot-2.9.0.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.9.0.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.9/html Support and funding: https://www.knot-dns.cz/support Regards, Daniel

5 let, 1 měsíc

← Newer
1
...
18
19
20
21
22
23
24
...
71
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users