DNS Daddy

A lightweight, self-hosted protective DNS resolver and DNS-security visibility tool.

Block malicious domains at the resolver. See which device asked for what, why it was stopped, and what your network is asking for — while keeping the telemetry on your own hardware.

Free & Open Source · No Account · No Trial · No Subscription

---

Alpha

DNS Daddy works and is actively developed, but it is early software and has not had an independent professional security review. Run it in environments you control. What is checked, and what none of it proves.

See DNS Daddy in action

Actual application screenshots from the current light interface, using synthetic lab data. Capture details and source revision.

The overview brings together query activity, blocks, findings and resolver setup, including a suggested server IP and configured DNS ports when a compatible local address is known. It identifies loopback-only access and incomplete address discovery, so you can see when another device still needs configuration.

Encrypted DNS controls and server connection details

Choose your own DoQ, HTTP/3 DoH and HTTP/2 DoH endpoints independently of Daddybound's local validation mode. The image shows a deliberately failed loopback test, so its TLS status correctly stays unobserved.

The Setup card identifies the server IP source, configured listener ports and where an address can be used. This isolated capture reports its actual host-only address; no reachable LAN address is invented.

Encrypted transport setup and scope.

Understand a blocked query

Filter the query log, open a decision and inspect the client, network, source and reason in context. The example above uses a clearly labelled synthetic threat feed.

Explainable behavioural detections

DNS Daddy includes six experimental behavioural detectors for DNS tunnelling, beaconing, NXDOMAIN anomalies, DGA-like domains, unusual TXT activity and repeated resolution failures. They alert and explain; they do not block.

More interface previews: sign-in, assurance and mobile

A straightforward control plane

The web control plane provides a consistent place to configure, observe and investigate a self-hosted resolver.

Assurance you can inspect

The Assurance page separates what is verified, tested, experimental and not verified. DNS Daddy is AI-assisted and early-stage; the project links claims to CI, security testing, threat modelling and documented limitations.

Useful on a smaller screen

The same overview adapts to a phone viewport, with navigation available from the menu.

Brand assets

The light blue-and-silver identity follows the current interface. Logo masters, colours and repository artwork are available in the Brand Package 3.0 assets. This is the brand edition, not a software version.

What is DNS Daddy?

DNS Daddy is a single Go binary that answers DNS for a network. It blocks known-malicious domains using public threat-intelligence feeds, records what happened in plain English, applies different policies to different networks, and raises explainable findings about traffic no feed has heard of yet.

It ships with its own dashboard, a documented REST API, Prometheus metrics, SIEM-friendly exports and a diagnostic command that tells you why DNS is not working when it is not working.

It is aimed at the space commercial protective-DNS platforms occupy — Cisco Umbrella, Cisco Secure Access, DNSFilter and the like — but from the other direction: lightweight, self-hosted and inspectable. It makes no claim to their capability, assurance, scale or support.

Why would I use it?

Public resolvers like Quad9 and Cloudflare can block known-bad domains. What they cannot give you locally is:

• which device made the request,
• why DNS Daddy blocked it and which feed said so,
• whether one endpoint has been quietly beaconing to the same infrastructure,
• or an inspectable record of what happened on your own network.

See what a network actually resolves	A homelab or small office where nobody has ever looked at DNS traffic before.
Investigate a device	“This laptop was flagged — what has it been asking for?”
Learn protective DNS	The code, threat model and detector maths are readable, and there is an offline lab.
Keep telemetry in-house	No account, no cloud tenant and no requirement to upload query logs.
Feed a SIEM	Findings and query data as documented, versioned NDJSON.

What you get

