When split DNS made a Firebase site appear offline

Start by proving which boundary disagrees

The Firebase-provided hostname returned HTTP 200, so the release itself was available. Independent public resolvers returned Firebase's Hosting address for the custom domain, and a remote fetcher loaded the updated portfolio. The workstation's default resolver returned a private tailnet address instead. That reduced the incident from “Firebase is offline” to “this resolver context selects a different endpoint.”

Public resolver     → Firebase Hosting address
Tailnet resolver    → private VPS address
Firebase hostname   → HTTP 200
Custom domain via public path → HTTP 200
Custom domain via private path → TLS handshake failure

Testing only the public resolver would have missed the user-visible failure. Testing only the local browser would have blamed a healthy deployment.

The TLS error was a routing clue

The private address belonged to a VPS running Caddy for an internal Git hostname. Caddy listened on the tailnet interface and had a valid certificate for that exact Git name, but no virtual host or certificate for the portfolio apex. When the browser sent the portfolio name as SNI, the private listener could not complete a matching handshake.

This was not a certificate-renewal problem and adding the portfolio to Caddy would have created a second delivery path unnecessarily. The portfolio was supposed to remain on Firebase; only the private Git hostname belonged on the VPS.

An Unbound zone type widened one record into every hostname

Tailscale routed queries for the domain to Unbound on the private VPS. The configuration comment said that one private hostname should differ from public DNS, but the implementation used a redirect zone and an apex record:

local-zone: "example.com." redirect
local-data: "example.com. 60 IN A <private-vps-address>"

For a redirect zone, the local answer applies across names beneath that zone. The apex, www, and private Git hostname therefore all received the VPS address. The configuration was syntactically valid and Unbound was healthy; its semantics were simply broader than the comment and intended ownership boundary.

Make the zone transparent and the exception exact

The correction allowed ordinary names to continue through the configured recursive path while retaining one explicit private record:

local-zone: "example.com." transparent
local-data: "git.example.com. 60 IN A <private-vps-address>"

The active file was backed up first. unbound-checkconf passed before the service was reloaded. Direct queries to the private resolver then returned Firebase for the apex and www, while the Git hostname remained on the VPS.

Validation must cover both positive paths

• The normal tailnet resolver returned Firebase for the portfolio domain.
• The homepage, project catalogue, flagship case study, and résumé returned HTTP 200 without resolver overrides.
• The www hostname redirected to the canonical apex and returned the same release.
• The private Git hostname still resolved to the VPS and returned HTTP 200 through its existing certificate.
• Independent public resolution and the Firebase-provided hostname remained unchanged.