The question I'd ask is whether DNS is the right place for a CDN - in some ways it seems like that should either happen at the routing level (e.g. anycast) or at the application level (e.g. http redirects to user-appropriate servers) depending on the service.

HTTP redirects would introduce a delay and quite a bit of additional traffic. However, application level choice of server embedded in the output HTML would be efficient, and more accurate because it knows the precise IP address of the client, not merely the DNS server it's using.

But this requires much more than just changing a URL, it requires logic on the CDN customer's servers and some form of replication of the database mapping IP address to server.

So you're right, DNS is not the right place for a CDN. But it works. It's just like web browsers are completely the wrong universal client for server based applications, but web applications work.

Pragmatism sometimes trumps correctness.

Both the end-to-end principle and the principle of common engineering sense argue against baking content distribution networks into "layer 3" Internet routing:

* Internet routing, particularly interdomain routing, is already overtaxed. Despite the fact that BGP4 is fully capable of doing so, it's still impossible to advertise a "typical" individual IP address (so that you could, for instance, multihome).

* There are as many different CDN service models as there are CDNs, and when you have flexible and changing app requirements, you want to keep the center of balance in the app layer, where it's easy to change.

The problem with Vixie's argument here is that while BGP4 is genuinely a "lower" layer --- where almost any policy innovation needs to be agreed on by multiple billion-dollar corporations --- DNS simply isn't. These stupid global traffic management pet tricks that Vixie is arguing against don't actually break the DNS; they just rob it of its purity of essence.