Let me take this opportunity to show you how I choose what application and
service roles can get into DebOps. :-)
On lip 24, hvjunk wrote:
- Consider including Kea (also from ISC) for DHCP
Alright... Kea. From the homepage we can learn that Kea is essentially
a next generation DHCP server, newer things always get at least a few points
towards the inclusion. Currently in DebOps we have ISC DHCP server, so there's
already an alternative solution, but the role is ancient and needs to be
redesigned. Luckly, I'm aware that Imre Jonk is currently working on a rewrite
of it so some improvements are on the way.
But let's get back to Kea. It's an open source, MPL-2.0 licensed
application with additional, premium features. Having paid-only features isn't
really a problem per-se, but DebOps users might find themselves wanting to use
some of them, and this could push them to pay for them. Kinda feels like they
were forced to pay for these features due to its use in DebOps... I guess it's
an ethical problem, but let's leave it at this point.
Now, the problem of actually installing the software. DebOps has a whole
policy about how to install software and what sources are acceptable, so
let's try them in order.
Is Kea available in Debian? Actually, yes - there's isc-kea package in the
Debian repositories, currently available in Oldstable and Unstable. Which
means that it's not in Stable, so we cannot use it right away.
Kea was available in Oldstable (Stretch), so somebody is interested in
maintaining it. Current version in Unstable has one bug from April 2020. It
looks like a relatively simple fix, so it will probably be done before Debian
Testing gets frozen at the beginning of 2021 and isc-kea package will land in
Testing again, and hopefully in the next Stable (Debian Bullseye). At this
point somebody who really would want Kea to be available in Debian Stable
could probably help with fixing that bug to ensure that it happens.
So, if we can wait until next Debian Stable, Kea will be easily available in
Debian and a role can be written then. Next Debian Stable will be around July
OK, so if it's not in Stable, the next on the list is Debian Backports... No
We can skip local APT repositories since that depends on the user... Any
upstream APT repositories? Yes, there is something available, although it
seems that ISC (upstream) is using a third party (Cloudsmith) to host the
There are instructions for setting up the APT repository access which could be
translated to Ansible 'apt_key' and 'apt_repository' tasks. So the
'kea' DebOps role could use the "upstream" APT packages as an option,
the next Debian Stable is released, enable/disable the use of the upstream APT
That settles it - we have a controllable and easy way to install Kea. overall,
the service seems to be useful, and another alternative to the 'dhcpd' role
wouldn't hurt since that role is not included in the 'common.yml' playbook
either service can be easily activated via Ansible inventory groups. I'm in.
Anybody wants to write the role?
- Knot/NSD as authoritative Domain Name Servers.
BIND has it issues or sometimes too big, when you need something less complex than BIND
and there is also YAdifa: https://www.yadifa.eu/download
We currently don't have any Ansible role for a primary DNS nameserver in
DebOps. There's a role for 'dnsmasq', but it's primarly a LAN service and
shouldn't be used on public networks. Tasos Alvas is working on a role for ISC
BIND, and I started working on one in the past, Tasos is aware of it so
that's a bonus for him.
An authoritative only DNS server as an alternative to BIND seems like a nice
role to have, although I would try and add BIND first since it's a very
popular DNS nameserver. It's also a personal bias since I'm using it and
I would like to have a role for it. Not to mention that ISC BIND can integrate
with ISC DHCP service for which we already have a role... Completionist
Let's see... I know that there's a well supported knot package in Debian,
so that's a no brainer. Knot was available in Oldoldstable (Jessie), is in
current Testing, there are no outstanding bugs. Seems to be an excellent
choice for us. Latest upload of the knot package to Unstable was on 2020-05-26
and it easily got into Testing.
The nsd package is also available in Debian and it is equally well
supported, being available from Jessie and present in Testing. Latest upload
to Unstable was on 2020-04-20 and also easily migrated into Testing.
The yadifa package is also in Debian First showed up in Debian Oldstable
(Stretch) and is currently in Testing. Latest upload to Unstable was on
2018-06-21 and went into Testing a few days later. But wait, yadifa package
was marked for autoremoval in August due to uses with compilation on GCC
10. But there's patch already so this might be fixed before the package gets
removed from Testing.
If I would want to add another authoritative DNS role, I would pick only one
at a time, we don't need to support like 20 DNS servers... So, any must-have
features in either Knot, nsd or yadifa?
From the comparsion of the DNS software on Wikipedia:
"Knot DNS is a free software authoritative DNS server by CZ.NIC. Knot DNS aims
to be a fast, resilient DNS server usable for infrastructure (root and TLD)
and DNS hosting services. Knot DNS supports DNSSEC signing and among others
hosts root zone (K and L Root_name_servers), several top-level domains."
"NSD is a free software authoritative server provided by NLNet Labs. NSD is
a test-bed server for DNSSEC; new DNSSEC protocol features are often
prototyped using the NSD code base. NSD hosts several top-level domains, and
operates three of the root nameservers."
"YADIFA is a BSD-licensed, memory-efficient DNS server written in C. The
acronym YADIFA stands for Yet Another DNS Implementation For All. It was
created by EURid, which operates the .eu top-level domain."
Both seem to be used in root DNS nameservers, which probably means that they
have dedicated developers behind them.
From the Wikipedia page about Knot DNS:
"Knot DNS uses a zone parser written in Ragel to achieve very fast loading of
the zones at the startup. It is also able to add and remove zones on the fly
by changing the configuration file and reloading the server using the 'knotc'
Not much else on the wiki page... Well, an ability to reload zones on the fly
doesn't seem that impressive since BIND can do it too...
Wikipedia page on nsd is much more informative. Some interesting tidbits:
"NSD uses BIND-style zone-files (zone-files used under BIND can usually be
used unmodified in NSD, once entered into the NSD configuration)."
That means that we could create a separate Ansible role to manage DNS zone
files for both BIND and NSD. That's a huge plus.
The YADIFA Wikipedia page is even more extensive and shows multiple
Well, let's what the project homepages tell us about each server. On the
Knot DNS features page we can find that Knot supports many useful featurs.
YAML-based zone configuration kind of rubs me the wrong way a bit since
in DebOps we would have to define YAML-in-YAML to have somewhat controllable
deployments with conditional options. Kind of counter-intuitive, but
configuring YAML via Ansible leaves lots to be desired if we want to be
The NSD project prominently displays a list of RFC documents related to DNS
which are supported in their project. This is a huge plus, keeping close
to the estabilished standards should ensure good compliance on the protocol
level - if something errors out it will probably not be on our side of the
connection. NSD is also closely related to Unbound and uses the same
configuration syntax. Which is good for us, since there's already an
role in DebOps which can be used as an inspiration for the 'nsd' role.
A quick check on the mailing list reveals that NSD does not support dynamic
DNS zones, which means that 'nsupdate' is not supported, which means that we
probably won't be able to implement Let's Encrypt support using
'nsupdate'. This could be handled by a custom code in the ACME
clients, but the solutions might be less portable between different DNS
servers and might cause overhead in PKI implementation. Knot supports
'nsupdate' via its own implementation, I'm not sure if it's compatible
the one from BIND. YADIFA also supports dynamic DNS updates. The 'nsupdate'
Ansible module most likely supports all three servers.
Well, it's a hard choice at this point, and it's almost 2 AM here, so I need
to finish this quickly... All three servers have their advantages, all are
easily available in Debian... If I would have to pick one, I'll probably would
go with YADIFA with NSD as a close second. I don't knock off the Knock DNS
entirely, of course. If anybody wants to work on roles for one of these
nameservers, be my guest.