> The subscriber must be directly network-accessible and is identified by its Subscriber Callback URL
Does this mean the subscriber needs to have a forwarded port open to the internet for this to work? Without IPv6, users behind NAT (and specifically behind CGNAT) wouldn't be able to use it.
I currently run my own (DNSSEC validating) Bind. But it has some drawbacks. For occasionally visited sites/tlds, my bind would need to contact root more often than if using a shared resolver.
The bad routes can be seen by agents: 219-YVR-Canana, 221-qeast, 16-TurboBytes, 6-VPS TH, 10-TurboBytes, 220-TurboBytes, 17-aks-seattle and 190-ATT-AS7018
From outages mailing list, following subnets were affected.
Fair enough, but most users won't care enough look it up and use 9.9.9.10 instead of 9.9.9.9 if they want better performance in exchange for allegedly lower privacy.
It appears 1.1.1.1 also does not pass client-subnet, atleast not by default. Queries to my authoritative from Google always includes client subnet, OpenDNS required request for whitelist. For Cloudflare its unclear.
>It appears 1.1.1.1 also does not pass client-subnet, atleast not by default.
Wow, this is actually a huge issue. Just as a simple test, I tried nslookup google.com for both 1.1.1.1 and 8.8.8.8, and Cloudflare's responses ping at about 200ms, whereas Google's responses ping at ~10ms.
That also explains the abnormally low response time of CloudFlare's solution compared to the 2nd and 3rd place solutions; the geo-location lookups require more time to reach and resolve a decision and thus represent an increase in response time from the resolver (in exchange for improved latency in all future communications to the target server).
If you have a CF PoP close to you, the absent of it shouldn't really matter. Will only have an effect for those with a Google peering much closer than CF peering.