1.1.1.1 outage explanation

This is a great write up. It's also why the DNS root servers have a policy of surviving DDoS through massively over-provisioned, multi-org, anycasted redundancy rather this sort of smart DDoS mitigation that drops traffic: DNS is so critical that any risk of dropping real traffic is unacceptable. (obviously, such a scale is impractical for 99% of services)

A good takeaway from this outage for the average user would be to make sure that your fallback DNS resolvers are operated by totally separate providers. (eg, configure 1.1.1.1 with 8.8.8.8 as a fallback, rather than 1.1.1.1 and 1.0.0.1) (Edit: fixed cloudflare's secondary address)

Re: 1.1.1.1 outage explanation

#5

Post by Dylan16807 » Fri, Jun 01, 2018, 5:27 AM UTC

gcommer wrote: post #4

This is a great write up. It's also why the DNS root servers have a policy of surviving DDoS through massively over-provisioned, multi-org, anycasted redundancy rather this sort of smart DDoS mitigation that drops traffic: DNS is so critical that any risk of dropping real traffic is unacceptable. (obviously, such a scale is impractical for 99% of services) A good takeaway from this outage for the average user would b…

(the cloudflare secondary is 1.0.0.1)

Re: 1.1.1.1 outage explanation

#6

Post by throwaway2048 » Fri, Jun 01, 2018, 5:30 AM UTC

another decent alternative fallback with the same featureset is quad9

https://www.quad9.net/

Re: 1.1.1.1 outage explanation

#7

Post by saghm » Fri, Jun 01, 2018, 5:40 AM UTC

> Our FRP framework allows us to express this in clear and readable code. For example, this is part of the code responsible for performing DNS attack mitigation: > > def action_gk_dns(...): > [...] > > if port != 53: > return None > > if whitelisted_ip.get(ip): > return None > > if ip not in ANYCAST_IPS: > return None > > [...]

What does this code sample have to do with FRP? This code seems extremely trivial and doesn't give any real indication to me why you'd need a framework of any sort. It seems like they really want to emphasize that they use FRP, but this code just seems completely unrelated.

Re: 1.1.1.1 outage explanation

#8

Post by kondro » Fri, Jun 01, 2018, 5:41 AM UTC

throwaway2048 wrote: post #6

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.

Re: 1.1.1.1 outage explanation

#9

Post by cmurf » Fri, Jun 01, 2018, 6:05 AM UTC

Dylan16807 wrote: post #5

gcommer wrote: post #4

This is a great write up. It's also why the DNS root servers have a policy of surviving DDoS through massively over-provisioned, multi-org, anycasted redundancy rather this sort of smart DDoS mitigation that drops traffic: DNS is so critical that any risk of dropping real traffic is unacceptable. (obviously, such a scale is impractical for 99% of services) A good takeaway from this outage for the average user would b…

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

Re: 1.1.1.1 outage explanation

#10

Post by bobf » Fri, Jun 01, 2018, 6:07 AM UTC

cmurf wrote: post #9

Dylan16807 wrote: post #5

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's not necessarily a bad thing, since it's probably better to use another source for a secondary if that's your primary.