DNS kicking my ass (Technitium and opnsense)
from roundup5381@sh.itjust.works to selfhosted@lemmy.world on 12 Jan 17:41
https://sh.itjust.works/post/53293260

edit: spent all day tryimg to make this work, in the end i got rid of the opnsense services, unbound and dnsmasq, and brought dhcp over to tDNS

I have been trying to set up Technitium DNS server (TDNS hereafter) for its clustering and fail over capabilities, it really does seem to be a one stop shop for DNS capabilities. But I have been hitting a wall so I’m asking if anyone here can see the flaw in my plan.

I have not been using TDNS for DHCP as it lacks ipv6 and router advertisements right now. And I like the idea of DHCP on the firewall router.

I have an opnsense firewall with DNSmasq performing DHCP and DNS forwarding to the Technitium server, which is hosted on proxmox in an lxc. I own my own public domain, example.com for our purposes here.

TDNS is set to “allow recursion only for private networks” this means that if something external tried to resolve using my TDNS they’ll be refused, correct? I ask because that could as be interpreted as not forwarding to external dns when needed.

I set NAT rules to force TDNS port 53 routing. TDNS is set to forward to quad9 and cloud flare externally. DNS blocking lists are set in TDNS.

I don’t really know what I’m doing with zones but I have a primary zone set with example.com. I set some static hosts records in this zone and enabled reverse lookup, expecting servicehost.example.com

query logs app enabled in TDNS.

Edit: 10.2.0.1 turned out to be my vpn’s dns server (When nslookup google.com from a laptop on this LAN, it returns Server: 10.2.0.1 Address: 10.2.0.1#53

nonauthoritative answer: google.com with ip information repeated.

I don’t under stand this return as it’s an ip outside my lan net and dhcp provisioning.)

Unable to reach external net when NAT rules active.

It seems the DHCP is handing out the fire wall’s ip for DNS server, 100.100.100.1 is that the expected behavior since DNSmasq should be forwarding to TDNS 100.100.100.333. Why not just hand out the TDNS address?

Do I have some setting misconfigured in either DNSmasq/opnsense or TDNS?

#selfhosted

threaded - newest

Zwuzelmaus@feddit.org on 12 Jan 18:24 next collapse

How many domains do you own when you try to set up so many DNS servers?

roundup5381@sh.itjust.works on 12 Jan 19:37 next collapse

Just one domain, I only have dnsmasq forwarding to tdns for recursive resolving, tdns forwards to quad and cloudflare for resolving what isn’t in my local cache. I’m not sure I am understanding your question.

kumi@feddit.online on 12 Jan 19:48 collapse

The OP is about hosting forwarding or recursive DNS for lookups, not authoritatative DNS hosting (which would be yet at least one separate server).

I count two servers (one clusterable for HA). How is that a lot for a small LAN?

More would also be normal for serving one domain internally and publicly. Each of these can be separate:

  • Internal authoriative for internal domain
  • Internal resolvers for internal machines
  • Internal source-of-truth for serving your zone publicly (may or may not be an actual DNS server)
  • Public-facing authoritative for your zone serving the above
  • Secondary for the above
  • Recursing resolver of external domains for internal use

Some people then add another forwarding resolver like dnsmasq on each server.

anamethatisnt@sopuli.xyz on 12 Jan 18:02 next collapse

When nslookup google.com from a laptop on this LAN, it returns Server: 10.2.0.1 Address: 10.2.0.1#53

nonauthoritative answer: google.com with ip information repeated.

I don’t under stand this return as it’s an ip outside my lan net and dhcp provisioning.

I’m unclear on what you’re confused about regarding the above quote. Here comes an explanation of nslookup.
The command is nslookup <domain> <dns-server> and if dns-server is empty it uses your default. F.e.:

***@fedoragaming:~$ nslookup www.google.com 8.8.8.8

The response starts by telling you which <dns-server> it used for the lookup and which address including port was used:

Server: 8.8.8.8
Address: 8.8.8.8#53

It then gives you the answer on where to find the <domain>, once for ipv4 and once for ipv6:

Non-authoritative answer:
Name: www.google.com
Address: 142.251.142.228
Name: www.google.com
Address: 2a00:1450:400f:807::2004

edit: I think I understand your question a bit better now. To check which dns-server you’re using do a “cat /etc/resolve.conf”
If you run a distro with systemd then use the command “resolvectl status”

roundup5381@sh.itjust.works on 12 Jan 19:36 collapse

Thanks for taking the time to comment.

My confusing was that <dns-server> used for the look up wasnt in my net nor upstream dns.

I turned off my vpn and it resolved as expected, so I suppose that 10.2.0.1 is the dns server for my vpn provider.

kumi@feddit.online on 12 Jan 19:45 next collapse

It seems the DHCP is handing out the fire wall’s ip for DNS server, 100.100.100.1 is that the expected behavior since DNSmasq should be forwarding to TDNS 100.100.100.333. Why not just hand out the TDNS address?

