Browser-only demoSynthetic dataInteractive demo · no DNS traffic leaves your browser · modelled on the DNS Daddy v0.3 development interface.View project on GitHubVisit dnsdaddy.dev

Setup

How to run DNS Daddy yourself.

Updated —

This is a browser demo

Nothing here configures a real resolver.

To deploy DNS Daddy on your own hardware:

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

Resolver endpoints

Example addresses from documentation ranges — these do not resolve anything.

Plain DNS (UDP/TCP)
192.168.10.10:53
DNS-over-TLS
192.168.10.10:853
DNS-over-HTTPS
https://dns.example/dns-query
Dashboard
127.0.0.1:8080

Per-network DoH URLs

Each network gets a tokenised DoH path so roaming devices keep their policy.

NetworkPolicy scopeDoH URL
Office LANEnforcinghttps://dns.example.com/dns-query/tok-office-demo
Guest Wi-FiEnforcinghttps://dns.example.com/dns-query/tok-guest-demo
LabEnforcinghttps://dns.example.com/dns-query/tok-lab-demo

Upstream resolvers

Where DNS Daddy forwards what it does not block.

UpstreamProtocolQueriesErrorsAvg latency
tls://192.0.2.53:853#resolver-a.exampletls · encrypted1,402218.4 ms
tls://198.51.100.53:853#resolver-b.exampletls · encrypted401021.9 ms
https://203.0.113.53/dns-queryhttps · encrypted39034.2 ms

Deployment shapes

How DNS Daddy is intended to be run. Nothing here changes a real system.

LAN / homelab

Trusted internal network

  • Resolver listens on the LAN interface; the client ACL is limited to your own ranges.
  • Dashboard reachable inside the network only.
  • DNS Daddy refuses to start as an open resolver.

Secure VPS

Remote deployment

  • Management interface kept behind HTTPS and restricted access.
  • DNS listener limited to known client ranges, never 0.0.0.0 with an open ACL.
  • Roaming devices use the per-network DNS-over-HTTPS token path.

Development / SSH access

Working on DNS Daddy itself

  • Dashboard bound to 127.0.0.1:8080 and reached over an SSH tunnel.
  • Single static binary, so a build can be swapped in place.
  • The lab profile generates synthetic traffic for detector work.

dnsdaddy doctor

Diagnostics with the evidence behind each result — not guesswork.

  • SYSTEMPASSConfiguration parsed and the data directory is writable.
    • · Config: /etc/dnsdaddy/config.yaml
    • · Data directory: /var/lib/dnsdaddy (writable)
  • DATABASEPASSOpened read-only; schema is at the expected version.
    • · Query log rows: 41,208
    • · Schema: current, no pending migration
  • DNS LISTENERPASSUDP, TCP and DoT listeners answered a probe for example.com.
    • · 192.168.10.10:53 UDP+TCP responding
    • · 192.168.10.10:853 DoT responding
  • CLIENT ACCESSPASSThe client ACL matches the configured networks — no open resolver.
    • · Allowed: 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24
    • · Queries from outside those ranges are refused
  • UPSTREAMPASSAll encrypted upstreams resolved the probe name.
    • · tls://192.0.2.53:853 — 18.4 ms
    • · tls://198.51.100.53:853 — 21.9 ms
  • WEB INTERFACEPASSDashboard responding on the loopback address only.
    • · 127.0.0.1:8080 responding
    • · Not reachable from outside the host
  • THREAT INTELLIGENCEWARNOne category list is serving last-known-good data.
    • · Cryptomining pools: last successful refresh 6 hours ago
    • · Blocking continues from the cached copy

    Suggested action: Check outbound access to the feed URL, then refresh that source.

On a real installation dnsdaddy doctor sends its own probe queries and reads the database read-only. In this demo no check contacts anything — the output above is fabricated.

Ready to run this for real? Install DNS Daddy — Docker, systemd or from source. The dashboard binds to 127.0.0.1:8080 by default.