FAQ
Why won’t this block YouTube ads?
YouTube serves videos and ads from the same hostnames (for example youtube.com and googlevideo.com) over HTTPS and QUIC.
DNS-level blocking can only allow or deny entire hostnames, so it cannot separate an ad stream from the video you actually want to watch.
- The traffic is encrypted end-to-end, which prevents the resolver from inspecting or stripping individual ad segments.
- Blocking those shared hostnames would break legitimate playback and stop the YouTube app from loading videos.
- YouTube rotates domains often and embeds ads inside the video manifest, bypassing hostname filters altogether.
To curb YouTube ads, use an app or browser extension with in-stream blocking (NewPipe, Brave, uBlock Origin) or a network filter that can rewrite manifests.
DNS filtering still removes most other ad and tracking domains that live on separate infrastructure.
Can I use DNS over QUIC (DoQ) instead of DoT?
Yes, if your platform has a DoQ-capable app. Install something like Nebulo or AdGuard DNS, choose DoQ, and point it at doq.xel-serv.com on port 853.
The app will create a local VPN tunnel to secure your DNS traffic. iOS does not expose system-wide DoQ yet, so Apple devices should stick with the DNS profile above until that changes.
Does this replace a VPN or block every in-app ad?
No. DNS filtering only decides which hostnames your device can reach. It improves privacy by cutting off known ad and tracker domains,
but it does not encrypt all traffic or spoof your location the way a VPN does.
- Apps that hard-code ad servers, ship ads inside the app, or use the same domain as core content will still show advertising.
- Connections outside DNS (for example hard-coded IPs or DoH inside an app) bypass this resolver and keep working.
- If you need full-tunnel encryption or geo-unblocking, pair this DNS service with a reputable VPN instead of treating it as a replacement.
Think of this resolver as a baseline network-wide filter. It pairs well with browser extensions or device-level blockers for stubborn apps.
Want the technical bits?
Resolver layout
Two Technitium v8 resolvers operate in the Netherlands without forwarders. Both hostnames dot.xel-serv.com and doq.xel-serv.com resolve to both nodes:
- Node A — self-hosted hardware in NL (DoT/DoQ on port
853, TLS 1.3 with ALPN dot).
- Node B — SSDNodes VPS in NL (DoT/DoQ on port
853, HTTP/3 enabled).
The nodes share one view, so whichever IP you hit delivers identical filtering and answers.
Filtering & security controls
- DNSSEC validation is enforced; bogus chains are dropped.
- Blocklists: big.oisd.nl for ads/trackers and the URLhaus host file for active malware domains.
- TLS certificates are issued automatically by Let’s Encrypt via Traefik.
- Recursion is closed to standard DoT/DoQ clients—no open UDP/TCP port 53 exposure.
Logging & retention
- No per-query or per-client logs are persisted.
- Error and audit logs (without client IPs or domains) are kept for at most 12 months for abuse detection, then purged.
- Anonymised aggregate statistics live in memory only; nothing is exported to third parties.
CLI verification & integration
Run quick checks or wire the resolver into homelab tooling.
kdig @dot.xel-serv.com example.com +tls +tls-host=dot.xel-serv.com
openssl s_client -connect dot.xel-serv.com:853 -alpn dot
kdig @doq.xel-serv.com example.com +quic
Stubby / dnscrypt-proxy: set the upstream to dot.xel-serv.com:853, require TLS authentication on that hostname, and enable IPv4/IPv6 as needed.
Troubleshooting tips
- If Android says “Cannot connect”, toggle airplane mode once to force a fresh certificate check.
- Allow DoQ apps to create VPN tunnels and exempt them from battery optimisations/background limits.
- Verify the resolver via 1.1.1.1/help or run an extended check on dnsleaktest.com.