Edge router and DNS controls
Tunnel-based access with internal services kept private, expected-state assertions with a drift check, and a DNS chain with no plaintext fallback.
Evidence tier: Verified | code for the access, assertion and DNS work described below. Proposed for the OpenWrt control plane, which is designed and not cut over. Both are stated separately here on purpose.
This page is a placeholder. The full write-up will cover the trust boundary, the expected-state assertions and the resolver chain. What follows is what can be stated today.
What exists
- Remote access without exposing the network. Tunnel-based access where applications, databases and secrets stay inside the network and only the edge is published.
- Expected-state assertions and a drift check. A file to host to sha256 map, plus assertions, deliberately kept as assertions rather than turned into configuration: the same fact in two files is two ways to be wrong.
- A DNS chain with no plaintext fallback. Forwarder to Unbound DNSSEC validator to encrypted upstream, so a broken validator fails resolution instead of silently degrading to plain DNS.
- Edge hygiene.
sshdhardening drop-ins,fail2banwith an explicit never-ban-the-management-path rule, and the runbook that goes with it.
What Broke / Challenges
A claim that survived because nobody measured it. An earlier version of this write-up described an alerting channel that reached a phone over cellular when the ISP was down. It read well, it was plausible, and it was false. Measured on 2026-10-19: no such configuration exists in the estate, the router repository says in its own words that the work is planned rather than implemented, and the claim’s only origin was third-party research about other people’s hardware. The failure was not the missing feature, it was a description that had drifted ahead of the system and would have been repeated in an interview. It is now named as withdrawn on this page, because deleting it quietly would have removed the evidence of the mistake as well.
A resolver that degrades instead of failing. The DNS chain is forwarder to a DNSSEC validator to an encrypted upstream. The tempting configuration is a plaintext fallback, so that a broken validator still resolves names. That is exactly backwards: it converts a visible failure into silent downgrade, and the estate keeps working with no DNSSEC at all. Removing the fallback means a broken validator stops resolution, which is loud, and being loud is the point.
Access that was private by accident rather than by construction. The first version of the remote access path exposed more than intended, because “internal” was a property of the address range rather than of the configuration. The pivot was to make the edge the only published component and to assert that the internal services are unreachable from outside, instead of assuming it.
What is not claimed
- The OpenWrt control plane is not deployed. The design documents exist; there is no committed UCI/netifd configuration in the tree, and the router repository says, in its own words, that the work is planned rather than implemented.
- No cellular alerting path. An earlier description of this estate claimed an alerting channel that survives an ISP outage. Measured: no such configuration exists. That claim was withdrawn and has not returned.
- No multi-data-centre operations claim. The estate is one site.
- No public repository. The estate repository is private, so there is no source link here. A short design note is the artefact, and the withdrawn claim above is part of it.