Threat blocking	Malware, phishing, C2 and cryptomining on by default. Additional categories are available.
Plain-English logs	Recorded queries explain what happened and why, subject to configured privacy, retention and bounded logging queues.
Per-network policies	Match clients by CIDR, including different sites and VLANs.
Instant allow-listing	Clear a false positive from the dashboard and purge the cached answer.
Forward, Learn or Live	Start with straightforward Cloudflare DoH forwarding. Choose background DNSSEC learning or local enforcement when ready; saved mode selections survive upgrades.
Choose the DNS transport	Native remains the default. An optional encrypted profile uses your approved DoQ, HTTP/3 DoH or HTTP/2 DoH endpoints with authenticated TLS 1.3 and no plaintext fallback. Live validates the returned records locally with either profile.
DoH and DoT	Serves DNS-over-HTTPS and DNS-over-TLS as well as plain DNS.
Server address on the homepage	Copy a compatible local server IP with its configured DNS ports. Address discovery is authenticated and labels interface, loopback, container/NAT and accepted-socket fallback limitations.
Behavioural detection	Six experimental heuristics plus a local learned baseline, with explainable measurements and no automatic heuristic blocking.
Self-diagnosis	dnsdaddy doctor explains configuration, listener, ACL, upstream and threat-intelligence problems.
Investigation and policy preview	Domain/client history, original decisions, current evidence, findings and native observations in one workflow. Policy preview is read-only and does not silently contact external providers.
Finding review	Acknowledge, resolve, classify false positives and add notes with versioned review history, preserving original evidence.
Operational protection	Bounded per-client rate limiting and IPv4/IPv6 rebinding checks, with explicit internal/split-DNS exceptions and counters.
External APIs	Add your own VirusTotal, Safe Browsing or custom HTTP/JSON credentials safely in the UI, with separate tests and outbound consent.
Recovery and change history	Redacted management change history, encrypted backups including credential keys and learned/native state, and verified restore into a fresh directory.
Exports and notifications	Complete paginated query/decision/finding NDJSON exports and an optional signed HTTPS webhook with bounded asynchronous delivery.
Open by construction	OpenAPI, Prometheus metrics, public threat-feed catalogue and documented design decisions.

DNS Daddy + Pi-hole

DNS Daddy is not a Pi-hole replacement. Pi-hole is excellent at blocking ads and trackers. DNS Daddy focuses on protective DNS, threat intelligence, explainable security decisions and visibility into what devices are resolving.

The two can run together. With the native transport profile in Forward or Learn mode, DNS Daddy can sit in front with Pi-hole as its configured upstream, retaining per-client identity while Pi-hole handles ad/tracker blocking. Native Live bypasses that forwarding path. The optional encrypted profile sends all client DNS through its approved encrypted endpoints; it does not inherit the Pi-hole upstream setting.

See docs/pi-hole.md for the topology options, trade-offs and current evidence level.

Quick start

Prerequisites

The Docker quick start expects:

• Git
• Docker Engine
• Docker Compose v2 (docker compose)

Source builds require Go 1.26.8 or newer; CI and container builds use Go 1.27.1. See CONTRIBUTING.md for the development setup.

Check them first:

git --version
docker --version
docker compose version

Then:

git clone https://github.com/jameshoulder/dnsdaddy.git
cd dnsdaddy
./deploy/install-docker.sh

Use --dry-run first if you want to see what the installer would do without changing anything. --upgrade rebuilds and restarts while keeping your data and .env; --uninstall stops the deployment while keeping your data.

./deploy/install-docker.sh configures and launches DNS Daddy. It does not install Git, Docker Engine or Docker Compose for you.

Fresh installations without an explicit resolver-mode override start in Forward (off); upgrades preserve saved mode choices, and explicit configuration takes precedence.

Allowed queries are filtered locally, then forwarded to Cloudflare over HTTPS on TCP 443 using https://1.1.1.1/dns-query and https://1.0.0.1/dns-query. These literal IP endpoints do not need another DNS resolver to find the upstream. Learn and Live are available in Overview and Daddybound through Apply resolver mode. Forward does not perform Daddybound's local DNSSEC validation.

Upgrading preserves your mode. If an earlier installation is stuck in Live and returns SERVFAIL, select Forward explicitly to establish working forwarding, then investigate validation before re-enabling Live. If the mode control is locked, remove the explicit dns.local_dnssec_validation or DNSDADDY_LOCAL_DNSSEC_VALIDATION override and restart to unlock it. Existing saved upstreams and configuration remain in effect; review old custom DoT endpoints if your network blocks outbound port 853.

Reaching the dashboard

The installer provides three deployment modes:

	Dashboard reached by	Backend binds	Use when
LAN (--lan)	http://<lan-ip>:8080	LAN address	the machine genuinely has no public exposure
SSH tunnel (--vps, default)	http://127.0.0.1:8080 through SSH	loopback	public VPS or when unsure
HTTPS (--https)	HTTPS through Caddy	loopback	public VPS where TLS termination is desired

The SSH-tunnel mode is the safe default for a public VPS:

ssh -L 8080:127.0.0.1:8080 you@your-server
# then open http://127.0.0.1:8080

For HTTPS, the architecture is:

