Simplest DNS server

I would like to put a very simple DNS server on TrueNAS Scale 25.04.2.3. I have a list of hostnames I would like to resolve to IP addresses.

In a perfect world, for lookup failures this server would delegate to whatever the local DHCP server recommends, but I could live without that.

I see an app for Pi-Hole is listed in the “stable” category. It seems like overkill but is reputed to have what I want. However, installation failed for me. I’m letting that failure be enough to listen to my instinct not to install overkill.

I see there is another ad-blocker app in a non-stable category which might let me do what I want. I’m letting its category be enough to listen to my instinct not to install overkill.

Anybody care to recommend a simple approach?

1 Like

Pi-hole most likely fails because port 53 is already used by incus. You can run the command below to free port 53 and retry to install pi-hole

sudo incus network set incusbr0 raw.dnsmasq="port=5354"

Edit: the other DNS app will most likely have the same problem as pi-hole as all DNS apps want to use port 53

1 Like

Why does Incus listen on port 53? What’s a KVM/LXC manager got to do with DNS?

1 Like

Reading up on this I found that even the official Incus docs recommend not using port 53, due to possible conflicts with an existing DNS service…

This has been fixed in one of the recent releases. You can launch pi-hole as an app without any problems.

I take it Incus is installed as part of TrueNAS. It also sounds as if TrueNAS or Incus includes an installation of dnsmasq.

I have a feeling the TrueNAS folks would like us to avoid messing with either of those things “behind the back” of TrueNAS.

Meanwhile, I am seeing elsewhere that bringing up a Docker container with dnsmasq is pretty easy, but wouldn’t that also conflict with the above?

I am glad I asked before bulling around in this china shop because the rabbit hole is already deeper than I expected.

incus was supposed to replace the libvirt backend to run vms and lxc container. But iX scapped the idea and incus will be removed (i believe in the next update in october) so if you do not run any incus based vms or lxc it doesnt matter if you mess around with it.

One of the releases more recent than 25.04.2.3? I gather you’re referring to a beta?

It works for me using TrueNAS Fangtooth 25.04.2

Do you have vms and a brige configured? Because as far as i can remember it’s not required if you’re using a bridge…

I have no VMs on this server.

I was trying to install the Pi-Hole app, which I am given to understand is ultimately a Docker container rather than a VM.

And forgive me but I don’t know what “bridge” means in this context.

Is 25.04.2.3 somehow earlier than 25.04.2? I’m not super-familiar with how TrueNAS structures version numbers, but for most systems 25.04.2.3 is later than 25.04.2, yeah?

The good news is that I fresh-installed 25.10.0.1 on unrelated hardware and noticed it could install PiHole. So I upgraded my first server to 25.10.0.1 and tried to install PiHole with hope in my heart! But noooooooo.

[EFAULT] Failed to render compose templates: Traceback (most recent call last): File "/usr/bin/apps_render_app", line 33, in sys.exit(load_entry_point('apps-validation==0.1', 'console_scripts', 'apps_render_app')()) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/catalog_templating/scripts/render_compose.py", line 48, in main render_templates_from_path(args.path, args.values) File "/usr/lib/python3/dist-packages/catalog_templating/scripts/render_compose.py", line 19, in render_templates_from_path rendered_data = render_templates( ^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/catalog_templating/render.py", line 31, in render_templates rendered_templates[i.name] = env.get_template(i.name).render( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1301, in render self.environment.handle_exception() File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 936, in handle_exception raise rewrite_traceback_stack(source=source) File "/mnt/.ix-apps/app_configs/pihole/versions/1.3.25/templates/docker-compose.yaml", line 50, in top-level template code {% do c1.add_port(values.network.dns_port, {"container_port": 53}) %} ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/mnt/.ix-apps/app_configs/pihole/versions/1.3.25/templates/library/base_v2_1_65/container.py", line 290, in add_port self.ports._add_port( File "/mnt/.ix-apps/app_configs/pihole/versions/1.3.25/templates/library/base_v2_1_65/ports.py", line 119, in _add_port self._render_instance.client.validate_ip_port_combo(host_ip, host_port) File "/mnt/.ix-apps/app_configs/pihole/versions/1.3.25/templates/library/base_v2_1_65/client.py", line 68, in validate_ip_port_combo raise RenderError(err_str) from None base_v2_1_65.error.RenderError: [EINVAL] render.pihole.schema: The port is being used by following services: 1) "10.102.141.1:53" used by Virt Service

I sure don’t know who 10.102.141.1 is, but there’s an HTTP server there that wants to redirect to the https port (443). There’s an SSH server there as well.

25.10 still uses incus for lxcs, so you still have to move it off port 53 with the command…

Ah. I had gotten the impression somewhere that Incus was going away in Goldeye.

I have been reluctant to mess with that command because it feels like coloring outside the lines.

I also have to wonder what is different about an upgrade-install vs a clean-install which requires this weird step.

If you don’t use lxcs that command does nothing you have to worry about. And lxcs will likely change with 26.04

I decided to try that command and reboot and now I have a system which…

  • colors outside the recommended configuration lines
  • still fails to install PiHole with the same error

If it wasn’t incus that’s listening on port 53 something else must.
Have you checked?

sudo netstat -tulpn | grep ":53"
# sudo netstat -tulpn | grep ":53"
tcp        0      0 10.102.141.1:5354       0.0.0.0:*               LISTEN      3414/dnsmasq        
tcp6       0      0 fd42:99e8:e2da:3ee:5354 :::*                    LISTEN      3414/dnsmasq        
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           3263/avahi-daemon:  
udp        0      0 10.102.141.1:5354       0.0.0.0:*                           3414/dnsmasq        
udp6       0      0 fd42:99e8:e2da:3ee:5354 :::*                                3414/dnsmasq

I assign individual IP addresses to each App For this reason. Add a bridge to your NAS (see @Stux YouTube video re same) then add additional IP addresses via the network pane.

Then you can assign these individual IP to each app, which is also beneficial re: password managers, and so on. You do that in the App Setup / edit page.

For example, if you have an app that runs on a FQDN, you can even have TrueNAS pull a SSL certificate and install it for you. That makes it far easier to get a UniFi cloud key replacement to run on a SSL Than even a bonafide cloud key 2