FluxMesh Phase 7 — HTTP/3, QUIC relay transport, active/active edge and DNSSEC checks
Phase 7 turns the Phase-6 public edge into a standards-oriented production path. It is intentionally additive: FluxMesh still owns host/public-edge connectivity; Network Fabric remains the VM-edge policy engine and Service Fabric remains the node-local VIP/Maglev dataplane.
Real browser HTTP/3
fluxmesh-edge now starts a UDP/QUIC listener (default [::]:443) backed by
h3 + h3-quinn + Quinn. The public certificate and routing/share-link policy
are the same ones used by HTTP/1.1 and HTTP/2. HTTP/2 responses advertise:
Alt-Svc: h3=":443"; ma=86400
so a browser can discover the QUIC path after an ordinary HTTPS connection. HTTP/3 counters are exported through the existing edge telemetry endpoint.
Boundary: browser QUIC is a direct UDP edge path. The blind CGNAT relay continues to accept visitor TCP/TLS on its public listener. We do not translate browser HTTP/3 into TCP or claim HTTP/3-through-CGNAT.
QUIC-first edge → relay tunnel
The edge's outbound relay channel can use QUIC with ALPN
fluxmesh-relay/1. transport=auto tries QUIC first and falls back to the
Phase-6 TLS/TCP tunnel. transport=quic makes failure explicit; tls-tcp
forces the compatibility path.
Both transports authenticate REGISTER, DATA and heartbeat messages with the existing per-site HMAC secret. Visitor bytes are still the original TLS ciphertext; the relay never receives the application's certificate private key.
Relay server example:
{
"public_listen": "0.0.0.0:443",
"tunnel_listen": "0.0.0.0:7444",
"quic_tunnel_listen": "0.0.0.0:7444",
"tls_cert": "/etc/fluxmesh-relay/server.pem",
"tls_key": "/etc/fluxmesh-relay/server.key",
"routes": [{
"hostname": "*.example.net",
"sites": ["home-a", "home-b"],
"mode": "active-active"
}],
"sites": [
{"id":"home-a","secret_file":"/etc/fluxmesh-relay/home-a.secret"},
{"id":"home-b","secret_file":"/etc/fluxmesh-relay/home-b.secret"}
]
}
Active/active public edge leases
A connected site is eligible only while its authenticated heartbeat lease is fresh. Active/standby chooses the first healthy configured site. Active/active uses rendezvous hashing over the visitor request id, spreading new connections while keeping deterministic selection for a given key.
Session ids make reconnects race-safe: a stale connection cannot refresh or remove a newer site registration.
DNSSEC-aware DNS-01
DNS-01 can optionally verify the expected TXT value through a configured trusted recursive resolver with EDNS0 DO and require the response AD bit before ACME is notified:
fluxctl cloud acme-dns01-cloudflare \
--email ops@example.net \
--domain example.net \
--domain '*.example.net' \
--zone-id "$ZONE" \
--validation-resolver 1.1.1.1:53 \
--require-dnssec-ad
This is deliberately a DNSSEC-aware verifier, not an in-process validating
resolver. When --require-dnssec-ad is used, the configured recursive resolver
is the trust boundary and must perform DNSSEC validation itself.
OTLP/HTTP tracing
fluxctl cloud otlp <endpoint> enables lightweight OTLP/HTTP JSON spans without
pulling the full OpenTelemetry SDK into FluxMesh. Phase 7 emits:
fluxmesh.edge.reconcilefluxmesh.ingress.requestwithhttp.protocol=h2fluxmesh.ingress.requestwithhttp.protocol=h3
The exporter has a bounded timeout and never fails an application request if the collector is unavailable.
Deployment ports
For direct HTTP/3, allow/forward both TCP/443 and UDP/443 to the edge. For a CGNAT-only site, no inbound home port is required; the edge creates its relay connection outbound. On the public relay, expose TCP/443 to visitors and the configured TCP/QUIC tunnel port to edges.