# addr.tools: six small DNS services sharing one custom authoritative server

> A Go monorepo holding the source for a family of public DNS utilities, from dynamic DNS with no account to a DNSSEC resolver checker, all served by one custom authoritative nameserver called addrd.

**brianshea2/addr.tools** — possibly useful tools for the Internet

- Repository: https://github.com/brianshea2/addr.tools
- Website: https://addr.tools
- Stars: 2,632 · Forks: 88
- Language: Go
- License: AGPL-3.0
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/brianshea2-addr-tools

## One repository, six public services

The README is short and does one job: it lists what is in here. Six hosted tools appear, each with a one-line description and a URL. `challenges.addr.tools` is a dns-01 ACME challenge helper zone. `dyn.addr.tools` is dynamic DNS for your own domains with no account required. `info.addr.tools` explores identifying information for domain names and IP addresses. `myip.addr.tools` returns your public IP address. `dnscheck.tools` identifies your DNS resolvers, checks DNSSEC validation and performs other DNS tests. `myaddr.tools` is dynamic DNS again, this time handing out a free custom subdomain.

That last detail is the one worth sitting with. Most dynamic DNS providers on the public internet want an account, an API key and a hostname you pick yourself. The pitch here is that you point a record at a name and get told what to set, with the account step removed. Whether that is safe to depend on is a question about the operator rather than the code, but the README states it plainly enough that it is clearly the intended use.

Underneath the six URLs sits a seventh item: `addrd`, described as the custom dns server behind many of the above services. The word many is doing real work. The repository is not six small programs, it is one DNS server implementation with several front doors.

## The tree shows a server, not a script

The repo layout section is the most informative paragraph in the README, because it describes a structure you would expect from software that runs continuously rather than software you invoke. The tree has five top-level entries, and the descriptions are short enough to quote directly.

```
cmd/addrd   - dns server application code
configs     - addrd, nginx, and other sample config files
internal    - dns server library code
scripts   - build and other helper scripts
website   - website content
```

`cmd/addrd` is the application entry point, so everything above it is a library the server links in. `configs` holding addrd, nginx and other sample config files is the clearest signal about deployment: there is a reverse proxy in front of the DNS server, which is what you would expect for a service taking public queries over HTTPS.

The `internal` directory then splits into named concerns, and the names are honest descriptions rather than abstractions. `config` parses the addrd config json and creates and starts the service listeners. `dnsutil` holds the server utilities named in the tree: dnssec, edns0 and a basic handler. `dns2json` is a simple http handler that provides DNS responses in json, which is what a browser-facing tool such as `info.addr.tools` or `myip.addr.tools` needs in order to render a page. `status` is a dns server status handler. `httputil` holds http request utilities. `ttlstore` is a key-value store with value expiration, which is the memory a dynamic DNS service needs to hold a name and value until the TTL runs out. `zones` holds the specific addr.tools service handlers.

## Why the whole thing depends on a fork of miekg/dns

There is exactly one dependency declared in the module file, and it is replaced with a fork. The whole of `go.mod` is short enough to quote.

```toml
module github.com/brianshea2/addr.tools
go 1.27.1
require github.com/miekg/dns v1.1.73
replace github.com/miekg/dns => github.com/brianshea2/go-dns master
```

Two things follow from those four lines. First, addrd is built on `github.com/miekg/dns`, the standard Go DNS library, which handles message parsing, EDNS0 and DNSSEC rather than this project reimplementing any of it. Second, the dependency is not the tagged v1.1.73 release: it resolves to `brianshea2/go-dns` on the `master` branch of a personal fork.

That is a deliberate choice and a real operational consideration. Forking the DNS library is what makes it possible to change resolver or server behaviour that upstream will not take, and for a project running public DNS tooling such as dnscheck.tools, the behaviour you want is often the behaviour you had to patch. The cost is that you are now depending on a branch of somebody's fork rather than on a released version, and the module targets `go 1.27.1`, a toolchain line newer than most of what you have installed.

It also tells you the scale of the codebase. One dependency, one binary, and a handful of internal packages.

## What a zone handler has to do

The `zones` package is where the interesting design question sits, and it is the part the README describes least. Each hosted service is a handler, which means the server is authoritative for several unrelated names at once: a challenge zone under `challenges.addr.tools`, dynamic zones for whatever domains users point at `dyn.addr.tools`, and a separate apex for `dnscheck.tools`.

