UniFi LAN-first fleet DNS repair

Repaired stale UniFi and fleet-host DNS so normal desktop names use native LAN/10-GbE addresses while explicit .ts.dataroo.net names continue to use Tailscale.

Scope

• Control host: rdmbair13m5
• Network appliance: UDM Beast at 192.168.1.1, UniFi Network 10.6.101 / UniFi OS 5.1.31
• Fleet hosts: rdmsm4x, rdmbair13m5, rdmbair15m5, rdmpw3265m, rdmpw3275m, and jdmbair13m5
• DNS policy: host.dataroo.net is LAN-first; host.ts.dataroo.net is the explicit Tailscale route; host.local remains Bonjour/mDNS.

Root cause

• The UDM returned stale 192.168.1.177 answers for rdmbair13m5 and rdmbair13m5.dataroo.net because an offline UniFi client record still owned the old address.
• The live Mac used a fixed private Wi-Fi identity and was active at 192.168.0.131 under a generic client name.
• The UDM intercepted ordinary port-53 DNS, including queries addressed to public resolvers. Cloudflare DNS-over-HTTPS and the Cloudflare API independently showed that no public rdmbair13m5.dataroo.net record existed, so Cloudflare was not the source.
• Every fleet Mac also had a managed /etc/hosts line mapping rdmbair13m5 to the stale address, overriding the corrected resolver until repaired.

Changes

UDM Beast

• rdmbair13m5: normalized the live client alias, fixed its reservation at 192.168.0.131, and enabled local DNS for rdmbair13m5.dataroo.net.
• rdmsm4x: preserved its existing fixed reservation at 192.168.0.29, normalized the alias, and enabled local DNS for rdmsm4x.dataroo.net.
• rdmpw3265m: preserved its existing fixed reservation at 192.168.1.53, normalized the alias, and enabled local DNS for rdmpw3265m.dataroo.net.
• rdmpw3275m: preserved its existing fixed reservation at 192.168.1.65, normalized the alias, and enabled local DNS for rdmpw3275m.dataroo.net.
• No Cloudflare, Tailscale, VLAN, WAN, DHCP-scope, firewall, or security-policy change was made.
• No unicast .local DNS record was added; .local remains mDNS-only.

Fleet hosts

• Updated /etc/hosts on all six Macs, changing only the managed rdmbair13m5 mapping from the stale address to 192.168.0.131.
• Preserved each host's other host-file content; two hosts had distinct pre-change checksums and were patched individually rather than overwritten from a common copy.
• Confirmed that dataroo.net was already present in the macOS resolver search-domain set on all three 10-GbE desktops. No duplicate resolver profile was installed.

Files touched

• /etc/hosts on all six fleet Macs
• /Users/richh/.agent-coordination/checkins/codex-rdmbair13m5-unifi-dns-lan-first-20260829.json
• /Users/richh/Library/Mobile Documents/com~apple~CloudDocs/Codex/projects/AGENTS.md principles/PROJECTS.md
• /Users/richh/dev/LLM/Claude/changelogs/PROJECTS.md.pre-unifi-dns-20260829-0345
• /Users/richh/dev/LLM/Claude/changelogs/rdmbair13m5-changelog-20260829-0342-unifi-dns-lan-first.md

Commands and interfaces used

• Read-only DNS diagnosis with dig, Cloudflare DNS-over-HTTPS, the Cloudflare API, dscacheutil, and scutil --dns
• Read-only fleet interface and route inventory with networksetup, ipconfig, ifconfig, and route
• Supported authenticated UniFi Site Manager / Network client settings in the existing Chrome session
• Per-host validated /etc/hosts mechanical rewrite with sudo -n cp -p, install, exact-match guards, and SHA-256 verification
• dscacheutil -flushcache after the host-file repair
• Fleet coordination sync with /Users/richh/dev/fleet/maintenance/scripts/fleet_checkin_sync.zsh
• Exact mechanical update of the canonical PROJECTS.md milestones and verified UniFi version fields, after taking the documented backup

Verification evidence

• Three consecutive direct UDM queries returned:
  • rdmbair13m5 and rdmbair13m5.dataroo.net → 192.168.0.131
  • rdmbair13m5.ts.dataroo.net → 100.75.186.59
• Final UDM answers:
  • rdmsm4x.dataroo.net → 192.168.0.29
  • rdmpw3265m.dataroo.net → 192.168.1.53
  • rdmpw3275m.dataroo.net → 192.168.1.65
  • Their existing .ts.dataroo.net records remained at their prior 100.x addresses.
• host.local resolved through mDNS for the repaired Mac and all three desktops; no unicast .local zone was created.
• All six Macs returned rdmbair13m5 → 192.168.0.131 after the host-file update and cache flush.
• The three desktops reported active 10Gbase-T Ethernet links:
  • rdmsm4x en0 → 192.168.0.29
  • rdmpw3265m en0 → 192.168.1.53
  • rdmpw3275m en0 → 192.168.1.65
• Every cross-desktop host.dataroo.net route selected en0; self-routes selected lo0.
• SSH effective hostnames did not force .ts.dataroo.net; the one local rdmsm4x.local alias also remains LAN/mDNS.

Backups and rollback

• Pre-change backup on every fleet Mac: /etc/hosts.pre-unifi-dns-20260829-034127
• Pre-change project-index backup: /Users/richh/dev/LLM/Claude/changelogs/PROJECTS.md.pre-unifi-dns-20260829-0345
• To undo the host-file change on a host, compare the backup and current file, then restore that host's backup with owner root, group wheel, and mode 0644.
• To undo the UDM changes, use the same client Settings panel:
  • disable Local DNS Record on the four documented clients;
  • restore the three desktop aliases to their prior host wired labels if desired;
  • for rdmbair13m5, disable the new fixed-IP reservation and restore the generic alias if returning to dynamic/private-address behavior is desired.
• Do not alter the existing .ts.dataroo.net Cloudflare records as part of this rollback; they were not changed.

Outstanding owner action

• Rotate the UDM root password because its value was pasted into the chat. The value was not used, copied, logged, saved, or included in this changelog.