Project status
Experimental, unaudited, and completely open about it.
Where the project actually is: what is finished, what is being researched, what is only planned, 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, AI-assisted open-source project maintained by one person.
It has not had the independent professional 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, a smaller organisation that understands the trade-off, or a learning context. It is not something to put in front of a business-critical network today.
Release status
Releases are tagged pre-releases at this stage of the project. Development continues on the default branch between tags, so the two are not interchangeable.
Latest tagged release
Release details are read live from GitHub and are unavailable right now.
View releases on GitHub →A tagged release is not the same as the current state of main. Work lands on the default branch continuously, and not every commit there is part of the latest tag.
Current development
Work in progress lands on main and is not part of any tagged release until it is tagged. If you build from source you are running development code, with whatever is unfinished in it at that moment.
Major completed areas
Implemented, tested and documented in the repository — which is not the same as audited.
- DNS, DoH and DoT serving, with DoT upstream by default
- Category blocking from public threat feeds, plus custom allow and block lists
- Per-network policy by CIDR, and roaming attribution by DoH token
- Client ACLs, open-resolver startup refusal and public-exposure warnings
- Query logging with plain-English reasons, rollups and Markdown reports
- Prometheus metrics, embedded dashboard and a REST API with OpenAPI 3.1
- dnsdaddy doctor diagnostics with evidence behind every verdict
- Structured security findings, stored and exportable as NDJSON
Missing, partial or out of scope
Stated by the project itself, not discovered by a disappointed user.
No local DNSSEC validation
DNS Daddy records the verdict of a validating upstream. It holds no trust anchor and verifies no signatures itself.
Behavioural detections never block
Alert-only by design, until there is a measured false-positive rate on real traffic.
No native SIEM connectors
Structured findings are exported as NDJSON for a log shipper. There is no bespoke Sentinel, Splunk, Elastic or Wazuh client.
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.
safeSearch not enforced
The API accepts the field and the resolver ignores it; the OpenAPI schema marks it deprecated for that reason.
Encrypted-DNS bypass
A client resolving through an external DoH or DoT service is not covered. That needs a network control.
No machine learning
None exists in the project today, and statistics are not relabelled as AI.
No independent audit
No third-party security assessment or penetration test has been performed.
Current research and development
Each of these is implemented far enough to read, run and criticise — and each is experimental rather than something to depend on.
Behavioural detection
Six detectors that observe, score, explain and alert. Thresholds come from synthetic corpora; the most valuable next step is measurement against real traffic.
read the docs →External API providers
VirusTotal, Google Safe Browsing and custom HTTP/JSON providers, disabled by default, with sealed credentials and bounded timeouts.
read the docs →Evidence model and decision records
A shared representation of a security claim, and persisted reasoning behind enforced decisions. Decision recording is off by default.
read the docs →Daddybound
A DNSSEC validation engine written from the standards and exercised in a differential lab. It is isolated from the resolver and validates nothing for a deployment.
read the docs →Deployment validation
An acceptance checklist recording what has actually been run on clean machines, VMs and VPSes — including secure VPS deployment.
read the docs →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.
Race detector
The test suite runs under the race detector, not only in plain mode.
Fuzzing
Fuzz targets on domain normalisation and suffix matching — the parsing 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 →What none of it proves
The assurance document sets out what is checked, by what, and the limits of each check. The claim the project holds itself to is simple: a claim should be traceable to evidence, and where there is no evidence, the page says so.
Where the project is going
There is a published roadmap in the repository, and it comes with no dates and no promises. Items are ordered by how much they would improve the project against how likely they are to happen, and everything on it is explicitly not implemented.
A recurring theme runs through it: most items are blocked on evidence rather than on code. The single most valuable contribution right now is not a feature — it is running the behavioural detectors on a real network and reporting what fired and whether it was real.
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 →