udpheaders

Well, I could prove it to you. Side by side speed test.

As for reliability, if you lose access to your "professioinally-configured endpoint" you're SOL. You can't do lookups (assuming you don't know how to do them by hand). Meanwhile I'm unaffected.

I would not have done this for myself and tell you about it if it wasn't faster. I'm not gathering info on users or selling anything. I'm not telling you what to do proclaiming I'm an "expert". I'm just an end user, like you.

When you use an open resolver, you are sharing a cache with everyone else who uses it. Some might do nefarious things to the cache.

When you use a resolver listening on 127.0.0.1 you are sharing it with whoever can access localhost on that port. i.e., no one (hopefully)

"professionally-configured" C'mon. You sound like a marketer's dream. Be a hobbyist. Be a hacker. Experiment. Thinks for yourself. Or don't.

This is a frustrating problem. Not only with Linux (which I'd argue has some of the best support of any open src OS).

The only solution I've come up with is to steer away from hardware that is brand new on the market. Buy stuff that is a few years old.

With an open source OS, it's still going to as fast (probably faster, and certainly more agile) than new hardware coming fresh off the assembly line loaded down with the latest crapware OS.

I did re-read it.

But where's the proof they used DNS? Upload a packet capture and let us be the judge.

Only if it's not already in your cache or in /etc/hosts

You can put hosts file on RAM disk.

With some servers it's also possible to save and reload caches.

Assuming you're not doing hundreds of thousands of new lookups (sites you've never visited before) every day, it's very easy to configure a system for yourself that is faster than any open resolver.

There is one trade-off: if sites switch IP's without telling their users (preferring instead to wait for ttl's in open caches to expire) then for those sites that like to hop from IP to another unexpectedly, you need to monitor for this. This is rare though, and you can try to safeguard against it by "pinging" less oft visited sites periodically, but it does happen occasionally.

Like when software used to come in a box. That packaging was like some sort of tether to the world of physical goods.

You might be going a little strong on the FUD thing though. I think many businesses are tapping into open source and what can be built with it, especially your beloved Linux kernel. Even going so far as companies like Wal-Mart opening an office in Silicon Valley and launching startups. Whether this is all good or bad I can't yet tell. Just as our inclinations are toward physical goods that come in attractive packaging, we have inclinations to try to make all aspects of a business proprietary and confidential with the belief it gives a competitive advantage.

It just feels strange to try to sell something that was never meant ot be commercial and price it high in order to create some illusion in the mind of a purchaser. But maybe that's just me.

But I'm not using any of those. (I have used all of them though [OSX, Windows, Linux] so I know what they're like.) Nice try. :)

As I said I feel terrible saying this about proprietary software. I've worked for companies that sell commercial software. But I'm just being honest. The open source stuff is the best I've used.

Next week: Economic Growth Doesn't Lead to ________, a New 65-Year Study Finds

Fill in the blank.

Do people want "economic growth" or whatever that might be assumed to lead to, or do they just not want to donate money to their country through their government?

One is kind of indirect and speculative, the other is direct and immediate.

I honestly can't think of one proprietray program I've paid for (and I have bought some expensive software) that exceeds the quality or reliability of the free, open source programs I use.

Sometimes I feel like I've been duped by every vendor I've paid for software. It sounds terrible to say that, but honestly the open source stuff just blows the commercial stuff away. Alas, open source is just not possible for all software needs; it only covers so much.

Thanks.

http://tools.ietf.org/html/rfc4732

"If builders constructed buildings the way software developers write software, the first woodpecker to come along would cause the collapse of civilzation."

The real solution is not to use open resolvers and open caches, full stop. Run your own cache on localhost. djb has always advised against third party DNS, but people don't listen. I've even caught the author of the DNS/BIND book admitting it's a smart idea. Moreover you'll be immune from DNS poisoning.

Yet another reason DNSSEC is more trouble than it's worth.

It's a gift to anyone wanting to do this type of DDOS.

Right. As the top post also points out. There's no way to distinguish incoming UDP traffic as "spoofed".

My question is does anyone filter UDP egress based on source IP? Is there guidance somewhere that tells admins to do this?

Let me put it another way: If it was a workable solution to get admins to do this - to filter outgoing UDP based on source IP, then why are people trying to get network admins to change their DNS server settings as a way to reduce the possibility of DNS-based DDOS? That seems like a far more difficult task given that there hundreds of thousands of open resolvers and most admins understand working with firewall rulesets better than DNS configuration.

So you are saying it is common practice to block outgoing UDP packets based on source IP? I did not know this. Does your ISP do that? Everyone is expected to block ingress with spoofed IP. But I can't find an BCP for blocking UDP egress based on source IP. Does it exist?

As for the rest the comment, this appears to be an "informational advertising" style marketing piece for Cloudflare so I think it's relevant.

Re-read the blog post. He's speculating the attack used DNS. (Though he has no proof.) In that case, with UDP, spoofed headers are allowed out. Connectionless.

Cloudflare uses anycast DNS - machines in different geographically located data centers all sharing the same IP. If you want to try to make your site DOS-proof (and potentially faster), one way is to move the site to the network edge. Move the data closer to the user. Put a copy on a machine in the data center nearest the user. Do this in data centers around the world. ("CDN") Give all the machines the same IP. ("Anycast") Your users will be accessing a mirrored copy of your site at some regional data center, instead of actually sending requests that go out to the internet. Does Google do this? Akamai? Netflix?

Next time you access a popular website ask yourself "Am I actually accessing the internet? Or am I just downloading a copy of something from a local data center?"

A lot of these services are just marketing. In theory they sound great, but things may be different in practice. And that's why we frequently see comments that things did not work as expected.

I did some CDN experiments downloading pages using Akamai where I accessed content on the "true IP address" (the master copy so to speak) versus the regional IP address they provide through stupid DNS tricks. Guess which one was faster?

It all depends on caching: what is in the cache and what isn't. Same applies to DNS. A DNS caching server (resolver) is only faster than non-caching DNS server (authoritative) if it's primed with the records you're after. If they are not in the cache, it will not be faster. In fact, it will be slower because there are more steps to the process.

These strategies are often based on 80/20, power law thinking. If you are not in the 20 percent of content being accessed 80 percent of the time, then you do not see the benefits. If no one in your region has requested a given page, and you're the first, it will be slower to wait for it to be cached at your regional data center than if you just grabbed it from the internet.