DNS Newbie - Whats the best W2k DNS?

Hi all,

I am planning on purchasing a dedicated server in the near future. The new server will let me host my site and my client sites (approx 10 domains right now) on the same machine, give me some additional flexibility, and (most importantly) increase my profit margin.

The new box is a Windows 2K box (which will allow me to run MS SQL Server, all my back end stuff is based on that...)

I would like to host my own DNS server on the new box, which will allow me to have full flexibility with domains, subdomains, etc.

However, I have some concerns. Though I'm fairly technical, I'm not a network guy and I have fears about security and reliability. ( I have gotten BIND working successfully on my local machine in the past, but the deamon ended up bogging down my machine and I have no idea what security issues I was exposed to...)

So my questions:

1. What is the best, most secure, easiest to use, reasonably priced DNS server out there?

2. What types of security issues will I need to worry about upon implementing the DNS servers? What can hackers do, how can I protect myself, and how am I exposed?

3. Please provide any words of wisdom you can for this venture. What areas do I need to explore further.

Thanks for any comments, newbie to DevShed all around, hope I can find a way to contribute back to the community. I look forward to your posts...

Bill

I've never really researched exploits for specific DNS server brands and versions. However, I do know of various DNS protocol exploits which would apply to any unsecured DNS server, however as an authoritative (host as opposed to caching) server you wouldn't have any control over DNS cache poisoning attacks.

I do know that there were some buffer overflow exploits for older versions of BIND, though I know of no exploits that work on the latest 8 and 9 series of BIND. BIND is free and available for both platforms and there's plenty of support for it. I use BIND on a windows 2000 machine and I very much like it. I have noticed no "bogging" and am not quite sure what you mean.

Microsoft DNS Server isn't free and once again I don't know of any current exploits for it, but then this is not my area of focus. I do consider myself fairly familiar with the server however in helping other people and I can feel secure in feeling that it is consistent with microsoft bloat-ware. I don't like this server.

djbdns is the last of the servers I've heard about and is worth mentioning. I know very little about this server, but I've had no problem with what I've heard. I believe this is a free server, but I don't know if it is available for the windows operating system, though it probably is.

For the BIND thing - all I know is the process ran away with the CPU for some strange reason....

Thanks for the list of ones to stay away from. I'll download the latest version of BIND and play with it. Am I hearing you right that basically I just need to make sure I have the latest version, the DNS software should take care of the security issues for me? Is it that simple?

Also, I saw this SimpleDNS software out there - any insight into this package?

Thanks!

I'm not sure. I tinkered with a couple DNS servers before I finally chose BIND, but I don't remember which ones. BIND is by far the most widely used, and it is free/open source and I like how it conforms to RFC defined standards. I would rather edit a master text file than a database any day.

Considering that DNS was originally intended to be a PUBLIC database, there's almost no need to worry about security. There's a dozen small things you can do to keep a tight DNS server, but really none of them are required. I haven't cared about my DNS server's security until I decided to enable dynamic zones where you can remotely change your DNS information. Under this unusual configuration security is VERY important. But you have to enable such things explicitly.

I posted a thread few months ago regarding to djbdns vs. BIND -> BIND vs. djbware flamefest. It was a followup to another thread which I forgot totally. Sorry, it doesn't run on M$ though. I used to run BIND for many years but its poor security record and system-resource-hungry and unreliability made me switch to djbdns.

Interesting thread, unfortunately I'm married to Windows for now so the Linux stuff is not an option. My new toy will have only 256K RAM, so memory may become an issue (esp. since I hope to eventually run some Java servers in addition at some point...)

Would love to hear more about those "dozen" things to keep a DNS server secure if you gt bored enough to indulge me - just really having a hard time getting my mind around the issue, maybe I'm just making it more complicated than it has to be...

Thanks again guys!

That was quite a reading. I think both of you put on a rather embarrassing display, but, there was a lot of good content at the same time on both sides of the argument.

In all of that, and after my extensive research in reguards to DNS security, I have only one thing to say. Keep in mind that this comment is not a bash on DJB. Rather, it is a bash on ANY DNS server software that has no encryption support for all kinds of DNS transactions whether it be between server to server, master to slave, client to server, or anything else you can think of. If DJB has encryption support for all DNS transactions (even if they are proprietary) then DJB is not included in my bash.

At the same time, estekguy, you will learn something about why the DNS protocol without encryption is insecure reguardless of the server.

== BEGIN: DNS Insecurity 101

If you don't implement cryptography in DNS transactions then you can be spoofed and cache poisoning can happen. That is the fact of the matter in terms of middle man attacks. I don't care if you're BIND, or djb, or a God inspired DNS server creation. This cannot be prevented as shown below:

For the purposes of this outline, "DNS Resolver" is defined as a dns resolving server such as bind or dnscache which performs as the main ISP resolution service for their customers.

Step 1) DNS resolver queries the root servers and eventually gets the authoritative server address for "www.yahoo.com" which is 66.218.71.63 (ns1.yahoo.com).

Step 2) DNS resolver sends a UDP request to 66.218.71.63 to resolve "www.yahoo.com".

Step 3) However, it just so happens that a gateway router to the yahoo network was hacked and is intercepting DNS requests.

Step 4) hacked router then sends a message back to the DNS resolver with "66.218.71.63" as the source IP. The reply contains the IP address for 12.34.56.78 which is a www.yahoo.com relay address where it logs all transactions between you and the REAL www.yahoo.com server to steal any and all your yahoo held private information. (NOTE: SSL won't even protect you against this kind of middle-man attack)

Step 5) DNS resolver recieves this reply and checks the source IP, port, DNS packet ID, and all check out to be genuine. It will then cache this response for up to the amount specified in the record's TTL field as sent by the hacked router.