internet → :443 Caddy (TLS) → 127.0.0.1:8080 DNS Daddy

See docs/deploy.md for firewalling, Caddy, TLS, upgrades, backups and uninstall guidance.

First-run password

The generated first-run password is stored on the server at:

<data-dir>/initial-password.txt

For the Docker deployment this is inside the DNS Daddy data volume and can be read with:

docker compose exec dnsdaddy cat /var/lib/dnsdaddy/initial-password.txt

Change the password from Settings, then remove the initial-password file when you no longer need it.

Allow the clients that should use it

DNS Daddy deliberately refuses DNS queries from source addresses it has not been told to serve. On a new installation, add your authorised LAN, VPN or client IP in Networks and enable Allow this network to use DNS Daddy. The Default network's ad-hoc access starts off; listing private ranges in dns.allowed_client_cidrs makes them eligible for that switch, rather than automatically granting every private client access. Configured loopback remains available for checks inside the server or container.

Explicitly permitted networks work regardless of the Default ad-hoc switch. The Setup page and dnsdaddy doctor show the effective permissions. With Docker, a query sent to the host's 127.0.0.1:53 can reach the container from its bridge gateway and still need permission; use the internal doctor check first. See docs/deploy.md.

The homepage and Setup page show addresses observed on this server and their compatible configured DNS ports. If hardened host permissions prevent interface enumeration, they can show only the local IP of the accepted dashboard connection, explicitly labelled as incomplete. A reverse proxy or SSH tunnel may make that address loopback. No external “what is my IP” service or request header supplies the result; container/NAT mappings, firewall rules and client access still need checking.

Start with encrypted DNS, then choose a resolver mode

In Daddybound → DNS transport → Encrypted forwarding, select Add Cloudflare example. This fills a complete HTTPS-over-HTTP/2 endpoint with the TLS name and bootstrap IPs; you do not need an API key or your own certificate. Review the provider, check the sharing agreement, select Test endpoints, then Apply DNS transport after a successful test. Start with Forward for a real lookup; choose Learn for independent background checks or Live for local DNSSEC enforcement when ready. Adding the example only edits your draft and preserves your current resolver mode.

The encrypted DNS guide walks through the provider choice, client ports and the first real lookup. The example uses Cloudflare's documented DoH service over outbound TCP 443. This explicit encrypted profile also covers supporting DNSSEC queries and the daemon's background hostname lookups. The standard Forward default uses DoH for client answers; its native transport profile leaves background hostname lookups to the system resolver. Native Learn and Live need outbound UDP and TCP 53 to authoritative DNS servers. Your saved transport and configured provider choices survive upgrades.

For a complete configuration example in Docker:

docker compose -f docker-compose.yml -f deploy/docker-compose.encrypted.yml up -d --build
docker compose -f docker-compose.yml -f deploy/docker-compose.encrypted.yml exec dnsdaddy dnsdaddy doctor

This explicitly selects the provider in dnsdaddy.encrypted.example.yaml, pins encrypted transport and its endpoints, and keeps the normal data volume. Forward/Learn/Live remain selectable in the UI: new data starts in Forward; existing saved modes are preserved. Repeat both -f arguments for updates. Environment overrides take precedence; remove an explicit mode override if you want the mode chooser unlocked. For a standalone local trial, make run-encrypted uses the same example with DNS on 127.0.0.1:5353 and a separate data directory.

Diagnose before rollout

Run dnsdaddy doctor before changing router or DHCP DNS settings:

docker compose exec dnsdaddy dnsdaddy doctor

Then test one permitted device using the server's reachable LAN or VPN IP:

nslookup -port=53 example.com <dnsdaddy-ip>
dig @<dnsdaddy-ip> -p 53 example.com A
dig @<dnsdaddy-ip> -p 53 example.com A +tcp

Docker's normal host DNS port is 53; its internal listener is 5353. The standalone encrypted example uses 5353 on the host, so use -p 5353 or -port=5353 for that trial. The dashboard port 8080 is separate. Most device and DHCP DNS settings take an IP address and use port 53.

NOERROR with an answer shows that this lookup completed. REFUSED points to client permissions; SERVFAIL means the server could not complete the lookup, so inspect Daddybound and transport status; a timeout points to the address, listener, port mapping or firewall. A successful Test endpoints only checks the encrypted exchange; finish with these real client lookups.

Point one device at DNS Daddy first and watch its traffic before rolling it out network-wide.

See requests arriving and completing

