Hello, 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: Alright... Kea. From the homepage[1] 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[2] so some improvements are on the way. But let's get back to Kea. It's an open source, MPL-2.0[3] 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[4], so let's try them in order. Is Kea available in Debian? Actually, yes - there's isc-kea[5] 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[6] 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 2021. OK, so if it's not in Stable, the next on the list is Debian Backports... No backported packages. We can skip local APT repositories since that depends on the user... Any upstream APT repositories? Yes, there is something available[7], although it seems that ISC (upstream) is using a third party (Cloudsmith) to host the packages. There are instructions for setting up the APT repository access which could be translated to Ansible 'apt_key' and 'apt_repository' tasks. So the potential 'kea' DebOps role could use the "upstream" APT packages as an option, and when the next Debian Stable is released, enable/disable the use of the upstream APT repository conditionally. 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 and either service can be easily activated via Ansible inventory groups. I'm in. Anybody wants to write the role? [1]: https://www.isc.org/kea/ [2]: https://gitlab.com/ciphermail/debops.dhcpd [3]: https://spdx.org/licenses/MPL-2.0.html [4]: https://docs.debops.org/en/master/dep/dep-0003.html [5]: https://tracker.debian.org/pkg/isc-kea [6]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959149 [7]: https://cloudsmith.io/~isc/repos/kea-1-6/packages/?q=distribution%3Adebia... [8]: https://cloudsmith.io/~isc/repos/kea-1-6/setup/#formats-deb 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[9], 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 achievement? Let's see... I know that there's a well supported knot package[10] 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[11] 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[12] 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[13] 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[14]: "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[15]: "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' utility." 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[16]... Wikipedia page on nsd is much more informative[17]. 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[18] and shows multiple interesting features. Well, let's what the project homepages tell us about each server. On the Knot DNS features page[19] 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 efficient. The NSD project prominently displays a list of RFC documents related to DNS which are supported in their project[20]. 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 'unbound' 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'[22]. This could be handled by a custom code in the ACME clients[23], 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 with the one from BIND. YADIFA also supports dynamic DNS updates. The 'nsupdate' Ansible module[24] most likely supports all three servers. [9]: https://github.com/drybjed/ansible-bind [10]: https://tracker.debian.org/pkg/knot [11]: https://tracker.debian.org/pkg/nsd [12]: https://tracker.debian.org/pkg/yadifa [13]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958009 [14]: https://en.wikipedia.org/wiki/Comparison_of_DNS_server_software [15]: https://en.wikipedia.org/wiki/Knot_DNS [16]: https://serverfault.com/questions/720287/safely-restart-reload-bind-dns [17]: https://en.wikipedia.org/wiki/NSD [18]: https://en.wikipedia.org/wiki/YADIFA [19]: https://www.knot-dns.cz/docs/2.9/html/introduction.html#knot-dns-features [20]: https://www.nlnetlabs.nl/projects/nsd/rfc-compliance/ [21]: https://lists.nlnetlabs.nl/pipermail/nsd-users/2013-September/001719.html [22]: https://dan.langille.org/2017/05/31/creating-a-txt-only-nsupdate-connecti... [23]: https://blog.znedw.com/lets-encrypt-wildcard-nsd.html [24]: https://docs.ansible.com/ansible/latest/modules/nsupdate_module.html 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. -- Maciej

Hello, My 2 cents: Imre wrote a role [1] for PowerDns [2]. There is also a role [3] for Opera DNS UI [4] : "A tool to manage a PowerDNS authoritative server in a corporate LDAP-driven environment." And Imre is a contributor [5] on this project ;-) [1] https://gitlab.com/ciphermail/debops.powerdns_auth [2] https://en.wikipedia.org/wiki/Powerdns [3] https://gitlab.com/ciphermail/debops.dnsui [4] https://github.com/operasoftware/dns-ui [5] https://github.com/operasoftware/dns-ui/commit/fb591d75f1390506a75f608748... -- Nicolas Quiniou-Briand Messagerie instantanée (Jabber) : nqb(a)azyx.fr Tél : 06 75 84 56 74