IdeaWell

Project ideas from Hacker News discussions.

An open DNS recursive service for free security and high privacy

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

Theme 1 – Performance and latency concerns
Users frequently reported that Quad9 (and similar public resolvers) can be slower or produce timeouts compared to other options.
- “I tried Quad9 at our business for a while, about a year. I ended up moving to something else due to latency.” – annoyingnoob
- “When I run a mix of CF and Quad9 resolvers, Quad9 was consistently slower in response times when measured.” – winstonwinston
- “Quad9 DNS sometimes returns a CDN node with obviously slower response and higher delay, so I have rarely used it since then.” – Linserin

Theme 2 – Privacy, security, and trust considerations
Many commenters weighed the privacy benefits of encrypted DNS against the risks of centralised logging or filtering.
- “Sending every single query to a centralized third party is hard to square with 'high privacy'. I prefer to run my own local recursive resolver.” – greyface-
- “Unless there’s a local resolver for every single one of your clients, aren’t the DNS requests sent in plaintext to the upstream of your local resolver?” – ebb_earl_co
- “quad9 is recommended by Privacy Guides” – Cider9986 (highlighting its privacy reputation)
- “by default 9.9.9.9 have 'protection' and for your safety will lie and return NXDOMAIN … for some dangerous domains” – Habgdnv (note of filtering/blocking)

Theme 3 – Trade‑offs between local resolvers and third‑party services
Discussion centred on when it makes sense to run your own resolver versus relying on a public service, touching on caching, TTLs, and operational simplicity.
- “Used to be fine. I stopped doing it when average TTL dropped to 300 seconds and it takes far too long for my local recursor to get the answer >100 ms, when 3rd party resolver delivers in <10 ms.” – winstonwinston
- “I run two local DNSes, one recursive and one forwarding… The forwarding one uses few services, like 1.1.1.1, 8.8.8.8, 9.9.9.9, etc.” – Habgdnv
- “It can, it depends on the systems and user patterns. Example: if an end user is going to the same site over and over, those DNS responses are probably cached locally on the device…” – esseph (explaining why latency may not matter in practice).

🚀 Project Ideas

Generating project ideas…

Adaptive DNS Forwarder (ADF)

Summary

  • A local DNS daemon that dynamically selects the fastest encrypted upstream (DoH/DoT) provider per query based on real‑time latency measurements, while caching results to reduce repeat lookups.
  • Core value: low‑latency, privacy‑preserving DNS without manual provider switching or sacrificing encryption.

Details

Key Value
Target Audience Power users, small businesses, privacy‑conscious individuals running their own network gear
Core Feature Real‑time latency benchmarking of multiple DoH/DoT upstreams (Quad9, Cloudflare, Google, etc.) and automatic routing of each DNS query to the fastest responder
Tech Stack Go (miekg/dns), Prometheus client for metrics, systemd service unit
Difficulty Medium
Monetization Hobby

Notes

  • HN users complained about Quad9 latency and NextDNS degrading (annoyingnoob, jordand); ADF would let them keep encrypted upstream while automatically picking the fastest, addressing winstonwinston’s comment about local resolver slowness due to low TTL.
  • Could spark discussion on latency vs. privacy trade‑offs and serve as a drop‑in replacement for stub resolvers on routers or Raspberry Pi.

DNS Latency Watchdog

Summary

  • A lightweight agent that continuously measures DNS resolution latency for a set of domains across multiple resolvers, aggregates metrics, and alerts when latency spikes or timeouts exceed thresholds.
  • Core value: gives visibility into DNS provider performance, helping users identify problematic services like Quad9 or NextDNS before they impact users.

Details

Key Value
Target Audience Sysadmins, SREs, small‑to‑medium businesses that rely on external DNS resolvers
Core Feature Periodic DNS probes (A/AAAA) via DoH/DoT to configured resolvers, storing latency histograms, exposing Prometheus metrics and optional Slack/email alerts
Tech Stack Python (asyncio) or Go, using dnslib, prometheus_client, YAML config
Difficulty Low
Monetization Hobby

Notes

  • Commenters noted timeouts with Quad9 and NextDNS degradation (annoyingnoob, jordand); this tool would give them concrete data to verify those experiences, supporting esseph’s point about perceivable difference.
  • Easy to integrate into existing monitoring stacks, fostering discussion on DNS SLA and encouraging providers to improve routing.

Prefetching Local Recursive Resolver (PLRR)

Summary

  • A local recursive resolver that prefetches frequently queried domains based on recent DNS history and implements aggressive negative caching to mitigate the impact of low TTL values, while forwarding unresolved queries via encrypted DoH/DoT to a trusted upstream.
  • Core value: reduces perceived DNS latency for repetitive browsing patterns and low‑TTL environments without sacrificing privacy or requiring manual resolver tweaks.

Details

Key Value
Target Audience Home users, small offices, developers running their own recursive resolver on a router or Raspberry Pi
Core Feature History‑driven prefetch cache + negative cache + encrypted forwarding, with optional user‑defined block/allow lists
Tech Stack Rust (trust‑dns) or C (Unbound) with Lua hooks, or Go with miekg/dns; storage via BoltDB or SQLite
Difficulty Medium
Monetization Hobby

Notes

  • winstonwinston complained that local recursive resolver became slow when average TTL dropped to 300 s; PLRR’s prefetching would keep hot entries warm, directly addressing that pain.
  • greyface- and ebb_earl_co discussed privacy of local resolvers; PLRR keeps encryption to upstream while giving local control, appealing to privacy‑focused HN readers.

Read Later