Step 6) All customers of that DNS resolver's ISP will then get the IP address to the fake yahoo website and are then compromised until the cache expires.

This is called DNS poisoning.

== BEGIN: DNS Security 101 (TSIG)

TSIG and SIG0 are two forms of transaction authentication. In my research of both, I found TSIG more to my preference for what I needed, so I will discuss that since I am more familiar with that. For this lesson I will demonstrate the usefulness of TSIG in transaction authentication between masters and slaves.

(NOTICE! To keep things simple, I have left out some details of the cryptography implementation)

Step 1) Both master and slave(s) must be configured to use a private key not accessible by anyone else.

Step 2) Master constructs a DNS NOTIFY packet to inform the slave(s) that a zone change has taken place.

Step 3) Master uses the private key on the DNS packet data to result in a MD5 digest of the two. This digest is then placed within a TSIG record which is appended to the DNS packet. This combined packet is then sent to the slave.

Step 4) The slave removes the TSIG from the packet and then performs a MD5 digest of that packet data and it's configured private key. It will then take this digest and compare it against the digest of the sender's TSIG and if they are identical, then the packet is confirmed to be authentic.

Step 5) The slave then acts on the request and requests cryptographically authenticated zone transfers from the master.

So what if a middle man attack was used like shown in the original outline?

Step 1) Hacked router intercepts the TSIG authenticated zone transfer response FROM the master TO the slave.

Step 2) The router attempts to keep the packet identical to the original except it changed a single IP address. This packet is then forwarded on to the slave.

Step 3) The slave recieves the response and removes the TSIG record. It then performs a MD5 digest on the private key and the packet data. However, the ORIGINAL packet data is different from the MODIFIED packet data so it results in a digest which is NOT identical to the digest in the TSIG record. Authentication fails and the slave discards the reply and may attempt to request another zone transfer later. The hacked router could not change the TSIG digest to match the modified data cause it does not know the private key! So therefor, you finally have transaction security.

==

Fascinating stuff isn't it?

I read through once and now my eyes are bleeding

Seriously, thank you for the info. I need to read through your post carefully and see how much I understand... but I think this is the road I need to go down to understand my exposure.

Thanks all, I think we're getting there...

sorry if I got a bit technical. If you have questions like the relationship between masters and slaves and what they are, then feel free to ask. My speech was more in response to the debate between freebsd and rsowner rather than to your need to understand security, so I may have gotten a bit technical as a result.

I like technical - gives me the whole story and a map of what I need to learn. I think your answer did address my question! Just need to do some homework. Anyway, pls keep it coming!

It wasn't about embarrassment but aggressive tones that we used.


So you claimed to be on the neutual side and get the whole picture, but I don't think you do because of your one dimensional expeience -> BIND only.


You need to learn more from here instead.


Like I just said, your DNS knowledge is insufficient to speak for djbdns. Apparently you don't even know what djbdns can do when you combine whether it be between server to server, master to slave, client to server, or anything else you can think of and confuse audience when djbdns only consists of: server to client and client to server.
Bringing up master to slave and TSIG is just non-sense because BIND reinvented the wheel. In practice there is no such thing as "zone transfer". Need I say more? I am tired, go here and here yourself. And please stop using DNS transaction, be explicit on which exact transaction.


Unfortunately your speech fits nowhere. Do a little more research and trials, then come back in a year or two.

Freebsd - Though I appreciate you contributing, this is not what I'm looking for here. Kindly take this pursuit elsewhere, it's not helping this thread.

estekguy: I'm replying to freebsd in this topic, but only cause I'm including some points which you may be interested in. I'll try to keep it impersonal.

"DNS Transaction" is meant to be defined as a DNS query/response between one entity and another.

I just want to reiterate that my DNS cache poisoning was a discussion of a vulnerability in the DNS protocol reguardless of which DNS resolver software is used. Any DNS resolver software that sends a DNS packet to an IP address with the intention to recieve a response is vulnerable to this type of middle-man attack. All DNS transactions (without encryption authentication) are vulnerable to this type of middle-man attack. It is a fundamental flaw made possible by the spoofing in the TCP or UDP layer. The implementation of middle-man attack that I described was just one of many ways that IP spoofing could be used to exploit DNS.

If you still have doubts freebsd as to whether djb is vulnerable to DNS cache poisoning then I am willing to bring in references which has nothing to do with djb or BIND or any other DNS software because it applies to ALL servers. As of now, authentication in general resolution is impractical (until a different type of authentication that use "public keys" is fully standardized and implemented). So the blame is not placed on djb here. I have never spoken a bad word about djb in my history here. I am open-minded about such things.

For the record. I could be 10, with no experience with any DNS software and my words would be no less wrong and no more right. Experience and age is irrelevent. But only because I have not spoken beyond what I have researched and learned. I will never bash djb or any other software directly until I have factual research to back me. And even then, it will only be on specific points. There is no point to debate on whether one software is better than another for it is all opinion. It is good enough to list the differences, that is all.

This is what you should have mentioned because you said:

"If DJB has encryption support for all DNS transactions (even if they are proprietary) then DJB is not included in my bash."

but you did not mention impractical use and standardization which could mislead audiences by thinking that djbdns is at disadvantage for not implementing authentication.


Zone spoofing is not avoidable but unlike BIND which caches good answers and negative answers which is more exploitable, djbdns only caches answer that can be traced to roots.


estekguy, this thread doesn't belong to you. BTW I never thought of your existence in here anyway.