The Thunderbolt That Killed DNS

Date: 2026-01-22 Duration: 3 hours Issue: DNS and SSH broken after plugging in Thunderbolt adapter Root Causes: Three. Yes, three separate problems. Casualty Count: DNS, SSH, my confidence in Thunderbolt networking

The Innocent Beginning

The Meridian-Mako-Silo NAS (Unraid) needed faster transfers to the Caph-Silo (Synology). Both have 10GbE ports. I had an OWC Thunderbolt dock with 10GbE sitting around.

Plugged it in. Unraid saw the interface. Cool.

Unplugged it. That's when things went sideways.

The Symptoms

After unplugging the Thunderbolt adapter and rebooting:

ping 1.1.1.1
# Works fine

ping google.com
# ping: unknown host google.com

DNS resolution: dead. But raw IP connectivity was fine.

SSH from my workstation: connection refused. Couldn't get in except via safe mode. The Unraid web UI worked locally, but DNS and SSH were toast.

Root Cause #1: The Boot Script

Unraid runs /boot/config/go on every boot. Someone (me, probably at 2 AM six months ago) had broken it.

if [ something ]; then
  # stuff
if [ something_else ]  # Missing 'then'
  # more stuff
fi
fi  # Extra fi with no matching if

Missing then after an if. Extra fi floating around. The script crashed partway through boot, leaving services half-started.

When a boot script has syntax errors, services fail silently. You don't get "syntax error on line 47" — you get "why doesn't DNS work?"

Fix: Corrected the syntax. Saved a backup first:

cp /boot/config/go /boot/config/go.backup.20260122_203912

Root Cause #2: Docker Zombie Interface

In /boot/config/docker.cfg:

DOCKER_CUSTOM_NETWORKS="wlan0 "

Docker was configured to use wlan0. A WiFi interface. That didn't exist. That had never existed on this server. The trailing space after wlan0 was a particularly nice touch.

The Thunderbolt adapter created some kind of network state weirdness, and Docker tried to bind to a ghost interface. Docker refused to start, dragging dependent services down with it.

Fix:

DOCKER_CUSTOM_NETWORKS=""

Revolutionary, I know.

Root Cause #3: Tailscale Route Hijacking

This was the subtle one.

Tarn-Host (Proxmox at 192.168.20.100) advertises the 192.168.20.0/24 subnet via Tailscale. When Tailscale started on Meridian-Mako-Silo, it accepted this route. Which meant:

Incoming SSH connections arrive via the local bridge (br0)
The server looks up how to send the reply
Tailscale says "I know that subnet! Route through me!"
Reply goes out via tailscale0 instead of br0
TCP handshake fails because of asymmetric routing

This is called asymmetric routing, and it's the networking equivalent of answering a phone call by yelling out the window.

Fix: Priority routing rule:

ip rule add to 192.168.20.0/24 lookup main priority 5200

This tells the kernel: "For traffic destined to the local subnet, always use the main routing table. Don't let Tailscale's routing table steal it."

Added it to the Tailscale startup script so it persists across reboots.

What is CorpDNS, Anyway?

During debugging, I encountered Tailscale's "CorpDNS" setting. In case you're wondering (I was):

CorpDNS ENABLED (true):

Tailscale overrides /etc/resolv.conf
DNS queries go through Tailscale's servers (100.100.100.100)
You get magic hostnames like Meridian-Mako-Silo.tail-net-name.ts.net
Less predictable, more magic

CorpDNS DISABLED (false) — my setting:

Tailscale doesn't touch DNS
System uses configured DNS (8.8.4.4 in my case)
Must use IP addresses or configure DNS separately
More predictable, less magic

For a NAS that needs reliable, boring networking? I'll take "more predictable" every time.

The Network Topology (For Future Reference)

Internet
    |
Router (192.168.20.1)
    |
    +-- Meridian-Mako-Silo (192.168.20.50) - Unraid server
    |       - eth0 -> bond0 -> br0
    |       - Tailscale: 100.64.0.30
    |
    +-- Tarn-Host (192.168.20.100) - Subnet router
    |       - Advertises 192.168.20.0/24 via Tailscale
    |
    +-- Caph-Silo (192.168.20.7) - Synology NAS

Verification

After all three fixes:

# Check routing uses local interface
ip route get 192.168.20.7
# 192.168.20.7 via 192.168.20.1 dev br0

# Check DNS
nslookup google.com
# Works

# Check the routing rule exists
ip rule | grep 5200
# 5200: from all to 192.168.20.0/24 lookup main

Rebooted into normal mode. Everything came up. DNS works. SSH works. No more Thunderbolt adapter.

Recovery Options (If This Happens Again)

Boot into safe mode (plugins/Docker disabled)
Tailscale SSH still works: tailscale ssh root@Meridian-Mako-Silo

Restore backups:

cp /boot/config/go.backup.20260122_203912 /boot/config/go
cp /boot/config/docker.cfg.backup /boot/config/docker.cfg

Files Modified

File	Change
`/boot/config/go`	Fixed if/then/fi syntax errors
`/boot/config/docker.cfg`	Removed nonexistent wlan0 from custom networks
`/boot/config/start-tailscale.sh`	Added local subnet routing priority

The Moral

One hardware change. Three bugs exposed.

The boot script was always broken. It just happened to fail after the commands I needed.

The Docker config was always wrong. It referenced a nonexistent interface that Docker ignored until now.

The Tailscale routing was always asymmetric. It only mattered when local SSH crossed paths with the subnet advertisement.

Plugging in that Thunderbolt adapter didn't cause these problems. It revealed them.

Better alternatives for 10GbE on Unraid:

USB 3.0 to 2.5GbE adapter (~$16, RTL8156 chipset, plug and play)
USB-C to 5GbE adapter (~$25, RTL8156B chipset)
Literally anything that isn't Thunderbolt

Three separate issues from one Thunderbolt adapter. Sometimes the speed upgrade isn't worth it. Sometimes you just use the slow, reliable 1GbE connection and get on with your life.

The Thunderbolt That Killed DNS (and SSH, and My Confidence)