Earlier quoted context omitted.
(the cloudflare secondary is 1.0.0.1)
Cloudfare makes it weirdly difficult to find this. 1.1.1.1 is plastered over many pages but not concomitant with the secondary.
1.1.1.1 outage explanation
11–20 of 87 posts
Re: 1.1.1.1 outage explanation
#12another decent alternative fallback with the same featureset is quad9 https://www.quad9.net/
The core feature of Cloudflare's DNS is getting you closer and faster resolves to their CDN (probably one of the largest at this point, barring the established enterprise encumbants) in a privacy-first way. Quad9's goal seems to be about threat-detection and prevention. It would be nice if you could have both simultaneously (and maybe you can), but at the moment both services are actually quite different.
Re: 1.1.1.1 outage explanation
#13another decent alternative fallback with the same featureset is quad9 https://www.quad9.net/
The core feature of Cloudflare's DNS is getting you closer and faster resolves to their CDN (probably one of the largest at this point, barring the established enterprise encumbants) in a privacy-first way. Quad9's goal seems to be about threat-detection and prevention. It would be nice if you could have both simultaneously (and maybe you can), but at the moment both services are actually quite different.
Re: 1.1.1.1 outage explanation
#14Earlier quoted context omitted.
The core feature of Cloudflare's DNS is getting you closer and faster resolves to their CDN (probably one of the largest at this point, barring the established enterprise encumbants) in a privacy-first way. Quad9's goal seems to be about threat-detection and prevention. It would be nice if you could have both simultaneously (and maybe you can), but at the moment both services are actually quite different.
9.9.9.10 is "quad nine without the threat detection" from memory.
The only way you get that in a more generic sense is if a specialist DNS CDN provider started up that provided DNS services for all the existing CDNs (or they all agreed to some type of federated standard that let them share the same recursive multicast IP addresses for DNS resolution).
Re: 1.1.1.1 outage explanation
#15Re: 1.1.1.1 outage explanation
#16TL;DR: we should have used an IP that is not traditionally used for testing and internal stuff by everybody including Cisco.
Re: 1.1.1.1 outage explanation
#17> Today, in an effort to reclaim some technical debt, we deployed new code that introduced Gatebot to Provision API.
> What we did not account for, and what Provision API didn’t know about, was that 1.1.1.0/24 and 1.0.0.0/24 are special IP ranges. Frankly speaking, almost every IP range is "special" for one reason or another, since our IP configuration is rather complex. But our recursive DNS resolver ranges are even more special: they are relatively new, and we're using them in a very unique way. Our hardcoded list of Cloudflare addresses contained a manual exception specifically for these ranges.
> As you might be able to guess by now, we didn't implement this manual exception while we were doing the integration work. Remember, the whole idea of the fix was to remove the hardcoded gotchas!
When porting legacy code it is not only important to understand the edge cases and technical debt built up over time, but to test more heavily in production because you never know if you got them all because some smart guy built them long ago and/or there are unknown hacks that were cornerstones of the system for better or worse.
Phased and alpha/beta rollouts in an almost A/B testing way is good for replacement systems. Version 2 systems can also add new attack vectors or other single points of failure that aren't as know from legacy problems, the Provision API seems like it is a candidate for that.
Over time the Version 2 system will be hardened just before it is EOL and replaced again to fix all the new problems that arise over time. Version 2's do innovate but they also shroud fixing old issues and pain points for new unknown problems.
Re: 1.1.1.1 outage explanation
#18Re: 1.1.1.1 outage explanation
#19Re: 1.1.1.1 outage explanation
#20One thing I’d be interested to know more about is why it took 17 minutes to fix. While you can and always should strive to make them less likely, outages are inevitable, so how you respond is crucial. Here the outage was very obviously caused by a deployment that I’d assume was supervised by humans – why did it take 17 minutes to roll back?