Serving the challenge zone is the least demanding job. A dns-01 ACME challenge works by publishing a token at a name derived from the domain being validated, and a helper zone that answers authoritatively for that pattern saves the user from touching their own zone files. It is a lookup, and a lookup is what a DNS handler does naturally.

Dynamic DNS is harder, because the server is now the source of truth for records the client claims to own. That is where `ttlstore`, the key-value store with value expiration, fits: the handler has to remember a name and value for no longer than the TTL it hands out, and expire them without anyone asking. Whether a given deployment allows updates from the public internet or restricts them is a configuration question, and `configs` holding sample addrd config files is where you would look for the answer.

`dns2json` closes the loop for the browser-facing tools. A page cannot perform a DNS query, so the handler resolves the query server-side and serializes the answer as JSON for an HTTP client to render.

## AGPL-3.0, no releases, and one push date

The license is AGPL-3.0, which is the single most consequential fact about the repository for anyone considering reuse. AGPL extends the copyleft obligation to network use: running a modified version as a service over a network requires offering that modified source. For the services described here, that obligation is already met in the most literal way possible, since the source is the public repository.

The repository publishes no releases. There are no tagged versions and no release notes, so version tracking means watching commits on the default branch, `main`. The last push recorded is 2026-09-14, and the project is not archived. With 2,586 stars, 87 forks and zero open issues, the shape is a popular project that people use and report through the services themselves rather than through the issue tracker.

`Dockerfile.addrd` in the tree is the deployment path, and its narrow name is telling: there is one container image, for the server, not one per service. `scripts` holds build and other helper scripts, and `website` holds website content, which suggests the documentation for the individual tools lives alongside their code rather than in this README.

## Where the README stops

This is a README that lists rather than explains, and the gap is consistent. It tells you what the services are, gives each a URL, names addrd, and prints a directory tree. It does not document configuration keys, deployment steps, how to run the server locally, or how a new service zone is added.

For a project like this that gap is partly structural rather than an omission. The interesting surface area is per-service, and per-service detail lives in `internal/zones` handlers and `configs` sample files rather than in a top-level document. The tree is genuinely the best available map, which is more than can be said for repositories whose README promises features the code does not carry.

The honest comparison to make is against the obvious alternative. If you want account-free dynamic DNS today, the usual move is a well-known client that talks to a hosted provider's API. Building on this instead means operating an authoritative server, a reverse proxy and a TTL store yourself, and accepting the fork-pinned DNS library as your foundation. That is a reasonable trade for someone who wants their names resolving from infrastructure they control, and a poor one for anyone who just needs a hostname to update from a home network.

What the repository does settle is the architecture: one server, per-service zone handlers, shared DNS utilities, and a JSON bridge for the browser-facing tools. What it does not settle is whether any of it is configured in a way you would want to run.

## Conclusion

addr.tools is not a library you import and not a product you configure. It is the published source for services that already run, and the interesting part is the shared addrd server underneath them: one Go binary with per-service zone handlers under internal/zones and shared plumbing under internal/dnsutil, dns2json and ttlstore. For a reader deciding whether the design holds up, the honest answers are in the tree rather than the README, and the README stops right where the operational detail begins. Start with configs to see how a zone is wired up, then read go.mod, which explains why every one of these services depends on a fork of miekg/dns rather than the upstream release.

## FAQ

### What is addrd in the addr.tools repository?

addrd is the custom DNS server application behind several of the hosted addr.tools services. The repository tree places its code in `cmd/addrd`, with the library split across `internal` packages for config parsing, DNS utilities, a JSON-over-HTTP handler, a status handler, an expiring key-value store and the individual zone handlers.

### Does addr.tools offer dynamic DNS without an account?

Yes. The README describes `dyn.addr.tools` as dynamic DNS for your own domains with no account required, and `myaddr.tools` as dynamic DNS that hands out a free custom subdomain, also with no account. Both run on the shared addrd server.

### What license is addr.tools released under and can I reuse the code?

The repository is licensed under AGPL-3.0. You can read, run and modify the code, but the AGPL copyleft obligation reaches network use, so a modified version offered as a service has to publish its source. The project itself publishes everything openly.

## Sources

- [brianshea2/addr.tools on GitHub](https://github.com/brianshea2/addr.tools)
- [Issues](https://github.com/brianshea2/addr.tools/issues)
- [License: AGPL-3.0](https://github.com/brianshea2/addr.tools/blob/main/LICENSE)
- [Project website](https://addr.tools)
- [README](https://github.com/brianshea2/addr.tools/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/brianshea2-addr-tools