Hi Everyone,
we're getting closer to the 1.5 release and because we're mostly
feature complete now, I think today might be a good opportunity to
share some of the new stuff we've created and hear out your opinions.
There's a ton of improvements that I can't cover in a few paragraphs,
but I've picked 3 of those that I think are the pillars for the bigger
plan for this year.
Just so you know, there is no tarball this time, but if you're brave
enough, you can actually try everything covered here. You can find the
code in our git repository under a tag "v1.5.0-alpha":
$ git clone -b v1.5.0-alpha https://gitlab.labs.nic.cz/labs/knot.git
1. Query processing and code base
We've known for a while that there were parts of the code that we
weren't happy with. It's not just that it was getting hard to patch
and read, but with we had a ton of ideas that we couldn't get
implemented because of the limitations (in fact, this effort bears
fruits as soon as of this release, but more on that later). One of
those places was query processing and dealing with queries in general.
Naturally, we've sat down and reworked this from scratch. Now, from
the user perspective it's not so exciting - yes we made it RFC
compliant in several cases and it's faster than ever (I'm running
benchmarks as we speak, so you might want to check out our webpage
later). It's still a preview and we're ironing things out, so don't
take the numbers as final.
For those who are interested in the details (thank you!), it's much
much more important because the code lays a solid foundation for the
cool stuff to come while being lightweight. How much? Around 10+k LOC
which is roughly 10-15% of our code base gone and we offset that by
adding almost 5k LOC worth of test cases. To put it in another words,
it means it does more with less and we're not done here.
2. Separating Knot DNS library
We also improved the Knot DNS build process overall. The code
providing basic building blocks for the server and utilities is now
held in the libknot library, which is by default linked dynamically to
these components. You will also notice the libzscanner library, our
high-performance zone scanner written in Ragel (with no dependencies
on Knot DNS). We plan to build some other projects on top of that and
provide public headers in the future (which is more likely to happen
for the libzscanner - if someone is interested). But currently, you
may benefit from a smaller size of the binaries.
3. Pluggable query processing modules + auto forward/reverse records
New features are always a compromise - usually between ease of use,
complexity and resource usage.
But what if we could make the core as lightweight as possible and let
the user choose? The new processing API is built like a Lego (don't
step on it though), it breaks down the processing into independent
parts that together form a plan for query processing. So what we did
was, we've created an interface for loadable modules and let it
add/remove or change the query processing plan as the module sees fit.
This allows to keep complexity at bay (for those who don't want extra
stuff) and provide a playground for new ideas. We actually have a
first module - it can synthesize per-answer forward/reverse records
for IPv4/IPv6 addresses from a template in configuration file (see
4.11 in the documentation on further information). For the impatient,
an example speaks the best:
We have an IPv6 reverse zone we need to take care of, but the problem
is the address space is too big to generate a zone file. So we create
an empty zone, put in static records we want and let the module to
synthesize other records per-answer (if they fit in the template and
aren't present in the zone):
# Configuration:
1.6.b.0.0.0.0.0.0.2.6.2.ip6.arpa {
query_module {
synth_record "reverse dynamic- example. 400 2620:0:b61::/52";
}
Now if we load Knot DNS, and kdig for a reverse record, we get a
following reply:
$ kdig PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.6.b.0.0.0.0.0.0.2.6.2.ip6.arpa.
;; QUESTION SECTION:
;; 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.6.b.0.0.0.0.0.0.2.6.2.ip6.arpa.
0 IN PTR
;; ANSWER SECTION:
..snip.. 400 IN PTR dynamic-2620-0000-0b61-0000-0000-0000-0000-0001.example.
Forward records can be dealt with in a similar fashion, see the manual
4.11 for more examples and information.
To sum it up, modules could be a way to accommodate for the "should
this be a in a nameserver?" sort of things. If you don't like it, just
don't put it in the configuration and you're good. As of now the
module API is open (no "how to" though), and so are we for ideas.
Phew, this was longer than I expected and I barely scratched the surface.
As you see, this version is going to be a lot about tidying up and
opening up the possibilities.
So what's your take on this?
Best,
Marek
--
Marek Vavrusa, Knot DNS
CZ.NIC Labs http://www.knot-dns.cz
-------------------------------------------
Americká 23, 120 00 Praha 2, Czech Republic
WWW: http://labs.nic.czhttp://www.nic.cz
Hi Everyone,
while we in the CZ.NIC Labs are all focused on the next big thing, I
thought now it might be a good time to get out another of our
(admittedly highly irregular) monthly patch releases. Bug fixes aside,
there are a couple improvements that we hope will make your life
easier. Here's the breakdown:
- 'knotc reload' does not immediately refresh/notify unchanged zones.
This fixes the flurry of refresh messages after each reload and makes
it lightweight enough to be used frequently. Note that new/changed
zones are still added and old zones are removed. However, if you want
to refresh zones explicitly, you need to call 'knotc refresh' after
reload now.
- 'knotc -f refresh' now truly forces a zone refresh. To put it in
another words, it's akin to the 'retransfer' command that you missed
in the Knot DNS and instead of checking for new zone, it starts a full
transfer of the zone right away.
- 'knotc' remote commands are now logged in the daemon logfile
Now, there are several bugfixes as well. See the NEWS for a complete
list, but here's a selection of the most notable - in several cases
notify messages weren't sent after a zone resign, progressive
bootstrap retry regression was fixed, few issues with journal and
maximum entry size. There is also a slight behaviour change in the
zone file parser and the daemon itself. First - zone file parser now
accepts asterisk in the domain name labels (wildcards aside). As for
the daemon, if a zone is in a slave mode and fails to load for some
reason, it immediately tries to reboostrap from the master server
instead of just reporting an error.
I'd also like to thank to Robert S. Edmonds for amending various
spelling errors and typos in manpages and documentation, thanks!
So that's it, I hope the improvements make this update a little
worthwhile before new stuff
comes out later this spring.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.4/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.gzhttps://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.xz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.gz.aschttps://secure.nic.cz/files/knot-dns/knot-1.4.4.tar.xz.asc
Kind Regards,
Marek
--
Marek Vavrusa, Knot DNS
CZ.NIC Labs http://www.knot-dns.cz
-------------------------------------------
Americká 23, 120 00 Praha 2, Czech Republic
WWW: http://labs.nic.czhttp://www.nic.cz
Hi there,
I migrated our primary DNS from Bind to Knot. I runned some tests by
nic.cz's dnscheck, but there is an error:
DNSSEC signature RRSIG(fnhk.cz/IN/SOA/64431) fails to validate the RR set:
key 1: keytag does not match key 2:RSA Verification failed
Link to test:
http://dnscheck.labs.nic.cz/?time=1395821962&id=102810&view=advanced&test=s…
Knot doesn't complains to anything in the system log, fnhk.cz zone is
succefully signed.
What did I missed ?
Thanks and best regards
J.Karliak.
Hello,
What do you guys recommend to audit every resource
record in a zone file against all the records in all the DNS.
I want something that I feed the master zone file and then goes to each
NS server and ensures that the records are correct in all of them.
For some strange reason all my DNS servers have the same SOA Serial, but
after deleting two MX records, some 4 out of 5 the DNS servers have not
taken this update. I've yet to figure out the cause, but I see that SOA
Serial is not to be trusted.
Regards,
Maren.
On 2/24/2014 7:00 PM, knot-dns-users-request(a)lists.nic.cz wrote:
> Date: Mon, 24 Feb 2014 09:16:27 +0100
> From: Jan Kadlec <jan.kadlec(a)nic.cz>
> To: "Maren S. Leizaola" <leizaola(a)hk.com>
> Cc: knot-dns-users(a)lists.nic.cz
> Subject: Re: [knot-dns-users] GLUE and additional records.
> Message-ID:
> <1393229787.1717.12.camel(a)labs.jan.kadlec.ws.eth.1.office.nic.cz>
> Content-Type: text/plain; charset="UTF-8"
>
> Hello Maren and thanks for your report. Knot normally sends glue records
> in additional section, it seems as if you might have encountered a bug.
> Could you provide more data? One NS, A (AAAA) combination and a dig
> output for this combination should be enough. Thanks again, Jan.
>
The environment is as follows. I host hk.com on 6 DNS servers, right now
5 are bind and one is Knot. hk.com's name servers are
a,b,c,d,e,f.udrtld.net b is running Knot.
Try this link www.intodns.com/hk.com
This reports that B provides no glue. Please ignore the errors on f.
i've yet not setup urdtld.net on it.
dig -cA hk.com @b.udrtld.net
when I do a
dig -cA hk.com @a.udrtld.net
Am I making any mistakes here?
Maren.
Hello,
I am currently testing Knot on our zones and find that it
does not give any of the additional records which contain the IP of the
names servers ie knot servers donot provide Glue records. This is one
good thing that Bind does at it reduces the number of queries a resolver
has to make.
Is there any way for us to be able to do this.
Regards,
Maren.
Hi Everyone,
I think the time is ripe for a small status update, preview of things
to come and a new patch release. Sounds good? So, at the moment, our
team at the CZ.NIC Labs is working towards the next major thing, but
I'd like to reiterate that we didn't forget about the 1.4 and as of
today we have a new release with several important backported
bugfixes, here's the brief version:
* Two bugs related to authenticated denial of existence proof with a
certain combination of wildcard expansions triggering an assertion
failure
* Comparison of $ORIGIN and zone file in configuration is case insensitive
* Corrupted journal data caused a cleanup failure during the zone loading
In addition to the bugfixes, we have also slipped in a small
enhancement - "include" statement in the configuration can include
whole directory, this is useful if you have really a lot of includes
in one place.
Now a brief status update on what are we working on and what can you
expect in the next few weeks/months. The next major release is going
to happen later this spring and it's going to be focused on three
things mostly - covering the code by tests, cleaning up and polishing
existing features. There's going to be a feature or two, but that is
not the main focus. The reason is the functionality we have piled up
over the time has taken it's toll and now is the right time to sit
back and make the features leaner and meaner (that includes usability
as well), as that was always an integral idea behind Knot DNS. Plus
less things means less things to break, right?
I'd like to thank namely Petr Stastny and Olafur Gudmundsson (among
others) for bugreports, ideas and thoughts.
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.3/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.gzhttps://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.xz
GPG signatures:
https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.gz.aschttps://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.xz.asc
Kind Regards,
Marek
--
Marek Vavrusa, Knot DNS
CZ.NIC Labs http://www.knot-dns.cz
-------------------------------------------
Americká 23, 120 00 Praha 2, Czech Republic
WWW: http://labs.nic.czhttp://www.nic.cz
Hi Knot developers,
I have a feature request: I'd like a knotc command that will force Knot
to transfer a zone that is configured as a slave. The only command I can
issue at the moment is "refresh", but this will not transfer a zone if
Knot has a higher serial than the master.
Such a forced transfer command is useful to help recover from situations
where due to some operational error on the master server, the serial
number has gone back, and we deliberately need our Knot server to sync
to that old serial number. Without this command, the only way to make
Knot recover is to stop it, delete the zone file from disk and start it
again. But this is not ideal on a running server with lots of zones,
because the stop and start times can be quite high (in our case, 37s to
stop, and 1m30s to start).
Both BIND and NSD provide such commands to ignore the serial number
check and force zone transfers. I'd love to see such a command for Knot too.
Regards,
Anand