...making Linux just a little more fun!
Ronald Nelson [rnelson at kennesaw.edu]
Thu, 28 Sep 2006 11:26:24 -0400
I am a member of the network group at a university in Atlanta Georgia, some time ago we had a minor DOS from off campus to our main DNS server, at that time we decided to only allow outside connections from our service provider (Peachnet) and block all others with our firewall. We seem now to have a problem with the root "EDU" servers.
;; AUTHORITY SECTION: edu. 172800 IN NS M3.NSTLD.COM. edu. 172800 IN NS A3.NSTLD.COM. edu. 172800 IN NS C3.NSTLD.COM. edu. 172800 IN NS D3.NSTLD.COM. edu. 172800 IN NS E3.NSTLD.COM. edu. 172800 IN NS G3.NSTLD.COM. edu. 172800 IN NS H3.NSTLD.COM. edu. 172800 IN NS L3.NSTLD.COM.They cannot resolve anything in our domain including our primary DNS server. Do we need to include these servers in our rule base ? How do we protect against a DOS attack on our DNS servers ?
thanks Ron Nelson 770 403-2135
Benjamin A. Okopnik [ben at linuxgazette.net]
Thu, 5 Oct 2006 12:37:09 -0400
Hi, Ronald -
On Thu, Sep 28, 2006 at 11:26:24AM -0400, Ronald Nelson wrote:
> I am a member of the network group at a university in Atlanta Georgia, > some time ago we had a minor DOS from off campus to our main DNS server, > at that time we decided to only allow outside connections from our > service provider (Peachnet) and block all others with our firewall. We > seem now to have a problem with the root "EDU" servers. > > ;; AUTHORITY SECTION: > edu. 172800 IN NS M3.NSTLD.COM. > edu. 172800 IN NS A3.NSTLD.COM. > edu. 172800 IN NS C3.NSTLD.COM. > edu. 172800 IN NS D3.NSTLD.COM. > edu. 172800 IN NS E3.NSTLD.COM. > edu. 172800 IN NS G3.NSTLD.COM. > edu. 172800 IN NS H3.NSTLD.COM. > edu. 172800 IN NS L3.NSTLD.COM. > > They cannot resolve anything in our domain including our primary DNS > server. Do we need to include these servers in our rule base ?
I'm not really sure that this has anything to do with Linux, but since running a DNS server is such a common thing to do on a Linux box, I'll give a shot at answering this one.
I certainly can't call myself a DNS guru, but the problem as stated seems a bit simplistic (if an upstream non-authoritative server can't get to your server to do a transfer, then - of course - it's not going to be able to resolve for you once that refresh interval has elapsed.) However, if you're asking something more complex than that - and I have a feeling that you are - then you need to a) frame your question beter (i.e., what is in your rule base? What transfer method are you using? What DNS server software? What firewall method?) and b) give us more pertinent information (i.e., what have you already tried? What information did you get from your troubleshooting so far? What IP/domain name[s] are you using? [1])
Ron, I suggest that you take a look at "Asking Questions of The Answer Gang" at 'http://linuxgazette.net/tag/ask-the-gang.html' and see if following the suggested process brings up any new insights. If you still don't have it solved, feel free to write us again - but do include as much relevant information as possible next time.
[1] This may not matter much, given your stated firewalling policy, but we might have somebody here who has access to Peachnet and can do some DNS lookups. Stranger things have been known to happen.
> How do we protect against a DOS attack on our DNS servers ?
Good, complex question. The answer is, "it's tough but there are some things you can do to both prevent and mitigate it." On a larger scale, the problem is like that of spam: it's going to take a critical mass of smart, educated sysadmins and self-policing in the DNS world to really bring that stuff to a halt. Here are the things that you can do (other folks with a DNS clue, feel free to jump in):
1) Vet your rule set carefully to prevent UDP-based spoofing.
2) Configure your servers to do recursive look-ups for your other DNS servers only (by "your", I mean "domains you trust" - not necessarily servers under your direct control.) Don't do recursion if you don't need to.
3) Delete RR records for expired domains.
4) Ask your ISP to find out what they're using - if anything - to detect and block that kind of traffic. If they're not, use your leverage to gently hint (using a large, blunt implement if necessary) that they should visit the year 2006 once in a while.
5) Get familiar with how these attacks work. I recommend the well-written "DNS Amplification Attacks", by Randal Vaughn and Gadi Evron ('http://www.isotf.org/news/DNS-Amplification-Attacks.pdf') - it focuses on DDoS attacks, which are a superset of DOS attacks. The authors have suggestions of of their own, which are also important:
* DNS name servers facing the world should not be the same ones
serving users or clients in your network.
* Limit usage of the DNS name server and the recursive functionality
to your network.
* Implement spoofing counter-measures such as those suggested in BCP
38 and SAC004.
That should be enough to keep you busy for a while. 
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *