26.1 seems break Tailscale MagicDNS

[tony_vFG]

I recently updated to 26.1 from 25.7.11_9. After upgrading OPNsense, Tailscale's MagicDNS no longer works.

The DNS server 100.100.100.100 can no longer resolve Tailscale's specific domain name like example.ts.net to Tailscale's 100.x.y.z IP addresses. This previously worked on the 25.7 series.

This is how I set up my Tailscale in 25.7:

1. First, install the official Tailscale plugin, enable Accept DNS and Advertise Exit Node only.
2. In the firewall's NAT outbound NAT settings, I set it to hybrid outbound NAT and added a manual rule that allows Tailscale to go through (following this thread).
3. After that, set up a split DNS that maps the resolver for Tailscale-specific domain to 100.100.100.100.

For me, I have the DNS servers running in Pi-hole and AdGuard Home as a Docker container on another host or under my network.

For Pi-hole, go to Setting > DNS. Under Conditional Forwarding, add an entry that forwards all Tailscale requests like this:

Code Select Expand

true,100.64.0.0/10,100.100.100.100,tail12345.ts.netThis is pretty much the same for AdGuard Home, which adds an entry to the upstream DNS Servers:

Code Select Expand

[/tail12345.ts.net/]100.100.100.100
And the results are as followed:

OPNsense	Ping 100.x.y.z (including 100.100.100.100)	Ping Tailscale FQDN	SSH remote hosts using 100.x.y.z	SSH Tailscale FQDN	nslookup/dig/drill Tailscale FQDN
25.7.11_9	✔️	✔️	✔️	✔️	✔️
26.1.3	✔️	❌	✔️	❌	❌

This is what's shown when running drill in OPNsense.

26.1.3 (os-tailscale 1.4, tailscale 1.94.1_1):

Code Select Expand

# drill @100.100.100.100 opnsense.example.ts.net
;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 34065
;; flags: qr aa rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; opnsense.example.ts.net.   IN      A

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 100.100.100.100
;; WHEN: Tue Mar 10 12:59:53 2026
;; MSG SIZE  rcvd: 43
Going back to snapshot 25.7.11_9 (os-tailscale 1.3, tailscale 1.92.2):

Code Select Expand

# drill @100.100.100.100 opnsense.example.ts.net
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 37476
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; opnsense.example.ts.net.   IN      A

;; ANSWER SECTION:
opnsense.example.ts.net.      600     IN      A       100.78.7.40

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 100.100.100.100
;; WHEN: Tue Mar 10 13:02:56 2026
;; MSG SIZE  rcvd: 84
nslookup/dig on hosts that do not run Tailscale give the same result: SERVFAIL under 26.1.3, and NOERROR under 25.7.11_9.

In the upgrade process of 26.1, nothing really changed except the OS and Tailscale. I didn't migrate the firewall rules to use the new firewall rules, as I expect the old rules should still be working under 26.1.

Googling yields no possible solution except for one Reddit user who faced the same situation as me.

Luckily, my OPNsense is running on a virtualised system, and I did take a snapshot before upgrading. I can verify that after going back to the 25.7 snapshot, the whole network can still visit remote hosts through Tailscale FQDN without any issue.

This thread is placed under the 26.1 Series sub-forum instead of the VPN sub-forum since it is only occurred due to OS upgrade rather than a VPN usage problem.

[abayliss]

I'm interested to know if you find a solution to this. I've upgraded to 26.1 today and am in a similar boat. I have dnsmasq on Opnsense forwarding queries for ts.net to 100.100.100.100, and since the upgrade all queries that should be forwarded as such return a SERVFAIL. On top of this if I query 100.100.100.100 directly from within my LAN I get the same result. Hosts elsewhere on the tailnet can resolve ts.net domains fine.

EDIT: So, I've been fiddling with this and tried turning off "Accept DNS" in the tailscale settings. This seemed to make MagicDNS work again, and would break it again if I turned the option back on, but after toggling it a few times it seems to have settled into working again even with the option turned on again!