You could and that should work but then it’s not called forwarding anymore. It does forwarding because that’s what you configured. Both approaches are valid.

I have an opnsense firewall with DNSmasq performing DHCP and DNS forwarding to the Technitium server

roundup5381@sh.itjust.works on 12 Jan 19:48 collapse

Thanks, that helps to clarify my understanding

Decronym@lemmy.decronym.xyz on 12 Jan 19:55 next collapse

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

Fewer Letters More Letters
DHCP Dynamic Host Configuration Protocol, automates assignment of IPs when connecting to a network
DNS Domain Name Service/System
HA Home Assistant automation software
~ High Availability
HTTP Hypertext Transfer Protocol, the Web
HTTPS HTTP over SSL
IP Internet Protocol
NAT Network Address Translation
SSL Secure Sockets Layer, for transparent encryption
TLS Transport Layer Security, supersedes SSL
VPN Virtual Private Network

9 acronyms in this thread; the most compressed thread commented on today has 9 acronyms.

[Thread #998 for this comm, first seen 12th Jan 2026, 19:55] [FAQ] [Full list] [Contact] [Source code]

stratself@lemdro.id on 14 Jan 11:08 collapse

Have you solved your problem? It seems like there are some issues with your setup:

TDNS is set to “allow recursion only for private networks” this means that if something external tried to resolve using my TDNS they’ll be refused, correct?

Correct. It only accept recursion queries from private networks and can make outbound requests to the internet as normal

10.2.0.1 turned out to be my vpn’s dns server

On the computer, you’re also using your VPN’s DNS service accessible within the VPN tunnel (hence the weird IP address). If you wanna use Technitium you should disable such service

I set NAT rules to force TDNS port 53 routing. TDNS is set to forward to quad9 and cloud flare externally. DNS blocking lists are set in TDNS.

Unable to reach external net when NAT rules active.

If you’re forcing every device to talk to TDNS, then your TDNS server is also talking to itself and cannot make queries to Cloudflare/Quad9 on port 53. You can either:

  • Create an exception rule to allow your TDNS address to talk to Cloudflare/Quad9, or
  • Use DNS-over-HTTPS/DNS-over-TLS as your TDNS forwarder protocols as they aren’t affected by rules on port 53 (recommended for encryption)

It seems the DHCP is handing out the fire wall’s ip for DNS server, 100.100.100.1 is that the expected behavior since DNSmasq should be forwarding to TDNS 100.100.100.333.

Yes it’s expected, if you’re telling your clients to forward their queries to dnsmasq, and then let dnsmasq forward those queries to Technitium. If you want clients to talk directly to TDNS instead, set the DHCP option to advertise its address and don’t use your firewall’s address as a forwarder. I prefer the second option as it’ll give you correct client IPs in query logs and save some round trips.

I don’t really know what I’m doing with zones but I have a primary zone set with example.com. I set some static hosts records in this zone and enabled reverse lookup, expecting servicehost.example.com

If you can query the zone and its reverse PTR record in Technitium’s DNS client, then you’ve properly set it up. Remember you’ll have to tick the PTR options when setting up said record. Also you can open an issue on Technitium’s Github or their subreddit for assistance.

roundup5381@sh.itjust.works on 19 Jan 00:49 collapse

thanks for taking the time to comment here, think I’ve gotten it mostly straightened out now!

one last thing I’m curious about, Id like to continue using a VPN for privacy concerns, would directing all my traffic through a vpn be the only way to benefit from VPN service while also benefiting from DoT and DNS self hosting.

stratself@lemdro.id on 19 Jan 06:02 collapse

Glad to know you got it working.

When you use a VPN as a matter of privacy, I believe you should use their DNS service too to blend in with the crowd. Because of DNS leaks, websites would likely know which DNS server you’re querying from, so using a selfhosted one instead of a VPN’s can be a major uniqueness vector. On the contrary however, I’ve seen many do exactly that, so I guess it’s not as big of an issue. So it’s your choice ultimately.

Now, if you opt for commercial VPN’s DNS servers, be aware that don’t usually block any ads (if they do it’s likely a paid option), and you’d want to configure your own local zones too. To intercept DNS queries and forward only the approved ones to the VPN, I think you have 2 options:

  • Host Technitium on the VPN’d machine (your computer) and set up blocklists there. Create Conditional Forwarding zones: 1 towards the main TDNS server for your local domains, and the rest towards the 10.2.0.1 server for your public queries. Technitium may be overkill, AdGuard Home can also do this.
  • Configure your main TDNS server to forward queries via the VPN tunnel. This requires the VPN tunnel having an available SOCKS5/HTTP proxy, to be used with TDNS’ Proxy and Forwarders options. Even better, you may use the Advanced Forwarding app to only use this routing for the VPN’d device, and use another routing for other devices
roundup5381@sh.itjust.works on 19 Jan 16:10 collapse

great answer, thanks for sharing the knowledge and taking the time to comment