vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(network): fix stale forge/matrix zone claim in resolver behaviour

Browse source 
Verified against nix/host-modules/hive-gateway/dnsmasq.nix + gateway.localNames
contributors (hive-forge, hive-matrix, swarm-authelia): forge and the matrix
gateway vhost are swarm-domain names (forge.<swarm-domain>, chat.<swarm-domain>),
not sub-domains of the hive's own domain as the doc previously claimed.
This commit is contained in:
iris 2026-08-15 12:24:25 +02:00 • committed by mara
commit f41acfcc6e
1 changed files with 13 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

21
docs/network.md
View file

@ -112,14 +112,19 @@ schemes pick their own.
## Resolver behaviour ## Resolver behaviour
dnsmasq is **authoritative** for the hive's own zones — answers dnsmasq is **authoritative** for the hive's own zone (`<hive-domain>`)
`<hive-domain>`, `forge.<hive-domain>`, `matrix.<hive-domain>` and — plus whatever swarm-service names this host contributes via
on the host running it — the swarm's `auth.<swarm-domain>` `gateway.localNames` — `forge.<swarm-domain>` and `chat.<swarm-domain>`
queries with the bridge IP (where nginx is reachable). Everything (matrix) when this host runs those services, and `auth.<swarm-domain>`
else is forwarded to the host's own resolvers: dnsmasq runs on the host when it runs authelia — answering each with the bridge IP (where nginx
and reads the host's `/etc/resolv.conf` directly. Containers don't need is reachable). Note forge and matrix are swarm-domain names, not
to know the upstream — they query the bridge IP and dnsmasq does the sub-domains of `<hive-domain>`: a swarm runs one forge and one
right thing per-name. homeserver, so their names belong to the swarm rather than to whichever
hive happens to host them. Everything else is forwarded to the host's
own resolvers: dnsmasq runs on the host and reads the host's
`/etc/resolv.conf` directly. Containers don't need to know the
upstream — they query the bridge IP and dnsmasq does the right thing
per-name.
There is deliberately no fallback `server=`: dnsmasq queries all known There is deliberately no fallback `server=`: dnsmasq queries all known
upstreams in parallel, so a hardcoded public resolver would take a share upstreams in parallel, so a hardcoded public resolver would take a share