Trilight Zone

[tricore]

The very heart of the Internet is the Domain Name System, or DNS. Protecting your DNS through best practices is not just a security issue, it's a reliability issue.

Compromises of DNS can expose a wealth of critical information about your network and the resources attached to it. This information could be useful simply on its own for competitive reasons, or (more likely) it could be used to make attacks on the network easier. A denial of service attack against a DNS server could make portions of or even the entire network inaccessible because DNS is necessary in order to do so many basic operations.

DNS can be tricked into serving false information through an effect called cache poisoning. Finally, because DNS runs on a computer, it can, if co-opted through attack like any other, be used to attack further systems.

This article will discuss a few techniques that can make such attacks less likely, and your DNS more reliable.

Don't go with the old

First, before addressing anything else, don't run old versions of DNS software, especially Bind (the current versions are 9.3.2, 9.2.6, and 8.4.7). Old versions generally have vulnerabilities that are well-understood in the hacker community, and thus can make your network vulnerable.

Second, intelligent redundancy is the key to high availability in DNS. Try to keep at least one redundant DNS server on a separate physical connection to your network. Keep the two servers (the extent possible) behind different routers, on a different subnet, and powered by different electrical circuits.

Arrange to have a separate slave server off-site, perhaps in a co-location server. Even if your entire infrastructure goes down, your DNS will still respond, and this can have important advantages. For instance, if your DNS doesn't respond, then outside SMTP servers sending mail to your domain will probably bounce messages back to the senders. But if the DNS responds and your mail servers do not, then the outside SMTP servers will usually re-queue and re-send the messages later.

Third, make sure to filter traffic to your DNS so that only necessary TCP and UDP ports, especially inbound, are open. Port 53 is the main port you need, but source ports above 1023 are also necessary.Fourth, lock down zone transfers so that only the proper ones will be allowed by Bind, or whatever you are using. There are also encryption/authentication standards, such as TSIG (Transaction Signatures) that make it almost impossible for an unauthorized user to compromise your zone data, and they're not that hard to use.

Separate event viewer

Microsoft provided a separate event viewer for the DNS Server; it's a good idea to check it regularly. You might, for example, see warnings in the log with an Event ID of 9999, indicating that the service has erratic network communications. This sort of thing is normal every now and then on TCP/IP networks, as there are often message collisions, especially during intense transfers.

But it could also be an indication of a denial of service attack. Are there just a few over a long period of time, or are there many of them persisting? The data value attached to the event indicates the number of events suppressed in the previous 15-minute interval. Many third-party management tools monitor event logs, and can be set easily to page you or perform other actions in event of conditions that you can define.

There are few elements on a network as key to its health as the DNS. If you don't keep it secure and well-maintained, odds are that you'll have problems that will affect many users.