A home DNS resolver (Blocky) was returning a dead IP for archive.is due to two compounding issues: ECS-stripping upstream resolvers (Quad9, NextDNS) causing archive.is's geo-steering to return a Vultr node with a closed port 443, and a configured `minTime` floor that pinned the bad answer for an hour instead of the intended 300-second TTL. The fix involved removing ECS-stripping upstreams and dropping the `minTime` cache floor, while keeping `maxTime` as a ceiling. The post also notes the privacy trade-off: forwarding EDNS Client Subnet leaks a truncated client prefix to every authoritative server, which is exactly what Quad9 and NextDNS deliberately avoid.
Questions this post answers
Why does my DNS resolver return a different IP for a CDN site than public resolvers do, and the IP it returns doesn't work?
This happens when your upstream DNS resolver strips EDNS Client Subnet (ECS) before forwarding queries. CDN and geo-steered services like archive.is use ECS to return a nearby node. Without it, the authoritative server sees only the resolver's egress IP and may return a node mapped to that location — which can be an unrelated or unreachable host from your actual location. Resolvers like Quad9 and NextDNS strip ECS by design for privacy. Developers running self-hosted resolvers hit this class of geo-steering failure more than they expect — others debugging the same on daily.dev.
What does the Blocky `minTime` setting do and why can it cause problems with CDN or failover DNS records?
Blocky's `minTime` raises any TTL shorter than the configured floor to that minimum. CDN and geo-steered services intentionally publish short TTLs (e.g., 300 seconds) for fast failover and node rotation. A `minTime` of one hour pins a bad answer for the full hour instead of five minutes, turning a brief glitch into a prolonged outage for every client behind the resolver. Removing `minTime` and keeping only `maxTime` avoids this. Self-hosters tuning DNS cache settings for reliability track these kinds of trade-offs on daily.dev.
Which DNS resolvers forward EDNS Client Subnet and which strip it?
Quad9 and NextDNS strip ECS by deliberate privacy policy. AdGuard forwards ECS, including over DNS-over-QUIC at roughly 49 ms median. Google forwards ECS over DNS-over-TLS at roughly 67 ms with no QUIC endpoint. Quad9's dns11 variant and OpenDNS also forward ECS but apply filtering. When racing multiple upstreams, a single ECS-stripping entry is enough to cause intermittent geo-steering failures, so the upstream set must be uniform. Choosing between privacy and geo-steering correctness in DNS is an ongoing trade-off developers discuss on daily.dev.