Forgot your password?
typodupeerror
Linux

+ - Nominations for the 2011 SysAdmin Awards->

Submitted by
davidu
davidu writes "We SysAdmins never get the love. We often save the day and because we do, nobody notices or even knows what we did.

That's why July is SysAdmin Appreciation Month and nominations for the 2011 SysAdmin Awards end on July 12th. Nominate yourself, or your favorite SysAdmin hero to receive recognition and an award."

Link to Original Source

Comment: Re:This is not accurate (Score 1) 187

by davidu (#32440100) Attached to: How CDNs and Alternative DNS Services Combine For Higher Latency

He titled his blog post "In a CDN'd world, OpenDNS is the enemy!" not "Using third-party DNS resolvers can in some cases cause suboptimal server targeting."

I thought my response and followups were fairly even-keeled all things considered but appreciate the feedback. I have no ill will to the author and welcome his further tests.

Comment: Re:This is not accurate (Score 1) 187

by davidu (#32392622) Attached to: How CDNs and Alternative DNS Services Combine For Higher Latency
What you're suggesting is really just another way of saying a "Man in the middle" attack. IE, someone in transit can copy, inspect or re-route your packets and do bad stuff. That always exists when using insecure channels, and is a different concern. DNS will never eliminate that concern actually. Even with DNSSEC. End to end dynamic ad-hoc encryption would, but that's a pipe dream. :-)

Comment: Re:This is not accurate (Score 2, Insightful) 187

by davidu (#32390920) Attached to: How CDNs and Alternative DNS Services Combine For Higher Latency

Well the critics argue that the Internet != The WWW. Which is true. If you are sending email, the destination SMTP server, and it's corresponding authoritative DNS server would never normally see the client's original IP. The fact that TONS of benefits exist from routing and performance to anti-spam measures would benefit from this, we're creating a vector of privacy leakage that possibly didn't previously exist in all scenarios.

None of this considers the fact that very few DNS operators would actually even implement this standard. Just big 3rd party resolvers like us and Google and big CDNs and eye-ball sites.

Comment: Re:This is not accurate (Score 2, Interesting) 187

by davidu (#32390900) Attached to: How CDNs and Alternative DNS Services Combine For Higher Latency

You have summarized the privacy concern well. That's exactly the issue. The fear that is held is that implementations won't respect someone who includes 0.0.0.0/0 and instead will replace it with the actual client's source_addr when forwarding a request along. Think hotel, cafe, wifi hotspot vendors, etc... Those folks tend to implement for ease, not privacy. And sometimes they opt against privacy.

The critics of the proposal think that there is no assurance of privacy, and they feel that's a reason to not move forward. In my world, there are much better ways to violate real privacy than to see a client IP address in a DNS request, but maybe I'm less sensitive about it. I think it's certainly worthy of discussion and attempting to find a solution.

Comment: Re:This is not accurate (Score 4, Informative) 187

by davidu (#32389528) Attached to: How CDNs and Alternative DNS Services Combine For Higher Latency
yep! This is the exact goal of the IETF draft I linked. Unfortunately the old guard of DNS (Vixie, et al) are not supporting it because they fear it raises insurmountable privacy concerns. Most disagree since the ultimate authority will see the clients IP eventually, but that's the current hold up. Not sure if it can be resolved to everyone's satisfaction. :-(

Comment: This is not accurate (Score 5, Informative) 187

by davidu (#32389146) Attached to: How CDNs and Alternative DNS Services Combine For Higher Latency

I'm the founder of OpenDNS (and long-time slashdot reader).

This article is not very accurate for a number of reasons. First, both my service (OpenDNS) and Google's are co-located in similar POPs to all of the major CDNs which causes this problem to be largely avoided. The author of the blog post used a tiny sample size and tested mainly from EC2 instances, neither of which helps his cause.

1) EC2 instances are BY DESIGN not co-located in the same place as major peering infrastructure because that real estate costs more. They are one or two hops away. People use EC2 for compute power, not for routing performance. So he needs to use something like Keynote or Gomez to test from home connections. If he had, he'd see it doesn't impact anything, and often improves performance, especially in the US. We don't have POPs in Asia yet, though they are coming this year, and when we do, we'll improve things for him.

2) Akamai is the only CDN where this will ever be perceptible because their deployments are so dense. They have 3000+ pops which means they will also be able to target more precisely. But this is being worked on RIGHT NOW in the IETF -- http://tools.ietf.org/html/draft-vandergaast-edns-client-ip-01

Anyways, this is really not the issue the author makes it out to be, and for the edge cases, they are being worked on.

Thanks,
David

The first version always gets thrown away.

Working...