knot-dns-users

knot-dns-users@lists.nic.cz

6 participants
749 discussions

Python libknot: Failed to load libknot.so, patch attached

by Frank Matthieß

Hi, i have the issue, that the example wont work, because there ist no "libknot.so" on my system: root@f-dns4:~# ldconfig -v 2>/dev/null | grep libknot libknot.so.8 -> libknot.so.8.0.0 root@f-dns4:~# lsb_release -a; dpkg-query -W knot No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.1 LTS Release: 18.04 Codename: bionic root@f-dns4:~# dpkg-query -W knot knot 2.7.3-1~ubuntu18.04.1ppa2 I has made a patch for that, with a search order, if no path is given. Hopefully this help to solve this issue. Greetings Frank -- Frank Matthieß Stapenhorster Straße 42b, DE 33615 Bielefeld Mail: frank.matthiess(a)virtion.de GnuPG: 9F81 BD57 C898 6059 86AA 0E9B 6B23 DE93 01BB 63D1

7 let, 1 měsíc

Python library behaviours

by Rick van Rein

Hi, I'm trying to spin a nice transaction model around libknot, intended for better automation, as attached. I'm running into problems. First and foremost, a lack of understanding what should go into what fields when doing other commands than in the "stats" demos. Are there more advanced explanations of what goes into what fields? I tried looking into knotc, but it is rather long. Perhaps there is a log somewhere with the stuff going into knotd? Secondly, the model by which transactions abort is not always logical. Like a commit() that fails but does not turn into an abort() when semantic errors are found. I will run zone-check beforehand, to ensure that this does not happen. Thirdly, I found that the library freezes when supplied with unknown commands or apparently funny data... >>> import knotcontrol >>> kc = knotcontrol.KnotControl() >>> kc = knotcontrol.KnotControl () >>> kc.knot (cmd='stats') KnotControl send {'cmd': 'stats'} KnotControl recv {'server': {'zone-count': ['1']}} {'server': {'zone-count': ['1']}} >>> kc.knot (cmd='zone-stats',item='vanrein.org') KnotControl send {'item': 'vanrein.org', 'cmd': 'zone-stats'} KnotControl recv {} {} >>> kc.knot (cmd='zone-recv',item='vanrein.org') KnotControl send {'item': 'vanrein.org', 'cmd': 'zone-recv'} ...and at this point it freezes, even to ^C -- before and after this sequence, "kdig @localhost vanrein.org soa" worked to query the zone in Knot DNS. Sorry to be testing this early :-S but I'm eager to use it this way. -Rick

7 let, 1 měsíc

zone delagation format?

by Milan Sýkora

