Protect. Observe. Respond.
Protective DNS with visibility into what your network is asking for.
Block known malicious domains at the resolver, investigate DNS activity, and understand the decisions behind your protection — without sending query telemetry to a SaaS platform.
See how it works ↓DNS queries
24,918
last 24 hours
Threats blocked
312
feed + policy matches
Resolver status
Healthy
udp/53 · doh · dot
Query activity
live
A bar chart of DNS query volume over time, with blocked queries highlighted.
| Time | Client | Query | Verdict |
|---|---|---|---|
| 14:02:11 | laptop-07 | cdn.example.com | allowed |
| 14:02:09 | phone-mia | track.adserve.net | blocked |
| 14:02:04 | nas-01 | updates.debian.org | allowed |
| 14:01:58 | iot-cam-3 | c2.badhost.example | blocked |
| 14:01:52 | laptop-07 | login.microsoftonline.com | allowed |
How it works
One control point. Every name your network resolves.
DNS Daddy sits between your devices and the resolver they would otherwise use. Nothing is installed on the endpoint — if a device uses your DNS, it is covered.
01
Device
A laptop, phone, server or IoT device asks for a name.
→02
DNS Daddy
Your self-hosted resolver receives the query over DNS, DoH or DoT.
→03
Protect
Policy and documented threat feeds decide whether the name is allowed or blocked.
→04
Observe
The outcome is logged locally with the client and a reason you can inspect.
→05
Respond
Use the evidence to investigate a query, change policy or review an allow-list decision.
PROTECT
Threat-feed matches and policy decisions perform blocking.
OBSERVE
Query activity and client context remain on infrastructure you control.
RESPOND
Evidence gives you a starting point for investigation and policy changes.
Why DNS Daddy
Protective DNS without the black box.
Public protective resolvers can block known threats. DNS Daddy is for operators who also want to see which device asked, understand the decision, and keep the record local.
Public resolver
- Easy to get started
- Limited local visibility
- Provider operates telemetry
DNS Daddy
- Self-hosted
- Per-network visibility
- Local telemetry
- Inspectable policies
- Open source
Commercial protective DNS
- Mature platforms
- Larger feature sets
- Managed service / SaaS model
DNS Daddy does not claim equivalent maturity, scale or support to established commercial platforms.
Threat intelligence
Known threats, blocked at the resolver.
DNS Daddy can ingest public and community-maintained threat intelligence for categories such as malware, phishing, command and control, and cryptomining.
Threat intelligence
Public feeds
No black-box intelligence. Every built-in source is documented and inspectable, and you can add local feeds in supported formats.
Explore threat intelligence →Behavioural detection
Six experimental detectors that observe, explain and alert.
DNS Daddy includes six experimental behavioural detectors designed to surface suspicious DNS patterns. They observe, explain and alert — they do not automatically block traffic. Enforcement stays with policy and curated threat feeds.
dns_tunnel
max highDNS tunnelling
DNS used as a data carrier
dga_like
max highDGA-like domains
Algorithmically generated names
nxdomain_anomaly
max mediumNXDOMAIN anomalies
Bursts of failed lookups
txt_anomaly
max mediumTXT anomalies
Unusual TXT record usage
dns_beaconing
max mediumDNS beaconing
Fixed-cadence check-ins
resolution_failure
max mediumResolution failures
Domains persistently failing upstream
Experimental · alert-only
Thresholds are currently calibrated against synthetic test corpora rather than large-scale production traffic, and no measured real-world false-positive rate has been published yet. That is precisely why detections remain alert-only.
There is no machine learning here, and the project deliberately avoids relabelling statistics as AI. A finding shows the measurements behind its score, so you can judge it rather than trust it.
Every detector reports its own maturity through /api/v1/detectors, so the running build states this rather than relying on a web page being current.
External intelligence
Bring your own threat intelligence.
Alongside the curated blocklist feeds, DNS Daddy can attach external reputation and enrichment services — VirusTotal, Google Safe Browsing, or any custom HTTP/JSON provider. This is optional and disabled by default; an operator chooses whether a provider participates.
Credentials encrypted at rest
AES-256-GCM sealing, handled by a dedicated keyring.
Write-only credentials
Secrets are not returned by the management API after configuration.
Connection testing
Check a provider answers before it participates in anything.
Health monitoring
Per-provider status, so a silent failure is visible.
Rate limiting and circuit breaking
A struggling provider is backed off, not hammered.
Caching and bounded timeouts
Two-layer cache; a lookup never waits beyond its budget.
Reputation modes
off
External services are not consulted at all.
cache_only
Only previously cached reputation data is used.
blocking
A provider may be briefly consulted during a DNS decision, within a bounded timeout.
Configuration establishes the maximum permitted mode. The dashboard can lower the operating mode during use; it does not raise it past that ceiling. A provider failure or timeout is treated as unknown, never as malicious.
What enabling a provider costs you
When an external provider is actively queried, the domain being investigated may be sent to that third party — the actual name, at the time it was asked for.
Nothing is sent anywhere unless you turn a provider on. This behaviour is opt-in, and the trade-off is documented in full rather than buried.
Read docs/external-apis.md →Evidence & decisions
Why was this domain blocked?
Blocklists, behavioural findings and external reputation providers used to describe evidence in incompatible ways. DNS Daddy now has a shared evidence model, so a claim from any of them can be read the same way.
Evidence model
- observationWhat was actually seen.
- sourceWhich named source reported it.
- timestampWhen it was observed.
- claimWhat that source asserts.
- confidenceHow strongly it asserts it.
- expiryWhen the claim stops counting.
- detailThe supporting specifics behind the claim.
Corroboration is expressed as agreement between identifiable independent sources — not as a single combined risk score with the working hidden inside it.
Decision records
DNS Daddy can persist the reasoning behind an enforced DNS decision: which rule fired, the policy path it took, and the evidence cited at that moment. The explanation is written when the decision happens rather than reconstructed later, so a feed that changes tomorrow cannot quietly rewrite why something was blocked today.
Read docs/decision-records.md →Not on by default
Decision recording is off unless an operator enables it, and it writes a record per blocked query rather than per query. Do not assume an existing deployment is already keeping these records.
Research
Daddybound — experimental DNSSEC validation research.
Daddybound is a DNSSEC validation engine being written from the DNS and DNSSEC standards in pure Go, and tested against established validators in a differential laboratory.
Not connected to the resolver
Daddybound answers no user DNS queries, enforces no DNS policy, and does not provide local DNSSEC validation to deployed DNS Daddy resolvers. A test in the repository asserts that nothing on the query path can even reach it.
DNS Daddy still relies on its upstream resolver for operational DNSSEC validation. Daddybound is an isolated experimental validation engine being developed and tested separately from the live resolution path.
Where the work has got to
- Positive chain-of-trust walk from a configured trust anchor to a signed answer.
- A differential laboratory comparing results against established validators.
- No NSEC or NSEC3, so no authenticated NXDOMAIN or NODATA yet.
- It is not, and must not be read as, production DNSSEC validation.
A separate point worth keeping straight: DNS Daddy can record the DNSSEC status reported by a validating upstream. That is a strictly weaker statement than validating signatures locally, and it is not presented as the same thing anywhere on this site.
Assurance
Evidence, not assumptions.
DNS Daddy is AI-assisted and says so plainly. Generated code is not automatically trusted code; claims are scoped to the evidence available today.
- VERIFIED
Automated test suite
Re-checked automatically in CI.
- VERIFIED
Race detector
Re-checked automatically in CI.
- VERIFIED
Static analysis
Re-checked automatically in CI.
- TESTED
Vulnerability scanning
Exercised by tooling at a known point in time.
- EXPERIMENTAL
Behavioural detection
Working concept; insufficient real-world validation.
- NOT VERIFIED
Independent professional security review
No evidence currently supports this claim.
There has been no independent professional security review.
This project is experimental software, not audited or production-grade security software.
Live threat intelligence
See DNS-related threats emerge, connect and evolve.
Explore DNS-related malicious infrastructure using real threat-intelligence observations, infrastructure relationships and defensive context — through the DNS Daddy Threat Observatory.
Real observations · Infrastructure relationships · ATT&CK context · Defensive guidance
threats.dnsdaddy.dev
An experimental DNS threat-intelligence and visualisation project built as part of the wider DNS Daddy security research ecosystem. This page shows only the Observatory's own sanitised public output — no provider feeds or credentials live here.
Live threat activity
ObservatoryDNS Daddy Threat Observatory
Explore live DNS-related threat intelligence, infrastructure relationships and defensive context.
Open Threat Observatory →The DNS Daddy ecosystem
Understand DNS. Protect DNS.
Protect
DNS Daddy
Open-source protective DNS experimentation you run yourself.
Observe
Threat Observatory
Explore real DNS-related threat intelligence and the infrastructure behind it.
Explore live data →Learn
Research & methodology
Understand how DNS threats are observed, correlated and defended against.
Self-hosted deployment
Run it where you want.
Designed to run on modest hardware, with deployment testing still ongoing. Choose an environment you understand and can maintain.
01
Docker
Containerised deployment
02
LAN / homelab
Local network resolver
03
Public VPS
SSH tunnel or HTTPS
04
Your infrastructure
Local telemetry and control
$ git clone https://github.com/jameshoulder/dnsdaddy.git$ cd dnsdaddy$ ./deploy/install-docker.sh
Works alongside Pi-hole
Already using Pi-hole? Keep it.
Pi-hole
Ads and trackers
Pi-hole is an excellent choice for network-wide ad and tracker blocking.
DNS Daddy
Threat intelligence and visibility
DNS Daddy focuses on protective DNS, documented threat feeds and DNS security visibility. They can run together.
Open source / built in public
A well-described bug is more useful than pretending the project is finished.
DNS Daddy is open because security software benefits from inspection, challenge and contribution. Read the source, review the decisions, and help improve the gaps.
Source of truth
Everything shipped on this site should be traceable to the repository or clearly marked experimental, planned or not verified.
View DNS Daddy on GitHub ↗Free & Open Source · Self-Hosted · No Account · No Subscription
Limitations
What DNS Daddy does not claim.
Protect. Observe. Respond.
See what your network is asking for.
Open source. Self-hosted. Built in public.