Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1.1.1.1 outage explanation

blog.cloudflare.com

Post reply on HN
Print view View original

71–80 of 87 posts

Re: 1.1.1.1 outage explanation

#71

Post by alibert »

joveian wrote: post #70
berti wrote: post #21

Earlier quoted context omitted.

Or 9.9.9.9 if you're not as comfortable with Google services.

At least for personal use, OpenNIC is nice and many of the servers say they do not keep logs. I use the 185.121.177.177 (2a05:dfc7:5::53) anycast server and it works well. They are more likely to disappear randomly than the ones run by large companies. https://servers.opennic.org/

Am I the only one not comfortable using DNS servers running by random volunteers? Is there any "vouching" of the operators or regular checks on common domain on those OpenNIC servers?

Re: 1.1.1.1 outage explanation

#73

Post by BicyclRepairMan »

alibert wrote: post #71
joveian wrote: post #70

Earlier quoted context omitted.

At least for personal use, OpenNIC is nice and many of the servers say they do not keep logs. I use the 185.121.177.177 (2a05:dfc7:5::53) anycast server and it works well. They are more likely to disappear randomly than the ones run by large companies. https://servers.opennic.org/

Am I the only one not comfortable using DNS servers running by random volunteers? Is there any "vouching" of the operators or regular checks on common domain on those OpenNIC servers?

You're definitely not alone. This sounds a little too Tor-ish for my taste.

Re: 1.1.1.1 outage explanation

#74

Post by Chris911 »

saghm wrote: post #7

> 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 does…

From one of the linked presentations: https://github.com/cloudflare/gatelogic

Re: 1.1.1.1 outage explanation

#76

Post by LinuxBender »

crtasm wrote: post #50
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…

I read on the Pi-Hole forums that 'fallback' is a misleading term because clients don't work that way - they will happily spread requests between two functioning DNS servers. Can anyone confirm this or provide further insight?

If your recursive DNS servers are Unbound DNS, they will keep note of which infra (upstream forwarder) nodes are responding and will blacklist the ones that do not. You can see this with

    unbound-control dump_infra
After the infra ttl expires, they will probe the down nodes. If they respond, then traffic will be distributed among them again.

Re: 1.1.1.1 outage explanation

#77

Post by LinuxBender »

cookiecaper wrote: post #58
crtasm wrote: post #50

Earlier quoted context omitted.

I read on the Pi-Hole forums that 'fallback' is a misleading term because clients don't work that way - they will happily spread requests between two functioning DNS servers. Can anyone confirm this or provide further insight?

Most systems do not round-robin by default afaik. They just try the listed DNS servers in order (and resolv.conf will only respect the first 3 IIRC). DNS fallback is often also misunderstood to mean "fall back if the domain is not found", but it really means "fall back if the name server fails to respond". If the domain is not found (i.e. servers returns a valid NXDOMAIN response), most resolvers do not consult any o…

There are also options for libc that affect this behavior that can be set in /etc/resolv.conf like:

    options timeout:2 retries:2 max-inflight:768 max-timeouts:100 single-request-reopen rotate
There are man pages that describe these options.

Re: 1.1.1.1 outage explanation

#79

Post by tracker1 »

bobf wrote: post #10
cmurf wrote: post #9

Earlier quoted context omitted.

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.

I'm using cloudflare first, and google as secondary in my router. For a while I was running my own, but it became less necessary when I stopped doing as much dev at home.

Re: 1.1.1.1 outage explanation

#80

Post by Funcrusher »

dx034 wrote: post #29
kondro wrote: post #14

Earlier quoted context omitted.

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 resolut…

Also, Cloudflare has a huge amount of data centres by now, probably more than any other service. Even Google often underperforms them. Debatable if a few ms make a difference but it can for people living in remote areas where CF has a centre and the next 9.9.9.9/8.8.8.8 is 100ms away.

I'm on Google Fiber and 1.1.1.1 is often 1ms for me and googles DNS is ~8-12ms.

It's amazing how fast it is.

Post reply on HN