knot-dns-users

knot-dns-users@lists.nic.cz

5 participants
727 discussions

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.

6 let, 5 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

6 let, 5 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

6 let, 5 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.

6 let, 5 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.

6 let, 5 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 >

6 let, 5 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

6 let, 5 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

6 let, 5 měsíců

Best practices for knot inline DNSSEC signing and zone loading

by Sebastian Wiesinger

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 -- GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

6 let, 5 měsíců

KSK Algorithm Rollover Question

by Sebastian Wiesinger

Hi, I'm currently testing a KSK algorithm rollover with my zone. I changed the signature scheme from RSA to ECDSA. Knot started adding new RRSIGs and new keys and now waits for the new DS to be published at the parent zone. One thing strikes me as odd though: http://dnsviz.net/d/6v6.de/W9AmtA/dnssec/ Looking at the graph the new KSK (54879) is not signing anything right now. Shouldn't it sign the DNSKEY records of the ZSKs so that the chain stays intact when the DS record changed at the parent zone? Kind Regards Sebastian -- GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

6 let, 5 měsíců

← Newer
1
...
26
27
28
29
30
31
32
...
73
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users