[dns-operations] opting in to stupid DNS tricks
jzp-dnsops at rsuc.gweep.net
Mon Feb 21 17:50:42 UTC 2011
As much as I am lothe to weigh in on a thread with increasing harshness,
On Mon, Feb 21, 2011 at 11:23:42AM +0000, Jim Reid wrote:
> On 19 Feb 2011, at 15:20, Patrick W. Gilmore wrote:
> >Just checking the three largest sites I know off the top of my head
> >(www.facebook.com , www.google.com, www.yahoo.com), all three return
> >different A records depending on which source IP address requests the
> Which is of course stupid because the IP address making the lookup is
> almost certainly not the IP address of the end client. So they're
> "optimising" for some recursive resolver rather than the end user's
> stub resolver that made the initial query.
While I've no love lost for the target for this, I see the larger
fault being in this [and other] opaque 'optimizations' rather than
the synthesis per-se. That's why I'm really suprised that I only
see customer-driven synthesis from actual multi-provider (cdn, cloud,
etc) end-to-end data from one entity [cedexis].
> BTW, I still don't understand why CDNs are abusing the DNS to solve
> something that is actually a routing problem. What's wrong with
> anycasting the IP address(es) of the web site or whatever? That way,
> the network figures out the truly optimal path (peering policies
> aside) between the end client and the content provider's server. Yes,
> I realise this may break TCP connections sometimes, but how much of a
> real problem is this? Has anyone got hard data about this?
I think there might be interesting v6 anycast-negotiate-to-regional-
connection-based address approaches, but haven't thought it through
for the simple cases let alone the inter-AS handling.
RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
More information about the dns-operations