Hi there!
At work, we make use something often referred to as "weighted records",
a feature offered by many managed DNS vendors. We use it to implement
e.g. a canary environment, where we test changes on a small portion of
production traffic.
I played around with knot-dns for a bit (quite impressed), and figured
it might be nice to implement such a feature for it. Turns out, the code
is so amazing that if you abuse the infrastructure of the geoip module,
it only takes an hour (very impressed).
If you are interested in trying it, read on further below, but just to
state my intention: I was wondering if such a feature would be of
interest at all?
I realize the geoip module may not be the appropriate for such an
implementation, consider this merely a demo of sorts.
So here goes nothing:
1. apply attached patch
2. config file snippet:
mod-geoip:
- id: test
config-file: /etc/knot/test.conf
ttl: 600
mode: weighted
zone:
- domain: example.com.
file: "/var/lib/knot/example.com.zone"
module: mod-geoip/test
3. /etc/knot/test.conf:
lb.example.com:
- weight: 10
CNAME: www1.example.com.
- weight: 5
CNAME: www2.example.com.
Results in this:
conrad@deltree ~/hack/knot-dns $ for i in $(seq 1 100); do dig
@192.168.1.242 A lb.example.com +short; done | sort | uniq -c
68 www1.example.com.
32 www2.example.com.
conrad@deltree ~/hack/knot-dns $ for i in $(seq 1 100); do dig
@192.168.1.242 A lb.example.com +short; done | sort | uniq -c
72 www1.example.com.
28 www2.example.com.
conrad@deltree ~/hack/knot-dns $ for i in $(seq 1 100); do dig
@192.168.1.242 A lb.example.com +short; done | sort | uniq -c
66 www1.example.com.
34 www2.example.com.
You get the idea. Anyways, any thoughts and feedback would be greatly
appreciated.
Thanks a lot,
Conrad
Hi @all
I was trying to migrate knot to a new server with Ubuntu 18.04 and knot
2.8.0. I managed this by just copying the content of /var/lib/knot/*
from the old to the new server.
One of my domains threw an error when starting knot:
knotd[5186]: error: [<zone>] zone event 'load' failed (malformed data)
keymgr throws the same error. I dumped the data out of the 2.7.6
installation with mdb_dump and imported it into the 2.8.0 installation,
which did not help.
I then uninstalled 2.8.0 on the new server and installed 2.7.6, migrated
data from the old server with the same procedure and it worked, no errors.
Just out of curiosity I upgraded then the new server from 2.7.6 to 2.8.0
to see what will happen: It was the exact same behaviour, the zone
couldn't load.
How can I proceed here? There is obviously something wrong that the
update breaks the loading of the zone. Is this on my end or a bug in knot?
Thanks
Simon
I perfoms benchmarks with knot-dns as a authoritative server and dnsperf
as a workload client. Knot server has 32 cores. Interrupts from 10Gb
network card are spreaded across all 32 cores. Knot configured with
64 udp-workers. Each knot thread assigned to one core. So there are at
least two knot threads assigned to one core. Then i start dnsperf with
command
./dnsperf -s 10.0.0.4 -d out -n 20 -c 103 -T 64 -t 500 -S 1 -q 1000 -D
htop on knot server shows 3-4 cores completly unused. Then i restart
dnsperf unused cores are changes.
That is the reason for unused core?
When we try to use the root zone file to load to verify the UDP or TCP
perfermance of knot
the result TCP performance is greater than UDP performance
--
Best Regards!!
champion_xie
Hi!
We've been experimenting with backups and disaster recovery in our knot
test setup and have been running into a weird issue.
Basically our backup strategy right now is to perform incremental
backups of the /var/lib/knot and the /etc/knot directories via rsync.
When we try to restore these backups knot starts successfully, but logs
the following messages for each of the zones that are currently in a
signed template:
2019-03-08T11:43:05 info: [example.com.] DNSSEC, signing zone
2019-03-08T11:43:05 error: [example.com.] zone event 'DNSSEC re-sign'
failed (invalid parameter)
When we try to query information about these zones via dig we receive a
SERVFAIL rcode for them.
All of the zones that are not processed through the DNSSEC mechanism are
unaffected by this.
We also experienced th same behavior, when we were experimenting with
adding new zones that are signed immediately.
To workaround this problem we currently add the zone in an unsigned
state (aka default template) to knot and after that we switch the
template of the zone to "signed".
This works like a charm for new zones and can also be used to recover
each of the broken zones after restoring the backup, but we'd rather not
use this workaround during disaster recovery as it would impose the
danger of breaking the zones if it is not performed correctly.
The templates and policies in our knot.conf look like this right now:
policy:
- id: shared
algorithm: RSASHA256
ksk-size: 2048
zsk-size: 1024
zsk-lifetime: 1d
ksk-lifetime: 2d
ksk-shared: true
ksk-submission: resolver
nsec3: true
cds-cdnskey-publish: always
template:
- id: default
storage: "/var/lib/knot"
semantic-checks: on
global-module: mod-stats
master: primary
notify: secondaries
acl: [primary, secondaries]
serial-policy: unixtime
dnssec-signing: off
- id: signed
dnssec-signing: on
dnssec-policy: shared
master: primary
notify: secondaries
acl: [primary, secondaries]
serial-policy: unixtime
zone:
- domain: example.com
template: signed
Thanks,
Thomas
Hi,
we are testing knot at the moment and are struggling with the concept of
automatic KSK rollovers. We are planning to fetch the current CDS for
further automatic processing and try to figure out how to achieve a
policy that performs KSK rollovers in a short period of time for testing
purposes. Until now we have not seen any KSK rollovers and we are not
sure why this is not happening. Can someone show me an example of a
policy that schedules a KSK rollover within a very short period, let's
say once a day? What policy parameters must be set? And what must be the
zone's parameters in terms of TTL and SOA values (expire, refresh, etc)?
Thanks a lot,
Thomas
Ahoj,
I'm tinkering with running knot-resolver for DNS-over-TLS (only). My kresd@1
is listening on the public interface by using a drop-in override file,
following kresd.systemd(7) (kresd-tls.socket.d/override.conf).
Thing is, I would like knot to not listen on port 53 on any interface, not
even localhost. But this is precisely what it does.
I naively tried to stop it from doing so, first with a
kresd.socket.d/override.conf with:
[Socket]
ListenStream=
But that failed with journalctl -u kresd.socket containing `kresd.socket:
Unit has no Listen setting (ListenStream=, ListenDatagram=, ListenFIFO=,
...). Refusing.`
And also by trying to disable that "socket-unit", with a
kresd(a)1.service.d/override.conf containing:
[Service]
Sockets=
Sockets=kresd-tls.socket
Sockets=kresd-control(a)%i.socket
But that did nothing.
Finally, using `systemctl mask kresd.socket` I get it to stop listening on
(localhost) port 53. But then instead systemd find itself in "degraded"
mode...
Any tip on how to accomplish this cleanly?
Hello Knot DNS users.
Our deb package signing key may have been compromised and has been
revoked. Open Build Service repositories are not affected.
The affected systems (https://deb.knot-dns.cz/knot-latest and
https://deb.knot-dns.cz/knot) now contain a new Debian repository. The
packages were re-built and re-signed with a new GPG key
rsa4096/0x8A0EFB02C84B1E9B.
We thank to security researcher calling himself "p3n73st3r" who notified
us earlier today.
Regards
Your Knot DNS team
