Razvan Dimescu 63ac69a222 ci: call homebrew-bump as reusable workflow instead of PAT event propagation (#53)
Reverts PR #44's approach of swapping GITHUB_TOKEN for a PAT on
action-gh-release. That approach worked in principle but failed in
practice during the v0.10.2 cut: HOMEBREW_TAP_GITHUB_TOKEN is a
fine-grained PAT scoped only to razvandimescu/homebrew-tap, so when
action-gh-release tried to create a release on razvandimescu/numa it
got 403 Resource not accessible. v0.10.2 had to be recovered manually
via `gh release create` from a user PAT.

Root cause of the original bug (from #44): GitHub Actions deliberately
does not propagate workflow events triggered by GITHUB_TOKEN, so a
release created by GITHUB_TOKEN silently failed to fire homebrew-bump's
`release: published` trigger.

Fix: sidestep the event-propagation rule entirely by invoking
homebrew-bump.yml directly as a reusable workflow via `workflow_call`.

- release.yml: drop the `token:` override on action-gh-release (reverts
  to GITHUB_TOKEN default, which v0.10.0 and v0.10.1 used successfully)
  and add a new `bump-homebrew` job that `needs: release` and `uses:`
  homebrew-bump.yml with `secrets: inherit`.
- homebrew-bump.yml: add `workflow_call` trigger with a `version` input,
  remove the `release: published` trigger (no longer needed), keep
  `workflow_dispatch` for manual recovery, and collapse the version
  determination step to a single `inputs.version` read.

Each token now does exactly what its scope permits:
- GITHUB_TOKEN creates the release on numa (contents: write, default)
- HOMEBREW_TAP_GITHUB_TOKEN pushes to homebrew-tap (unchanged)

The tap update becomes a child job in the release run, so failures are
visible in one place instead of "why didn't the release event fire?"
mysteries.

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-09 23:33:48 +03:00
2026-04-09 22:59:10 +03:00
2026-04-09 22:59:10 +03:00
2026-04-06 22:28:30 +03:00
2026-04-06 22:28:30 +03:00

Numa

CI crates.io License: MIT

DNS you own. Everywhere you go.numa.rs

A portable DNS resolver in a single binary. Block ads on any network, name your local services (frontend.numa), and override any hostname with auto-revert — all from your laptop, no cloud account or Raspberry Pi required.

Built from scratch in Rust. Zero DNS libraries. RFC 1035 wire protocol parsed by hand. Caching, ad blocking, and local service domains out of the box. Optional recursive resolution from root nameservers with full DNSSEC chain-of-trust validation, plus a DNS-over-TLS listener for encrypted client connections (iOS Private DNS, systemd-resolved, etc.). One ~8MB binary, everything embedded.

Numa dashboard

Quick Start

# macOS
brew install razvandimescu/tap/numa

# Linux
curl -fsSL https://raw.githubusercontent.com/razvandimescu/numa/main/install.sh | sh

# Arch Linux (AUR)
yay -S numa-git

# Windows — download from GitHub Releases
# All platforms
cargo install numa
sudo numa                              # run in foreground (port 53 requires root/admin)

Open the dashboard: http://numa.numa (or http://localhost:5380)

Set as system DNS:

Platform Install Uninstall
macOS sudo numa install sudo numa uninstall
Linux sudo numa install sudo numa uninstall
Windows numa install (admin) + reboot numa uninstall (admin) + reboot

On macOS and Linux, numa runs as a system service (launchd/systemd). On Windows, numa auto-starts on login via registry.

Local Services

Name your dev services instead of remembering port numbers:

curl -X POST localhost:5380/services \
  -d '{"name":"frontend","target_port":5173}'

Now https://frontend.numa works in your browser — green lock, valid cert, WebSocket passthrough for HMR. No mkcert, no nginx, no /etc/hosts.

Add path-based routing (app.numa/api → :5001), share services across machines via LAN discovery, or configure everything in numa.toml.

Ad Blocking & Privacy

385K+ domains blocked via Hagezi Pro. Works on any network — coffee shops, hotels, airports. Travels with your laptop.

Three resolution modes:

  • forward (default) — transparent proxy to your existing system DNS. Everything works as before, just with caching and ad blocking on top. Captive portals, VPNs, corporate DNS — all respected.
  • recursive — resolve directly from root nameservers. No upstream dependency, no single entity sees your full query pattern. Add [dnssec] enabled = true for full chain-of-trust validation.
  • auto — probe root servers on startup, recursive if reachable, encrypted DoH fallback if blocked.

DNSSEC validates the full chain of trust: RRSIG signatures, DNSKEY verification, DS delegation, NSEC/NSEC3 denial proofs. Read how it works →

DNS-over-TLS listener (RFC 7858) — accept encrypted queries on port 853 from strict clients like iOS Private DNS, systemd-resolved, or stubby. Two modes:

  • Self-signed (default) — numa generates a local CA automatically. numa install adds it to the system trust store on macOS, Linux (Debian/Ubuntu, Fedora/RHEL/SUSE, Arch), and Windows. On iOS, install the .mobileconfig from numa setup-phone. Firefox keeps its own NSS store and ignores the system one — trust the CA there manually if you need HTTPS for .numa services in Firefox.
  • Bring-your-own cert — point [dot] cert_path / key_path at a publicly-trusted cert (e.g., Let's Encrypt via DNS-01 challenge on a domain pointing at your numa instance). Clients connect without any trust-store setup — same UX as AdGuard Home or Cloudflare 1.1.1.1.

ALPN "dot" is advertised and enforced in both modes; a handshake with mismatched ALPN is rejected as a cross-protocol confusion defense.

LAN Discovery

Run Numa on multiple machines. They find each other automatically via mDNS:

Machine A (192.168.1.5)              Machine B (192.168.1.20)
┌──────────────────────┐             ┌──────────────────────┐
│ Numa                 │    mDNS     │ Numa                 │
│  - api (port 8000)   │◄───────────►│  - grafana (3000)    │
│  - frontend (5173)   │  discovery  │                      │
└──────────────────────┘             └──────────────────────┘

From Machine B: curl http://api.numa → proxied to Machine A's port 8000. Enable with numa lan on.

Hub mode: run one instance with bind_addr = "0.0.0.0:53" and point other devices' DNS to it — they get ad blocking + .numa resolution without installing anything.

How It Compares

Pi-hole AdGuard Home Unbound Numa
Local service proxy + auto TLS .numa domains, HTTPS, WebSocket
LAN service discovery mDNS, zero config
Developer overrides (REST API) Auto-revert, scriptable
Recursive resolver Yes Yes, with SRTT selection
DNSSEC validation Yes Yes (RSA, ECDSA, Ed25519)
Ad blocking Yes Yes 385K+ domains
Web admin UI Full Full Dashboard
Encrypted upstream (DoH) Needs cloudflared Yes Native
Encrypted clients (DoT listener) Needs stunnel sidecar Yes Yes Native (RFC 7858)
Portable (laptop) No (appliance) No (appliance) Server Single binary, macOS/Linux/Windows
Community maturity 56K stars, 10 years 33K stars 20 years New

Performance

691ns cached round-trip. ~2.0M qps throughput. Zero heap allocations in the hot path. Recursive queries average 237ms after SRTT warmup (12x improvement over round-robin). ECDSA P-256 DNSSEC verification: 174ns. Benchmarks →

Learn More

Roadmap

  • DNS forwarding, caching, ad blocking, developer overrides
  • .numa local domains — auto TLS, path routing, WebSocket proxy
  • LAN service discovery — mDNS, cross-machine DNS + proxy
  • DNS-over-HTTPS — encrypted upstream
  • DNS-over-TLS listener — encrypted client connections (RFC 7858, ALPN strict)
  • Recursive resolution + DNSSEC — chain-of-trust, NSEC/NSEC3
  • SRTT-based nameserver selection
  • pkarr integration — self-sovereign DNS via Mainline DHT
  • Global .numa names — DHT-backed, no registrar

License

MIT

Description
Portable DNS resolver in Rust — .numa local domains, ad blocking, developer overrides
Readme MIT 4.1 MiB
v0.14.2 Latest
2026-04-23 04:57:37 +08:00
Languages
Rust 76%
HTML 12.1%
Shell 11.4%
Python 0.2%
Makefile 0.1%