Since I needed it to be my primary DNS, I also added: recursive resolution from root nameservers, DNSSEC chain-of-trust validation, ad blocking (385K+ domains), and LAN service discovery.
Very interesting project! I have a couple of questions. With all the default blocked domains loaded, what is the average memory usage? Currently, I am using Pi-hole on a low memory single board computer. Is it possible to use this instead of Pi-hole? If so, I’d like to use it for all of my devices."
Thanks! If you hit any issues during setup, feel free to open an issue — happy to help debug. The dashboard at localhost:5380 shows what's happening in real time.
Please don't break the site guidelines, regardless of how wrong someone is or you feel they are.
You're right about em dashes of course (https://news.ycombinator.com/item?id=47154752) but being right on a point does not make it ok to attack another user or violate the rules of the site.
I have a couple of projects that once a month need to run a few million dns lookups as quickly as possible. I'm tempted to try this just to see how it performs and if it breaks.
Nice idea. To test I ran a simple nextjs on port 3000. Added the service via the dashboard.
However, when I visit the url, (using chrome latest version), https://{mygivenname}.numa/ I hit a DNS resolution fail error.
If I do not use a trailing '/' then it is going to google search for {mygivenname}.numa and shows me some search results. Should I open an issue?
Is it possible you didn't start it as root ( sudo numa install)?
Does dig {mygivenname}.numa @127.0.0.1 return 127.0.0.1 ?
What OS are you on?
Maybe you report it as an issue?
Thanks for quick response. It started to work. I think it must be some caching issue. But it needs a trailing '/' . Maybe will raise the issue for this. Cool.
I believe that is actually browser specific behavior. I sometimes use a fake TLD for stuff hosted at home, and both chrome and firefox resort to search if I don't include a trailing '/'. My assumption is the browser does a quick match against known TLDs and if it doesn't match then it resorts to search.
The first thing I look at in new DNS code is whether it’s vulnerable to DNS name compression loops. This code passes the test! However it’s vulnerable to dots embedded in labels: it doesn’t escape bytes properly when converting from wire format to text.
It's neither here nor there but can I ask about the name? I only ask because when I see "numa" in relation to computing I immediately think "Non-Uniform Memory Access".
Very cool project by the way. I wonder how this would run on an OpenWRT device.
I see in your install.sh that you support Linux and Darwin/MacOS, do you think there would be any major hurdles in supporting FreeBSD?
The interface looks vibecoded. I have no problem with people vibecoding things. In fact, I have zero frontend skills, so I rely on AI to be able to make easy-to-use interfaces. However, I feel like this should be clearly and prominently displayed in the project page.
Furthermore it is a little off-putting to see a vibecoded UI because I have very little confidence that the rest of the backend code is not vibecoded. I know I am possibly being unfair, but this is how it looks to me. If the developer tells me they didn't use AI at all, I would believe it.
It definitely is and you can see it in the git commits. The DNS wire protocol parser was the original learning project I wrote to understand the spec. Later features (recursive resolver, DNSSEC validation, the dashboard) were built with the help of AI
I dont get this criticism at all, would you prefer someone write a shittier UI? And since when were people writing amazing bug free software before hand where not being vibe coded meant you could trust its good software?
I guess to be fair, beforehand no body would be attempting this kind of thing and releasing it unless they knew what they were doing
Both GP's and your example in effect mean "I'm fine with other people doing this, but I don't want to have anything to do with it, or at least be able to decide case-by-case."
Which is a valid stance IMO.
In the OP, a vibecoded UI when the whole project emphasizes "I did this myself, from scratch" is a bit awkward.
Does "I did this myself" mean they read all the relevant specs and then wrote the code - or did they just write the prompts themselves?
Edit: OP already answered and confirmed that they in fact did write the code themselves.
This was started as a learning project, went from the start to the lowest level then I've just added features I wanted one by one, it just made the most sense
Same hack here ; I have no DSN running by default - much more handy than having to set up nginx as it has no opinion on the targeted infrastructure. And the bonus point is that you can see every sneaky request that happens when you browse ; so another side-project connected to this is to make an inventory and policy filter
Yes sir!
The query log is at GET /querylog (or on the dashboard) shows every request with domain, type, path (forwarded/recursive/cached/blocked) and latency
Thanks! If you hit any issues during setup, feel free to open an issue — happy to help debug. The dashboard at localhost:5380 (or at https://numa.numa)
Numa can do recursive resolution from root nameservers + DNSSEC, .numa local domains with auto HTTPS for dev, and LAN service discovery.
What features would you be interested in?
Split DNS already works — Numa auto-detects Tailscale forwarding rules from the system config. Queries matching .<ts.net> go to Tailscale’s DNS, everything else goes through Numa
If you want to skip Tailscale entirely for home servers, Numa’s LAN discovery auto-finds machines running Numa on the same network. Or add static records in numa.toml for machines that don’t run it.
Actually, if you point a container's DNS at the host (dns: [host.docker.internal] in compose), it works for resolution + ad blocking for the reverse however, I've added it on the radar, thanks!
Yes — numa install generates a local CA and stores it in the system trust store. When you register a .numa service, it generates a per-service TLS cert signed by that CA
I wrote about the DNSSEC implementation here: https://numa.rs/blog/posts/dnssec-from-scratch.html It's now my daily system DNS. Single binary (~8MB), macOS/Linux/Windows.
`sudo numa install`
It binds to 0.0.0.0:53 by default, so just point your devices' DNS to the board's IP
5 minutes ago | parent | next | edit | delete
You're right about em dashes of course (https://news.ycombinator.com/item?id=47154752) but being right on a point does not make it ok to attack another user or violate the rules of the site.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
Very cool project by the way. I wonder how this would run on an OpenWRT device.
I see in your install.sh that you support Linux and Darwin/MacOS, do you think there would be any major hurdles in supporting FreeBSD?
On OpenWRT — it's musl-based Linux so the binary should run the arm one would need a crosscompile Free BSD can be done (pr's welcome?)
Furthermore it is a little off-putting to see a vibecoded UI because I have very little confidence that the rest of the backend code is not vibecoded. I know I am possibly being unfair, but this is how it looks to me. If the developer tells me they didn't use AI at all, I would believe it.
I guess to be fair, beforehand no body would be attempting this kind of thing and releasing it unless they knew what they were doing
"I'm fine with people eating meat, as long as they declare so when we go out" like why? Why does it matter?
Which is a valid stance IMO.
In the OP, a vibecoded UI when the whole project emphasizes "I did this myself, from scratch" is a bit awkward.
Does "I did this myself" mean they read all the relevant specs and then wrote the code - or did they just write the prompts themselves?
Edit: OP already answered and confirmed that they in fact did write the code themselves.
If you want to skip Tailscale entirely for home servers, Numa’s LAN discovery auto-finds machines running Numa on the same network. Or add static records in numa.toml for machines that don’t run it.
There's also a per-domain allowlist and you can pause/unpause blocking from the dashboard or API.
Here's how the resolution pipeline looks like: https://numa.rs/blog/posts/dns-from-scratch.html#the-resolut...
Still, if you're looking for something that "just works" and is widely used, have a look at caddy.