[codexon]

Building your own CDN these days requires you to own a large ip block and ASN, and colo at several locations so the DC will actually bother routing to you, in order to deploy anycast.

Certainly too expensive for a small deployment which is why people buy from CDNs instead of setting up their own.

If it was as easy as just doing dns geolocation (which is awful due to geolocation failing and ISP caching), few people would bother buying from CDNs.

[zzzcpan]

> If it was as easy as just doing dns geolocation

It is that easy. The importance of anycast is just PR, nothing more. Some very large CDNs use DNS just fine.

[toomuchtodo]

You shouldn't be anycasting TCP, only UDP. DNS is sufficient.

[codexon]

If anycast TCP didn't work, then cloudflare wouldn't exist. DNS is not sufficient. It takes forever to handle downtime because ISPs don't respect TTL.

[zzzcpan]

You are incorrect, I'll try to explain.

Anycast is essentially an SPOF. Well, not only anycast and not anycast per se, but a single AS it is under. It breaks from time to time because of various mistakes, bugs, etc. and brings down every server as a consequence. This occurs roughly every couple of years and takes hours to resolve.

So, with anycast, if you have 10 servers in different places, you get hours of downtime for 100% of users from time to time.

With DNS, on the other hand, if one server goes down, it affects only 1% or so of users of a particular server, that have incorrect TTL in the resolvers they use, others see change in DNS right away and use working server. But, those 1% of users don't all go to that server at the same time, only small percentage of them does and also sees the old record. Leaving us with let's say 10% of that 1% on 1 out of 10 servers, or 0.01% of all users unable to see the new DNS record for an hour or so. If a typical server on some random AS goes down five times a year, you get 0.01% * 5 * 10 or 0.5% of users affected for an hour per year. Now if you use round robin and let users see multiple records nothing is even going to stop working in the browser for them, just going to make them wait longer until they see a set of working records.

To summarize, anycast is 100% of users not able to reach any server for hours every couple of years, while DNS is 0.5% of users experiencing slowness for an hour per year. In other words: anycast alone cannot be reliable enough for a CDN.

[codexon]

I never said you can't use dns on top of anycast.

[zzzcpan]

You have to understand that anycast comes from ISP/networking people, who are biased towards network level solutions for anything and don't care about hard numbers, no matter how badly anycast looks there.

EDIT: Anyway, resilience, just like security, needs a threat model to avoid wasting resources on things that don't actually work, otherwise it's all just hype.

[codexon]

As someone who has looked into deploying a DNS based CDN, I have frequently found ISPs ignoring TTL.

Routers handle bgp updates much faster. Anycast routing is much more superior to geolocation which gives a completely incorrect location as high as 10% of the time. Anycast ips are also the best way to handle DDoS attacks. Attackers can easily shut down ips listed in DNS while people's ISP and browser repeatedly try to access the same dead IP for hours.

If DNS was an acceptable option, I would have gone with that instead of paying a CDN for an anycast solution.

These are all from my personal observations, they are not something I just heard from "ISP/networking people".