Hi,
I'm running Knot 2.0.0 and automatically signing my zone with manual key
management policy. When I manually refreshed the signatures by running
"knotc signzone <zone>", all the signatures were refreshed as expected,
except the DNSKEY RRset, whose signature remained untouched. I thought
this wouldn't be a big deal, as Knot would probably automatically
refresh DNSKEY RRset signature when about 1/10 of its lifetime will be
remaining.
However, when I now look at "knotc zonestatus", it shows that the next
resigning is scheduled far beyond the exipration of the DNSKEY RRset
signature. So, is my DNSKEY RRset signature going to be expired or is
DNSKEY handled in some special way so that it will be eventually
refreshed before expiring?
My current DNSKEY RRSIG will expire at 20150828172101:
nxdomain.fi. 600 IN RRSIG DNSKEY 8 2 600 20150828172101 20150729172101
61894 nxdomain.fi. qQJm.....
But the next resigning is scheduled on 2015-09-14:
nxdomain.fi. type=master | serial=2015081708 | DNSSEC resign in
647h56m43s | automatic DNSSEC, resigning at: 2015-09-14T02:26:59
Thanks,
Antti
Hi,
My system is debian 6.0 (yes I know it's out of date).
When I installed knot from source following the document, I got failed
as below. How can I get continued? thanks.
$ autoreconf -i -f
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:35: error: possibly undefined macro: AC_SUBST
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:93: error: possibly undefined macro: AS_IF
configure.ac:102: error: possibly undefined macro: AC_MSG_WARN
configure.ac:122: error: possibly undefined macro: AC_DEFINE
configure.ac:163: error: possibly undefined macro: AC_MSG_ERROR
configure.ac:251: error: possibly undefined macro: AC_SEARCH_LIBS
autoreconf: /usr/bin/autoconf failed with exit status: 1
Network renumbering requires that A and AAAA RRs are directly or
indirectly (DHCP) updated. This in turn requires dynamic DNS updates
(RFC 2136).
Although Knot DNS allows dynamic updates, it is not really prepared to
securely handle this scenario. Knot DNS can either allow an address or
key to update RRs in a zone via ACLs which is not fine-grained enough to
useful for this purpose because it is questionable from a security
perspective (under a certain threat model etc.). Assume that example.com
uses dynamic DNS updates to update A and AAAA RRs to be prepared to
renumber its network. If example.com uses a DHCP server to update the
RRs, it suffices to take over the DHCP server of example.com to update
any RRs in the zone of example.com, including NS, MX, TLSA and SSHFP
RRs. If every host of example.com updates its own A and AAAA RRs
directly and indirectly via a DHCP server, the problem is still the
same, even if you move every hostname in a separate zone, for example it
suffices to take over the webserver that serves example.com to change
the MX RRs of example.com. With more fine-grained ACLs the problem would
not exist.
Currently ACLs consist of a subject (address and key), operation
(transfer, notify, update, control) and object (zone). I think it would
suffice to extend the object of an ACL to a triple (zone, name, type)
similar to dynamic update policies in BIND. Perhaps it would also be
useful to be able to use wildcards and negation. Are there any plans to
extend the ACL mechanism in this way?
Regards,
Matthias-Christian
Hi
Is keymgr broken or what am I doing wrong?
/knot# mkdir kasp
/knot# cd kasp
/knot/kasp# keymgr init
/knot/kasp# keymgr zone add example.com policy none
/knot/kasp# keymgr zone key generate example.com algorithm rsasha256 size 2048 ksk
id 36b49807bcdf448c5034cf37688b99616760529c keytag 24400
knot/kasp# keymgr zone key generate example.com algorithm rsasha256 size 1024
Cannot retrieve zone from KASP (malformed config value).
Regards,
shadice
Hello
I've built knot 2.0.0 and created a rpm for redhat 7 and have a problem
with the knot.service systemd file.
I've used the rpm SPECS and knot.conf, knot.service file from the src
rpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=670057 and
adapted the SPECS file slightly to get it working on redhat 7.
The knot.service file has the following Service section:
[Service]
Type=notify
ExecStart=/usr/sbin/knotd
ExecReload=/usr/sbin/knotc reload
Restart=on-abort
ExecStartPre=/usr/sbin/knotc checkconf
If I use the type "notify" and start the service (systemctl start knot)
the command does not complete but stays in the foreground. After a few
seconds, minutes systemd gets a timeout and terminates the service:
systemd: knot.service operation timed out. Terminating.
knot[32446]: info: stopping server
knot[32446]: info: shutting down
systemd: Failed to start Knot DNS server daemon.
systemd: Unit knot.service entered failed state.
I now changed the knot.service file to use type "simple" [1] and that
works and resolves the problem. However, I believe to have read that
type "notify" should work. Is this a bug?
Daniel
[1] http://www.freedesktop.org/software/systemd/man/systemd.service.html
Hi
I have problems in v2.0.0 with the serial-policy definition as it is not working as expected.
Here is my knot.conf which I am using:
# knot.conf
server:
user: knot:knot
udp-workers: 1
tcp-workers: 1
background-workers: 1
listen: 0.0.0.0@53
listen: ::@53
log:
- target: syslog
any: debug
template:
- id: default
storage: /opt/knot
semantic-checks: on
dnssec-signing: on
kasp-db: kasp
serial-policy: increment
zone:
- domain: example.com
dnssec-signing: off
2015-08-11T18:27:33 info: configuration is valid
Using increment as serial-policy, first the serial gets incremented by 1. After that, it will stay at 1, nevertheless how many changes I make.
info: [example.com] loaded, serial 0 -> 1
info: [example.com] loaded, serial 1 -> 1
info: [example.com] loaded, serial 1 -> 1
info: [example.com] loaded, serial 1 -> 1
Using unixtime as serial-policy, the serial stays always at 0.
info: [example.com] loaded, serial 0 -> 0
info: [example.com] loaded, serial 0 -> 0
info: [example.com] loaded, serial 0 -> 0
info: [example.com] loaded, serial 0 -> 0
Am I doing it wrong?
Do you use in anyway a RTC? because I do not have it.
Regards
shadice
Has anyone used the rosedb or dnsproxy modules extensively in production?
I'm concerned about whether it would reliably scale as well as Knot does
without it. I'm evaluating knot in hopes that I can use it to offer part of
my would-be service to potentially millions of websites. I'm planning a
free usage tier would would hopefully be heavily utilized.
Regarding the specific implementation, I want to provide an authoritative
DNS server that returns predefined values based on record types/host
(rosedb). If the host/record combo conditions aren't met, proxy the request
to the original nameserver(s). After reviewing the nightly code it looks
like I'll likely need to invest a lot of time in order to support that
chained query plan.
Thank you for any feedback in advance.
-Anonymous Coward
Hi
Knot DNS v2.0.0 reserves up to 620 MB memory on my Raspberry Pi.
But it actually uses only 0.4 % of the available 512 MB memory.
How can I limit the memory reservation/allocation to 100 MB?
Regards
shadice
