dns.toys is an MIT-licensed DNS server, written in Go, that takes creative liberties with the DNS protocol to deliver everyday utilities — weather, world time, unit and currency conversion, IP lookup and more — to anyone with a terminal and a dig command.
What it is
dns.toys is a DNS server that answers ordinary DNS queries with useful data instead of addresses. It lives in the DNS ecosystem and is queried with standard resolver tooling: the README's entire interaction model is dig @dns.toys. The public instance at dns.toys acts as a shared resolver, and the same server can be run privately from the dnstoys Docker image or built from source with make build and ./dnstoys.bin.
The concrete problem it replaces is the small HTTP detour. Checking the time in Mumbai, converting 42 kilometres to miles, looking up the weather in New York, converting 100 USD to INR, spelling a large number, or finding the aerial distance between two coordinate pairs each normally requires a website, an app, or a bespoke API client. dns.toys answers all of them through the resolver that is already installed on the machine, using only the dig command that already exists. The project has 2,828 stars and 186 forks, with 10 open issues and its most recent push in February 2026.
Key capabilities
- Responds to plain
dig queries against a public resolver; dig help @dns.toys lists the available utilities.
- World time and time-zone conversion:
dig mumbai.time @dns.toys for a city's local time, and dig 2023-05-28T14:00-bengaluru-berlin/de.time @dns.toys to convert a timestamp between two cities.
- Weather by city name:
dig newyork.weather @dns.toys.
- Unit and currency conversion through the
.unit and .fx suffixes, for example dig 42km-mi.unit @dns.toys and dig 100USD-INR.fx @dns.toys.
- Numeric, textual and identifier utilities:
dig 987654321.words @dns.toys, dig 100dec-hex.base @dns.toys, dig pi @dns.toys, dig 5.16.nanoid @dns.toys, dig fun.dict @dns.toys and dig excuse @dns.toys.
- Geolocation helpers: the caller's own address with
dig ip @dns.toys, and aerial distance between two coordinates with dig A12.9352,77.6245/12.9698,77.7500.aerial @dns.toys.
- Distributed as a Docker image named
dnstoys listening on port 5354 for both TCP and UDP, configured through config.toml derived from config.sample.toml.
Who uses it and how
- Terminal-first developers and operators who want weather, time, conversions or small lookups without leaving the shell or adding another client.
- Anyone whose existing tooling already speaks DNS, since a query reaches the server through the same resolver path used for ordinary lookups.
- Self-hosters running the
dnstoys container with --restart unless-stopped, publishing 5354/tcp and 5354/udp on a private network.
- Operators building from source, who must also supply the supporting datasets the build expects:
cities15000.txt, the WordNet database and the IFSC data, with instructions in config.sample.toml.
- .NET developers who prefer a typed interface, using the third-party DnsToys.NET client library for the service.
Getting started
The quickest route is docker compose up, or docker run with the dnstoys image and ports 5354/tcp and 5354/udp published. Building from source requires copying config.sample.toml to config.toml, adding cities15000.txt, the extracted WordNet directory and the IFSC data, then running make build and ./dnstoys.bin.
How it compares
No paid or self-hosted alternatives are named in the facts for this entry, so no licence, hosting or cost comparison can be drawn. The only related project listed is DnsToys.NET, a third-party .NET client library that consumes the service rather than competing with it. Within this registry, dns.toys stands alone.
When to use it — and when not to
Use it when the goal is a quick answer from a shell and DNS is an acceptable transport; the hosted instance at dns.toys removes all operational work. A self-hoster, however, must run a DNS service on both TCP and UDP port 5354, maintain config.toml, and — for a source build — source and refresh cities15000.txt, WordNet and the IFSC dataset, which is a heavier footprint than the sample commands suggest. It is a poor fit for anyone who needs a documented HTTP or JSON API, formal uptime guarantees, or a comprehensive reference: the README is a command list that defers documentation to the external site, and the Docker example shown there is abbreviated rather than copy-paste complete.