Overview → Resolver activity shows messages reaching the DNS handler, independently of query logging: received, answered, blocked, cached, failed, refused and rate-limited counts, plus in-flight work and the last activity time. The indicator changes when new requests arrive. The status distinguishes waiting or idle traffic from active, degraded, refused or failing traffic; a failed dashboard fetch appears unavailable or stale.

The recent window covers 60 seconds; lifetime totals reset when the process restarts. This is an in-memory aggregate without query names or client IPs. Internal health probes count, and a completed response means the handler produced a reply, not that a remote device received it. Malformed wire messages and DoH authentication/parsing failures rejected before the handler are outside these counters. Keep using the client lookups above to verify the whole path. Enable Query log when you also need individual names, policy decisions and validation evidence. The authenticated API exposes the same counters at GET /api/v1/activity/live.

See it working without real traffic

The offline lab creates synthetic DNS clients and a synthetic upstream so you can exercise the resolver and detectors without contacting malicious infrastructure:

docker compose --profile lab up --build
# dashboard: http://127.0.0.1:8081
# password: dnsdaddy-lab-demo-password

The lab includes benign and detection-triggering scenarios, including tunnelling, NXDOMAIN anomalies, suspicious TXT activity, DGA-like domains and beaconing. Everything uses .example or .test names and seeded synthetic traffic.

See labs/README.md.

Detection, and what it deliberately does not do

Blocking a domain because it is on a threat feed and inferring malicious intent from DNS behaviour are different problems.

None of DNS Daddy's behavioural detectors block anything. They are heuristics, they can have false positives, and their thresholds are currently calibrated against synthetic traffic rather than a production corpus. Every detector is therefore marked experimental.

Findings publish the measurements behind the score so an analyst can inspect the evidence rather than accept an opaque severity label. Full detail: docs/detection/README.md.

Threat intelligence

Default threat intelligence comes from public, no-registration sources listed in internal/catalog/catalog.go, including abuse.ch URLhaus, Phishing Army, The Block List Project, HaGeZi and CoinBlockerLists.

Downloaded feeds are cached to disk. A failed or malformed refresh keeps the last-known-good index rather than emptying it.

The project-operated Threat Observatory integration has been retired. Its built-in feed is removed from the active catalogue and disabled on existing installations; recorded history is retained. Extension now centres on your own external APIs and credentials, with deliberate consent before outbound lookup or delivery.

See docs/threat-intel.md.

Security and assurance

DNS Daddy is an AI-assisted open-source project. AI assistance is implementation support, not security review.

On every change the project runs combinations of build/test, race detection, staticcheck, gosec, govulncheck, CodeQL, Semgrep, container scanning and end-to-end resolver tests. Security testing and design limitations are documented in the repository.

It has not undergone an independent professional security review. There has been no independent penetration test, third-party code audit or certification. Automated scanners and CI do not substitute for one.

Start with:

• docs/assurance.md — what is checked, by what, and what none of it proves
• docs/security-testing.md — security-testing methodology and evidence
• docs/threat-model.md — assets, boundaries, threats and mitigations
• docs/audit-2026-08.md — latest documented audit and reviewer guide
• SECURITY.md — responsible vulnerability disclosure

Honest limitations

Worth knowing before you rely on DNS Daddy:

• No independent professional security review. Automated testing and implementation evidence are not an independent audit.
• Safe Search is not enforced. The deprecated safeSearch API field only preserves a stored compatibility value; even true does not restrict any search engine or rewrite answers. There is no actionable dashboard toggle.
• Native Live is experimental. Fresh installations start in Forward. Select Live deliberately after verifying real answers; production reliability, constrained-hardware performance and long-running key-rollover behavior are not established. Saved selections survive upgrades.
• Native authoritative traffic is plaintext. With the native profile, Live uses UDP/TCP 53 and Learn adds independent native observation traffic. The optional encrypted profile instead forwards to explicitly approved recursive resolvers; it does not make native authoritative recursion encrypted.
• Encryption has boundaries. An approved encrypted resolver receives the DNS names. Client-to-DNS-Daddy traffic and the provider's onward resolution are separate connections. Daemon background hostname lookups use the encrypted profile when selected, but do not receive Daddybound's independent Live validation.
• Live does not silently fall back. With checking enabled, bogus, indeterminate, timeout and bounded-work failures return SERVFAIL. A client's explicit CD bit skips DNSSEC checking without skipping policy or rebinding checks. Encrypted endpoint failures never select plaintext DNS automatically.
• Learning and behavioural findings are alert-only. A learned anomaly is not a maliciousness probability. The checked-in evaluation is synthetic and contains false alerts and misses; there is no measured production false-positive rate.
• Rebinding exceptions require deployment knowledge. Legitimate split-DNS/private answers need explicit exceptions; exceptions are not learned automatically from traffic.
• Recovery has explicit boundaries. Backups capture consistent SQLite data and committed auxiliary files, not every in-flight observation. Restore is offline into a new directory; service/firewall/reverse-proxy configuration is not recreated.
• Browser DoH can bypass network DNS. Mitigations require network/endpoint configuration.
• No clustering, anycast, SSO, RBAC or multi-tenancy. One DNS Daddy instance is one server with an administrator account and API tokens.

