Live data from Hacker News

1.1.1.1 outage explanation

blog.cloudflare.com

11–20 of 87 posts

Re: 1.1.1.1 outage explanation

#11
post #9

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.

That is not my experience at all. By following the `install`-instructions on http://1.1.1.1, all available DNS addresses are listed for both ipv4 and ipv6.

Re: 1.1.1.1 outage explanation

#12
post #8

another 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.

Maybe check out what NS1 is doing with DNS

https://ns1.com/

Re: 1.1.1.1 outage explanation

#13
post #8

another 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.

9.9.9.10 is "quad nine without the threat detection" from memory.

Re: 1.1.1.1 outage explanation

#14
post #13
post #8

Earlier 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.

Yeah, but the reason why 1.1.1.1 is so fast for sites that use Cloudflare as DNS is because Cloudflare is the authoritative DNS for them.

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

#16

TL;DR: we should have used an IP that is not traditionally used for testing and internal stuff by everybody including Cisco.

Not even close. The system had a glitch because they were doing a major DNS resolver at all. It had nothing to do with the baggage that comes with 1.1.1.1 specifically.

Re: 1.1.1.1 outage explanation

#17
Great information on the outage. Looks like another version 2 syndrome side effect [1].

> 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.

[1] https://en.wikipedia.org/wiki/Second-system_effect

Re: 1.1.1.1 outage explanation

#20
Major credit to Cloudflare for publishing a clear, honest, and detailed description of what happened. I wish more companies would do this.

One 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?

Post reply on HN