DDoS Attacks Via DNS Recursion

JehCt writes "Associated Press is running a story about how the recursion feature of open DNS servers can be used to launch massive distributed denial of service (DDoS) attacks: 'First detected late last year, the new attacks direct such massive amounts of spurious data against victim computers that even flagship technology companies could not cope.' A thread at WebmasterWorld explains, 'To make a long story short, having a DNS server that allows recursion for the Internet is like running an open SMTP relay.'"

Comments

djbdns

[Russ Nelson]

That's why you run djbdns -- by default it's closed to recursive queries.

Re:djbdns

[PaisteUser]

It's not that difficult to make BIND9 not respond to recursive queries, add "recursion no;" to the "options {};" section of the named.conf file, reload the config and your good to go.

Re:djbdns

[rob_squared]

Isn't this just anothery iteration of, "people abuse technology?"

Though if you're setting up a DNS server, you should have a fair amount of expertise on how those abuses can arise and limit the possibility.

Re:djbdns

[Anonymous Coward]

Done and done. 3 DNS servers, 3 minutes.

Re:djbdns

[Anonymous Coward]

caveat: I am admittedly not the world's greatest DNS admin. I wouldn't mind running a couple of slaves on djbdns, but fuck me skating if there's a way to transfer my DNS data over. I have roughly 200 domains I'm admin for, and about 75 class-C nets. There's no way I'm going to copy that data in by hand. djbdns' docs are mind-numbing in both obtuseness and readability and AFAIK there's no way to manage the damn thing via any sort of GUI.

Re:djbdns

[Anonymous Coward]

Yes because switching to a new dns server you know nothing about is safer then updating the config on your current setup

What you know about djbdns is that you have the code to look at and that everyone in the industry that cares about security uses it.

What you know about bind is that you have the code to look at and that everyone in the industry that cares about security avoids it.

Re:djbdns

[Russ Nelson]

Your users are going to be a little upset when they discover that their DNS server doesn't resolve anything anymore.

You see, the chief difficulty is *exactly* the same as the open smtp relay problem. Back when everybody on the Internet knew each other, and abuse was resolved with a phone call, nobody understood that some services needed to be authorized, and some needed to be public. Thus, relaying and delivery SMTP servers were the same thing, and caching and authoritative DNS servers were the same thing. The big challenge with this issue is not reconfiguring BIND 9 to not recurse. The big challenge is to split your caching from your authoritative DNS servers.

Re:djbdns

[Anonymous Coward]

Really?

Why, then, does the OpenBSD team use a hardened version of BIND whilst DJBDNS remains a bit player?

Re:djbdns

[eln]

I'm a big fan of DJB's software, and I use most of it regularly. However, if you've ever actually looked at his code, you might decide having the ability to look at his code is a negative for everyone except for maybe the ibuprofen industry.

Re:djbdns

[Russ Nelson]

It's a style of coding; sure. If you're not used to it, it can be hard to read. But he gets a bunch of things right, like checking EVERY malloc for failure. Like not merely exiting when a malloc fails, but instead exiting with a special code for temporary failure, or in the case of a daemon which cannot exit, sleeping until memory becomes available. Like making counted strings easy to use in C (null termination is the tool of the demons in charge of buffer overflows). Like making it trivially easy to avoid memory leaks. Like subtle things like str_chr always returning a usable pointer, rather than NULL sometimes and a pointer to the character other times like strchr does.

Re:djbdns

[Perl-Pusher]

I have 3 dns servers are NAT'd on the private lan and allow recursion, the public one outside doesn't. I'm not a DNS expert but I haven't had any issues from users or attacks.

Re:djbdns

[eln]

Don't get me wrong, I have a lot of respect for his techniques, and his code is rock solid. But, as you say, it can be rather cryptic.

Most people I know of that won't use his code cite things like his personality, which they generally only know by reputation. Personally, I don't give a toss about how difficult a person the developer of my software is, I just want to use good software. It's not like I'm going to be taking the guy out to dinner any time soon.

Re:djbdns

[eln]

That has more to do with DJBDNS's license than its performance. DJBDNS is not GPL, and is certainly not BSD licensed.

See here

Re:djbdns

[Russ Nelson]

Because djb refuses to let the OpenBSD folks make changes. Note that they don't actually have any changes they want to make. They argue that they must be able to make changes without negotiating with the author of the code. djb says, with good reason, that nobody writes more secure code than himself, so any patches written by somebody else would be unlikely to make the code more secure. Both parties are arguing from reasonable positions, it's just that they are incompatible positions.
Thus, BIND9 (which needs to be hardened) versus djbdns (which is shipped without security holes).

Re:djbdns

[Russ Nelson]

You have a correct configuration. You gain 2 skill points.

Re:djbdns

[Malor]

Turning recursion off is likely to result in lots of support calls from people who are dependent on your servers. A better solution is to deny queries that don't come from trusted hosts.

First, make an ACL that lists all the IP addresses for which you want to provide general DNS services. These are IP addresses you should trust... any of these can use your server as a DoS attacker.

acl internal { 127.0.0.0/8; 1.2.3.0/24; }; // we trust 1.2.3.0 not to DoS anyone

options {
                allow-query { internal; };
                [...](other options)
};

Then, in the zone definitions for the domains you want to serve to the whole internet:

zone "example.com" {
                type master;
                file "/path/to/db.example.com";
                allow-query {any;};
};

