v0.79.0 — the bridge can bootstrap

The bridge could not bootstrap through itself

v0.78.0 gave the bridge a systemd unit so it survives a reboot. That fixed the disappearing bridge and immediately exposed a worse bug underneath it, because a supervised bridge starts in a situation a hand-started one never does.

discoverUpstreams reads the machine's resolv.conf and drops loopback servers. That is correct — right up until the machine's resolver is this bridge. Then the only nameserver on file is the bridge itself, discovery quite rightly refuses to hand it back, and the daemon comes up with nowhere to forward.

What follows is total, and it hides its own cause:

pit.moshcode.sh → NXDOMAIN
api.morgen.so → NXDOMAIN
mail-ads.google.com → NXDOMAIN

Every clearnet name NXDOMAINs. pit.moshcode.sh is a clearnet name, so the bridge never reads the ending list, so it is not authoritative for anything either and Moshpit names fail the same way. The machine has no DNS at all, and it cannot look up the reason, because the lookup goes through the bridge.

dns enable never met this, which is why it went unnoticed for so long: it runs before the routing exists, so discovery still sees the real servers. A unit starting at boot meets it every single time, because the resolved drop-in is a file and is already in place. Observed on a Kubuntu desktop with the bridge up, listening, correctly routed to, and answering NXDOMAIN to the entire internet.

Upstreams are sayable now, not only discoverable

moshcode dns start --port 5354 --upstream 1.1.1.1
moshcode dns start --port 5354 --upstream 1.1.1.1,1.0.0.1
moshcode dns start --port 5354 --upstream 9.9.9.9#5353

Repeatable and comma-separated both work. address#port is the spelling resolv.conf and dnsmasq already use, rather than a third one invented here. Anything that is not an address is reported rather than quietly dropped — discarding it in silence produces precisely the bridge-that-forwards-nowhere the flag exists to prevent. A named upstream overrides discovery outright, on the grounds that someone who says where to forward has usually said it because discovery was wrong.

The half that actually fixes the reboot

dns service is where this matters. It now asks for the upstreams while a working resolver is still there to answer, and writes them into the unit:

ExecStart=/…/node /…/moshcode.mjs dns start --port 5354 --registry https://pit.moshcode.sh --upstream 1.1.1.1,1.0.0.1

At boot the daemon has nothing left to guess. If discovery comes up empty at generation time, the command says so and prints the flag to pass, rather than writing a unit that will come up mute. dns start explains the empty case as well, because "every name NXDOMAIN" looks nothing like "no upstreams" to the person reading it.

If names stop resolving after a reboot, the journal now says which case you are in — a healthy bridge logs forwarding non-Moshpit lookups to … and answering for N endings on the way up:

journalctl --user -u moshcode-dns -n 20