The first fix widened matchDomains but only where the netmap refine runs — first
connect. Every connect after that takes the fast path, which applies settings before
any netmap exists and then deliberately does not touch the live tunnel again.
So its match domains could only come from the file the previous refine wrote. Fine
for the suffix, which never changes; wrong for extra_records and split-DNS domains,
because on the first connect there is no file yet — the tunnel comes up resolving
tailnet names only and stays that way, since nothing re-applies on any later connect.
That is the shape of what Andre still saw after reinstalling and reconnecting:
officer.pertento.ai going to public DNS and failing TLS against 100.64.0.4, on a
device that had connected more than once.
The fast path now watches for the overrides and re-applies once if they differ from
what it used. Bounded like the existing refine, silent when they match, and
re-applying on a live tunnel is not novel — the exit-node and accept-routes paths
have always done it.
Still unconfirmed on hardware: this is the most likely cause found by reading, not a
diagnosis from device logs. The tunnel now says which domains it claimed, so the next
attempt can be settled rather than reasoned about.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhasandClaude Opus 5
2e8bd497df