Hello knotty people ;)
Both userspace-rcu and knot are now in the FreeBSD ports collection.
http://www.freshports.org/dns/knot/
--
Met vriendelijke groet,
With kind regards,
Leo Vandewoestijne.
Hi:
I'm trying to test Knot 1.0.1 with a basic configuration, and I managed
to crash it.
Compiled from source on a Ubuntu 11.04, serving one signed zone.
uname -a
Linux turista 2.6.38-13-generic-pae #55-Ubuntu SMP Tue Jan 24 15:54:51
UTC 2012 i686 i686 i386 GNU/Linux
autoreconf -if
./configure --prefix=/opt/knot
make
sudo make install
The configuration file looks like this
system {
identity "knot 1.0.1";
storage "/opt/knot/var/knot";
}
interfaces {
my-iface { address 192.168.22.152@53; }
}
zones {
co.nz {
file "/opt/knot/etc/co.nz";
}
}
log {
syslog { any warning, error; }
}
Then
root@turista:/opt/knot# sbin/knotc -c etc/knot.conf compile
Parsing file '/opt/knot/etc/co.nz', origin 'co.nz.' ...
Compilation successful.
root@turista:/opt/knot# sbin/knotc -c etc/knot.conf -i start
control: Running in interactive mode.
Reading configuration '/opt/knot/etc/knot.conf' ...
And when I send a query to the server
dig dnskey co.nz @192.168.22.152
I get this in syslog
Mar 15 17:00:44 turista kernel: [1487877.778230] knotd[6010]: segfault
at 0 ip (null) sp b489e03c error 14 in knotd[8048000+50000]
The error is consistent. If I restart the server, wait a little bit to
load, and then send the query, it crashes.
Running under gdb provides the following backtrace
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x0804f2d4 in udp_master_recvmmsg (thread=0x850b5f0, thread_stat=0x0)
at knot/server/udp-handler.c:427
#2 0x0804f6f6 in udp_master (thread=0x850b5f0)
at knot/server/udp-handler.c:526
#3 0x08085adc in thread_ep (data=0x850b5f0) at knot/server/dthreads.c:160
#4 0xb7e56e99 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#5 0xb7d999ee in clone () from /lib/i386-linux-gnu/libc.so.6
If you need anything else, please let me know. Unfortunately I can't
send you the zone.
Cheers,
--
Sebastian Castro
DNS Specialist
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 495 2337
mobile: +64 21 400535
Hi,
a bugfix release of Knot DNS was made today. Some minor bugs were fixed
and some simple features added. Here are some of the changes:
- Implemented jitter to REFRESH/RETRY timers
- Problem with creating IXFR journal for bootstrapped zone
- Race condition in processing NOTIFY/SOA queries
- TSIG improper assignment of algorithm type
For all changes made since the last release, see RELNOTES in the source
directory.
Source files can be downloaded here:
http://public.nic.cz/files/knot-dns/knot-1.0.1.tar.gz
Packages will be available shortly on http://www.knot-dns.cz
Have a nice weekend!
Regards,
Lubos
--
Ľuboš Slovák Knot DNS
CZ.NIC Labs http://www.knot-dns.cz
-------------------------------------------
Americká 23, 120 00 Praha 2, Czech Republic
Email: lubos.slovak(a)nic.cz
WWW: http://labs.nic.czhttp://www.nic.cz
-------------------------------------------
Please consider the environment before printing this email.
Join the campaign at http://thinkBeforePrinting.org
Hello,
Congratulations to the release of Knot 1.0 which I'm looking at a bit
now, starting off with a minimal configuration.
system {
storage "/etc/knot";
user: "root";
}
interfaces {
ipv4 { address 127.0.0.1@53; }
}
keys {
my-key hmac-md5 "xxxx";
}
remotes {
local0 { address 127.0.0.1; }
mastr { address 192.168.1.145; }
m2 { address 192.168.1.53; key my-key; }
}
zones {
example.com {
file "example.com.zone";
}
inline.aa {
file "inline.aa";
semantic-checks off;
xfr-in mastr;
notify-in mastr;
}
jpmens.net {
file "jpmens.net";
semantic-checks off;
xfr-in m2;
notify-in m2;
xfr-out local0;
}
}
Apologies for nitpicking on these rather cosmetic issues, but maybe they
can be addressed in a future version:
An invocation of `knotc -c knot.conf compile' complains that slave zone
files don't (yet) exist. (True enough: they haven't yet been
transferred):
Zone file 'inline.aa' doesn't exist.
Zone file 'jpmens.net' doesn't exist.
Parsing file 'example.com.zone', origin 'example.com.' ...
Compilation successful.
After launching Knot with `knotc -c knot.conf start', zones are
populated from the master server(s) and I see the *.db and *.db.crc
files. The zones are loaded and I can query them. So far, so good. :)
A small change to `example.com.zone' and a compile, again warns that the
slave zone files don't exist. In effect it is true: the filenames I've
configured in knot.conf do not exist, but the message is confusing
because the zones have been loaded/exist.
knotc -c knot.conf compile
Zone file 'inline.aa' doesn't exist.
Zone file 'jpmens.net' doesn't exist.
Parsing file 'example.com.zone', origin 'example.com.' ...
Compilation successful.'
A subsequent server reload `knotc -c knot.conf reload' says in the log
that the file(s) I just compiled are out of date:
Loading 3 compiled zones...
warning: Database for zone 'example.com' is not up-to-date. Please recompile.
Loaded zone 'example.com.'
Zone 'inline.aa.' is up-to-date, no need for reload.
Zone 'jpmens.net.' is up-to-date, no need for reload.
Loaded 3 out of 3 zones.
Configuration reloaded.
Regards,
-JP