docs/capabilities.md is the authoritative capability map: available, experimental and planned.

Daddybound: local DNSSEC validation plus local learning

Daddybound has two distinct responsibilities: DNS resolution with local DNSSEC validation, and a local incremental model of client DNS behaviour. Cryptographic validation and statistical anomaly detection make different claims and remain visible as separate evidence.

Mode	Client answer path	Behavior
Forward (off)	Configured upstreams with the native profile; approved endpoints with the encrypted profile	Forwards allowed queries without Daddybound validation, observations or anchor refresh. Filtering, rate limiting and rebinding protection remain active.
Learn (observe)	The same forwarding path as Forward	Independently validates sampled allowed names after their answers are decided. Observations cannot change those answers. Supporting lookups and anchor refresh use the selected profile.
Live (enforce)	Native authoritative recursion, or approved encrypted recursive endpoints	Locally validates the records actually returned. With checking enabled, secure or proven-insecure answers can be served; bogus, indeterminate and operational failures return SERVFAIL.

Fresh installations default to Forward. The stored/API value remains off for compatibility with existing configurations. Upgrades preserve all recorded choices, including Live. Explicit YAML or environment mode settings pin the choice; otherwise Overview and Daddybound can save an acknowledged mode change. Transport is a separate persisted choice: native remains the default and uses the configured DoH upstreams for Forward/Learn answers; the encrypted profile requires approved endpoints and acknowledgement. Native authoritative traffic uses plaintext UDP/TCP port 53 with QNAME minimisation. The encrypted profile supports outbound DoQ, HTTP/3 DoH and HTTP/2 DoH with TLS 1.3; these are not new inbound listeners. A client DNSSEC CD request skips cryptographic checking only; policy and rebinding checks still apply.

Recorded provenance distinguishes native_live and encrypted_live observations, and native and encrypted_forwarded local query validation sources. Forward/Learn client answers retain their upstream source. Changing the current profile never relabels older evidence. See encrypted DNS.

The native engine implements DNS/DNSSEC protocol and trust logic in Go, using established cryptographic primitives and the DNS wire library. It handles chain validation, NSEC/NSEC3 denial, CNAME/DNAME processing and managed RFC 5011 anchors. libunbound and BIND delv are differential test oracles, not the implementation that produces Daddybound's verdicts.

Local learning is enabled by default and never blocks by itself. It learns bounded per-client baselines for query rate, label length/entropy, name diversity, TXT usage and label count. It warms up from eligible five-minute windows, compares later windows with the previous baseline, and updates parameters gradually. It excludes blocked, failed, partial, saturated and strongly anomalous windows from normal-baseline updates. Persisted checkpoints carry fitted parameters and sample counts, not raw queried names.

A ready baseline is not proof of accurate detection. Warm-up contamination, gradual changes and benign application changes remain limitations. The UI shows sample counts, exclusions, persistence health and uncalibrated anomaly distance. The evaluation report publishes synthetic test populations and investigated misses/false alerts with their denominators.

Read Daddybound and local learning for the implementation and its limits.

Resource target

DNS Daddy is intentionally designed to run on small infrastructure. A 1 GB / 1 vCPU VPS is the reference class, with threat-intelligence memory use scaling with the number of indexed domains and disk use scaling with retained query volume.

The 1 GB / 1 vCPU figure is a design target, not a fresh benchmark of native Live, learning and all optional integrations together. Work queues and state are bounded; workload-dependent performance still needs deployment measurement.

Configuration

Configuration is YAML with DNSDADDY_* environment variables taking precedence. Every option is documented in dnsdaddy.example.yaml.

This starter leaves mode and transport under dashboard control. New data starts in Forward using the same Cloudflare HTTPS upstreams as the built-in defaults; an existing database keeps its saved mode and transport. Query history is enabled explicitly here. See encrypted-dns.md for the profile that also encrypts validation and background DNS.

dns:
  upstreams:
    - "https://1.1.1.1/dns-query"
    - "https://1.0.0.1/dns-query"
log:
  query_log: true
  log_client_ip: true
  retention_days: 7

API and integrations

Every resolver serves an OpenAPI 3.1 specification at /openapi.yaml. Prometheus metrics are available at /metrics, and versioned exports are available for SIEM workflows.

The External APIs page lets each operator add their own provider credentials, save configuration, run a deliberate connection test and choose how the provider may contribute. Reputation starts Off and enrichment starts disabled. Saving a disabled provider makes no external call. Enabling/testing a provider requires consent; synchronous blocking reputation also requires accepting its DNS latency budget.

Credentials are write-only and encrypted with a separate local master key. The project does not supply shared accounts or API keys. Current built-in adapters are VirusTotal v3, Google Safe Browsing Lookup and Custom HTTP/JSON; adapter fixtures and an operator’s successful connection test are reported separately.

Optional signed webhooks deliver new finding events and, when selected, review events to the operator’s own HTTPS receiver. Delivery is bounded and asynchronous, with persistent counters and at-least-once semantics. Receivers should deduplicate using the event ID.

Network/SIEM guidance includes pfSense, OPNsense, UniFi, FortiGate, Windows Server, Wazuh, Elastic, Splunk and Sentinel.

See:

• docs/external-apis.md
• docs/webhooks.md
• docs/exports.md
• docs/recovery.md
• docs/integrations.md
• docs/siem.md
• internal/api/openapi.yaml

Documentation

docs/ is intended to be a DNS-security knowledge base as well as product documentation.

docs/capabilities.md	Available / experimental / planned — start here
docs/assurance.md	What is checked and what none of it proves
docs/audit-2026-08.md	Audit findings, fixes and reviewer guide
docs/threat-model.md	Assets, boundaries, threats and mitigations
docs/detection/	Detection engineering and finding schema
docs/learning.md	Local fitted baselines, privacy, warm-up and limitations
docs/external-apis.md	Provider credentials, consent, modes and testing
docs/encrypted-dns.md	Optional encrypted outbound DNS, local Live validation and transport boundaries
docs/recovery.md	Configuration history and encrypted backup/restore
docs/exports.md	Complete paginated exports and retention limits
docs/webhooks.md	Signed asynchronous event delivery
docs/threat-hunting/	Threat-hunting workflows
docs/dns-security/	Protective DNS, DNSSEC, DoH/DoT and bypass
labs/	Offline lab and synthetic scenarios
docs/siem.md	SIEM integrations
docs/threat-intel.md	Threat feeds and false-positive handling
docs/privacy.md	Data storage and privacy controls
docs/architecture.md	Query flow and architecture
docs/roadmap.md	Future work and prerequisites
CONTRIBUTING.md	Development setup and contribution guidance

Help wanted

DNS Daddy is a solo project and external evidence is particularly valuable.

Useful contributions include:

• independent review of the resolver, policy attribution, authentication and threat-feed handling,
• deployment testing across Ubuntu, Debian, cloud VPSes and virtualisation platforms,
• real-world Pi-hole integration testing,
• security testing within environments you own or have explicit permission to test,
• well-described bugs, documentation fixes and reproducible deployment failures.

Report security-sensitive findings privately through SECURITY.md.

☕ Support the project

DNS Daddy is free, open source and self-hosted. There are no paid tiers or supporter-only features.

If you find it useful and want to support hosting, testing and development, you can buy me a coffee. Contributions, code review, testing and bug reports are equally welcome — and often more useful.

Project status

Alpha. Actively developed, not independently reviewed, and free — permanently.

Maintained by	One person, in spare time
Licence	Apache-2.0
Independent security review	None
Core DNS resolution	Tested and fuzzed
Behavioural detection	Experimental, alert-only
API	Versioned under /api/v1 with OpenAPI
Breaking changes	Recorded in CHANGELOG.md

DNS Daddy began as a cybersecurity Master's project exploring how a small, transparent protective DNS platform could work without enterprise infrastructure. It has since developed into an open-source project with an explicit emphasis on inspectability, evidence and documented limitations.

Licence

Apache-2.0.