Technitium DNS (and DHCP)

I just leave this here…
https://technitium.com/dns/
…when the team decides to add a real DNS (and DHCP) server. :slight_smile:

Please…

2 Likes

…and if dev team considers adding this to NS, make sure it really also takes over from Samba container (Active Directory) DNS services too.
(in other words a Technitium setup also checks if AD is enabled and takes over AD compliant DNS entries - and the opposite, if AD gets enabled, checks if Technitium is enabled, so that AD entries get there too)
Point is, is Technitium takes over all DNS and DHCP in the network.

Looking over their page, it looks very similar to Pi-hole. What do you see as the difference(s) between the two?

Why is Pi-Hole enabled in NethServer?
AFAIK NethServer implements a very basic DNS that just forwards requests.
(the lack of “real” DNS server has been discussed before in this forum)

In any case Technitium is a full DNS server, so it implements most if not all kinds of records, TXT, SRV etc. (not just A) and can act as authoritative DNS. Not sure if Pi-Hole can do that.
Also Technitium works with DNS-over-TLS and DNS-over-HTTPS.

It isn’t; it’s just another DNS-level ad blocker that (from what I’ve seen) is considerably better-known, and ad-blocking is the headline feature of Technitium:


That was the reason for my question–if the devs were going to implement a DNS-level ad blocker in Neth, there’s at least one other package out there, so it would be worth considering the relative pros and cons. But it sounds like your concern isn’t so much the ad blocking but other DNS features–and I also don’t know whether (or to what degree) Pi-hole supports those.

Current NethServer services rely heavily on dnsmasq. Wouldn’t it be a lot less invasive if you just install Cockpit-Machines addon and fire up a VM and use that as Pi-Hole or Technitions DNS Server?
We already have cockpit and it is a 1 line install (something like yum install cockpit-machines )

If you ask me personally, I don’t have the need to do this Robb, as my Neth is already a VM in my unRAID server. In unRAID server there is already a plugin (I suspect a container) that implements Technitium.

Makes more sense though that my Neth setup would also be my GW and DNS. I see dnsmasq as a real limitation to make Neth a full Win Srv replacement (I migrated to above setup from SBS2011 at home but would also consider it for work), I believe T is a very nice (and admin friendly) DNS/DHCP server.
Also my point (see reply to myself above) is to implement it “properly” (as part of Neth) and take over ALL DNS/DHCP functionality both from Neth itself (dnsmasq) and Samba container (that also implements DNS, but needs Windows tools to actually manage it) - otherwise this will not be the case (and we need to make manual entries and maintain them),.

Indeed ad blocking is secondary (but welcome) functionality. A bonus.
I really think Technitium should become an “app” for Neth.

I wake up this topic… I was forced to add a Technitium container on my unRAID server (which is an out-of-place choice for the DNS), because NS (that should provide a real DNS server) doesn’t actually provide a real DNS…

NethServer has Threat Shield and Pi-Hole which seems an alternative to Technitium, see AlternativeTo.

AFAIK none of the two is a fully fledged DNS server.
It blocks and forwards the rest.

Technitium is a nice, fully fledged, DNS (and DHCP) server, with web interface, plugins, beautiful graphs etc.

@NLS can this be of help to you too, since it also provides s full fledged DNS server.

if it can be gotten to work effectively.Full DNS software, even via docker - #5 by oneitonitram

I actually installed and successfully use Technitium on a docker container I use in my unRAID server. where Nethserver is a VM.

But if you ask me, this is a “hit” to what Nethserver supposedly is.
Right now the only part of NS I actively use is the mail server, antispam (and similar) and webtop.
All the rest where taken over by stand-alone containers on my host machine.
But that of course is my own case scenario. Your mileage may vary.
That said, NS needs a real update, but that is a different topic.

Have you been unable to isntall technitium on NEthserver using the available Nethserver-docker?

I haven’t tried.
There is no point enabling NS docker module, when NS in itself is a VM running on a host that in turn already runs other containers.
My point is that NS should have an integrated full DNS solution (like Technetium) instead of the one they integrate now.

1 Like

and as you have been informed before, Nethserver in its current form, is tightly intertwined with dnsmasq so doing a direct integration of technitium would be next to impossible, if not pseudo-engeneering.

In that case, if you yourself, who is the user of the software solution you are proposing are not willing to get it working, or even try to get it working using the available method, so that other implementation scenario s can be looked into.

Why should anyone else be bothered in this community?

2 Likes

how really does sone create a vm using cockpit machines, especially loading iso images or

EDIT:

i get this erro:

ERROR internal error: process exited while connecting to monitor: 2021-10-22T14:48:53.915662Z qemu-kvm: -drive file=/home/vboxweb/CentOS-7-x86_64-DVD-2009.iso,format=raw,if=none,id=drive-ide0-0-0,readonly=on: could not open disk image /home/vboxweb/CentOS-7-x86_64-DVD-2009.iso: Could not open '/home/vboxweb/CentOS-7-x86_64-DVD-2009.iso': Permission denied Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect qemu:///system start tcc otherwise, please restart your installation.

edit fixed by chmod =rwx /home/vboxweb/CentOS-7-x86_64-DVD-2009.iso

I wonder if this might be easier to integrate with NS8, given its all-container architecture. I’m seeing more value in it than I once did (see Full, public, authoritative DNS support), but with the current architecture, I think it’d be near-impossible to replace dnsmasq in NS7. But it’d sure be nice for NS to be able to automagically handle all the dozens of DNS records that are used for email…

4 Likes

But they really aren’t. Technitium states as their headline feature that it’s DNS-based ad blocking, but it’s apparently a full-featured DNS server. Pi-Hole has improved since this topic was started; it now allows local DNS entries (so I can configure local hostnames on my LAN–which I can also do with NS, of course), but I’m not aware of any supported way for it to handle, say, TXT or SRV records.

4 Likes

While we are on the subject of “make a wish”… I would also very much appreciate a full DNS server. But for me it would only be full-fledged if the integration with Nethserver would allow to automatically generate and apply the current TLSA-Record at every LE-certificate renewal.
Currently, I have to manually generate a TLSA record every time I change my LE certificate, and then file it with my DNS provider. This is more than just annoying, but creates an interruption in the DANE state when the LE certificate is renewed automatically (certbot renew).

https://ssl-tools.net/mailservers/dargels.de

https://dane.sys4.de/smtp/dargels.de

But I’m not sure how many mail server administrators value DANE.

https://dane.sys4.de/smtp/nethesis.it

https://de.ssl-tools.net/mailservers/nethesis.it

Seems like there are two possible solutions to this:

  • Since the TLSA record is tied to the public key, not the certificate, instruct whichever ACME client you’re using to reuse the keys. For acme.sh, that’s the default behavior; for certbot, you’d use the --reuse-key flag. If the public key doesn’t change, the TLSA record doesn’t need to change.
  • If your DNS host supports automation (and if it doesn’t, consider changing to one that does–I continue to like and recommend Cloudflare), automate the update to the DNS record. This script (and its comments) should point you in the right direction for Cloudflare: A bash script to update a Cloudflare DNS A record with the external IP of the source machine · GitHub
  • Edit: a possible third. In the day of HPKP, it was recommended to pin a CA cert, not the leaf cert. If TLSA also allows (or recommends) this, do so.

Not to say this wouldn’t be a nice feature to automate into Neth’s hypothetical built-in authoritative DNS server, but I think it can be handled now with less difficulty than what you’re doing.

2 Likes