[dns-operations] opting in to stupid DNS tricks

Joe Provo 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,
but:

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 
> >hostname.
> 
> 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.
[snip]

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.

Cheers,

Joe

-- 
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE



More information about the dns-operations mailing list