Hello, could you please send me a short guide how to delegate a zone subnet (class) to different NS. I have a zone i.e. 0.10.in-addr.arpa.zone where I would like to delegate a part of the zone 10.0.0.104/29 (255.255. 255.248) to different NS. It includes 8 IP addresses (10.0.0.104, 10.0. 0.105, 10.0.0.106 .... 10.0.0.111) then I create a record in the mentioned zone like 104/29.0.0.10.in-addr.arpa. 300 NS my.test.server. I tried to understand the syntax in RFC 2317 (https://tools.ietf.org/html/ rfc2317) but it seems to be wrongly implemented from my side. When I tried to "dig" records I have to ask next IP address in the row not like dig -x 10.0.0.105 bud like dig -x 10.0.0.104/29.105 Many thanks for the clarification, best regards Milan.

7 let, 1 měsíc

Issue with set_timeout in the Python library

by Rick van Rein

Hi, I am following Daniel's advise > Consider controlling the server directly using our > python wrapper: in trying to get more transactional rigour through the Python library from Git. The library certainly is easier to integrate! But I think I hit upon a bug. The code def __init__ (self, socketpath='/var/run/knot/knot.sock'): """Connect to knotd """ self.ctl = None self.txn_conf = False self.txn_zone = set () self.txn_success = True self.ctl = libknot.control.KnotCtl () self.ctl.connect (socketpath) self.ctl.set_timeout (3600) seems to not set any timeout; it always cuts off after 5s sleep, and never after 4s sleep. This is true for the first command as well as later ones. Same when setting the timeout to 7200, so it's not a ms/s issue. This code is almost literally the same as in StatsServer, except that demo runs too fast to detect timeout problems. I ran into it when working interactively. Ideally, I would want to disable connection timeouts altogether, so it is possible to abort any open transactions upon whatever cause for termination there might be; this should benefit stability. -Rick

7 let, 1 měsíc

KnotDNS on FreeBSD 11.2

by Thomas Belian

Hello, I want to switch to KnotDNS on my private zone (bt909.de). I've installed the knot2 port as binary package within a FreeBSD jail. I configured my zones and zone transfer works fine, but KnotDNS didn't answer any query. I have a acl for the zone transfer, is there anything I need to do, that knot answers my queries? Knot is running, I found nothing in the logs, even the port ist open, but Knot just does nothing and my queries run into timeouts. I tried NSD in the same jail, which works fine, but I want to use KnotDNS. Regards, Thomas -- Thomas Belian; https://bt909.de

7 let, 1 měsíc

Knot refusing to use the PKCS #11 interface

by Full Name

I have a knot.conf file with the following keystore section: keystore: - id: TheBackend backend: pkcs11 config: "pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System Trust" where the value assigned to the config keyword is obtained from the output from the GnuTLS p11tool command: $ p11tool --list-tokens Token 0: URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust Label: System Trust Type: Trust module Flags: uPIN uninitialized Manufacturer: PKCS#11 Kit Model: p11-kit-trust Serial: 1 Module: p11-kit-trust.so Also in knot.conf I have policy: - id: manual manual: on zone: - domain: example.com storage: /var/lib/knot/zones/ file: example.com.zone dnssec-signing: on dnssec-policy: manual With all this in place, I launched the following from the CLI: # keymgr example.com. generate algorithm=ECDSAP256SHA256 This does not seem to be using the PKCS #11 library, as instructed in knot.conf. I debugged the command above and noticed that, at some before the signing operation itself is addressed, the keystore_load function from the Knot code base is invoked. This function takes several arguments, the second of which is a backend identifier. According to the keystore entry in knot.conf, this should be the PKCS #11 identifier KEYSTORE_BACKEND_PKCS11. However, what I see with the debugger is that the backend argument is, in fact, KEYSTORE_BACKEND_PEM. Even more intriguing (to somebody unfamiliar with the internal workings of Knot, at least) is that, before keystore_load is invoked, the check_keystore function is invoked and it evaluates the following conditional: if (conf_opt(&backend) == KEYSTORE_BACKEND_PKCS11 && conf_str(&config) == NULL) This conditional clearly succeeds - i.e. at that point the backend has been correctly identified as PKCS #11. But, like I said above, when keystore_load gets called later on, such is not the case any longer. Any idea as to what is going on here? Why is PKCS #11 not being used? In the config string above in knot.conf I tried replacing %23 and %20 with # and the space character, respectively. It made no difference. This all is happening with Knot 2.7.3.

7 let, 1 měsíc

Knot refusing to use the PKCS #11 interface II

by Full Name

More info on this: The keymgr command invokes first the init_confile function. This results in the following backtrace: #0 conf_db_get (conf=0x6bfcc0, txn=0x7fffffffe1b0, key0=0x47b76a "\bkeystore", key1=0x47b761 "\abackend", id=0x6c6648 "TheBackend", id_len=11, data=0x7fffffffdf70) at knot/conf/confdb.c:704 #1 0x0000000000410018 in conf_rawid_get_txn (conf=0x6bfcc0, txn=0x7fffffffe1b0, key0_name=0x47b76a "\bkeystore", key1_name=0x47b761 "\abackend", id=0x6c6648 "TheBackend", id_len=11) at knot/conf/conf.c:78 #2 0x0000000000417f4a in check_keystore (args=0x7fffffffe090) at knot/conf/tools.c:268 #3 0x000000000041777d in conf_exec_callbacks (args=0x7fffffffe090) at knot/conf/tools.c:62 #4 0x000000000040ebaa in finalize_previous_section (conf=0x6bfcc0, txn=0x7fffffffe1b0, parser=0x6ed560, ctx=0x6c6620) at knot/conf/base.c:506 #5 0x000000000040ee8d in conf_parse (conf=0x6bfcc0, txn=0x7fffffffe1b0, input=0x4783c7 "/etc/knot/knot.conf", is_file=true) at knot/conf/base.c:592 #6 0x000000000040f128 in conf_import (conf=0x6bfcc0, input=0x4783c7 "/etc/knot/knot.conf", is_file=true) at knot/conf/base.c:669 #7 0x000000000040b677 in init_confile ( confile=0x4783c7 "/etc/knot/knot.conf") at utils/keymgr/main.c:240 #8 0x000000000040bb70 in main (argc=4, argv=0x7fffffffe488) at utils/keymgr/main.c:349 A few lines later, keymgr invokes key_command. I get the following backtrace: #0 conf_db_get (conf=0x6bfcc0, txn=0x6bfce0, key0=0x47c042 "\bkeystore", key1=0x47c04c "\abackend", id=0x0, id_len=0, data=0x7fffffffdf90) at knot/conf/confdb.c:705 #1 0x00000000004101a3 in conf_id_get_txn (conf=0x6bfcc0, txn=0x6bfce0, key0_name=0x47c042 "\bkeystore", key1_name=0x47c04c "\abackend", id=0x7fffffffe090) at knot/conf/conf.c:109 #2 0x0000000000419117 in conf_id_get (conf=0x6bfcc0, key0_name=0x47c042 "\bkeystore", key1_name=0x47c04c "\abackend", id=0x7fffffffe090) at ./knot/conf/conf.h:138 #3 0x000000000041a516 in kdnssec_ctx_init (conf=0x6bfcc0, ctx=0x7fffffffe180, zone_name=0x6a81d0 "\aexample\003com", from_module=0x0) at knot/dnssec/context.c:169 #4 0x000000000040aee4 in key_command (argc=3, argv=0x7fffffffe490, optind=1) at utils/keymgr/main.c:113 #5 0x000000000040bba9 in main (argc=4, argv=0x7fffffffe488) at utils/keymgr/main.c:359 In both cases conf_db_get is eventually invoked. With a big difference: the first time, the information concerning the keystore id is present, as the value of id - namely, "TheBackend". With this value, conf_db_get returns KNOT_EOK, and the backend id is retrieved as KEYSTORE_BACKEND_PKCS11. The second time, however, the value of this argument is just the NULL pointer. This causes conf_db_get to return KNOT_ENOENT, and the value of the backend is therefore eventually set to the default - KEYSTORE_BACKEND_PEM. What am I doing wrong? What is causing for the second invocation to of conf_db_get to receive an id argument set to NULL? Is this the way it is supposed to work, or is it a bug in the Knot 2.7.3 code? If it is not, what do I have to do in order to get Knot to use the PKCS #11 interface? By the way, I forgot to mention in my previous email that Knot was built with PKCS #11 support all right.

7 let, 1 měsíc

Re: [knot-dns-users] Best practices for knot inline DNSSEC signing and zone loading

by libor.peltan

Hi Sebastian, 1) that's OK. You don't need to worry about that warning unless you edit the zonefile on the signer manually. You can also consider zonefile-less signer, either completely headless (needs AXFR after each daemon start) or with the zone stored in journal (needs some thoughts regarding journal capacity policies). Check "zonefile-load", "journal-content", "max-journal-db-size" and "max-journal-usage" options in config. 2) No, "discontinuity in changes history" is not expected. Could you please describe what did you do before such warning appeared, with longer snippets of the log? In any case, there is no need to be scared of journal getting full, once you read the documentation ;) https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#journal-behaviour BR, Libor Dne 29.10.18 v 13:07 Sebastian Wiesinger napsal(a): > Right now I have two zone types for my knot test setup, one where knot > is doing DNSSEC signing as a slave (AXFR in -> sign -> AXFR out) and > one where the knot is the master for the zone and zone data is coming > out of a git repository and gets signed. > > Reading older threads on this ML and browsing the configuration has > led me to the following configuration and I wanted to make sure this > is actually supported or if there is a best practice that is > different. > > > 1) Inline DNSSEC signing for slave zone. > > zone: > - domain: example.com > serial-policy: unixtime > storage: "/var/lib/knot/slave" > file: "%s.zone" > zonefile-load: difference > dnssec-signing: on > dnssec-policy: rsa-de > master: ns1_signer > notify: ns1 > acl: acl_ns1 > > policy: > - id: rsa-de > algorithm: RSASHA256 > ksk-size: 2048 > zsk-size: 1024 > ksk-submission: tld_de > > > This seems to work fine, zone gets transferred from master (with low > serial), signed and with a new unixtime serial transferred out again. > I'm not sure if "zonefile-load: difference " makes any difference for > a slave zone but without it I get warnings about possibly malformed > IXFRs... > > 2) Inline DNSSEC for master zone from git: > > zone: > - domain: dnssec-test.intern > serial-policy: unixtime > storage: "/var/lib/knot/master" > file: "%s.zone" > zonefile-sync: -1 > dnssec-signing: on > dnssec-policy: rsa > acl: acl_ns1 > zonefile-load: difference-no-serial > > policy: > - id: rsa > algorithm: RSASHA256 > ksk-size: 2048 > zsk-size: 1024 > > > This also works but I get warnings like this: > > [dnssec-test.intern.] journal, discontinuity in changes history > (1540307365 -> 28), dropping older changesets > > Is this expected? Also I read in older threads that this might fill > up the journal. Is that still the case? > > > Best Regards > > Sebastian >

7 let, 1 měsíc

(where) is the python control script packaged?

by Rick van Rein

Hi, You/Daniel pointed me to the Python control library, but I cannot find it in the 2.7.3 packages -- is that forgotten, or am I missing it? Thanks, -Rick

7 let, 1 měsíc

Question about obtaining information for parent zone of DNSSEC KSK rollover

by Maximilian Engelhardt

Hi, I'm having a question about DNSSEC KSK rollover and obtaining the relevant information for submission to the parent zone of the new key. I'm currently using these steps: - running "keymgr example.org list" - manually identifying the new key using the parameters "ksk=yes" and having a look at the created, publish, ready and active parameters. The new key always seems to be the one with active=0 and I also check the dates of the other parameters for plausibility. I then note the tag of the identified key. - using "keymgr example.org dnskey <keytag>" or "keymgr example.org ds <keytag>" to get the corresponding information for submission to the parent zone. Is there an easier way of achieving this, especially without the manual key identification step? Ideally would be a single command I can run and specify the zone of interest and it will output the dnskey and/or ds information of the new key. Thanks, Maxi

7 let, 1 měsíc

← Newer
1
...
28
29
30
31
32
33
34
...
75
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users