Slashdot Mirror
Misconfigured Open DNS Resolvers Key To Massive DDoS Attacks
msm1267 writes with an excerpt From Threat Post: "While the big traffic numbers and the spat between Spamhaus and illicit webhost Cyberbunker are grabbing big headlines, the underlying and percolating issue at play here has to do with the open DNS resolvers being used to DDoS the spam-fighters from Switzerland. Open resolvers do not authenticate a packet-sender's IP address before a DNS reply is sent back. Therefore, an attacker that is able to spoof a victim's IP address can have a DNS request bombard the victim with a 100-to-1 ratio of traffic coming back to them versus what was requested. DNS amplification attacks such as these have been used lately by hacktivists, extortionists and blacklisted webhosts to great success."
Running an open DNS resolver isn't itself always a problem, but it looks like people are enabling neither source address verification nor rate limiting.
In before the fight between those two guys and their walls of text...
Running an open DNS resolver isn't itself always a problem, but it looks like people are enabling neither source address verification nor rate limiting.
One has to wonder if this is caused by negligence, or if it's more a case of "oopsie, we left this door open, oh well" - which would be a great way to set up nodes around the 'net specifically to allow these types of attacks to occur.
Not saying that is right or wrong - asking a genuine question.
Peace,
Andy.
Why are they not sending out emails to the people running these things.
Check which domains these servers are authoritative for and send them a damn email.
It claims that the problem is DNS resolvers that don't authenticate the sender's IP address using BCP38. It is comparing chalk and cheese. Filtering out spoofed IP addresses is something that needs to happen at the edge of the network. It's not something that a single server on the network can do.
I see that the Open Resolver Project has a tool to scan for offending servers in your IP space, but it doesn't explain what the results indicate. I'm guessing that an RCODE value of 0 means you're not part of the problem?
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
I know Its not the primary topic here,, but gizmodo has some evidence that the whole cyberbunker thing is a fake
http://gizmodo.com/5992652/that-internet-war-apocalypse-is-a-lie
If an experiment works, something has gone wrong.
Have the SWAT team bust down their door and hall their asses to jail. Seriously, this is rediculous. Hacking into someone elses servers is a sevre crime the last time I looked and there is ample evidence from OpenDNS who does not even have to file charges.
Otherwise you are showing the Russian Mobfia and others they are not accountable to their actions and can do whatever the hell they want. I wish more arrests would be made. Shutting down and arresting cyberpunk officers would be a great start. After all they got KimDotCom and he didn't do damage. I have noticed youtube is barely working with syncing issues and I am on fios which is no doubt related as Google admits they trying to absorb the punch so the internet doesn't get knocked out
http://saveie6.com/
Maybe this is over my head. But how would one rung a "safe" DNS server then? My interpretation of the article basically says to let only specific people use your DNS server, but then how would a company run a public resolver?
For example, Google runs open public name servers on 8.8.8.8 and 8.8.4.4, same with OpenDNS, and many, many more. What is to stop those servers from being used in this sort of attack? Is this article really advocating a situation where you MUST use only your own ISP's resolver and trust them not to do what so many of them consistently do and mess with the results?
Or am I completely missing the point to this article?
than the users that get their computers infected with botnets and spew spam. These people are supposed to know what they're doing.
Take away their Geek Card, and then suspend their internet license ;)
I work for the Department of Redundancy Department.
http://www.theregister.co.uk/2013/03/28/spamhaus_mega_ddos_little_collateral_damage/
Maybe this is over my head. But how would one rung a "safe" DNS server then? My interpretation of the article basically says to let only specific people use your DNS server, but then how would a company run a public resolver?
For example, Google runs open public name servers on 8.8.8.8 and 8.8.4.4, same with OpenDNS, and many, many more. What is to stop those servers from being used in this sort of attack? Is this article really advocating a situation where you MUST use only your own ISP's resolver and trust them not to do what so many of them consistently do and mess with the results?
Or am I completely missing the point to this article?
Two different things. If you are running a DNS server yourself, for your own domain then you should only respond to requests for your domain from the outside. IE - Non-recursive. The only answers you serve are for those queries you are authoritative for. You only accept recursive queries from inside your own network. Those are the recursive ones.
Public servers would use rate-limiting to to protect against being effective in spoofed attacks.
DNS resolvers were originally intended to be open. There was no reason for them not to be. But furthermore, the recursive functionality of DNS made open resolvers a near requirement. This has changed a little and slowly over the years, but it's still largely the case.
Now compound the above with the fact that neither of the two most widely used DNS servers on the planet, BIND and MicrosoftDNS(That's right Bernstein fans so STFU.), check requesting source address validity. It's not in the spec, so why should they?
This attack suggests that the spec needs refinement, but don;t go blaming people for doing what has been accepted best practice for the past 20 years or more.
Or am I completely missing the point to this article?
Yes.
It's talking about spoofed requests - much like if someone sent a request for more information to a Scientology center, and they put your return address on the form. Suddenly you're getting very creepy mail from the Scientologists and you have no idea where it came from. If they do it enough times to enough organizations, and your mailbox is full, and your Netflix Blu-ray of Tootsie is deferred until you can clean out your mailbox.
The problem is that almost no one actually needs to run a public resolver.
Your ISP provides a DNS server to you that is recursive (usually), so they can use ACLs to make sure only their clients are using them.
Domain owners provide DNS servers that are authoritative, but only for their own domain, so it limits the scope of the problem as well.
The problem is when domain owners provide DNS servers authoritative for their domain, but -also- allowing other people to use them as public recursive servers. There's usually no reason for this other than the server administrator's competence.
There are legit uses for open recursors, you mention Google DNS and OpenDNS as an example. These guys have to use rate limiting and defeat the attacks themselves, there's no easy solution.
The kind of traffic it generated could practically disconnect entire countries from internet, and is still open to whatever with the right resources to use it, What kind of measures can be taken to prevent it? To have as DNS mirrors several with really big bandwidth?
Two other different things...
1) ISPs could drop out-going tcp and udp packets on port 53 from all their IP address except their own DNS servers. That would stop their customers from using public DNS server outside their networks. But it would also stop this kind of attack.
2) Drop all outgoing traffic that has a spoofed source IP address. This is a very simple bit mask operation. Yes, it requires more compute power than not doing it, but not very much. The ISPs know what IP addresses they own, they can very easily prevent spoofed traffic from leaving their networks, effectively stopping this kind of attack, as well as other types of hacking. At the same time, it would still allow legitimate use of public DNS servers.
OpenDNS is a DNS service, whereas "open dns servers" were abused - but not at OpenDNS...
To reply myself... no it can't, it's non..recursive..
Um, not exactly... You an have an authoritative non-recursive DNS server that gives large responses to questions used in an amplification attack...
'dig a www.authoritative.domain @authortative.domain.ip'
RESPONSE = 1000+ bytes follows...
Sure it could. If it is (mis)configured to allow a zone transfer, you could have a bot net send it zone transfer requests for your own domain with the source ip address spoofed to be your target. A little more complex setup than a recursive request, but you still some get good amplification. Do that on thousands or millions of DNS servers that aren't recursive, but allow zone transfers, and you still get a DDOS attack with very little input traffic. You could also do it on root servers (or any recursive server) by asking for MX records on a domain that has a bunch of MX records, like big ISPs. Not as much amplification as a zone transfer, but still some.
So really the only way to stop it is for ISPs to just stop traffic with spoofed source addresses from leaving their networks.
#2 is the right answer, be responsible for the traffic on your network.
#1 is the wrong answer. Too many ISPs fuck with DNS by returning IP addresses to advertizing domains instead of NXDOMAIN.
Why not? sure, it would be more difficult as each request would have to be tailored to the DNS server it's using, but the same principle should apply, spoof the source address, request information (in this case something within the domain being hosted) and let the larger reply go to the spoofed (victim's) address.
The only thing preventing this is that it's more work than the easier current method of being able to send the same request to every name server, but there's no reason it couldn't still be done.
1) would be REALLY bad, and I hate anyone who would even consider such a solution.
2) I can't imagine why every ISP and transit provider doesn't already do this. This has been a known problem for over a decade, deal with it already!
You're confirming that I understood the article perfectly. The problem is in their choice of solution.
It seems there are 2 possible solutions.
1) get ISPs and transit providers to actually start blocking IP spoofing (something they all should have been doing years ago)
2) break the internet by banning all public resolvers.
Unfortunately the article seems to me to be advocating for number 2, which would harm many people, and just cause the attackers to continue to use IP spoofing on different services or protocols.
Fix number 1 and you fix a lot. implement number 2, and you delay the issue by a few days while the attackers work around it.
It could, but only if they knew what domain your server was authoritative for when they picked your DNS server at random.
Your server would also have to be able to cough up a pretty big response to make it worthwhile.
If I have been able to see further than others, it is because I bought a pair of binoculars.
You simply configure your DNS server properly, including setting the networks it's allowed to resolve for. A nameserver can be both authoritative for certain domains globally, and also be recursive for specific hosts.
Of course, there's also the problem of DNS amplification using source address spoofing by requesting authoritative DNS records, but simply doing the above greatly mitigates the effectiveness of the attack.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Also, one has to wonder if it's negligence by the person installing the resolver, or by the person distributing the resolver.
What are the default values for source address verification and rate limiting? If having them both disabled is a problem, at least ONE of them should be on by default, requiring it to be explicitly DISabled by the user, and the config file should have a warning about WHY it's on/even there.
If the default configuration is vulnerable you can't expect a whole user population to ALL figure out ALL the fine details and tweak the configuration into safety the FIRST TIME and EVERY TIME. It should be safe (if crippled) out of the box and a warning obvious during the process of changing it to be less safe.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
That was an internal dispute between the Allied Southern APK Schism and the Second Western APK Heresy. It was a private matter but unfortunately tempers reached a boiling point and things spilled over into public view. The New Central APK Orthodoxy stepped in a few days later & now everybody's back on civil terms. Don't post shit when you don't know a damn thing about APK culture and governmental structure.
Sure it could. If it is (mis)configured to allow a zone transfer, you could have a bot net send it zone transfer requests for your own domain with the source ip address spoofed to be your target. A little more complex setup than a recursive request, but you still some get good amplification.
You're less likely to do this by accident. Besides, a spoofed zone transfer will almost always fail on the TCP three-way handshake step.
Two other different things...
1) ISPs could drop out-going tcp and udp packets on port 53 from all their IP address except their own DNS servers. That would stop their customers from using public DNS server outside their networks. But it would also stop this kind of attack.
It would also have a high collateral cost: diagnosing many DNS issues becomes impossible when you can only work with one recursive resolver (which may be what is causing the DNS issues!) It is necessary to access legitimate open resolvers and authoritative servers on any kind of Internet connection, even residential broadband (don't think of grandma but think of the tech helping grandma).
In short, we *need* TCP and UDP port 53 traffic unfiltered.
2) Drop all outgoing traffic that has a spoofed source IP address. This is a very simple bit mask operation. Yes, it requires more compute power than not doing it, but not very much. The ISPs know what IP addresses they own, they can very easily prevent spoofed traffic from leaving their networks, effectively stopping this kind of attack, as well as other types of hacking. At the same time, it would still allow legitimate use of public DNS servers.
This is what we need more of. Provided, of course, that it isn't applied in situations where it breaks things, but in those cases the customer is hopefully smart enough to implement their own filtering.
And of course with this "feature" it will never support DNSSEC ever.
Let's say I want to run a public DNS recursive server, that is, I want to allow anyone to issue a handful of queries for any arbitrary DNS records, and in addition to just serving up my own, I want to also service requests for whatever arbitrary thing they requested. Is there an easy way to rate limit these queries based on source IP address, to prevent abuse of this service I've chosen to offer?
How should one set that up?
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
The statement that implied DNS servers can implement this is bunk. However BCP38 is the fix. The attack would have been impossible without spoofed IP source addresses.
An application/reflection denial of service attack is actually possible with SNMP and several other protocols. Even if all of the DNS servers were closed this attack could happen.
I would love to implement DNSSEC for MaraDNS, but, again, it's a case of TANSTAAFL: http://maradns.org/products.html
MaraDNS is an open-source DNS server.
For sake of argument assume you are able to snap your fingers and miraculously all open resolvers have been locked down. What has been accomplished?
Will anyone still be able to issue legitimate DNS queries using forged source address with impunity for which response is several times larger than request? YES.
Will DNSSEC with egregiously enormous amplification when configured entire as recommended simply go away? A man can dream. I doubt this will come to fruition.
The way I see it there are two solutions to this problem. BOTH need to be implemented.
1. Ingres filtering (AKA tools.ietf.org/html/bcp38) as TFA and many others here point out needs to be implemented with enough specificity to meaningfully raise the bar for successful source address spoofing.
2. All UDP protocols allowing amplification or resource exhaustion from spoofed source addresses need to be beaten with a clue stick for making the Internet worse than need be. There is NO EXCUSE.
It does not need to be perfect it only needs to not suck more than the underlying network.
We know how to do this. There are production protocols which get it right. The answer is stateless cookies. It might require an extra round trip once in a blue moon or a few extra CPU cycles to calculate HMACs... we can easily afford it.
In return we get UDP protocols at least as trustworthy as underlying transport. Protocols which can no longer be turned into weapons of mass deluge.
For DNS we have had reasonable solutions for years...yet we sit on our hands and nothing gets done...
http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03
This can easily be phased in conjunction with DNS query rate limiting applicable for requests without cookies.
It seems to me all the money and political interest follow fools errands like DNSSEC which paradoxically makes the Internet we actually have right now less safe from denial of service.
Maybe this is over my head. But how would one rung a "safe" DNS server then? My interpretation of the article basically says to let only specific people use your DNS server, but then how would a company run a public resolver?
The problem is one of degree. The theory is if you don't offer a recursive resolver to the public amount of amplified output you get for your input is diminished over running a resolver that would respond to just whatever your authoratitive for.
Personally I don't buy much into this theory. There are enough ways to request an earfull from enough properly configured servers we can find much more effective things to be doing with our Internet fixing time.
Same here, we got a call from the hosting company just last week about a huge bandwidth use. Luckily I heard about these style attacks before, so once I noticed them I knew how to stop them. Somewhere out there is a DDoS now with 20 MB/s less. Just our $0.02 I guess.
MaraDNS 1 and Deadwood do not support a technology called "EDNS" that allows for large DNS packets
Sounds like a side effect of a deficiency (read: less than complete DNS protocol support); lack of EDNS support is a potential problem, as it impacts IPv6+DNSSEC, where large legitimate responses may be more frequent. DNSSEC support is critical, as is the ability to resolve such zones without falling back to TCP.
BIND has max-udp-size and edns-udp-size parameters. As do other DNS resolvers.
One feature that would be nice would be to be able to restrict how much data my DNS server sends to a given IP
On authoritative DNS server implementations, perhaps. DNS resolvers should not be usable by the world.
Any DNS server that provides recursive DNS ought to not simultaneously provide authoritative DNS from the same service, or from the same IP.
Unfortunately, since I am not developing new features for MaraDNS like this without being compensated for my time, I would need a corporate or government grant to implement this.
So you would put forward a DNS server that doesn't actually provide complete DNS functionality, and is no longer being developed?
I fully expect any government or corporate grants will go towards DNS server implementations that are more widely used, already under development, and fully featured, towards research and development of new advanced experimental options or capabilities, that require substantially large development efforts.
Because spending grant dollars to help a competing implementation get up to speed with the slew of other competing implementations, sounds like a potential waste, when, instead research dollars could be more efficiently spent on upgrading BIND or PowerDNS, or whatever. :)
(Because corporations are more likely to be already using, and want additional functionality on existing DNS server implementations that are popular and best fit their needs, other than the special features they want developed.)
So, not to discount MaraDNS, but it seems like a dead-end, in regards to support for protocol functionality that are becoming more and more critical month by month...
It's not corrupt, the moderation system is working as intended. :)
It's not an attempt if it was done. :)
I do not believe that is a goal of his, but rather a side effect of his campaign against the super power known as APK. :)
Woha, you just mentioned using something other than hosts files, you are clearly an imposter. :O
Change is certain; progress is not obligatory.
Actually, transit providers are one of the groups that can't reliably apply BCP38 or RPF. BCP38 and RPF is very easily applied at the edge, where you know specifically the IPs involved, since they're either connected or statically routed. Now, when you get into things over BGP, it gets dicey. You may see traffic over a BGP-managed link from an IP that isn't involved in the received prefixes, but yet still belong to the specific peer. Is this an error? No. Is dropping the bits on the floor because you're not seeing that prefix an error? Most definitely. Not announcing a prefix over a link is a common traffic engineering practice, so this isn't an uncommon scenario. Another option to work around that would be to have a prefix-list with all of that peer's possible prefixes and build an ACL off that, but that's also not always tenable when you're potentially dealing with 1,000s or 10s of 1,000s of prefixes for the larger networks. Nice thing is, at this level, usually you can bust out the sFlow/NetFlow-fu and find out where the spoof is coming in from, and then whack it at that point.
But looking at the OpenResolver project list, when broken out by ASN, it really looks like a huge amount of those open recursors are CPE gear with WAN-facing DNS services, just based on the ASNs. China Telecom (AS4134), Uninet (AS8151) and Turk Telecom (AS9121) accounted for 3.5 million (15%) of the recursors alone.
TL;DR The grandparent complained about MaraDNS not having more features. He responded to my "show me the money" reply by saying "why should anyone pay you if you don't have more features". My reply: "Because DNS shouldn't be a monoculture".
(As an aside, I actually somewhat respect the parent poster because he does a reasonable job of articulating his points. His thinking is a little rigid and absolute "this is how it must be done" for my tastes, but he at least has clue, something becoming rarer and rarer as Slashdot slowly goes the way of the horse and buggy)
Another thing I forgot to add: Why use MaraDNS.
Since I have Karma to burn, and since it probably would be best if my Karma went to hell, discouraging me from wasting time on Slashdot, here's my thoughts on the negative moderations:
Sure, the first post came off as an ad. I wrote it too quickly, and I can see why a moderator didn't like it. I can also see why a moderator--perhaps the same one--didn't like the parent to this. A good number of Slashdot readers still live in that "everything should be free and no one has bills to pay since they all live in my mother's basement [1] like I do" neckbeard fantasyland probably don't like how I pointed out that it's going to take real money for MaraDNS to get DNSSEC or have rate limiting. They probably stopped there and moderated down (the post was also too long, but a long post deserves a long reply).
[1] In other cultures, multiple generations living under the same roof is normal; I feel the idea that a kid has to move out of the house at 18 to be a real man is one that is bad for families. It's actually in many ways good when a 45-year-old man still lives in his mother's basement, since he will become the one taking care of his aging mother instead of sending her to a nursing home.
OK, I'm out of Slashdot for the rest of 2013. I will not post here until the beginning of 2014. The moderators hath spoken and I really need to get out of the shithole Slashdot is becoming. MaraDNS is the past; it's time for me to make a new mark on the world!
MaraDNS is an open-source DNS server.
You're compounding two things. One is providing RECURSIVE RESOLUTION to clients and the other is providing an AUTHORITATIVE NAMESERVICE for particular zones. I'll explain the two briefly:
1. Recursive resolver - this is a nameserver that you can ask to resolve any domain name and it'll do just that. If it isn't authoritative for it (meaning you RUN the zone and it's in a config file locally) it will go through the recursive resolution process for you. It will look at it's root hints, talk to the root name servers, find the TLD zone, ask for the next nameserver to ask and on down the chain. This is "recursive resolution" it's how clients find things on the internet. This is the dangerous thing and what you want to secure. You can do this in BIND for example by writing a bind ACL and only allowing recursion to clients you trust, typically the RFC 1918 address space (aka "private IP addresses").
2. Authoritative Nameserver - this is what you put on the internet if you want to run your own nameservice for your domains. This will only answer questions to clients about domains that it runs specifically. So if you own abc.com and a client asks about www.abc.com it will provide the answer. If you ask it to resolve google.com it will kindly tell you to fuck off (or possibly provide root hints, by an old convention).
Actaully, I wasn't confusing the 2 at all. But I don't think that we should be banning public resolvers and forcing people to use the resolver operated by their ISP when those resolvers have frequently been messed with for profit by the companies running them. The article would propose killing OpenDNS, Google DNS, and many, many more.
The correct solution is not to break the internet by banning a harmless and very useful feature, but to fix the internet by blocking IP spoofing. Why on earth are there any ISPs out there that still allow spoofed traffic off their network? this is not a new issue, and should have been fixed ages ago.
DNS used to not be a threat; that's been changing. Rate limiting wasn't an issue. Source address verification was a problem for ISP routers (to prevent address spoofing), but it wasn't a problem for recursive DNS servers (who were willing to serve anybody, not just their own customers), and it especially wasn't a problem for authoritative DNS servers, because they're supposed to tell anybody the address for www.yourdomain.com, and aren't in the right part of the network to verify whether a UDP DNS request came from a forged address (that's an edge problem, not a center problem.)
Unfortunately, it's easy to have DNS configurations where a response is larger than the query (sometimes even a lot larger.) The emerging standards have been to require TCP if the responses don't fit in a single UDP packet, but not everybody supports it (and since not all clients support it, servers can't always enforce it), but even then there's a sweet spot where you can still send a request that's under 100 bytes and get up to 576 bytes of response (or sometimes even 1500), depending on what records the DNS server is configured for.
And rate limiting is a server software feature, but record sizes available for querying are very much a user data issue.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
An ISP can filter out spoofed UDP packets just as easily as spoofed TCP packets - the filtering happens at the IP layer in the router, not at the transport or application layer. Unfortunately, as another Anonymous Coward points out, it has to be done at/near the ISP where the spoofed packets originated, and that ISP may be spammer-friendly and have an upstream that's not enforcing anti-spam policies or using strict-mode uRPF (because that's something that normally you don't do except on leaf nodes.)
An authoritative DNS server can't do much about spoofing except rate-limit and try to keep response sizes small, but a recursive DNS server can do more than that. If you're an ISP providing DNS resolution for your customers, and you filter it so you ONLY accept requests from your customers' addresses, somebody can still use your DNS server to spoof attacks against your customers, but can't use it to attack people who aren't your customers. It's a good start.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
If you read my later posts in this thread, you'll see that I agree that source address filtering should be our #1 concern.
With that said, there are ways to provide recursive DNS resolution to clients openly, but without being used as an attack vector. Specifically by rate limiting the requests.
The reason ISPs are allowing spoofed traffic is simply one of two things: ignorance or laziness. It's very easy to write an ACL that mirrors your BGP announcements then apply that as an outbound filter at your peering points. It's absolutely as trivial as it sounds. The Tier 1 carriers need to start de-peering anyone who's found to not filter traffic they're not announcing.
Sure, all ISPs ought to be following BCP38 and blocking spoofed-source packets, and at $DAYJOB we've been doing it since the mid 90s, but for some reason spammer-friendly ISPs don't do that. And you can't properly run strict-mode uRPF except on single-homed customers.
But there are two kinds of DNS servers - authoritative, and recursive. Authoritative servers are the ones that domain name owners use to resolve queries about their own domains, and they're supposed to reply to everybody who asks. They can do things like rate-limiting responses, and trying to configure their data so that small queries only get large responses over TCP, not UDP, which makes spoofing much much harder, but that does require careful administration.
Recursive DNS servers are the ones that ISPs, Enterprises, and sometimes even individuals use so that end users can send one query for www.foo.bar.com and have somebody else do the work of querying the different servers that handle the root, .com, bar.com, foo.bar.com, and www.foo.bar.com, and ideally keep a cache so that most of those names are remembered locally instead of needing queries. An "Open Recursive DNS server" will accept recursive queries from anybody, but you really don't have to do that - you can limit your servers to accepting queries from your own users. That doesn't prevent somebody from using spoofed UDP DNS requests to attack your users, but it does prevent them from using your DNS server to do spoofed attacks against people who aren't your users, keeping the internet safer for everybody.
There are businesses who have good reasons for running open DNS servers - half the machines in my lab are configured to use Google's 8.8.8.8 because it's an easy-to-remember number and because different parts of my lab aren't always connected in ways that let them reach my corporate DNS servers. I don't know the architecture of Google's DNS servers, but my guess is that they've got lots of servers deployed over anycast, and that they've probably done their own anti-spoofing so they'll only send out replies over the connections the requests came from.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
How is an accidental public resolver an issue if IP spoofing is impossible?
Unfortunately many common DNS packages do not include rate limiting options. I wouldn't blame this on the admins running those machines as much as on the package maintainers who don't seem to think that's an important feature.
I don't believe this should be handled by the DNS software. We shouldn't have to add rate-limiting code into every individual service we run. It's easily implemented using a firewall. Even iptables (software firewall) supports rate limiting:
http://wiki.opennicproject.org/IPTablesRulesToBlockDDOSTraffic
http://falkhusemann.de/blog/2012/07/iptables-dns-query-limiting-with-burst-rate/