Capabilities
Available, experimental, and only planned.
This page is a reading of docs/capabilities.md, the repository's own single source of truth. Available means implemented, tested and documented — not audited. Experimental means implemented but validated only against synthetic data or a handful of deployments. Planned means nothing in the code does this today.
Available
DNS resolution
How queries reach DNS Daddy and how they leave it.
Forwarding resolver over UDP and TCP
AvailableNot recursive — it does not walk the root zone. It always forwards to an upstream you configure.
docs/architecture.md →DNS-over-TLS listener
AvailableRequires a certificate; off unless configured.
DNS-over-HTTPS endpoint
AvailableRFC 8484, served at /dns-query/<token>.
Encrypted upstream (DoT)
AvailableThe shipped default. Upstream certificates are verified.
Answer cache
AvailableBounded, sharded and TTL-aware, invalidated on a feed or policy change.
Request collapsing
AvailableIdentical concurrent questions share a single upstream flight.
ANY refusal (RFC 8482)
AvailableOn by default; ANY is the classic amplification lever.
Client ACL
AvailableSource addresses outside the list are REFUSED before any other work happens.
Open-resolver startup refusal
AvailableA public listener with no ACL is a startup error, not a warning.
docs/deploy.md →Available
Filtering and policy
What gets blocked, and how an operator stays in control of it.
Category blocking from public threat feeds
AvailableMalware, phishing, C2 and cryptomining on by default; ads, adult, gambling and newly-registered available.
docs/threat-intel.md →Custom allow and block lists, per policy
AvailableAllow-list wins, so an operator can always override a bad feed entry.
Per-network policies
AvailableMatched by CIDR, most specific prefix first.
Roaming attribution by DoH token
AvailableA per-network token in the DoH path applies that network's policy from any address.
Configurable block response
AvailableNXDOMAIN, 0.0.0.0 / ::, or REFUSED.
Immediate allow-listing
AvailableThe answer cache is purged on a policy change, so a fix applies on the next query.
Available
Telemetry and reporting
What you can see, keep and export after the fact.
Per-query logging with plain-English reasons
AvailableNon-blocking and batched; it drops rather than delaying a lookup.
docs/privacy.md →Hourly and daily rollups
AvailableThey survive query-log pruning, so reporting history outlives browsing history.
DNSSEC status per query
AvailableThe upstream's verdict, recorded as validated, unvalidated or servfail. This is not local validation.
docs/dns-security/dnssec.md →Prometheus metrics
AvailableHand-rolled, with no client library dependency.
Markdown reports
AvailableA period summary written for someone who does not run the network.
Structured security findings
AvailableStored, queryable, and exportable as NDJSON for downstream logging and SIEM workflows.
docs/siem.md →Available
Management and diagnostics
Running it, and finding out why it is not doing what you expected.
Embedded dashboard
AvailableNo build step and no npm tree; served from the binary.
REST API with OpenAPI 3.1
AvailableEach build serves its own specification at /openapi.yaml.
Session and bearer-token authentication
AvailableBcrypt password, rate-limited login, and same-origin checks on cookie-authenticated writes.
Single static binary
AvailableCGO disabled, pure-Go SQLite, cross-compiles from a laptop.
dnsdaddy doctor
AvailableReads configuration and the database and sends real queries at the listeners and upstreams, reporting PASS/WARN/FAIL with the evidence behind each verdict. Changes nothing; --json for machine use.
Client-access cross-check and public-exposure warning
AvailableNames each permitted range reachable from the internet and the setting responsible. It never claims a firewall state — DNS Daddy cannot see a cloud security group.
docs/deploy.md →Port-conflict attribution
AvailableDistinguishes 'nothing is listening' from 'another process holds the port', and names the process where permissions allow.
Management-exposure detection
AvailableRaises management requests that actually arrive over plain HTTP from a public address. Evidence, not inference.
Experimental
Implemented, but not validated enough to depend on
These exist and are tested, but only against synthetic data or a small number of deployments. Behaviour and thresholds may change. Do not build a control you depend on around anything in this section.
Behavioural detection — six detectors
Experimentaldns_tunnel, dga_like, nxdomain_anomaly, txt_anomaly, dns_beaconing and resolution_failure observe query behaviour and raise explainable findings. Thresholds are calibrated against synthetic corpora, not production traffic, and no real-world false-positive rate has been measured. They observe, score, explain and alert; they never block.
docs/detection/README.md →Daddybound — DNSSEC validation engine
ExperimentalA chain-of-trust walk implemented from the standards in pure Go, exercised in a differential laboratory. It answers no queries and enforces no policy, a test asserts the query path cannot reach it, and there is no NSEC/NSEC3 yet — so no authenticated NXDOMAIN or NODATA. It is not local DNSSEC validation for a deployment.
docs/daddybound/README.md →External API providers
ExperimentalVirusTotal, Google Safe Browsing and custom HTTP/JSON providers, disabled by default. Credentials are sealed with AES-256-GCM and are write-only through the management API. Enabling a provider means the domain being investigated may be sent to that third party.
docs/external-apis.md →Evidence model and decision records
ExperimentalA shared representation of a security claim, and persisted reasoning behind enforced decisions written at the time they occur. Decision recording is off by default.
docs/decision-records.md →NDJSON findings file
ExperimentalA findings stream any log shipper can tail. The format is stable within schema version 1.x. There are no bespoke Sentinel, Splunk, Elastic or Wazuh connectors.
docs/siem.md →The lab
ExperimentalAn offline lab profile with seven scenarios, two of which are supposed to find nothing. detection.window_scale is a lab demonstration setting rather than a tuning knob.
labs/ →Planned
Not implemented. Nothing in the code does this today.
Listed so the gaps are visible, not so they can be read as features. The roadmap explains what would have to be true first — most of these are blocked on evidence rather than on code.
Local DNSSEC validation in the resolver path
PlannedNeeds trust-anchor management, negative-proof handling and a considered failure mode. Daddybound is the work towards it and enforces nothing today.
Policy enforcement from behavioural findings
PlannedRequires a measured false-positive rate first. Blocking on a heuristic with an unknown rate is not a feature.
safeSearch enforcement
PlannedAccepted by the API and stored on the policy; the resolver does not act on it. The field is marked deprecated in the OpenAPI schema so a generated client cannot present it as a working control.
Webhook and syslog sinks
PlannedThe NDJSON file plus a log shipper covers the same ground today without a client per vendor.
Sigma rule export / detection-as-code
PlannedResearch. The finding schema was designed with it in mind.
Behavioural baselining
Planned'Unusual for this network' needs a learned baseline, and a considered answer to poisoning during the learning window.
Word-list DGA detection
PlannedThe current heuristic measures surface statistics and misses dictionary-word generators entirely.
Machine learning anywhere
PlannedStays planned until there is a defensible dataset, a baseline to beat and an evaluation method. Statistics relabelled as AI would make the output less trustworthy, not more.
Clustering, anycast and high availability
PlannedOne server is one server. Run two and give clients both addresses.
SSO, RBAC and multi-tenancy
PlannedA single admin password plus API tokens is the whole access model.
Blocking encrypted-DNS bypass
PlannedDNS Daddy cannot stop a device resolving elsewhere. That needs a network control on your firewall.
Deliberately excluded
Things DNS Daddy will never do
Block on an unvalidated heuristic
Observe, score, explain and alert is the point of the detection engine, not a stepping stone to automatic blocking.
Send your data anywhere by default
No telemetry, no phone-home, no account, no licence check. Feeds are public URLs downloaded from their operators.
Claim to protect against what it cannot see
A device using an external DoH resolver bypasses DNS Daddy entirely. That is a property of DNS.
Label arbitrary statistics as AI
Entropy is entropy.
Check this list against the code.
A running build states its own position: /api/v1/detectors reports each detector's maturity, /openapi.yaml is the API surface that build actually serves, and dnsdaddy doctor --json reports its own configuration and health. Those cannot drift the way a page can. If anything here disagrees with the repository, that is a bug worth reporting.