Hello,
I'm trying to use Knot 2.6.7 in a configuration where zone files are
preserved (including comments, ordering and formatting) yet at the same
time Knot performs DNSSEC signing – something similar to inline-signing
feature by BIND. My config file looks like this:
policy:
- id: ecdsa_fast
nsec3: on
ksk-shared: on
zsk-lifetime: 1h
ksk-lifetime: 5h
propagation-delay: 10s
rrsig-lifetime: 2h
rrsig-refresh: 1h
template:
- id: mastersign
file: "/etc/knot/%s.zone"
zonefile-sync: -1
zonefile-load: difference
journal-content: all
dnssec-signing: on
dnssec-policy: ecdsa_fast
serial-policy: unixtime
acl: acl_slave
zone:
- domain: "example.com."
template: mastersign
It seems to work well for the first run, I can see that zone got signed
properly:
>
> # kjournalprint /var/lib/knot/journal/ example.com
> ;; Zone-in-journal, serial: 1
> ;;Added
> example.com. 60 SOA knot.example.com. hostmaster.example.com. 1 3600 900 1814400 60
> example.com. 60 NS knot.example.com.
> first.example.com. 60 TXT "first"
> ;; Changes between zone versions: 1 -> 1529578258
> ;;Removed
> example.com. 60 SOA knot.example.com. hostmaster.example.com. 1 3600 900 1814400 60
> ;;Added
> example.com. 60 SOA knot.example.com. hostmaster.example.com. 1529578258 3600 900 1814400 60
> example.com. 0 CDNSKEY 257 3 13
> …lots of DNSSEC data.
However, if I try to update the unsigned zone file, strange things
happen. If I just add something to a zone and increase the serial, I get
these errors in the log:
>
> Jun 21 13:00:08 localhost knotd[2412]: warning: [example.com.] zone file changed, but SOA serial decreased
> Jun 21 13:00:08 localhost knotd[2412]: error: [example.com.] zone event 'load' failed (value is out of range)
If I set the serial to be higher than the serial of last signed zone, I
get a slightly different error:
>
> Jun 21 13:22:36 localhost knotd[3096]: warning: [example.com.] journal, discontinuity in changes history (1529580085 -> 1529580084), dropping older changesets
> Jun 21 13:22:36 localhost knotd[3096]: error: [example.com.] zone event 'load' failed (value is out of range)
In either case, when I look into the journal after the reload of the
zone, I see just the unsigned zone:
> # kjournalprint /var/lib/knot/journal/ example.com
> ;; Zone-in-journal, serial: 2
> ;;Added
> example.com. 60 SOA knot.example.com. hostmaster.example.com. 2 3600 900 1814400 60
> example.com. 60 NS knot.example.com.
> first.example.com. 60 TXT "first"
> second.example.com. 60 TXT "second"
Yet the server keeps serving the previous signed zone no matter what I
try. The only thing that help is a cold restart of Knot, when the zone
gets signed again.
So this approach is obviously not working as expected. If I comment out
option `zonefile-load: difference`, I get somehow working solution where
zone is completely resigned during each reload and I get this warning to
the log:
> Jun 21 13:27:38 localhost knotd[3156]: warning: [example.com.] with automatic DNSSEC signing and outgoing transfers enabled, 'zonefile-load: difference' should be set to avoid malformed IXFR after manual zone file update
I guess this should not bother me a lot as log as I keep serial numbers
of unsigned zones significantly different from signed ones. The only
problem is that this completely kills IXFR transfers as well as signing
only differences.
So far the only solution I see is to run two instances of Knot, one
reading the zone file from disk without signing, transferring it to
another instance which would do the signing is slave mode.
Is there anything I'm missing here?
Sorry for such a long e-mail and thank you for reading all the way here.
Best regards,
Ondřej Caletka
Hi!
One of our customers uses Knot 2.6.7 as hidden master which sends
NOTIFYs to our slave service. He reported that Knot can not send the
NOTIFYs, ie:
knotd[10808]: warning: [example.com.] notify, outgoing,
2a02:850:8::6@53: failed (connection reset)
It seems that Knot sometimes tries to send the NOTIFY with TCP (I see
also NOTIFYs via UDP). Unfortunatelly our NOTIFY-receiver only supports UDP.
So, this is the first time seeing a name server sending NOTIFYs over
TCP. Is this a typical behavior in Knot? Can I force Knot to send
NOTIFYs always over UDP?
Thanks
Klaus
Hello
I am using ecdsap256sha256 as algorithm. Why does the KSK DNSKEY (=257) use as digest type SHA1 (=1) and not SHA256 (=2)?
For example:
> dig DNSKEY nic.cz | grep 257
nic.cz. 871 IN DNSKEY 257 3 13 LM4zvjUgZi2XZKsYooDE0HFYGfWp242fKB+O8sLsuox8S6MJTowY8lBD jZD7JKbmaNot3+1H8zU9TrDzWmmHwQ==
> dig DNSKEY nic.cz | grep 257 > dnspub.key
> jdnssec-dstool dnspub.key
nic.cz. 868 IN DS 61281 13 1 091CECC4D2AADB7AC8C4DF413DDF9C5B0B61E5B6
Regards
dp
Hello all,
my Knot DNS is now in production and I would like to setup some
backup tasks for the configuration and of course keys. Are there any
recommendations regarding backup? And restore? I can see that it is very
easy to dump current config but I am to sure how to backup keys. What do
you recommend? Save the content of /var/lib/knot on a hourly/daily
basis? I am not using shared keys.
Thanks
With regards
Ales
Hi
I have a question about this commit
“01b00cc47efe”
Replace select() by poll()?
The performance of epoll is better then select/poll when monitoring large
numbers of file descriptions.
Could you please let me why you choose poll()?
Thanks for your reply!
Dear all,
While trying to migrate or DNS to Knot I have noticed that a slave
server with 2GB RAM is facing memory exhaustion. I am running
2.6.5-1+0~20180216080324.14+stretch~1.gbp257446. There is 141 zones
having around 1MB in total. Knot is acting as pure slave server with
minimal configuration.
There is nearly 1.7GB of memory consumed by Knot on a freshly rebooted
server:
root@eira:/proc/397# cat status
Name: knotd
Umask: 0007
State: S (sleeping)
Tgid: 397
Ngid: 0
Pid: 397
PPid: 1
TracerPid: 0
Uid: 108 108 108 108
Gid: 112 112 112 112
FDSize: 64
Groups: 112
NStgid: 397
NSpid: 397
NSpgid: 397
NSsid: 397
VmPeak: 24817520 kB
VmSize: 24687160 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 1743400 kB
VmRSS: 1743272 kB
RssAnon: 1737088 kB
RssFile: 6184 kB
RssShmem: 0 kB
VmData: 1781668 kB
VmStk: 132 kB
VmExe: 516 kB
VmLib: 11488 kB
VmPTE: 3708 kB
VmPMD: 32 kB
VmSwap: 0 kB
HugetlbPages: 0 kB
Threads: 21
SigQ: 0/7929
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: fffffffe7bfbbefc
SigIgn: 0000000000000000
SigCgt: 0000000180007003
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
Seccomp: 0
Cpus_allowed: f
Cpus_allowed_list: 0-3
Mems_allowed: 00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 260
nonvoluntary_ctxt_switches: 316
root@eira:/proc/397#
Config:
server:
listen: 0.0.0.0@53
listen: ::@53
user: knot:knot
log:
- target: syslog
any: info
mod-rrl:
- id: rrl-10
rate-limit: 10 # Allow 200 resp/s for each flow
slip: 2 # Every other response slips
mod-stats:
- id: custom
edns-presence: on
query-type: on
request-protocol: on
server-operation: on
request-bytes: on
response-bytes: on
edns-presence: on
flag-presence: on
response-code: on
reply-nodata: on
query-type: on
query-size: on
reply-size: on
template:
- id: default
storage: "/var/lib/knot"
module: mod-rrl/rrl-10
module: mod-stats/custom
acl: [allowed_transfer]
disable-any: on
master: idunn
I was pretty sure that a VM with 2GB RAM is enough for my setup :-)
BR
Ales
Hello all,
I noticed that Knot (2.6.5) creates an RRSIG for the CDS/CDNSKEY RRset
with the ZSK/CSK only.
I was wondering if this is an acceptable behavior as RFC 7344, section
4.1. CDS and CDNSKEY Processing Rules states:
o Signer: MUST be signed with a key that is represented in both the
current DNSKEY and DS RRsets, unless the Parent uses the CDS or
CDNSKEY RRset for initial enrollment; in that case, the Parent
validates the CDS/CDNSKEY through some other means (see
Section 6.1 and the Security Considerations).
Specifically I read that "represented in both the current DNSKEY and DS
RRsets" means that the CDS/CDNSKEY RRset must be signed with a KSK/CSK
and not only with a ZSK and a trust chain to KSK <- DS.
I tested both BIND 9.12.1 and PowerDNS Auth 4.0.5 as well. PowerDNS Auth
behaves the same as Knot 2.6.5 but BIND 9.12.1 always signs the
CDS/CDNSKEY RRset with at least the KSK.
Do I read the RFC rule too strict? To be honest, I see nothing wrong
with the CDS/CDNSKEY RRset only signed by the ZSK but BINDs behavior and
the not so clear RFC statement keeps me wondering.
Thanks,
Daniel
