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
Hi,
I just upgraded to Knot 2.0 from the PPA repository and noticed that the
script /usr/lib/knot/prepare-environment is still expecting the old
style configuration format and as such is not working with the new YAML
formatted configuration. As a consequence the /run/knot directory is not
chown'ed to the configured user:group and the control socket creation fails.
Cheers,
Antti
Hey all,
if you are using Knot DNS repositories for Debian and/or Ubuntu, the repositories with just 'knot' will start shipping (or already started) shipping Knot DNS 2.0. There will be no Knot DNS 2.0 packages for Debian wheezy, since we don't want to backport that many libraries. If you absolutely have to stay on Debian wheezy, please switch to Knot DNS LTS.
if you want to stay with Knot DNS LTS (1.6.x) replace the part that says /debian or /knot with /knot-lts or /knot-dns with /knot-dns-lts
The full instructions should be soon up on the webpages, but TL;DR for Knot DNS LTS:
Debian:
su -
wget -O - http://deb.knot-dns.cz/knot-lts/apt.key | apt-key add -
rm -f /etc/apt/sources.list.d/knot.list
echo "deb http://deb.knot-dns.cz/knot-lts/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/knot-lts.list
apt-get update
apt-get install knot
Ubuntu:
# remove ppa-purge ppa:cz.nic-labs
sudo add-apt-repository -r ppa:cz.nic-labs/knot-dns
sudo add-apt-repository ppa:cz.nic-labs/knot-dns-lts
sudo apt-get update
sudo apt-get install knot
Cheers,
--
Ondřej Surý -- Chief Science Officer
--------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.sury@nic.cz https://nic.cz/
--------------------------------------------
I'm migration from PowerDNS using AXFR and some of the domains fall on
Section 2.4 having CNAME on top domains.
Is there a way to ignore the warning and receive the query?
An example of troublesome domain transfer:
Jun 30 11:33:40 p-01 knot[2930]: info: [strangedomain.com] AXFR, incoming,
127.0.0.1@53: starting
Jun 30 11:33:40 p-01 knot[2930]: warning: [strangedomain.com] semantic
check, node 'strangedomain.com.' (CNAME, node contains other records than
RRSIG and NSEC/NSEC3)
Jun 30 11:33:40 p-01 knot[2930]: error: [strangedomain.com] AXFR, incoming,
127.0.0.1@53: failed (failed)
Jun 30 11:33:40 p-01 knot[2930]: error: [strangedomain.com] transfer,
failed (no active master)
I'm running on Gentoo compiling Knotd 1.6.4 from source w/ no special flags.
Thanks in advance!
--
[ ]'s
Filipe Cifali Stangler
