[dns-operations] opting in to stupid DNS tricks

[David Miller]

On 2/21/2011 6:23 AM, 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.

The fact is that *most* users have resolvers that are "near" their 
client IP address (for some definition of "near").  There is nothing in 
the current protocol that signals to the authoritative DNS server the 
client IP address that made the request through the resolving server, so 
that information isn't available to the authoritative DNS server.

> I wonder what these DNS tricksters are going to do if/when these zones 
> deploy Secure DNS.

I don't believe this will be an issue.

>
> 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?

There is some data available:
http://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf

http://www.nanog.org/meetings/nanog34/presentations/karrenberg.pdf

http://www2.research.att.com/~slee/pubs/www09-anycast-transport.pdf

Any routing changes during the entire length of a connection that causes 
packets sent from the client to end up at a different content server 
than the one with which the client started the session will cause the 
loss of the connection unless state is synchronized across the (usually 
geographically diverse) content serving nodes.  Synchronizing connection 
state in real time is hard.

Note in the first presentation above, slide 5, bullet 4 - "State is 
accomplished with custom hardware".

How often do routing changes occur that break connections?  Often enough 
for an anycast CDN provider to develop custom hardware to address the issue.

>> Therefore, you know damned well that Akamai (and all other CDNs, 
>> large websites, and anyone else who publishes heterogeneous A 
>> records) is 100% opt-in.
>
> You must be using a different definition of opt-in. This term 
> generally means getting explicit consent beforehand. I don't remember 
> any of these CDNs ever asking me if I wanted to (not) depend on their 
> stupid DNS tricks. Anyone looking up names like the ones you mentioned 
> is of course 100% dependent on this DNS trickery. But please don't 
> imply they have opted in to it. And anyway just because lots of people 
> do something doesn't make it right or desirable. Lots of people drink 
> a US-produced liquid called Budweiser.
>

You appear to have lost the plot here.  The owners of content "opt-in" 
to how and where they want their content hosted.  The consumers of 
content "opt-in" by requesting the content or not requesting the content.

-1 on Budweiser... yuck.

> FWIW it's also very annoying (and stupid) to be presented with content 
> which the CDN thinks is relevant for the country where it believes the 
> resolving name server I've used is located rather than for the country 
> actually I'm in or the language(s) I understand. We can agree to 
> disagree about that.
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations