11 Úno
2015
11 Úno
'15
20:03
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
13 Úno
13 Úno
18:07
Hello,
We are looking forward to hear some feedback from you.
a couple of things I noticed:
1. `keymgr zone add example.com policy XX' does not complain if the XX
policy doesn't exist, nor if the specified zone isn't configured in
knot.conf.
2. I created a config as in the example on [1] with a single, tiny, zone
and started the daemon afresh:
Feb 13 16:58:32 knot knot[24845]: info: Knot DNS 1.99.1 starting
Feb 13 16:58:32 knot knot[24845]: info: binding to interface '0.0.0.0@53'
Feb 13 16:58:32 knot knot[24845]: info: binding to interface '::@53'
Feb 13 16:58:32 knot knot[24845]: info: configured 2 interfaces and 1 zones
Feb 13 16:58:32 knot knot[24845]: info: changing UID to '1000'
Feb 13 16:58:32 knot knot[24845]: info: PID stored in
'/usr/local/var/run/knot/knot.pid'
Feb 13 16:58:32 knot knot[24845]: info: changed directory to /
Feb 13 16:58:32 knot knot[24845]: info: loading zones
Feb 13 16:58:32 knot knot[24845]: info: [k20.aa] zone will be loaded, serial 0
Feb 13 16:58:32 knot knot[24845]: info: starting server
Feb 13 16:58:32 knot knot[24845]: info: [k20.aa] DNSSEC, executing event
'generate initial keys'
Feb 13 16:58:33 knot knot[24845]: error: [k20.aa] DNSSEC, failed to execute event
(not enough memory)
Feb 13 16:58:33 knot knot[24845]: error: [k20.aa] DNSSEC, failed to process events
(unknown error -12)
Feb 13 16:58:33 knot knot[24845]: error: [k20.aa] failed to store changes into
journal (unknown error -12)
Feb 13 16:58:33 knot knot[24845]: error: [k20.aa] zone reload failed (unknown
error -12)
Feb 13 16:58:33 knot knot[24845]: info: server started as a daemon, PID 24845
Feb 13 16:58:33 knot knot[24845]: info: binding remote control interface to
'/usr/local/var/run/knot/knot.sock'
I really don't think 'not enough memory' can be the reason. :)
$ knotc memstats
2015-02-13T16:58:58 info: [k20.aa] 3 RRs, used memory estimation is 0 MB
2015-02-13T16:58:58 info: estimated memory consumption for all zones is 0 MB
$ free
total used free shared buffers cached
Mem: 1048576 94948 953628 0 0 81396
-/+ buffers/cache: 13552 1035024
Swap: 524288 4880 519408
The KASP contains:
$ cat policy_jp.json
{
"algorithm": 10,
"dnskey_ttl": 1200,
"ksk_size": 2048,
"zsk_size": 1024,
"zsk_lifetime": 2592000,
"rrsig_lifetime": 1209600,
"rrsig_refresh_before": 604800,
"nsec3_enabled": false,
"soa_minimal_ttl": 0,
"zone_maximal_ttl": 0,
"propagation_delay": 3600
}
$ cat zone_k20.aa.json
{
"policy": "jp",
"keys": []
}
$ ls -l keys # (after 5 or 6 start attempts)
-rw-r----- 1 knot root 916 Feb 13 16:53 3b049186c134727344dc80b120ddc2c00e62aec5.pem
-rw-r----- 1 knot root 916 Feb 13 16:55 5b0e47b34228aff884a424696055f9bdc772e14c.pem
-rw-r----- 1 knot root 912 Feb 13 16:54 5e94000ca936730f5996a7958a719d2f72bb2ad1.pem
-rw-r----- 1 knot root 1704 Feb 13 16:57 6419e0ccffcdd2e4b18c10a214c9638fd92ce111.pem
-rw-r----- 1 knot root 1704 Feb 13 16:54 751349b03c28d0159d812ef45a1435f7fae508d2.pem
-rw-r----- 1 knot root 1704 Feb 13 16:53 858ec94a2d67d2cc52ab9f119fab804cb7e9c789.pem
-rw-r----- 1 knot root 1708 Feb 13 16:56 98fcde8448d9088f41962138d0191d7ecb05b4fd.pem
-rw-r----- 1 knot root 916 Feb 13 16:57 cf4ce3c2dc2b19e85d01c4a6505b70107a4d457a.pem
-rw-r----- 1 knot root 1704 Feb 13 16:55 deb79a52e0ce28e647593e5b738d35fa4b8f5f5f.pem
-rw-r----- 1 knot root 916 Feb 13 16:56 f266eb8fda589e5ffbf222b7c6e906db6187a358.pem
-rw-r----- 1 knot root 1704 Feb 13 16:58 f7ad92de2535110119681aa2c163bf0a105141bb.pem
-rw-r----- 1 knot root 916 Feb 13 16:58 f96530696293f79b5365d77fc8869da225eb31f1.pem
^^^ the content of each of the .pem files *is* a private key
$ cat knot.conf
zones {
storage "/usr/local/var/lib/knot";
dnssec-keydir "/etc/kasp";
k20.aa {
file "/usr/local/etc/knot/k20/k20.aa.zone";
dnssec-enable on;
}
}
Any query to this zone results in a SERVFAIL. If I remove `dnssec-enable', the
server responds correctly.
This is running on Debian 7, 2.6.32-16-pve #1 SMP Fri Nov 9 11:42:51 CET 2012 x86_64
GNU/Linux
built with GnuTLS gnutls-3.3.9 and nettle 2.7.
Regards,
-JP
[1] https://gitlab.labs.nic.cz/labs/knot/wikis/kasp-setup
16 Úno
16 Úno
12:11
Hello.
On Friday 13 of February 2015 18:07:11 Jan-Piet Mens wrote:
1. `keymgr zone add example.com policy XX' does
not complain if the XX
policy doesn't exist, nor if the specified zone isn't configured in
knot.conf.
Right, this is a bug.
2. I created a config as in the example on [1] with a
single, tiny, zone
and started the daemon afresh:
I really don't think 'not enough
memory' can be the reason. :)
Please, can you verify the file permissions on KASP database? I guess knot
can't write into the zone_k20.aa.json file in the KASP database.
The error message is wrong. Based on the fact that so many private keys were
generated. I believe that something failed when writing the zone state into
the KASP database.
With the "on disk database", some operations cannot be performed atomically.
The server generates a new private key and tries to reference this key in the
zone file in the KASP database. If something fails later, like writing the new
zone state into the database, we don't delete the generated key.
Any query to this zone results in a SERVFAIL. If I
remove `dnssec-enable',
the server responds correctly.
Right. If zone sign fails, SERVFAIL responses for the failed zone are
expected.
Thank you, JP! I will investigate the problems you pointed out.
Best regards.
Jan
20:35
Hello Jan,
Please, can you verify the file permissions on KASP
database? I guess knot
can't write into the zone_k20.aa.json file in the KASP database.
I checked that, and it looks OK to me (all belong to user `knot'):
(here: restarted after clearing out keys/ directory)
49685941 4 drwxrwxr-x 3 knot knot 4096 Feb 13 16:43 /etc/kasp/
49685943 4 -rw-r--r-- 1 knot knot 278 Feb 13 16:38
/etc/kasp/policy_jp.json
49685944 4 -rw-r--r-- 1 knot knot 35 Feb 13 16:43
/etc/kasp/zone_k20.aa.json
49685942 4 drwxrwxr-x 2 knot knot 4096 Feb 16 19:32 /etc/kasp/keys
49685946 4 -rw-r----- 1 knot root 916 Feb 16 19:32
/etc/kasp/keys/1c4c994fde0b73169a79682038d689d8a045c8a5.pem
49685945 4 -rw-r----- 1 knot root 1704 Feb 16 19:32
/etc/kasp/keys/fc88d86e1b150e36d6baec75b9ed3fe9405722a5.pem
If I change knot.conf to have it run as `root', there no change other
than files being created as root of course:
2015-02-16T19:34:36 error: [k20.aa] DNSSEC, failed to execute event (not enough memory)
2015-02-16T19:34:36 error: [k20.aa] DNSSEC, failed to process events (unknown error -12)
2015-02-16T19:34:36 error: [k20.aa] failed to store changes into journal (unknown error
-12)
2015-02-16T19:34:36 error: [k20.aa] zone reload failed (unknown error -12)
Regards,
-JP
18 Úno
18 Úno
6:52
For the record: prompted by a question Jan asked, I removed the
OS-packaged libjansson-dev and installed from source [1]. Bingo!
info: [k20.aa] DNSSEC, executing event 'generate initial keys'
info: [k20.aa] DNSSEC, loaded key, tag 534, algorithm 10, KSK yes, ZSK no, public yes,
active yes
info: [k20.aa] DNSSEC, loaded key, tag 35202, algorithm 10, KSK no, ZSK yes, public yes,
active yes
info: [k20.aa] DNSSEC, signing started
info: [k20.aa] DNSSEC, successfully signed
info: [k20.aa] DNSSEC, next signing on 2015-02-18T09:58:55
info: [k20.aa] loaded, serial 0 -> 3
Regards,
-JP
[1] http://www.digip.org/jansson/
9:18
On 18.2.2015 06:52, Jan-Piet Mens wrote:
For the record: prompted by a question Jan asked, I
removed the
OS-packaged libjansson-dev and installed from source [1]. Bingo!
I will check if we can make it compatible with older libjansson, at
least the one in debian/wheezy. If that's not possible, I will at least
update the configure to require certain version.
Jan
15 Úno
15 Úno
17:20
ons 2015-02-11 klockan 20:03 +0100 skrev Jan Včelák:
Today, CZ.NIC Labs releases Knot DNS 1.99.1. The next
step towards the 2.0.
...
...
We are looking forward to hear some feedback from you. And we are happy to
answer all your questions and concerns.
So, spent some day today setting up knot 1.99.1, having it act as master
for the (test) domain f13g.se.
First of all, let me say that I really the koncept of the KASP. It's
definitely the way I want my DNS Master to handle DNSSEC.
While the signing appear to work, there appear to be something odd with
the policy handing. The default policy I have was created by running:
keymgr policy add default
Note the difference between the json file and the parsed output.
root@sandbox:/usr/local/var/kasp# cat policy_default.json
{
"algorithm": 10,
"dnskey_ttl": 1200,
"ksk_size": 2048,
"zsk_size": 1024,
"zsk_lifetime": 2592000,
"rrsig_lifetime": 1209600,
"rrsig_refresh_before": 604800,
"nsec3_enabled": false,
"soa_minimal_ttl": 0,
"zone_maximal_ttl": 0,
"propagation_delay": 3600
}
root@sandbox:/usr/local/var/kasp#
vs.
root@sandbox:/usr/local/var/kasp# keymgr policy show default
algorithm: 10
DNSKEY TTL: 1200
KSK key size: 2048
ZSK key size: 1024
ZSK lifetime: 36096
RRSIG lifetime: 29952
RRSIG refresh: 14976
NSEC3 enabled: false
SOA min TTL: 0
zone max TTL: 0
data propagation: 3600
root@sandbox:/usr/local/var/kasp#
At least based on the created RRSIGs it appear to be the values returned
by "keymgr policy show default" which are the ones actually used by
knotd.
On the topic of policy, what is the reason for going with algoritm 10 by
default? I have really no opinion whatever it's right or wrong, just
curious, since most of the world appear to be using algoritm 8 today?
I'm also wondering if I'm really doing things right in regards to the
zone file. Based on the following part of knot.conf
zones {
dnssec-keydir "/usr/local/var/kasp";
f13g.se {
file "/usr/local/etc/knot/master/f13g.se.zone";
xfr-out halleck, mohiam;
notify-out halleck, mohiam;
dnssec-enable on;
}
}
I have ended up in a situation where both me and knot edits the same
file /usr/local/etc/knot/master/f13g.se.zone. First I edit a regular
None-DNSSEC record, and upon reload knot updates RRSIGS, etc. While it
kind of works, it feels a bit messy/unstable.
As a comparison I'm used to BIND's Inline Signing[1] where one edits a
regular plain zone file, and BIND keeps all the DNSSECy regards in its
journal files.
I'm running knot 1.99.1 on Debian Jessie.
// Andreas
[1]: https://kb.isc.org/article/AA-00626/0/Inline-Signing-in-ISC-BIND-9.9.0-Exam…
16 Úno
16 Úno
12:40
Hello Andreas,
On Sunday 15 of February 2015 17:20:36 Andreas Olsson wrote:
First of all, let me say that I really the koncept of
the KASP. It's
definitely the way I want my DNS Master to handle DNSSEC.
We love to hear that! :-)
While the signing appear to work, there appear to be
something odd with
the policy handing. The default policy I have was created by running:
keymgr policy add default
Note the difference between the json file and the parsed output.
Yes, I can confirm this problem. It is a bug. I will fix it soon.
At least based on the created RRSIGs it appear to be
the values returned
by "keymgr policy show default" which are the ones actually used by
knotd.
Right, the values of keymgr output are the ones used.
On the topic of policy, what is the reason for going
with algoritm 10 by
default? I have really no opinion whatever it's right or wrong, just
curious, since most of the world appear to be using algoritm 8 today?
Well, we don't have any specific reasons for that. We are probably fine with
anything using SHA-2. So algorithm 8 would work as well.
The size of the RSA signature depends on the size of the key, so the size is
not a concern. The difference in computational complexity is insignificant.
And the only reason to use SHA-256 instead of SHA-512 could be a compatibility
with legacy devices. And I'm not sure if there are any legacy devices
supporting SHA-256 and not SHA-512.
There is still a time to change the default. :-)
I'm also wondering if I'm really doing things
right in regards to the
zone file. Based on the following part of knot.conf
Your config is correct.
I have ended up in a situation where both me and knot
edits the same
file /usr/local/etc/knot/master/f13g.se.zone. First I edit a regular
None-DNSSEC record, and upon reload knot updates RRSIGS, etc. While it
kind of works, it feels a bit messy/unstable.
If you are editing an up-to-date zone file (with changes from journal flushed)
and update SOA serial correctly, Knot will preserve valid signatures and fix
the void ones. And everything will work just fine.
As a comparison I'm used to BIND's Inline
Signing[1] where one edits a
regular plain zone file, and BIND keeps all the DNSSECy regards in its
journal files.
We currently don't support that. But we are looking in a way how to separate
the unsigned zones from the automatically generated signatures.
Thank you for the ideas!
Best regards,
Jan
17 Úno
17 Úno
1:19
Hello Jan,
On 2015-02-11 20:03, Jan Včelák wrote:
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].
Is there any reason why you chose JSON over a simple and securely and
deterministically parseable file format for KASP?
Regards,
Matthias-Christian
10:50
Hello Matthias-Christian,
On 17.2.2015 01:19, Matthias-Christian Ott wrote:
Is there any reason why you chose JSON over a simple
and securely and
deterministically parseable file format for KASP?
We were looking for something, which is easy parseable by machines,
readable by humans, and available in popular scripting languages.
We originally wanted to use YAML (because the syntax is more
user-friendly), but we weren't satisfied with current open-source
implementations of YAML libraries. JSON was the second candidate. And
libjansson provides really nice and convenient API.
I'm aware that we won't please everyone by this decision. But I,
personally, prefer well-known and widespread format than a custom one.
I agree that JSON is not very simple, but it is definitelly secure and
deterministically parsable:
# Python
import json
with open("policy_default.json") as f:
data = json.load(f)
print("RRSIG lifetime: %d" % data["rrsig_lifetime"])
# Ruby
require 'json'
data = File.open("policy_default.json") do |f|
JSON.load(f)
end
puts "RRSIG lifetime: %d" % data["rrsig_lifetime"]
# Bash
(I give up... it won't be simple. But I can parse output of keymgr...)
If you have any strong opinions against JSON, we can still discuss it.
But as for me, I think using JSON is fine for this purpose.
Best regards,
Jan
18 Úno
18 Úno
22:52
Jan Včelák wrote:
I agree that JSON is not very simple, but it is
definitelly secure and
deterministically parsable:
# Python
import json
with open("policy_default.json") as f:
data = json.load(f)
print("RRSIG lifetime: %d" % data["rrsig_lifetime"])
# Ruby
require 'json'
data = File.open("policy_default.json") do |f|
JSON.load(f)
end
puts "RRSIG lifetime: %d" % data["rrsig_lifetime"]
# Bash
(I give up... it won't be simple. But I can parse output of keymgr...)
$ sudo apt-get install jq
$ echo "RRSIG lifetime: $(jq .rrsig_lifetime < policy_default.json)"
:-)
--
Robert Edmonds
edmonds(a)debian.org
19 Úno
19 Úno
19:13
On 2015-02-17 10:50, Jan Včelák wrote:
Hello Matthias-Christian,
Hello Jan,
On 17.2.2015 01:19, Matthias-Christian Ott wrote:
Just to clarify: With the term deterministically parasable I meant to it
requires a bounded amount of memory and can be parsed with a
deterministic finite automaton (hence the name).
It seems there is also JSON library that would meat that I didn't know
about but meets that requirement: jsmn [1].
Is there any reason why you chose JSON over a
simple and securely and
deterministically parseable file format for KASP?
We were looking for something, which is easy parseable by machines,
readable by humans, and available in popular scripting languages.
We originally wanted to use YAML (because the syntax is more
user-friendly), but we weren't satisfied with current open-source
implementations of YAML libraries. JSON was the second candidate. And
libjansson provides really nice and convenient API.
I'm aware that we won't please everyone by this decision. But I,
personally, prefer well-known and widespread format than a custom one.
I agree that JSON is not very simple, but it is definitelly secure and
deterministically parsable: If you have any strong opinions against JSON, we can
still discuss it.
Not in particular, I just found it a bit unusual to use JSON in a
security-relevant context. If JSON meets your requirements, the library
is well tested and other users are happy to easily use it with other
software, I have nothing to object.
Alternatives would have been the file system (like qmail), line and
colon delimited files text files (netstrings, CSV etc.), fixed length
binary formats or variable length binrary formats (Protocol Buffers,
ASN.1, XDR etc.). All of which have their own advantages and disadvantages.
So in my opinion, we can mark this discussion as "issue solved".
Regards,
Matthias-Christian
[1] http://zserge.com/jsmn.html
20:44
Hello.
On 19.2.2015 19:13, Matthias-Christian Ott wrote:
In that case, you are right. :-)
We use JSON only to store metadata. So it's not that security-critical
usage. But right, your concerns are quite legitimate. On the other hand,
Jansson seems to be very popular, has active development, and I'm
definitely their happy user. So we should be OK. ;-)
I agree that
JSON is not very simple, but it is definitelly secure and
deterministically parsable:
Just to clarify: With the term deterministically parasable I meant to it
requires a bounded amount of memory and can be parsed with a
deterministic finite automaton (hence the name). It seems there is also JSON library that would meat
that I didn't know
about but meets that requirement: jsmn [1].
jsmn looks really great. I didn't know it. I decided to use Jansson, as
it has really clean and intuitive API and a very good documentation.
Also, for our purpose, working with JSON as with objects is much easier
than parsing the input by tokens.
If you have
any strong opinions against JSON, we can still discuss it.
Not in particular, I just found it a bit unusual to use JSON in a
security-relevant context. If JSON meets your requirements, the library
is well tested and other users are happy to easily use it with other
software, I have nothing to object. Alternatives would have been the file system (like
qmail), line and
colon delimited files text files (netstrings, CSV etc.), fixed length
binary formats or variable length binrary formats (Protocol Buffers,
ASN.1, XDR etc.). All of which have their own advantages and disadvantages.
I can just agree.
Cheers,
Jan
3364
days inactive
3372
days old
14 comments
5 participants
participants (5)
-
Andreas Olsson -
Jan Včelák -
Jan-Piet Mens -
Matthias-Christian Ott -
Robert Edmonds