[trebecks]

the "Stupid DNS Tricks" section says using dns to map clients to a nearby pop is a trick. they predicted this trick would be used for decades and it seems like they were right. i know cloudfront uses this in some fancy form.

i don't know if i'd call it a trick though. if you have multiple pops, dns feels like a natural place to control what traffic goes to which pop. you will need resolvers to be well behaved which will never be the case. not all will respect ttls and use the client subnet extension but a lot do. dns gives you a nice knob and hooks to apply rules to control the traffic to each pop. this paper i think describes the idea well https://www.sigcomm.org/sites/default/files/ccr/papers/2015/....

if using dns like this is a trick, what is the right way to map a client to 1 of multiple pops? anycast?

[cortesoft]

I work for a CDN who uses anycast for routing. It does work really well and is robust to failures... it auto heals when routes go down, and is immune to issues with DNS caching or people using DNS servers that aren't near their actual location.

There are down sides, though. Control is not very fine grained, meaning you can only move fairly large chunks of traffic at a time. It is also a method better suited to fewer, larger POPs instead of many, smaller, pops, which has its own limitations.

Another option that I have seen used for large download distributions (e.g. game downloads) is to use http redirects... the first request hits a server whose only job is to choose where the actual download will come from, and return a 301 redirect pointing to the actual content targeted to a specific pop or server. This works well, because you can choose exactly where traffic goes without the downsides of DNS redirection, but you do get the downsides of needing two requests for each client request, as well as requiring client support for redirects (which not all traffic supports)

[jiveturkey]

surprised you’ve seen this redirect method. i thought it was patented by google. the most obvious search only turns up an edgio patent. i’ll have to search harder

https://patents.google.com/patent/US20140108674A1/en

[trebecks]

yeesh i didnt realize there was a patent on that. your link lines up with the authors predictions of cdns coming up with and patenting different ways to accomplish this. i guess it makes sense and maybe it isn't a bad thing, but i never thought about it. i wonder how anyone infringing on that is even caught? is something like that ever enforced?

edit: i was blind and missed that it is marked as abandoned "ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION". i never look at these so maybe thats a normal ending, but it is interesting to me.

this guy sounds uhhh exactly the same https://patents.google.com/patent/US11706292B1/en...? reading these brings up the duration of a connection as a relevant dimension. in my bubble i've only dealt with relatively short lived conns. long lived conns must be more likely to get caught up in routing changes so a redirect to unicast can help.

[plagiat0r]

The thing about know-how it's that it is a secret. But the moment you fill a patent, it is not a secret anymore, but clearly http redirector concept based of geoip db lookup of the client is as old as the internet... We did this in early 2000 just based on public IANA ip address split over each RIR as a naive approach without a proper geoip DB.

[cortesoft]

I work for Edgio :)

[xp84]

Not a bad approach. Minor nitpick to your hypothetical (lol) -- in this case one may want to use a 302 redirect since you might want to be consulted again for a subsequent download, rather than have your response cached (potentially on behalf of multiple users).

[cortesoft]

You are right, it was a typo I meant 302

[plagiat0r]

I admire the work of Paul Vixie over the years, been using postfix and bind since 2000.

However, I'm a fan of geodns concept in general, and we have ECS standard as well to help with better answers. This allows small players or individuals to do what Big companies do, but without running anycast network, which is very expensive at every step of the journey: from getting ASN, then PI address space, paying yearly fees, then getting bgp peering and operating it efficiently. Thousands of $ per month and a required expertise. Instead of just spinning up 5 cheap vps and put a smart DNS in front, accepting all the tradeoffs, for $50 per month.

I do agree however, that some of the operational cost (marginal) is shifted to other parties because of small TTL need for this to work sensibly. But still, majority of traffic goes to my authoritative DNS servers that I operate, as the higher zones have a big TTL anyway. You can't geodns a glue record, it is static and it is cached properly.

So who bear this cost? End user pays for the bandwidth so an extra packets for lookup is not an issue. ISP resolvers? A bit yes, but they can enforce a policy on minimal TTL if this is too expensive for the ISP... Clearly it is not. At the end of the day, customer (ISP customer) will pay the bill if ISP needs to spin up more resolvers.