Project status
Experimental, unaudited, and completely open about it.
Most security projects have a page like this that says 'enterprise-ready'. This one tells you what actually exists, what is missing, and what has been done to find the bugs — so you can make your own decision about where to run it.
Read this before you deploy it anywhere that matters
DNS Daddy is an experimental proof of concept maintained by one person.
It has not had the independent security review, penetration testing or long-term production validation you would expect from an established security product. Assume there are bugs, design mistakes and weaknesses that have not been found yet.
It is a reasonable thing to run in a homelab, a lab network, a test environment or a learning context. It is not something to put in front of a business-critical network today.
Shipped and working
Implemented today and documented in the repository.
- DNS, DoH and DoT serving
- DNS-over-TLS upstream by default
- Threat-feed blocking with categories
- Per-network policy by CIDR or DoH URL
- Instant allow-listing with cache purge
- Query logs with plain-English block reasons
- Dashboard and REST API with OpenAPI 3.1 spec
- Markdown report generation
- Prometheus metrics endpoint
- Custom threat-feed sources
Missing, partial or out of scope
Stated by the project itself, not discovered by a disappointed user.
No DNSSEC validation
Signatures pass through; DNS Daddy does not verify them.
Not recursive
It forwards to an upstream resolver rather than resolving itself.
No clustering or anycast
One server is one server. Plan availability accordingly.
No SSO, RBAC or multi-tenancy
A single admin password plus API tokens is the whole access model.
Safe search not enforced
The API accepts the field, the resolver ignores it. Treat it as unimplemented.
Browser DoH bypasses it
True of any network-level DNS control; mitigations are manual firewall work.
No independent audit
No third-party security assessment or penetration test has been performed.
What runs on every commit
Automated scanning is not the same as an audit, and it never will be. But it is evidence that the code is being examined rather than only written, and every one of these is a real workflow in the repository you can go and read.
CodeQL
GitHub's semantic analysis on the security-extended query set.
gosec
Go-specific static analysis for insecure patterns and unsafe usage.
govulncheck
Checks dependencies and call paths against the Go vulnerability database.
Trivy
Scans the container image and dependency manifests for known CVEs.
Fuzzing
Fuzz targets on domain normalisation and suffix matching — the parsing that attacker-controlled input reaches first.
CycloneDX SBOM
A software bill of materials generated in CI so dependencies are inventoried, not assumed.
A worked example, published in full
A one-off Semgrep run produced findings that were triaged individually and written up in the repository — including a Markdown-injection issue in generated reports that was confirmed and fixed. The triage notes are public because the process is as much the point as the outcome.
Read the triage notes →Why there's no roadmap with dates on it
A roadmap from a single-maintainer project is a list of promises nobody is contractually obliged to keep, and it has a habit of being read as a feature list. This project deliberately doesn't publish one — the README says so directly.
What you get instead is the issue tracker and the commit history: the actual, current, unedited state of what is being worked on. If you want to influence direction, the most effective thing you can do is open an issue explaining the problem you have.
Found a vulnerability?
Please report it through the disclosure process in SECURITY.md rather than exploiting it against live deployments, and only test systems you own or have explicit permission to test. Good-faith reports are genuinely welcome — finding problems is the entire reason this project is public.
Read the disclosure policy →