Most nameservers assume you already know DNS. You edit a zonefile, remember to bump the serial, reload, and let a resolver tell you whether you got it right. That has worked since the eighties and it still works. It is also why a lot of small networks have no DNS worth the name: the cost of the first zone is a weekend of reading, so people put up with IP addresses in bookmarks instead.

Wegweiser is one static binary. Start it, open the interface, and have a zone answering queries before you have learned zonefile syntax. The name is German for signpost.

Reverse zones look after themselves. An address record produces the PTR that belongs with it, in whichever reverse zone is responsible, IPv6 nibble zones and RFC 2317 delegation included. Delete one and the other goes. Where two records disagree you are told, rather than one of them quietly winning.

History is the mechanism, not a feature bolted on. Every change is an event in a journal. Zone history, a diff of any edit, the audit trail, incremental transfer to a secondary and rollback to an earlier state are one thing read five ways.

A cluster needs nothing beside it. Three or five servers vote, and any more join to answer. They keep the same zones in step through that one journal, replicated, with no Postgres, no etcd and no primary and secondary wired up by hand. A change sent to any of them reaches the one that leads. Losing the majority stops changes and never answers: every server goes on answering from what it holds. Two servers that want a third vote run a witness, which keeps the log and answers nothing.

One API, and every client is a client of it. The web interface and the weg command line reach the server the same way your own scripts would. Neither has a private path to the database, which is what keeps a feature from existing in one of them and not the other.

Both interfaces are designed. The web side is dense and keyboard-driven, with a command palette and a live view of queries as they arrive. The command line is meant to feel like gh or lazygit rather than named-checkconf: predictable verbs, JSON and YAML from every command, colour that disappears on its own when nothing is watching, and errors that say what to do next.

It does not resolve. No recursion, no forwarding, no cache of anything it is not authoritative for. That one is settled rather than pending, and there is no seam kept open for it. A name outside its own zones is answered with REFUSED.

A network that wants both its internal names and the rest of the internet runs a resolver in front, hands that out over DHCP, and points a stub zone at Wegweiser. Both fit on one machine, on different ports.

The documentation and the server's README are where the current state lives: what is built, what is not, and what the release you are looking at actually covers. This page describes the project, not its progress.

Parts of Wegweiser are written with an AI assistant, and I would rather say so than let you work it out. The direction is mine, every design call is recorded and argued in the repository, and the test suite is what keeps the rest honest: race detector, fuzzing on the wire parser, a browser suite over the interface, and a linter that enforces the architecture mechanically. All of it runs on every push, and it is the same gate the code I typed myself has to pass. The long version is in the repository README.

GNU Affero General Public License v3.0 or any later version (AGPL-3.0-or-later), for all the code here. Chosen deliberately for something that faces a network: if you run a modified Wegweiser as a service, the people using it are entitled to the source. "Or later" because contributions come under the DCO with no copyright assignment, so nobody holds the rights to all of the code, and only that form lets it follow its licence forward without asking every contributor one at a time.

The website's code is under the same licence. Its writing and pictures are CC BY-SA 4.0, and the examples in the documentation are CC0, so that a configuration copied from it brings no conditions with it.