{"id":1709,"date":"2023-09-13T14:09:00","date_gmt":"2023-09-13T14:09:00","guid":{"rendered":"https:\/\/www.dnsfilter.com\/blog\/dns-network-why-it-wont-go-down"},"modified":"2023-09-13T14:09:00","modified_gmt":"2023-09-13T14:09:00","slug":"our-dns-network-wont-go-down-heres-why-dnsfilter","status":"publish","type":"post","link":"https:\/\/ddi.mohflo.net\/index.php\/2023\/09\/13\/our-dns-network-wont-go-down-heres-why-dnsfilter\/","title":{"rendered":"Our DNS Network Won\u2019t Go Down, Here\u2019s Why | DNSFilter"},"content":{"rendered":"

At DNSFilter, we\u2019ve never had a global outage. You\u2019ve probably heard us say that before. We repeat that because it\u2019s something we\u2019re proud of, and we\u2019ve done a lot of work to ensure that our DNS network (our anycast network) has 100% uptime. What I want to address here is how<\/em> we achieve that uptime.<\/p>\n

<\/p>\n

We take pride in this because most other DNS filtering providers don\u2019t go to the lengths that we do to ensure our network is both fast (we\u2019re the fastest DNS resolver in the world and <\/span>North America according to dnsperf.com<\/a>) and redundant. We\u2019ll explore here how and why our network was built to be resilient.<\/p>\n

\"fastest-dns-resolver\"<\/figure>\n

 <\/h2>\n

Our DNS network<\/h2>\n

Anycast is a way to route a network when there are multiple routing paths available. In our case, we have nearly 90 data centers globally in over 60 cities that someone\u2019s DNS request might go through. We announce the same IPs from those data centers, from Singapore to New York City.<\/p>\n

Our users point their DNS requests to the IP addresses we supply. Depending on which data center you\u2019re closest to, your DNS requests will be sent to that data center. So if you\u2019re in Germany, your requests might go through our Frankfurt location, while if you\u2019re in the Pacific Northwest your requests will likely go through our Seattle location.<\/p>\n

We\u2019re able to do this through BGP (Border Gateway Protocol) and announcing our IP space from multiple locations; this is what enables anycast. We use a technology called ECS to pass along a portion of your source IP so that authoritative DNS<\/a> servers and CDNs can determine your \u201ctrue\u201d location and point you to the best servers for them. Using that information, our servers send your DNS requests to the closest server based on your location. As an example, if you\u2019re in Portland, using our Seattle anycast POP, but the website you\u2019re using happens to have a Portland CDN location, ECS will enable that provider to send you to the Portland CDN location instead of the more-distant Seattle location. This results in a much faster experience for you as an end user.<\/p>\n

This differs from the alternate method used in DNS resolution by other providers called unicast. In a unicast network, a single<\/em> server is spun up in a single<\/em> location. This means, whether you get online in Frankfurt or Seattle is irrelevant. No matter what, your DNS requests will travel to the same server. This is not an optimal method in DNS resolution as it creates more latency and higher end-user risk because if that single server goes down, everything goes down.<\/p>\n

But, our service is actually comprised of two<\/em> separate anycast networks (DNS1 and DNS2).<\/p>\n

So if you\u2019re in Germany, and you send a DNS request but DNS1 doesn\u2019t answer, DNS2 will return your request instead with no impact on speed.<\/p>\n

Further, the parts that make up DNS1 are not identical to the components that make up DNS2, even in the same city. For instance, we use Hurricane Electric for DNS1, but not for DNS2. That\u2019s because if we only used Hurricane Electric and they had a global outage, so would we<\/em>.<\/p>\n

Our DNS1 and DNS2 networks are totally different. We use different hosting providers, data centers, and server architectures. This same strategy is actually used by the root DNS servers of the Internet. Setting up our network in this way benefits our customers by protecting them from issues that could be caused by our third party providers, such as:<\/p>\n