This will explicitly allow you to trust and offer name service resolution to particular entities (like, say, your home network, if you're just an Average Joe, or your netblocks, at an ISP), while explicitly refusing to talk to anyone else about any zones for which you're not authoritative.

You're still vulnerable to DNS-poisoning for non-authoritative domains from internal hosts, but at least in theory, you should be able to track those down and make life painful for the miscreant.

Re:djbdns

[starmeup]

By doing that you will resolve most of the problem.

However, with the current state of DNS servers, even if you do not do recursive resolution on your DNS server (or only do it for your IP Address space), you could be used to do a DDDoS attack.

I could send you a query for one of the domains for which you are authoritative, using a spoofed IP address, and you will respond to the victim. The "amplification effect" still works, only it can not be "custom amplified", I have to stick with whathever records you happen to have.

p.

Re:djbdns

[speculatrix]

I used to work for a company which bought one of the oldest ISPs in the UK, and inherited their venerable antique set of sparc servers.

There was a server (named after a famous London landmark), which did DNS serving and also resolving, and was open to the whole internet (which, admittedly, wasn't too big). When customers moved away, they continued to use it for resolving. When the server was finally shut down in, errm, 1999 (wasn't the Y2k bug a marvellous excuse to get rid of services noone wanted to maintain anymore?!), we sniffed the network and there were still people using it. The network block was reallocated for other purposes, and even two+ years on there were still steady numbers of DNS resolving requests.

We also had separate resolvers and name servers, and we put up big announcements for months that name servers were going to lose recursion (because reloading the servers was taking longer and longer and people complained about slow resolving), and yet there were die-hards who held out until rebutted customer complaints made them fix things. We guessed these customers, basically, had had someone set things up, the person resigned/died/was fired/kidnapped by aliens from redmon/ and they had no clue how anything worked any more.

So, yes, changing the default behaviour of DNS servers to not resolve can cause problems.

Oh yeah, one final thing. When I started work at that ISP in the mid nineties, 20-25% of customers ran windows, the rest ran some form of unix; the windows users "ate" 80%+ of support. When I left three years later the windows users were 60-70% of customers, and the number of support staff grew to accomodate the cluelessness.

Re:djbdns

[TCM]

BIND9 has a concept called views. Views are separate sets of option{}; and zone{}; scopes based on client address or destination address or even something else.

It's very easy to define an external zone without recursion and some master zones and an internal zone that recurses. This also has the benfit of split caches. If you just disabled recursion for some clients in a "single-zone" BIND, you still are "vulnerable" to information leakage where external clients can probe your cache for records.

http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch06 .html#view_statement_grammar

Re:djbdns

[PaisteUser]

Correct, they would be pissed off if I had 1 DNS server that did everything for everyone. I believe there is an RFC somewhere that reccommends splitting up the DNS servers that are public facing and internal facing. I run 3 internal DNS servers for our users, and 2 public facing for the internet. No unnecessary load on any of the DNS servers, and the firewall rules are alot easier to manage that way. The key IMHO is to treat the public zones and internal zones as 2 seperate entities. Seems to work okay for us, and no complaints from users on either end of the spectrum.

Re:djbdns

[Anonymous Coward]

> That's why you run djbdns -- by default it's closed to recursive queries.

Its also closed to proper handling of truncation and a few other minor DNS interoperability issues. Don't worry, many patches exist to cover up the shortcomings of the author's 5 year-old latest release.

Enough of the nameserver implementation baiting; the problem at heart is not whether your nameserver answers recursively or not; its whether the size of the response is bigger than the size of the query.

If your (or someone else's) authoritative zones contain a big record, a small query (eg, 'MX hotmail.com') will trigger a much larger response. If evil-doers order their zombie network to send out spoofed queries apparently from your.i.p.address to the hotmail.com nameservers, your.i.p.address will receive a flood of un-asked-for responses from the hotmail.com nameservers. The reverse will also work in using your authoritative nameservers to assist in flooding some.other.IP.address off the network. Rinse and repeat for however many authoritative nameservers/zones it takes to overload a given pipe; the evil-doers will always have more bandwidth than you.

Without the hotmail.com/your nameservers doing something special, such as rate limiting the queries, or everyone applying BCP38 to stop IP spoofing, any.i.p.address is open to this attack, irrespective of the nameserver being used at your, or hotmail's end.

Re:djbdns

[Alioth]

It's not a big challenge to configure BIND to serve recursive queries to some clients and not to others - it's just one line in the configuration file (and it's well documented).

Re:djbdns

[zenmojodaddy]

Run it? I can't even SAY it.
 
I'll make a note of it for Scrabble purposes, though.

Doctor, it hurts when I go like this

[$RANDOMLUSER]

> 'To make a long story short, having a DNS server that allows recursion for the Internet is like running an open SMTP relay.'

OK, don't do that then.

Re:Doctor, it hurts when I go like this

[mph]

No, this is: "Doctor, it hurts me when that guy over there does this..."

"Don't do that, then" is not helpful advice to the people who are suffering from this attack.

Re:Doctor, it hurts when I go like this

[jonaskoelker]

"Don't do that, then" is not helpful advice to the people who are suffering from this attack.

That's not what parent said. What he said was (depending on exactly what you mean by your analogy) "don't let him do that then" or "have the third party that lets that guy over there do that stop letting him do that then". Okay, so if it involves the third party, the attackee doesn't have much they can do to defend themselves except asking the third party to do the Right Thing, but the doctor is equally out of options.

Re:Doctor, it hurts when I go like this

[mph]

That's not what parent said.

Yes it is. He was quoting, verbatim, a classic joke in which a patient keeps hurting himself. There is no third party in the joke, so it does not make sense to apply it to this situation.

Recursion == recursion == recursion == ...

[bcat24]

recursion: n.

    See recursion. See also tail recursion.

From the Jargon File.

Could someone explain how the attack works?

[defile]

From what I understand of DNS resolvers, this attack can't work unless there's another compromise at play here. Either a compromise of one of the victim host's zones, or a compromise of the servers hosting the open resolvers themselves.

Re:Could someone explain how the attack works?

[Anonymous Coward]

No compromise needed. You just send requests to the DNS server spoofing yourself as the victim's IP. (UDP is much easier to spoof, and can be sent out very quickly.) The replies, which are some 30 times larger than the requests, get sent to the spoofed IP (victim). It is a classic form of amplification attack.

Re:Could someone explain how the attack works?

[winkydink]

Come on now. How dare you confuse the hyperbole with things like facts.

Re:Could someone explain how the attack works?

[LurkerXXX]

Then you don't understand DNS resolvers. Did you bother reading the linked site? All you need to do is query an open resolver with some domain you set up (ex my.span.com), then change the authoritiative DNS of your registered domain as the target open DNS resolver. Now whenever someone anywhere in the world queries for my.spam.com, it hits your DNS server (until their local server caches it). It looks like you are hosting the spammer.

Another problem:
(Quoting a post on the other site)"they can send a 70 byte packet to your DNS server, and your DNS server will send a 500+ byte packet to the victim. With EDNS0, that can be 4,000+ bytes.

So with a dialup account, it would be possible to saturate a T1.

There's plenty of ways for them to mess with you without any 'compromised' machines on your network.

Re:Could someone explain how the attack works?

[Anonymous Coward]

The problem is not only with the amplitude increase, but with the multiple responses. The most common amplification ratio is 2.5:1 (a 47 byte packet with a 117 byte return). Compound that with the fact that it is trivial to find servers that replay this back 8-12 times, and you've got a real problem. 8 * 2.5 gives you a total of a 20x amplification of the packets you send out, which is fairly significant. Also, servers that replay these responses up to 24 times are not uncommon. This type of thing has been around for years, but it is only now coming into the spotlight as it becomes a more common method of attack.

Re:Could someone explain how the attack works?

[Anonymous Coward]

The same way /. works, if your site gets posted.

Re:Could someone explain how the attack works?

[Anonymous Coward]

disabling open recursive servers helps slow the issue, but does it really solve it?

It doesnt take much to get a 10+:1 ratio with non-recursive servers.

Just ask them for a zone they dont have, most of them will reply with a list of 10+ root servers.

example $ dig w.net @ns1.ostg.com
...
;; MSG SIZE sent: 23 rcvd: 508

20:1 ratio.

Re:Could someone explain how the attack works?

[defile]

Then you don't understand DNS resolvers. Did you bother reading the linked site? All you need to do is query an open resolver with some domain you set up (ex my.span.com), then change the authoritiative DNS of your registered domain as the target open DNS resolver. Now whenever someone anywhere in the world queries for my.spam.com, it hits your DNS server (until their local server caches it). It looks like you are hosting the spammer.

No, the problem was that I did read the article and was utterly confused by their description of the flaw.

Re:Could someone explain how the attack works?

[Cramer]

That's "another compromise"... IP Spoofing hasn't a f***ing thing to do with DNS recursion. One can just as easily spoof your address in a non-recursive request.

Re:Could someone explain how the attack works?

[zer0skill]

I believe this may answer your question:

http://grc.com/dos/drdos.htm

Re:Could someone explain how the attack works?

[zer0skill]

I believe this may answer your question: http://grc.com/dos/drdos.htm

Re:Could someone explain how the attack works?

[Cramer]

Did you bother reading the linked site?

Yes, I did. That explanation doesn't make any sense. You may be able to change the dns servers on record at the registrar in seconds, but the root name servers may not update for days. Most modern DNS servers detect "lame servers" and stop asking them about those domains. For example, if foo.com lists 1.1.1.1 as the authoritative server but it has no records for the domain (not configured, not in cache), any server asking about foo.com will tag 1.1.1.1 as a lame server and not bother asking it any more. (obviously, the "lameness" will eventually expire, but not soon enough for a DDoS.) And btw, the coopted server will still have the original NS records cached -- if it has anything at all in it's cache.

It looks like you are hosting the spammer.

Only an idiot blames the listed authoritative DNS server IP's for spam. The DNS server didn't send you spam. You find the spammer by looking at WHO registered the domain and WHERE the spam actually originated (i.e. what IP address connected to your SMTP server.) Who's hosting the DNS for it is completely immaterial.

(Oh yeah, since when is "hosting spam" a "DDoS"?)

Re:Could someone explain how the attack works?

[scatters]

Hmmm. It seems that if it is just an amplification attack, a non-recursive server would work just as well. Simply spoof the source address of the UDP packet and request a record for which the DNS server is authoritative. Should have about the same effect.

Re:Could someone explain how the attack works?

[geniusj]

Agreed! I think this problem is one we're just going to have to live with for now unless we start requiring all DNS queries to have a 3 way handshake. You could actually hack a 3 way handshake into the existing protocol pretty easily without changing the protocol or the client library implementation whatsoever. However, you'd be doubling or more the load on your DNS server.

Example:

A? example.com

example.com CNAME ._a.example.com (this response is generated)

A? ._a.example.com (cookie sticks around in temporary cache for say.. 10 seconds or until the first query for it arrives) ._a.example.com A

Talk about a hack. But it could be done. I'm not sure if it would work for every record type, but hopefully. The key would be to keep the cookie length fairly small as to not amplify your response drastically.

Still sounds like more hassle than it's worth

Re:Could someone explain how the attack works?

[LurkerXXX]

You aren't going to find a spammer by looking at the IP the connecting to your SMTP server either. That's only some dumb zombie machine or open relay left open, that the real spammer, located elsewhere in the world, is taking advantage of. (I'll leave out the part about only an idiot assuming the person owning the IP would be the real spammer. It just goes to prove my point that some folks will call someone a spammer, when they are actually the victim of one.)

"hosting spam" isn't a DDos. It was just an example of how an open resolver can be abused with no local machines being compromised.

Re:Could someone explain how the attack works?

[geniusj]

(whoops.. fixed formatting)

Agreed! I think this problem is one we're just going to have to live with for now unless we start requiring all DNS queries to have a 3 way handshake. You could actually hack a 3 way handshake into the existing protocol pretty easily without changing the protocol or the client library implementation whatsoever. However, you'd be doubling or more the load on your DNS server.

Example:

A? example.com

example.com CNAME [cookie]._a.example.com (this response is generated)

A? [cookie]._a.example.com (cookie sticks around in temporary cache for say.. 10 seconds or until the first query for it arrives)

[cookie]._a.example.com A [IP for example.com in zone file]

It's a hack. But it could be done. I'm not sure if it would work for every record type, but hopefully. The key would be to keep the cookie length fairly small as to not amplify your response drastically.

Still sounds like more hassle than it's worth

Re:Could someone explain how the attack works?

[Anonymous Coward]

The article referenced in parent describes attack by reflection but does not consider the use of recursive DNS lookups.

Re:Could someone explain how the attack works?

[7x7]

http://it.slashdot.org/comments.pl?sid=180427&cid= 14937868

Re:Could someone explain how the attack works?

[Cramer]

Right. I left off the bit about "WHERE" being mostly useless. Zombie or not, that *is* where the spam came from. It's surprisingly helpful to ban those addresses and even the surrounding netblock(s). The DNS server IP(s) are completely useless -- I've never seen a spammer hosting his own DNS. Banning the dns server address(s) won't do much to stop the spam, but could break a number of things.

Re:Could someone explain how the attack works?

[scatters]

Sure, your scenario target's the DNS servers that host a specific zone. The scenario I'm talking about is a bandwidth DDoS for any publicly accessible network.

1. Pick the target network who's bandwith you want to consume.
2. Send a bunch of DNS requests to a number of DNS servers with requests for records in their respective authoritative zones and send the response to the target network by spoofing the source address to one from the target network.
3. Sit back and imagine the screams of anguish.

The DNS servers don't need to be recursive for this to work...unless I'm missing something...

Re:Could someone explain how the attack works?

[mrogers]

Perhaps what you do is send a spoofed DNS Notify for a popular domain like msn.com, giving the victim's address as the authoritative server for that domain and using a very short timeout. Then every time someone looks up msn.com, the victim gets hit with a recursive request.

Re:Could someone explain how the attack works?

[mrogers]

But the question is, why would anyone look up my.spam.com? I think the attack might be based on spoofing DNS NOTIFY messages to change the authoritative server for a really popular domain. Specifying a short timeout would prevent the reflector from caching the response, so all requests would be forwarded to the victim.

Re:Could someone explain how the attack works?

[Anonymous Coward]

Gibson is moron. At least recently he's been a quiet and otherwise harmless moron; but still a moron.

Re:Could someone explain how the attack works?

[Anonymous Coward]

"(whoops.. fixed formatting)"

Use the fucking "Preview"button, and you won't have this problem, moron.

Re:Could someone explain how the attack works?

[Anonymous Coward]

in it's cache

"its".

Re:Could someone explain how the attack works?

[Cramer]

Notify doesn't work like that. Oh, and it has nothing to do with recursion.

Re:Could someone explain how the attack works?

[geniusj]

Thank you, Mr. Coward. You are ever so kind :-)

Re:Could someone explain how the attack works?

[mrogers]

As far as I know, Notify tells a slave server to contact its master for an update, even if the relevant entry is in the slave's cache and hasn't expired. Notify messages aren't authenticated because spoofed messages are supposedly harmless, but if you're on the same segment as the slave or the master or you can guess the ID number of the request (old versions of BIND), you can spoof the master's response and replace the entry in the slave's cache. If the slave has slaves of its own, it will push the new entry out to them too.

Recursion comes into play when someone asks the slave for the spoofed entry. You can list the victim as the authoritative source, so all requests will be recursed or iterated onto the victim.

Re:Could someone explain how the attack works?

[Cramer]

I don't think you understand what NOTIFY is or how it works:

When a slave receives a NOTIFY announcement for a zone from one of its configured master name servers, it responds with a NOTIFY response. The response tells the master that the slave received the NOTIFY announcement so that the master can stop sending it NOTIFY announcements for the zone. Then the slave proceeds just as if the refresh timer for that zone had expired: it queries the master name server for the SOA record for the zone that the master claims has changed. If the serial number is higher, the slave transfers the zone.

Why doesn't the slave simply take the master's word that the zone has changed? It's possible that a miscreant could forge NOTIFY announcements to slaves, causing lots of unnecessary zone transfers and amounting to a denial-of-service attack against a master name server.

-- DNS and BIND, 4th Ed.

First off, it only applies to authoritative zones which means there aren't any caches to exploit. Second, query recursion and dns notify are completely unrelated.

If you send a NOTIFY for a domain that isn't a slave, the server will ignore it. Even if you happen to be in a position to mount a man-in-the-middle attack and forge the SOA QUERY results, all you'll manage to do is trigger a zone transfer -- which happens over TCP, not UDP, so poisoning the zone will be much more difficult. But we're straying off topic... this has nothing to do with recursion, nor is it a DDoS. (and very few people are in a position to mount such an exploit.)

Notify messages are validated, if not authenticated. They have to come from a configured master or they're ignored. At best, for each NOTIFY properly forged, 2 (*two*) packets, almost exactly the same size, will be generated: the NOTIFY response, and a QUERY for the SOA. If a 2x amplification is enough to be an effective DDoS, then it's very likely the script kiddie's zombie botnet is large enough to not need any amplification. Oh yeah, and the entire process is hinged on IP SPOOFING, not on the status of any dns server's "query recursion" settings.

Disabling recursive queries on public dns servers, and properly configuring the feature on internal dns servers is a good practice. HOWEVER, it's not the solution to using DNS servers in DDoS attacks. It is at best, a small part of the solution. All of this depends on successful ip spoofing; and that is what needs to be fixed, but because of lazy, and/or incompotent networking professionals, ip spoofing is going to be with us for a long time. (we've had the necessary technology for nearly a decade.)

Re:Could someone explain how the attack works?

[tyldis]

To make the attack more effective you create a domain with a huge TXT record, and use it for those queries...

Re:Could someone explain how the attack works?

[mrogers]

I wasn't suggesting that the query triggered by the NOTIFY would form the DoS. The NOTIFY is just used to get the slave server to query its master, at which point the attacker sends a forged response and replaces the slave's entry for some popular domain with the address of the victim. As you pointed out, this part of the attack is just IP spoofing (and DNS query ID spoofing). The recursive part of the attack comes later and doesn't even require the attacker to stay online: queries for the popular domain are recursed onto the victim by the slave server. The attacker doesn't need a botnet because innocent lookups for the popular domain generate the traffic.

Re:Could someone explain how the attack works?

[Cramer]

As I said, it. does. not. work. like. that. The NOTIFY has to appear to come from a master server. Assuming one can get the timing exactly right and fake the SOA QUERY result, all it will do is trigger a zone transfer from that master server; an (optionally) authenticated process done via TCP, not UDP, and thus not generally succeptable to ip spoofing. No where in there is there a place for a 3rd party to specify where to send/receive anything. The slave is only going to talk to the master(s) it's explicitly configured to use.

The whole "DDoS by hacking someone's zone file", AGAIN, has nothing at all to do with enabling or disabling recursion. In this case, you've managed to replace an AUTHORITATIVE RECORD forwhich the server will ALWAYS answer; it's authoritative for the domain, so it has to. Historically, such crap has been done by buffer overflows compromising the entire DNS server, and less often by specific, complex cache/internal db poisoning attacks -- both the result of bugs in the dns server, unrelated to "recursion on".

That's a bold statement

[fak3r]

having a DNS server that allows recursion for the Internet is like running an open SMTP relay.'

Anyone want to discuss how DNS Cache addresses this? AFAIK this is a pretty "safe" way to provide DNS to at least a small sized network - but that's all I run it on. Comments, concerns, advice?

Re:That's a bold statement

[kindbud]

Well to start with, dnscache supports simple ACLs for recursion requests. You can have a publically accessible DNS cache for your organization, which won't resurse for the whole world. Better to use a VPN, though, but not everyone can do that. So if you gotta do it, dnscache is a good choice.

The authoritative server tinydns does not cache at all, and so it is useless for this attack.

Old NEws

[Anonymous Coward]

This has been happening for years, and security folks have been saying to make sure you don't have recursive DNS servers open to the public for years. Not sure how this is news.

Re:Old NEws

[Intron]

Correct. Here is the CERT writeup from 2000.

Separate authoritative and recursive

[Aspirator]

I am quite a fan of djbns, but the key here is to separate authoritative and
recursive, which is something that DJB has been preaching for a while.

Consequently djbdns won't do this, but it is quite possible to make bind not
do this also. (In fact Bind now has come round and reccomended this.)

It seems to me like a no-brainer, why is splitting the two such a problem?

SDNS wouldn't hurt either, but that will take a lot more doing.

Re:Separate authoritative and recursive

[Russ Nelson]

why is splitting the two such a problem?

It isn't that hard, but it's perceived to be difficult. You have to set up your authoritative records on a separate IP address from your current DNS server (e.g. using tinydns). Then you tell your registrar that your nameserver has a different IP address. At that point, the only queries coming to your old IP address should be recursive queries coming from your users. Then you can close off recursive queries coming from the rest of the net (e.g. using dnscache).

Then you have to make your secondarying work, which may be easy, or merely annoying depending on your setup.

Re:Separate authoritative and recursive

[schon]

You have to set up your authoritative records on a separate IP address from your current DNS server

I don't think so.

Why don't you just add a "query { trusted-hosts; }" line to the global options, and a "query { any; }" line to your authoritative zones? It's not rocket science.

Disable recursion in BIND

[Ponga]

Put this line in your zone definition:
recursion no;

Problem solved.

Re:Disable recursion in BIND

[Anonymous Coward]

Problem solved......unless your customers rely on your name servers for dns.

Re:Disable recursion in BIND

[tepples]

unless your customers rely on your name servers for dns.

Then have two separate DNS servers: one non-recursive server in the DMZ for serving your domain to the Internet and one recursive server behind the firewall for serving the Internet to your customers.

Re:Disable recursion in BIND

[Kakurenbo Shogun]

I tightened up my DNS configuration when it was being abused for one of these attacks last October by adding the following to named.conf:

options {
      allow-recursion { 127.0.0.1/32; };
};

That allows my server to use the local copy of bind for recursive queries, but limits everyone else to queries for which my server is authoritative. Bandwidth usage went from practically off the chart to low enough not to cost me extra for bandwidth immediately, and soon the attacker stopped trying to abuse my server.

Re:Disable recursion in BIND

[Cheeze]

let customers behind your firewall for dns?

What kind of network are you running?

If you have internet-based customers that get services from you that require DNS, you better turn on recursion or those will be some pissed off customers.

Re:Disable recursion in BIND

[tepples]

let customers behind your firewall for dns? What kind of network are you running?

A corporate network, where the IT department's "customers" are the company's employees. Were you thinking of a residential ISP?

Re:Disable recursion in BIND

[kence]

Depending on the DNS server, turning off recursion completely is not the answer. Granted most internet-facing DNS servers can simply turn recursion off without negatively impacting lookups (generally) but doing so for an internal system (or one that bridges an internal and external) is begging for trouble.

According to Chapter 2.2.6.2 of Pro DNS and BIND (http://www.zytrax.com/books/dns/ch2/index.html#re cursive))

Note: The above sequence is highly artificial since the resolver on Windows and most *nix systems is a stub resolver - which is defined in the standards to be a minimal resolver which cannot follow referrals. If you reconfigure your local PC or Workstation to point to a DNS server that only supports Iterative queries - it will not work. Period.

A better solution would be to use allow-recursion to specify which clients will receive recursive DNS responses.

Re:Disable recursion in BIND

[cerberusss]

Put this line in your zone definition: [...] Problem solved

Hey, great man! Tha Host slashdot.org not found: 3(NXDOMAIN)

Re:Disable recursion in BIND

[schon]

A better solution would be to use allow-recursion to specify which clients will receive recursive DNS responses.

Or to use allow-query to specify which hosts can query your nameserver at all (and do allow-query {any;} on any zones you serve authoritatively for.)

overwhelming floods of amplified data

[digitaldc]

Name servers are specialized computers that help direct Internet traffic to its destinations. The attacker then sent falsified requests to the compromised directory computer, which unleashed overwhelming floods of amplified data aimed wherever the attacker wanted.

Suggestion:
-Verify requests
-Verify directory computers have not been comprimised
-Disallow amplified data
-Build a new secure system for handling traffic

Re:overwhelming floods of amplified data

[Anonymous Coward]

Suggestion:
-Verify requests
-Verify directory computers have not been comprimised
-Disallow amplified data
-Build a new secure system for handling traffic

I think reading some of these might be worthwhile. I'm sure you could make a fortune by creating a piece of software which is backwards compatible with the myriad DNS clients currently in operation, which follows your suggestions.

MOD REPLY TO PARENT UP

[quokkapox]

Seriously, when one of these really impacts something or other, the people who are responsible will figure out what went wrong, fix it, and life will go on as usual. Maybe some of us will get away from the keyboards for a while, chat at the water cooler or something. Some of us will get a day off and others will get plenty of overtime.

The real risk is perhaps The Final Virus.

That's by Berenstain?

[Philip K Dickhead]

With his weird license? God. He writes good software. He's even a bloody certified genius, but he's amost as insufferable as Dave Weiner. Don't try and submit a patch - unless you are just donating to his case, and want nothing as a contributor. Also, be prepared for the contempt of his responses.

Besides, who wants software written by a cartoon bear?

Re:That's by Berenstain?

[Anonymous Coward]

His software is "public domain". That is to say, the software has no license. How can "no license" be confusing?

Re:That's by Berenstain?

[Anonymous Coward]

His software isn't remotely public domain. http://cr.yp.to/distributors.html gives his licensing details, which make it quite clear he's an idiot.

Re:That's by Berenstain?

[Russ Nelson]

No, most of his software is copyrighted. The only djb software which is in the public domain is software that he has explicitly given to the public domain. The term for the rest of his software is "license-free". You don't need a license to use it. Just download it! Copyright law lets you do anything you want with a copyrighted work, except redistribute it. You can publish patches, as we've done with netqmail.

Re:That's by Berenstain?

[Russ Nelson]

Okay, so obviously we can see why you clicked on the "Post Anonymously" checkbox. I think Slashcode needs "Post Anonymously" to be a dropbox of reasons why you're posting anonymously:

Post Anonymously because:
    o Posting something stupid
    o Posting something illegal
    o Posting something embarrassing
    o Posting something shameful

I think you would have selected the last one.

Re:That's by Berenstain?

[killjoe]

"You can publish patches, as we've done with netqmail."

Believe it or not that why I moved from qmail to postfix. I wanted to patch our version of qmail to add a feature but I could not recreate our current binary because I had no idea which set of patches were applied to it. It seemed easier to install posfix and configure that (and it was!).

Re:That's by Berenstain?

[Russ Nelson]

I note that you didn't say you were using netqmail. We intend for your problem to be exactly and precisely solved by netqmail. If it's not, you should complain on the qmail@list.cr.yp.to mailing list. And we WILL listen to you, and you WILL get a response (unlike, say, complaining to djb).

Re:That's by Berenstain?

[killjoe]

I wasn't using netqmail, I didn't even know it existed. Anyway I am happy with postfix now so I don't think I will switch back. Good luck to you though.

Re:I must resist

[AKAImBatman]

That's self-referential, not recursive. One does not immediately imply the other. GNU, on the other hand, is recursive.

Re:I love djbdns

[Russ Nelson]

Eh, he's gotten a lot better. Hey, everybody was young when they were young. It's just that not all of us inflicted our youth on others. He just writes good software these days. If you don't use it, well, it's your loss.

Fiction indeed...

[bsdluvr]

"The real risk is perhaps The Final Virus."

"Though Linux passed Microsoft in web-server market share long ago, it remains second in overall share for intranet and general-purpose servers. But unless there is some break in the trend curves Linux really will be #1 around the beginning of 2005."

Oh...

Re:I must resist

[Anonymous Coward]

To know recursion, you must first know recursion.

There is a defense

[Alwin Henseler]

FTA: "Silva said the attacks earlier this year used only about 6 percent of the more than 1 million name servers across the Internet to flood victim networks. Still, the attacks in some cases exceeded 8 gigabits per second, indicating a remarkably powerful electronic assault."

/.ers will know that only the mighty foot of Chuck Norris is powerful enough to kick back such a massive DDoS attack. There is a problem though: since there is only 1 of him, Chuck can't defend more than one site at a time. And ofcourse his ourly rates are a bit steep, too.

Vary your mileage may.

Re:There is a defense

[SomeoneGotMyNick]

Chuck can't defend more than one site at a time

He also can't sing either... as evidenced on the theme song of Walker, Texas Ranger.

(sniff..... sniff..sniff..) I love the smell of burning karma in the morning.

Re:There is a defense

[WilliamSChips]

since there is only 1 of him

Actually, Chuck Norris is a Cylon, so there are multiple Chuck Norrises.

Re:There is a defense

[Anonymous Coward]

"Chuck can't defend more than one site at a time."

You're in trouble now. Don't you know that once, Chuck Norris went back in time to the point where the word can't was defined and put a note into the definition that Chuck Norris and * are not to be place in the same sentence.

*can't.

Why do you think you need a license?

[Russ Nelson]

Why do you think you need a license? Copyright law doesn't impose ANY restrictions on what you do with something you've downloaded. It only stops you from making copies.

Oh, and look at qmail-1.03.tar.gz#CREDITS -- my name is in there because of patches I've submitted to djb. Granted, he rewrote most of my code because his design was better than mine, but just because most patches 1) suck, 2) aren't necessary, 3) make the code worse, and 4) are badly design, doesn't mean that all are.

Re:Why do you think you need a license?

[Anonymous Coward]

Downloading /is/ making a copy.

Unlike the GNU GPL, copyright law does not make a distinction between "copying" and "distributing". That is why (in the US) you have the fair use right to make *one* copy of any copyrighted work for archival purposes. You cannot make two copies -- even if neither ever leaves your posession -- without explicit permission (ie, a license) from the copyright holder.

If you were allowed to, say, make an arbitrary number of copies of MS Windows so long as you didn't distribute it, you would be allowed to install it on an arbitrary number of computers /without violating copyright law/. Now, since a corporation is a person under the eyes of the law, GM could buy a single copy of WinXP and intall it on every single one of its desktop systems. Sure, they'd be in violation of the EULA, but (legitimacy of shrink-wrap EULAs notwithstanding) that falls under an entirely different section of law (ie, contract law).

Obviously this is not the state of affairs under the current regime, so by contradiction QED.

Re:Why do you think you need a license?

[Russ Nelson]

Downloading /is/ making a copy.

True, but it is djb who is making the copy, not you. Every copy he gives you is a legally independent copy, which you are free to do whatever you want with, including give it away to someone else.

You cannot make two copies without explicit permission (ie, a license) from the copyright holder.

So? If you download a copy A of djb's software, and then legally copy it to make A', and you want another copy B, just go download it. djb is happy to give you as many separate copies of his software as you think you need.

Re:Why do you think you need a license?

[kimvette]

Why do you think you need a license? Copyright law doesn't impose ANY restrictions on what you do with something you've downloaded. It only stops you from making copies.

You got that ALMOST right. Let's correct it:

Why do you think you need a license? Copyright law doesn't impose ANY restrictions on what you do with something you've downloaded. It only stops you from making and distributing copies which are not in accordance with the Fair Use clause.

There. Much better. Methinks you work for the MPAA or RIAA.

Re:Why do you think you need a license?

[Anonymous Coward]

Sure. I wasn't disagreeing with your point about djbdns per se, but with the statement as descriptive of copyright in general.

Re:Why do you think you need a license?

[Russ Nelson]

Yeah, but we're not talking about copying which falls under fair use. Incorporating a copy of code into a unidiff patch would be fair use (commentary). Making a copy of a djb subroutine for pedantic purposes ("see how he does this") would be fair use. Making a copy of code which is no longer for sale and cannot be purchased for any reasonable price might be fair use. Making a copy of code which is freely downloadable elsewhere -- even if you use it to create a derived work -- is almost certainly not fair use. Fair use always ends up being a judgment call on part of a judge. You'd always prefer not to have to rely on fair use.

Re:Why do you think you need a license?

[cperciva]

Making a copy of a djb subroutine for pedantic purposes ("see how he does this") would be fair use.

I hate to be pedantic about this, but I think you mean pedagogical purposes.

Re:Why do you think you need a license?

[Nevyn]

Why do you think you need a license? Copyright law doesn't impose ANY restrictions on what you do with something you've downloaded. It only stops you from making copies.

As I'm sure you know Rick Moen has an informative text on this. IMO you'd have to be insane not to have a license on software you are using for SMTP/DNS (Ie. speaking directly with the outside world).

But, hey, you're free to be insane. Just don't act surprised when people don't want to join you for a glass of kool-aid.

Re:Why do you think you need a license?

[Russ Nelson]

Grammer Nazi!

Re:I love djbdns

[Anonymous Coward]

And that matters to you how? When you can write better software then he can maybe you can have your say, but until then trash-talking someone you don't know is rude.

Re:I love djbdns

[winkydink]

Really? Has he stopped with the peurile name-calling?

Re:I love djbdns

[winkydink]

And assuming I don't know him is preposterously presumptive.

Wrong wrong wrong

[A nonymous Coward]

His license forbids distributing binaries unless they are made from his sources. You want to add any of the many well known patches? Great, you distribute his source and your patches, you do not distribute patched sources and you do not distribute binaries.

No way is DJB software public domain.

In fact, I bet a dollar you don't even know what public domain is.

Re:Wrong wrong wrong

[hackstraw]

His license forbids distributing binaries unless they are made from his sources. You want to add any of the many well known patches? Great, you distribute his source and your patches, you do not distribute patched sources and you do not distribute binaries.

Yeah, such a restrictive license killed the pine mail reader years ago.

Re:Wrong wrong wrong

[Xenna]

And that's exactly what he's doing. Killing his own software. I love Djbdns and I put it on all my servers as a local cache (don't worry, it's on 127.0.0.1) but DJB's stubborn unwillingness to do the normal OS thing is killing his software.

Qmail is great in many ways and I've been running it for years, but to make it acceptable in today's spam & virus-filled world requires an ever growing amount of patches. Some of which won't work together any more.

As a result I switched to Postfix on many of my installs.

Pity, though...

X.

Re:Wrong wrong wrong

[schon]

Yeah, such a restrictive license killed the pine mail reader years ago.

Except that pine is, y'know, actually useful in the real world, without applying any patches. The same can't honestly be said for qmail.

Re:I must resist

[Soporific]

The first rule of recursion is to not talk about recursion...

~S

Re:I love djbdns

[Russ Nelson]

When is a spade not a spade? If someone engages in puerile activity, don't they deserve a puerile name? djb (the old djb, anyway)'s biggest problem is that he didn't give people the truth gently. He would tell people "That's stupid, and you're being stupid for proposing it." The best djb quip I ever heard was:

djbwm - it's the best window manager in the world, but when you try to move a window, it argues with you for ten minutes that it was already in the right place.

Split-split DNS Design

[lazarus]

For enterprise systems a split-split DNS design is the best. There are three components to this design:

ADVERTISER
RESOLVER
INTERNAL

The advertiser sits outside, Internet-facing, and is only responsible for resolving outside queries for your own domains. It does not do recursion or dynamic updates, and has a secured cache.

The resolver and internal sit inside, are intranet-facing, and handle internal requests for outside domains, and internal requests for internal domains respectively.

There are lots of articles on-line which show how to set this up.

Re:Split-split DNS Design

[eqdar]

Exactly -- a split DNS setup is quite easy to implement, and is an elegant solution

There are lots of articles on-line which show how to set this up.

You might want to check http://www.castalie.org/Linux/DNS.html for an example implying BIND as an internal resolver and NSD as an authoritative-only advertiser,

Re:Split-split DNS Design

[PilotDvr]

Agree completely. Never really understood why people insisted on running the same server both inside and outside...never made sense to me.

Re:Split-split DNS Design

[arivanov]

That is almost correct. As stated it requires 3x2 machines (primaries and secondaries) which is a serious resource waste. In most cases the RESOLVER and ADVERTISER can be combined on one machine.

You simply need to set listen statements in the named.conf's so that the ADVERTISER listens on an externally reachable address and the RESOLVER issues queries on an externally reachable address while listening on an address that can be reached only from the inside.

Depending on your topology and security constraints you can throw in the INTERNAL on one more set of addresses or keep it separately (lo:0, lo:1, lo:2, etc).

In addition to everything else, having no-recursion in the ADVERTISER helps decrease the possibility of cache poisoning attacks. While bind has gotten much better lately they still can happen.

Re:Split-split DNS Design

[binner1]

Although with properly configured zones, this is perfectly reasonable now, imo.

-Ben

Re:Split-split DNS Design

[larry bagina]

you would need 6 ip addresses, not 6 machines.

Re:Split-split DNS Design

[arivanov]

I assume you mean "public" addresses and the answer is: Not necessarily.

You need the same number for your ADVERTISERs as normal. No change there.

You can use martian addresses for the listen address of the rest and the ADVERTISERs address with a high port (non-53) as query source for the RESOLVERs (so that you do not churn a lot of NAT entries for them).

So there is no public address wastage here.

Re:I must resist

[AKAImBatman]

That's a self-referential paradox, not a recursive statement. The grandparent is an example of a recursive statement.

Recursion considered harmful

[Anonymous Coward]

Should have used gotos! -1 for the functional language weenies!

Known since February 2000

[Anonymous Coward]

TESO - Nameserver traffic amplify and NS route discovery.

Who does not learn from history is doomed to repeat it... oh, wait, its still the same bug.

Fixing bind9

[pjkundert]

If you run an internet facing bind9 DNS server, you may want to allow recursion (caching) to your internal clients, while continuing to serve DNS requests to external clients for your domains (those for which you are "authoritative").

Lets say that your local LAN and WLAN networks are 192.168.0/24 and 192.168.1/24, respectively. Make the following additions to your /etc/bind/named.conf.options (or equivalent):

options { allow-query { any; }; allow-recursion { 192.168.0.0/24; 192.168.1.0/24; localhost; }; ...

Re:Fixing bind9

[KiloByte]

It's better to write your example as:

allow-recursion {
        192.168.0.0/16;
        172.16.0.0/12;
        10.0.0.0/8;
        127.0.0.0/8; ::1;
};

This way, those who mindlessly cut&paste will be less likely to shot themselves in the foot. And, since people are going to leave the old wide-open but working version if anything breaks, it's better to have it work out of the box.

Re:Fixing bind9

[PowerBert]

With that config, bind will still give out already cached data. That could be used in information gathering attacks.
It would be better to use:

          allow-query { clients; };
          allow-recursion { clients; };

acl clients {
    192.168.1.0/24
}

and then in your zones

zone "example.com" {
                type master; ...
                allow-query { any; };
};

In other news...

[fahrbot-bot]

...researchers have confirmed that posting a link in a Slashdot article is just as effective as other DDoS Attacks.

Re:I must resist

[Spy der Mann]

The grandparent is an example of a recursive statement.

stop talking about this thing called "recursion" that makes me yell at you to stop talking about this thing called "recursion" that makes me yell at you to stop talking about this thing called "recursion" that makes me yell at you to stop talking about this thing called "recursion" that makes me yell at you to ...

Re:I must resist

[Philip K Dickhead]

you say container, I say pointer...

When BIND is fixed I'll implement it

[jmorris42]

There really isn't a good reason one nameserver can't serve internal and external users. All that is needed is recursive lookups need to be restricted to the internal IP space. It doesn't look like BIND can currently do that but I suspect that if this problem is really serious it will quickly gain the ability.

Some of us don't like the idea of maintaining more servers than are absolutely required, this looks like a pretty bogus reason to install another set of nameservers.

Re:When BIND is fixed I'll implement it

[questionlp]

You can use the allow-recursion directive to limit the IP addresses that are allowed to do recursion. For instance, if your internal IP space is 192.168.0.0/24 and want to allow localhost recursion, use the following in the options section of named.conf.

allow-recursion { 127.0.0.1; 192.168.0.0/24; };

I don't know if it's foolproof, but it's better than no restrictions at all.

Re:When BIND is fixed I'll implement it

[Anonymous Coward]

Uh, yeah bind can do it. You can either setup two different views, one for recursive queries and one for authoritative queries. Or you can just do a allow-recursion { whatever }; I guess reading the docs instead of posting nonsense would be out of the question though huh?

Re:When BIND is fixed I'll implement it

[Anonymous Coward]

Uhh...

allow-recursion { 127.0.0.0/8; 192.168.0.0/24; };

Or else 127.168.32.117 (still localhost) doesn't work.

Re:When BIND is fixed I'll implement it

[19thNervousBreakdown]

view "internal" {
  match-clients {
    10.0.0.0/8;
  };
  recursion yes;
  zone "example.com" {
    yadda yadda yadda;
  };
};

view "external" {
  match-clients {
    any;
  };
  recursion no;
  zone "example.com" {
    blah blah blah;
  };
};

Re:When BIND is fixed I'll implement it

[GeekWithGuns]

There already is a fix in BIND (at least in the 9.2.4 release shipped with RHEL 4 & all like distros). Just add this to your "options" section of your bind.conf:

allow-recursion { localhost; mygroup; 10.10.10.1; 10.2.3.0/24; };

This would allow the localhost, the machines on the mygroup ACL, one computer at 10.10.10.1 and all the hosts in 10.2.3.0/24 access to recursive queries.

If you don't need to provide recursive lookups at all, you can just use this:

recursion no;

Re:When BIND is fixed I'll implement it

[sloth jr]

As has been mentioned, BIND can do this without much issue - EXCEPT it doesn't QUITE follow all expectations. Apparently, BIND uses a common name cache - so although a recursive query with an uncached answer can arrive at a DNS server and be rejected, if that BIND server ALREADY has a cached answer (eg, from an internal query) - it'll serve that up to the requestor. This was true in implementations of BIND about 6 months ago - I'm not sure things have changed since...

Re:When BIND is fixed I'll implement it

[gkitty]

In Bind9 you don't have to return cached data, so though it happens by default you can turn it off ("additional-from-cache"):

view "internal" {
        match-clients { internals; guests; };
        recursion yes;

        zone "." {
                type hint;
                file "bootstrap/cache";
        };

        zone "example.com"{
                type master;
                file "example-int.com";
        };
};

view "external" {
        match-clients { any; };
        recursion no;
        additional-from-auth no;
        additional-from-cache no;

        zone "example.com"{
                type master;
                file "example-ext.com";
                allow-query { any; };
        };
};

---------

I believe that should prevent bind from being too useful from the outside.

Re:When BIND is fixed I'll implement it

[jmorris42]

> In Bind9 you don't have to return cached data, so though it happens by default you can
> turn it off ("additional-from-cache"):

Excellent. The commentary on the aite with the original article didn't seem to know about that trick. So now I just need to make sure I have wrapped my head around all of the details and start making the changes. Going to be a bit of bother this way but managable. Installing another pair of nameservers was right out, this way is doable.

old new

[7x7]

This is old news. If you're running an open DNS server, you're very likely participating in someonelse's DDoS attack and have been for the last couple years. We bought a company last year and part of my job was to assimilate their DNS systems that were reportedly flaking out constantly. I can't speak to the people running the servers before me, but the diagnosis was easy. Once we turned off recursion and convinced the network not to let spoofed UDP packets enter the network, the attacks stopped instantly.

Re:old new

[Cramer]

If you're running an open DNS server, you're very likely participating in someonelse's DDoS attack and have been for the last couple years.

Then please explain to me how RECURSION contributes to DDoS attacks? Every example or attempted explaination I've seen so far immediately falls on IP SPOOFING and/or various well timed cache tricks. In the case of ip spoofing, if your dns server answeres any request, it can be using as an amplifier. There's nothing the dns server can do about that; ISP's are the only ones in the right place to stop ip spoofing.

Recursion can certainly be used to DoS the dns server itself -- by making it do a whole bunch of requests. But DoS'ing someone else...

Re:old new

[7x7]

Set up an open DNS server with recursion turned on and do not allow UDP spoofing. If you know anything about UDP, you know it is connectionless. The only way you could possibly know if a UDP packet is spoofed is if it is *your* IP space (packets coming in from the internet could be from anywhere). Your own IP space cannot source from outside your network, so you discard any packets that do.

From outside your network, send a request for a DNS record to your server: a.example.com Your server will try to look up a.example.com from example.com's name servers. It will send an answer to the source IP in the UDP packet.

Now send another request for b.example.com and forge the source IP. Your server will try to look it up and send the answer back to the fake IP.

Now send millions of packets looking up [randomnumber].example.com, each with a unique source IP. Your server will essentially flood the name servers for example.com with requests for zones that do not exist and scatter the answers to the far corners of the internet where the UDP packets are simply discarded.

Now combine your recursion set up with a few others and watch example.com drop from the face of the planet.

That is what I found when I took over the servers from the other company. They had a high capacity system with loads and loads of bandwidth (phone company). Their machines could knock out a small name server without sweating. Combined with other networks, they could knock out much larger installations.

The attack is simple to perform and simple to avoid.

Re:old new

[Cramer]

Turning off recursion won't prevent such attacks. At best, the script kiddies will simply stop sending requests to your server(s).

Think about... The zombies can fire spoofed requests at the target dns server just as easily as an open server. And they can do so at the exact same rate. When the zombie sends a request to an open server, that server is going to send basically the exact same request on to the target. The request won't magically be 3x larger. And one zombie request will not be magnified into more than one target request. (ignoring timeouts.) There's no need for a middle man either, since the source is spoofed anyway.

The only reason to turn off recursion is to stop people from consuming your resources (maybe killing your server), and limit one avenue of possible bugs that could compromise the server.

1 question?

[CrackedButter]

Would doing this get you banned from WoW?

Re:1 question?

[sabat]

Only if you are running Cosmos. I heard that's bannz0rd. Also, hunters are losing aim-shoot, and the rogue class is getting canceled altogether (all rogues will automatically become warrior class). And all Alliance races will be getting a new racial ability: Detect Horde.

Re:I love djbdns

[Anonymous Coward]

He also teaches at UIC, so that can be a problem for some people (his students).

slashdot DNS is OPEN!

[Anonymous Coward]

http://www.dnsreport.com/tools/dnsreport.ch?domain =slashdot.org

FAIL Open DNS servers ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn't happen). This can cause an excessive load on your DNS server. Also, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Also, the bad guys could use your DNS server as part of an attack, by forging their IP address. Problem record(s) are:

Server 66.35.250.12 reports that it will do recursive lookups. [test]
Server 12.152.184.136 reports that it will do recursive lookups. [test]
Server 12.152.184.135 reports that it will do recursive lookups. [test]

See this page for info on closing open DNS servers.

Re:slashdot DNS is OPEN!

[J0nne]

Obviously that is the thing causing the slashdot effect...

And to say CmdrTaco blamed it on us, the innocent readers with souped up Firefoxes and Reloadevery extensions...

Re:slashdot DNS is OPEN!

[jaiyen]

They don't seem to be anymore. http://www.dnsreport.com/tools/dnsreport.ch?domain =slashdot.org is now showing...

OK. Your DNS servers do not announce that they are open DNS servers. Although there is a slight chance that they really are open DNS servers, this is very unlikely. Open DNS servers increase the chances that of cache poisoning, can degrade performance of your DNS, and can cause your DNS servers to be used in an attack (so it is good that your DNS servers do not appear to be open DNS servers).

I guess that shows the slashdot editors actually do read their site sometimes after all!

Re:slashdot DNS is OPEN!

[Slashcrap]

I guess that shows the slashdot editors actually do read their site sometimes after all!

Or maybe they read the actual article before posting it?

Sorry, just my little joke.

Right right right

[Russ Nelson]

I'll also bet a dollar that he doesn't know what public domain is. I'll even give two to one odds against it.

Re:GREAT...

[pheco]

Now if only someone could do this to slashdot... Then the Web would be a better place... ;-)


Yeah then people wouldn't be able to find out about such things and thus not do them to slashdot?

Hasn't BIND implemented it already?

[swb]

Hasn't it been fixed for some time via the allow-query and allow-recursion configuration options?

History repeats itself

[Anonymous Coward]

Back in 1983, IBM put Microsoft's "PC-DOS" on a "microcomputer." It was later named by Microsoft to MS-DOS, then simply DOS.

Digital Research cloned it and improved it in the late 1980s (early '90s?), making a program called DR-DOS that pundits called "a better DOS than DOS."

Flash forward to Yahoo News:

"Experts call the attack technique a 'distributed reflector denial of service,'" says the site.

So once again, DoS has been supplanted by DRDoS.

Re:History repeats itself

[Anonymous Coward]

LOL.

Now if only Microsoft would fix Windows so it won't allow DRDoS...

Re:I must resist

[maxwell demon]

To understand recursion, follow the instructions you get by adding its quote after the text "To understand recursion, follow the instructions you get by adding its quote after the text"

Of course there is...

[emil]

There really isn't a good reason one nameserver can't serve internal and external users.

Back in the bind 4 days, when I did serious DNS, my company wanted a few servers visible in their domain(s) for external dns host resolution.

For people behind the firewall, they wanted a far more extensive list of hosts that were not to be seen for queries outside the firewall.

I did this by using scp to transfer the zone files from the external to the internal DNS server; the internal server would then "cat" the additional hosts to the zone and HUP the named.

AFAIK modern BIND uses "zones" so you can accomplish the above on one server, if you want. I've never used it, but I can see a number of situations where I'd need my above solution even with this feature.

What BIND needs is not a "recursion no;" option, but instead a "recursion eth0;" or "recursion 1.2.3.*;" so recursive queries must originate from a trusted network.

Remember also that not everyone in the world uses BIND - people with ActiveDirectory or NDS name servers might be screwed until a vendor patch.

Re:Of course there is...

[Anonymous Coward]

While the internal vs. external hosts issue is quite easy to fix these days, what BIND still lacks is a way to synchronize both lists to a secondary server. Currently, the secondary can only transfer the zones it sees.

Re:Of course there is...

[cortana]

allow-recursion { 1.2.3.0/24; };

Re:Of course there is...

[inKubus]

Yeah, there's a checkbox to disable all recursion in Windows Server DNS, under DNS > Forwarders and Advanced tabs.

The problem is doing the cache for internal hosts (or an internal interface) and running zone authority for external (internet) users on one server. Apparently it's not possible using the built in configuration tool. There's probably a registry key which determines which interface will forward or not, around here: HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\Cu rrentVersion\DNS Server
It may be possible to get another instance running on a different interface also..

Until then, you need two hosts in Windows, with one not allowing recursion on the outside or DMZd/NATd and one local cache/forwardder box inside. Thanx MS

DDoS? "R", matey!

[spyrochaete]

This isn't just a simple DDoS because DNS servers point many other resources to the attack target. This makes this a Distributed Reflective Denial of Service Attack, or DRDoS. I published an article on this topic in 2600 Hacker Quarterly magazine in 2004. I was a network\security student when I wrote it so it might not teach you ubergeeks anything new.

http://hyppy.zapto.org/DRDoS-Spyrochaete.html

TV Media

[Klowner]

Oddly enough, just the title of this article alone explained the threat much more clearly than the anchorwoman on TV at noon. Why do they even report tech stuff if they can't even explain the problem? Sorry, this is off topic but I felt like whining about something..

Re:I must resist

[14erCleaner]

This statement is not self-referential.

Re:I must resist

[Vampyre_Macavity]

No, that's just self-referential.

Recursive would be something like what the acronym LAME stands for: "LAME Ain't an MP3 Encoder."

(Which, originally, it wasn't.)

MOD PARENT DOWN FOR REDUNDANCY

[Anonymous Coward]

from the to-understand-recursion-you-must-understand-recurs ion dept.

Re:I must resist

[jonaskoelker]

This sentence no verb.

StormPay: A recent example of this attack

[miller60]

The credit card processing gateway StormPay was knocked offline by this type of DNS amplification last month. The traffic peaked above 6 gigabits per second, and continued for weeks.

As previous posters have noted, these attacks have become more frequent in recent months, prompting an advisory from US-CERT (PDF) in December. It's a hot topic on several security lists, and a special focus of SecuriTeam blogger Gadi Evron.

Re:StormPay: A recent example of this attack

[Cramer]

The attacks work in the following manner: a malicious attacker sends several thousand spoofed requests to a DNS server that allows recursion. The DNS server processes these requests as valid and then returns the DNS replies to the spoofed recipient (i.e., the victim). -- US-CERT

You'd think CERT would have enough sense to realize, recursion is not the problem here. Spoofed. F***ing. Requests. Are the problem. Recursion will add to the load of any dns servers in the party, but disabling recursion will NOT stop a DDoS from spoofed requests. If the server answers the request at all, it's participating in the DDoS.

In a DNS amplification DDoS, attackers use a botnet to send a large volume of requests to DNS servers, spoofing the target's URL [correction: IP] as the "from" address on the request. Instead of responding to the machines in the botnet, the DNS servers send responses to the target, in this case stormpay.com. Because nameserver responses can be significantly larger than DNS requests, the attack can be amplified. -- NetCraft

... and recursion doesn't matter at all. This works even with a properly secured, non-recursing server. The ONLY way to stop such attacks is for networking professionals to properly configure their networks to prevent IP spoofing. It's not that hard to do with modern router hardware.

Well duh!

[Todd Knarr]

It's taken them this long to notice this one? The cricket book discusses it, fer cryin' out loud, and had a good recommended solution: refuse recursive queries by default, then enable them only on those nameservers that'll be used by your client machines and only if the query comes from your local network. I thought everybody setting up a nameserver knew this one, BIND even comes with options specifically to make it easy to do.

DRDOS

[vginders]

Sounds more of a Distributed Reflection Denial of Service attack actually. Old news indeed.

By default it's also useless.

[Medievalist]

Shades of OpenBSD. "By default there are no vulnerabilities" - but in the Real World [TM] systems require configuration, and that process will introduce vulnerabilities if the human being involved in configuration is an idiot or insufficiently skilled.

That's why I have all my systems configured by CHUCK NORRIS.

No, just kidding. Anyway, no DNS system works without configuration, and a properly configured system is immune to this problem regardless of whether you run Vixie's code or Bernstein's.

Disable Recursion in old versions of BIND

[nuckfuts]

If, like me, you are still running some old version of BIND (like 4.9 or 5.X) you can turn off recursion by adding the following line to named.boot & restarting named:

      options no-recursion

Another recommended configuration is

      options no-recursion no-fetch-glue

NOTE:
If you turn off recursion on any DNS server make sure you don't list that server in any other computer's resolv.conf file.

Re:Disable Recursion in old versions of BIND

[jroysdon]

Note: Bind9 doesn't fetch glue, ever, but won't error on the fetch-glue statement according to this document.

Re:I must resist

[Anonymous Coward]

That not sentence.

Attacks reflected by authorative servers?

[vginders]

What would be the difference to start a DRDOS attack by sending spoofed requests to authorative servers, querying for records they are authorative for?

Re:I must resist

[14erCleaner]

So say you!

You could try PowerDNS

[Anonymous Coward]

I don't wanna sound like a fanboy, but as stated before: PowerDNS has a seperate authoritive and recursive component, which can operate seperately or together, depending on your needs.

Comment removed

[account_deleted]

Comment removed based on user account deletion

vi /etc/named.conf

[Anonymous Coward]

# this really should be default

        allow-recursion { 127.0.0.0/8; 192.168.0.0/16; };

Parent poster is slightly incorrect.

[schon]

Why recursion is bad:

Find a large TXT record somewhere (or set one up on your own domain.) Make it about 4K (which, incidentally, is the size that was used in this last batch of attacks.)

Request this TXT record from an open resolver (the amplifier) with lots of bandwidth, with a spoofed IP address of your target. Repeat as fast as you can.

The amplifier will cache your TXT record, and start sending replies, swamping the target.

Each request uses ~ 100 bytes from you. Each reply from the amplifier to the target will use 4096 bytes. That's a 40X amplification. Doing this from a T1 will result in consumption of 60Mbps of bandwidth from your target (enough to swamp an OC-1.) If you have more upstream bandwidth, you can do more damage.

Now do you see why it's bad?

Re:Parent poster is slightly incorrect.

[Cramer]

Key words: with a spoofed IP address of your target

Ah, thanks for the picture. Recursion isn't the problem. IP Spoofing is the problem. Turning off recursion is only a band-aid...

If you are successfully spoofing the address of your target, disabling recursion won't prevent you from making requests. You can ask the dns servers for authoritative information or simply make non-recursive queries. The replies may be smaller, but they'll be larger than the requests. (once it's in cache, it no longer needs to be a recursive query. the trick then is to get it into the cache.)

Preventing IP spoofing (both at the router and the dns server) will stop this sort of crap.

only kidding, right?

[Anonymous Coward]

JehCt writes:
> 'To make a long story short, having a DNS server that
> allows recursion for the Internet is like running an open
> SMTP relay.'

JehCt wields a +7 bong of vision!
JehCt hits! JehCt hits! JehCt hits! -- more
You die...
Do you want to see your possessions identified? y[n]

the djb way

[Anonymous Coward]

djbdns is not a DNS server adherring to the RFC documents, i.e. it allows setting CNAME with SOA, while the standard does not permit CNAME with any data.

while it might look like a mistake which would get corrected quite quickly, this is a standard djb practice. for instance, qmail does not cycle to MXes with lower priority after a temporary failure.

this is a standard djb practice - applying the standards at his own discretion.

detailed technical paper on the subject

[GrayWolf42]

Was just released: http://www.isotf.org/news/DNS-Amplification-Attack s.pdf

DNS Amplification Attacks - A Smokescreen?

[DNSJohn]

We need to be careful in proposing a suggested solution.

Inclusive Namespace roots provide public resolvers for users whose ISPs are too stubborn or dumb to provide their users with choice. Customers of such ISPs can simply decide to use the public resolvers provided by the INS roots, like Public Root or ORSC.

Shutting off user choice by suggesting that ISPs block outbound 53/TCP, 53/UDP will take away that choice.

I'm sure that some ICANN synchophants will be happy about this and if I were the suspicious type, I'd say that this sudden "awareness" of a "severe security problem" that has been around for a long time may be planned by those who are becoming uncomfortable with the ever increasing number of people who are abandoning the ICANN root in favor of DNS Service Providers (DSPs) who provide a view of the entire internet and don't impose non-related policies (UDRP) on domain registrants.

What better way to kill the INS than by putting up a security straw man and scaring people, especially ISPs, into taking away DNS choices from internet citizens. I am especially suspicious about this after seeing who was quoted in the recent MSNBC piece about the so-called "new" security risk that has "just been discovered". His jihad against allowing internet citizens to have freedom to chose their DSP from among global choices is well known to all.

Watch out here - there may be more to this story than meets the eye...

Re:I must resist

[LilGuy]

I don't understand how this affects you in any way?

Now if only....

[charlesnw]

microsoft and sco and all the other evil corps hosted DNS with joker it would be alright. :) Has anyone actually been unable to get to sites because of this? 500,000 domains isn't that many really. And the sites thet the majority of the world visit (google/yahoo/slashdot/myspace) are all up and accessible. So I don't see what the big deal is. Unless this DdOS spreads to the rest of the name server system or causes it to overload.