[dns-operations] dns-operationsopting in to stupid DNS tricks

Wes Hardaker wjhns1 at hardakers.net
Mon Feb 21 15:59:51 UTC 2011


>>>>> On Mon, 21 Feb 2011 11:23:42 +0000, Jim Reid <jim at rfc1035.com> said:

JR> 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.

JR> Which is of course stupid because the IP address making the lookup is
JR> almost certainly not the IP address of the end client. So they're
JR> "optimising" for some recursive resolver rather than the end user's
JR> stub resolver that made the initial query.

Oh, they do much worse things that simply changing stuff based on where
you came from.  I actually recently wrote a whole blog entry
(http://bit.ly/i5UGoA) on how they they're breaking things with the way
they're (not) doing IPv6 deployment.  The blog entry documents how you
can get bind to return a SERVFAIL for certain facebook queries [note:
they seem change *how* they break things regularly and I haven't checked
the previously seen behaviors again recently]

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

It's obvious to me that there are a large number of institutions that
will likely not be deploying secure DNS to within their zones because it
won't let them intentionally break things any longer, be it DNS
balancing or IPv6-hackery or ...  What we need to do is give them or
teach them how to use different tools to accomplish their goals.

JR> What's wrong with anycasting the IP address(es) of the web site or
JR> whatever? That way, the network figures out the truly optimal path
JR> (peering policies aside) between the end client and the content
JR> provider's server.

I think anycast scares some places because it gives control over what's
actually happening to the network.  They'd rather do
questionably-good-things because they can control the results.

-- 
Wes Hardaker
Cobham Analytic Solutions



More information about the dns-operations mailing list