[dns-operations] opting in to stupid DNS tricks
Patrick W. Gilmore
patrick at ianai.net
Mon Feb 21 16:38:58 UTC 2011
On Feb 21, 2011, at 11:17 AM, Jim Reid wrote:
> On 21 Feb 2011, at 14:55, Patrick W. Gilmore wrote:
>> On Feb 21, 2011, at 6:23 AM, Jim Reid wrote:
>>> 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.
>> Just so we are clear, you are saying that if someone makes an approximation on the Internet which is good for high 90s percent of the userbase, it is 'stupid'.
> No Patrick, I'm saying the starting assumption is stupid. We violently disagree about that. Fine. My concern is where these sorts of starting assumptions end up when it comes to (future) impacts on the DNS protocol and operations.
I'm unclear on how that affects the -protocol-.
If you mean the client-IP extension, that's still a draft, not everyone has signed on. But assuming it goes through, what deleterious effects would it have? Additional qps? That's between the recursive and authoritative NSes that -pre-agree- to use the extension. You don't like it, don't support it, and nothing happens to you.
> BTW where does your "high 90s" claim come from? Has anyone measured this? How did they do it?
Yes, who would have such data? If only there were an entire industry whose business model depended on having such data, and customers who measure such things religiously for SLA violations & such.
>> If you don't like that, you don't have to use those web pages. Not sure why it bothers you that other people use those pages though.
> DNS != web. Internet != web either.
True. But how many Akamai hostnames do you resolve that are not web pages?
>>> I wonder what these DNS tricksters are going to do if/when these zones deploy Secure DNS.
>> Feel the pain everyone else feels? :)
>> Again, not really sure what that has to do with you, though.
> You're right: it's not my problem. However I would like to find out how the CDNs are going to deal with Secure DNS deployment and what instabilities (if any) that may cause. This is a variation of the NXDOMAIN rewriting that some ISPs are fond of. I wonder what problems and instabilities will arise when DNSSEC intervenes in that behaviour.
I must not be smart enough to figure out why you think this is similar to NXDOMAIN rewriting?
Remember, CDNs do not own hostnames. Our authorities are only queried when someone else CNAMEs to the CDN. At that point, the answer is 100% within the discretion of the CDN. There is no way to hijack someone else's (or no one else's) domain or hostname & give an answer pretending to be authoritative for something you are not.
Bringing DNSSEC into this, if the CDN does not support DNSSEC, that seems to me to be between the CDN & the CDN's customer.
>>> 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 can explain it to you, but I honestly believe you do not want to know.
> I do. That's why I asked. Feel free to explain it over beer the next time we meet. I might even buy some of them. Other postings on this thread provided URLs I'll be reading them shortly.
Or maybe some other thread, I think people are tired of this one. I know I am.
More information about the dns-operations