4 ms·

Would a networking expert with some historical perspective then not say that we're misusing DNS for routing or load balancing?

by zo1 5y ago

schoen 5y ago
I'm sure there was a huge debate about this when CDNs first started doing it. (I think Akamai was already doing it 20 years ago or so, so it wasn't just invented now.) You could, of course, try to handle it at a higher protocol layer. For example, you could try to dynamically generate HTML like <img src="https://dallastx.mycdn.com/mysite/someimage.png https://dallastx.mycdn.com/mysite/someimage.png"> for one visitor, whereas a different visitor would get <img src="https://seoul.mycdn.com/mysite/someimage.png https://seoul.mycdn.com/mysite/someimage.png"> This would mean that latency for an initial HTTPS page load would be higher, but then for subresources and maybe other pages on the site it would be lower. But there are other difficulties, like requiring the web server to generate page content (at least slightly) dynamically instead of statically. I'm sure that there are many people who felt that there was something seriously improper about intentionally serving different RRs within the same zone at the same point in time. From what I've heard, this practice is so common that most people working on related Internet standards just assume that this practice has to be accommodated because CDNs and their customers will definitely refuse to give it up. (I know this issue came up a ton in ESNI because in the first version there was a risk that you could cache one version of an A record and another version of an ESNI key record, so the two could be out of sync and therefore inconsistent, if they pointed to different CDNs or different CDN instances that had different public keys. A "nice" solution might be to say "well, don't create deliberately inconsistent sets of DNS records in your DNS zone, then" but apparently nobody found that solution at all acceptable for performance, so they created a more complicated workaround where both pieces of information are merged into a single rrtype.)

Would a networking expert with some historical perspective then not say that we're misusing DNS for routing or load balancing?

by zo1 5y ago

Would a networking expert with some historical perspective then not say that we're misusing DNS for routing or load balancing?

schoen 5y ago

I'm sure there was a huge debate about this when CDNs first started doing it. (I think Akamai was already doing it 20 years ago or so, so it wasn't just invented now.) You could, of course, try to handle it at a higher protocol layer. For example, you could try to dynamically generate HTML like <img src="https://dallastx.mycdn.com/mysite/someimage.png https://dallastx.mycdn.com/mysite/someimage.png"> for one visitor, whereas a different visitor would get <img src="https://seoul.mycdn.com/mysite/someimage.png https://seoul.mycdn.com/mysite/someimage.png"> This would mean that latency for an initial HTTPS page load would be higher, but then for subresources and maybe other pages on the site it would be lower. But there are other difficulties, like requiring the web server to generate page content (at least slightly) dynamically instead of statically. I'm sure that there are many people who felt that there was something seriously improper about intentionally serving different RRs within the same zone at the same point in time. From what I've heard, this practice is so common that most people working on related Internet standards just assume that this practice has to be accommodated because CDNs and their customers will definitely refuse to give it up. (I know this issue came up a ton in ESNI because in the first version there was a risk that you could cache one version of an A record and another version of an ESNI key record, so the two could be out of sync and therefore inconsistent, if they pointed to different CDNs or different CDN instances that had different public keys. A "nice" solution might be to say "well, don't create deliberately inconsistent sets of DNS records in your DNS zone, then" but apparently nobody found that solution at all acceptable for performance, so they created a more complicated workaround where both pieces of information are merged into a single rrtype.)