As has been recently pointed out by both SANS Institute and The Measurement Factory, DNS is clearly not working. Year after year, surveys have shown that public DNS servers are compromised by security problems that threaten the stability of the entire Internet.

I recently had a discussion with a distinguished gentleman who has been working in and around this problematic area for a rather lengthy time. As I was rather interested in his take on this topic, I asked him if he had any idea as to why people were so hesitant to make changes to their DNS servers to resolve the associated problems. His response was rather interesting.

In his view, the problem isn’t so much about reluctance to fix DNS related problems. Rather, he said that networking professionals tend to be rather skeptical about touching functional DNS installations, in part because screwing them up would be a sure way to interrupt a network’s operation and to cause havoc, and on the other hand because DNS servers are often used to run also other TCP/IP services alongside DNS. This in turn makes these servers more complex, which raises the bar for tweaking them. If it works don’t fix it, as the old adage goes.

Running other services in a DNS server is actually a security threat cited by SANS Institute in their latest 2006 update of Internet Security Attack Targets listing. The reason for this is quite simple: if a server runs both DNS and, say, sendmail, one doesn’t need O/S or DNS vulnerability to hack into the system. A hole in sendmail is enough to do the trick (and there have certainly been some security flaws in sendmail over the years).

To get rid of this problem for once and for all, there are actually two optional approaches that are now available:

Virtualization
If there is a specific reason as to why an organization wants to run several TCP/IP services in a single physical server, the best way to build a secure, dedicated DNS server is to run it in a virtual server. With several virtual servers or virtual appliances in a single physical server, organizations can run several services side by side while keeping them secure. There are several options to choose from ranging from VMware to open source solutions such as XEN.

DNS appliance / dedicated DNS server
If there is no specific need to run all services in the same physical server, another good way of securing DNS is to run an appliance. Admittedly, dedicated DNS appliances have been fairly expensive in comparison with traditional DNS servers. However, with software appliances making their way to the mainstream, setting up a dedicated DNS server appliance is not expensive at all. We have just certified Nixu SNS on HP ProLiant series, which means that the investment required for a dedicated server starts from significantly below $2,000.00 (US). That’s less than half of the cost for traditional hardware-based DNS appliances.

Regardless of whether you decide to proceed with a virtual appliance or a dedicated DNS appliance, they both offer two significant security benefits. Due to their purpose built design, they are more secure than servers that run other services alongside DNS. Also, because appliances automate the maintenance and software update processes, they are patched automatically whenever new vulnerabilities are found. This reduces the workload at customers’ end as the DNS servers are maintained for them, which otherwise would be somewhat time-consuming and therefore costly. And last but not least, DNS appliances tend to be easier to live with because they are supported and offer tools that cannot be found in DNS server implementations running plain BIND.

On November 15, SANS published 2006 annual update of the Top-20 Internet Security Attack Targets. Each year, some of the most security conscious organizations from all over the world help SANS in compiling this list based on severe vulnerabilities that have been discovered during the last 12 months or so. If any network service or product that has made this list has been safe for more than 12 months, it gets dropped out.

As you may have already guessed, DNS made it on this list – to see the DNS part of the annual update, please click here. This year, the major problem with DNS has been DoS attacks – many of which were caused by the BIND vulnerabilities discovered last spring. To take a look at the related vulnerability announcement, please click here.

What strikes me the most with SANS’s Top-20 is that DNS and BIND have made the list every single year since SANS started publishing it in 2000. Yes, that’s every year for seven years now. And so, one would imagine that the network community would like to do something to address the associated security problems, DNS being one of the most critical TCP/IP services and all.

If you would like to make your own public DNS servers secure, please take a look at Nixu SNS (Secure Name Server) that we launched in October. It provides you with two distinct advantages over any other DNS server, including plain BIND:

• Nixu SNS is more secure. It runs on hardened Linux platform, has a built-in Intrusion Prevention System that blocks port scans, DNS DoS attacks and DNS cache poisoning attacks, and provides you with software updates and security patches automatically. Please see our DNS Security White Paper for further details.

• Nixu SNS has lower TCO than BIND. Yes, that’s right: it’s cheaper than “free”. That’s because once you think about it, there’s no such thing as free software: even if the download itself didn’t cost anything, someone still has to pick up the costs associated with installation, hardening, maintenance, testing and support. As Nixu SNS automates these processes and as we sell the annual subscriptions at $495 per year, running Nixu SNS is much cheaper than running plain BIND in a secure fashion.

So there you have it: Nixu SNS offers better level of DNS security at lower cost. If you’d like to download Nixu SNS for free evaluation, please click here.

During the 2005-2006 period, the number of external DNS servers has grown by 20% from 7.5 million to 9 million installations. Roughly 75% of these are BIND servers, and I would assume that relatively high percentage of them – especially the new installations – are running on Linux. According to a recent survey by The Measurement Factory, a large percentage of these servers are somewhat insecure making them perfect targets for DoS attacks and cache poisonings.

While I think Linux and BIND as such are beautifully suited for most external DNS implementations, I would urge anyone active in this area to make sure that they are secure. Otherwise your organization becomes a sitting duck for malicious individuals.

But on a general level, I think Linux and BIND offer a great basis for a secure Internet name server, as long as they are installed, maintained and configured diligently and securely. This is actually one of the reasons why I liked Microsoft’s decision to start supporting Linux: their customers are now better equipped to secure their external DNS with MS’s blessing. Before, Microsoft would have urged them to use Microsoft DNS on external servers, which may not be the best of ideas from the network security point of view. Now, also they can recommend better solutions.

In internal networks, it’s a different ballgame altogether. A rather high percentage of internal DNS implementations are based on Microsoft’s Active Directory / Domain Controller, largely because the server software is readily available and perceived to be ’sort of free’. As such, running AD in isolated workstation networks is no problem – as a matter of fact, as most hosts in a typical workstation network are dynamic and require virtually no manual intervention (often with the sole exception of a network printer with a static IP), AD is actually quite well suited for the task.

The problem with Microsoft’s DNS implementation in internal networks becomes apparent if there are many AD servers. This is because all Microsoft AD based DNS servers think they are DNS primaries, and use LDAP to update all other Microsoft DNS servers in the network. As the number of AD servers increase and as they all get new dynamic updates on on-going basis, the amount of traffic also increases as AD servers become rather talkative in installations such as this. I once had the pleasure of seeing the network architecture of one of the largest companies in the world, who had hundreds of Microsoft AD servers in their enterprise network – I don’t think their internal DNS ever reached a stable state, not to mention that their global enterprise backbone was badly bogged down by the traffic caused by the AD servers.

And this, my dear readers, is the second reason why I welcomed Microsoft’s official support for Linux. The best way to reduce the amount of Microsoft DNS related traffic in a network is to isolate each workstation network running AD, and add a lower DNS layer in the enterprise network that is implemented using BIND-based DNS solutions. The static IPs (network printers) in isolated, AD-based workstation networks can be propagated to this lower DNS layer using dynamic DNS, and all other static DNS entries (e.g. servers) can be added and managed on this very same DNS layer. This makes DNS management easier, allows it to be stable, and reduces the bandwidth consumption created by AD servers (as they are isolated, they don’t have to update each other constantly).

Previously, this really wasn’t supported by Microsoft because they wanted to put Microsoft AD everywhere. At least officially. But now that Microsoft supports Linux, this approach has suddenly become a legitimized option: organizations can implement more intelligent DNS architecture at very low cost. The bandwidth savings alone make this a very attractive proposition.

So at the end of the day, I think the recent developments surrounding Linux may actually have a positive impact on Domain Name System.

Let reason prevail!

During the recent times, there have been several developments that are likely to have an impact on the way CIOs and CTOs of large enterprises view Linux. Whether this will lead to a fragmentation of the Linux market, remains to be seen.

First, Oracle announced that they will start offering support contracts for their own Linux distribution which is essentially a RedHat Enteprise Linux without the RedHat logos and trademarks. Interestingly enough, it seems that Oracle has chosen pretty much the same approach as CentOS. I doubt this is a coincidence, as CentOS distribution of Linux has been gaining a lot of traction during the recent year or two.

Then, Microsoft and Novell came out with their announcement in which Microsoft basically legitimized the usage of Linux in connection with their products. In my view, this was mostly a reality check on the behalf of the good people of Redmond, as most organizations have been running mixed networks for years. And on the other hand, Microsoft really didn’t have much choice in terms of the Linux distribution they would support, as Oracle, RedHat and CentOS are already working on RHEL.

In many ways, Microsoft’s move was much like opening up Pandora’s Box: it’s hard to believe that the impact will be limited to SuSe Linux, especially as Oracle is pushing their RHEL based edition of Linux at the same time. What I do hope is that this situation doesn’t lead into the fragmentation of the Linux market; at least not to the extent that it would ruin the interoperability between different Linux distributions. After all, the power of open source software is that it is – hmmm – open.

I will be posting Part 2 of Legitimizing Linux within the next few days. In that blog, I’m planning on digging deeper into how all this will affect DNS and IP addressing technologies and markets going forward. So, please stay tuned for more.

It certainly seems like a demand for a blog on DNS existed before we took up on the idea. After only six weeks, we’ve had more than 4,000 readers from more than 80 top-level domains – that’s nearly one half of countries in the world, and much more than I ever could have hoped for within such a short timeframe. And so, I would first like to say a big “thanks” to all of you patient enough to spend time on my wanderings in the wonderful world of DNS.

But now, let’s move on to the good stuff: November’s Classic.

Unlike in October, I thought we could perhaps forget about papers this time around and move on to more pragramatic online materials on DNS. After all, anyone who read October’s Classic should now be in the know about security considerations that should be taken into account when building up a DNS server.

Enter November’s Classic: DNS Oversimplified by R. Scott Perry.

While this online resource is updated on continuous basis, I think it none the less constitutes a ‘Classic’ as I believe this site has been online since 2000. And as you already know how an internet name server should be secured, I thought it would be equally important to make sure that it has been configured appropriately. After all, even the most secure DNS server doesn’t do much good if it hasn’t been configured properly.

DNS Oversimplified provides a simple yet fairly thorough six-step guide on how to check for, and avoid, the most common errors in DNS server configurations. It also includes some links to tools that can be used for more comprehensive DNS checks if that’s in the cards.

ISC announced late last week that vulnerabilities found in OpenSSL library may also affect BIND users.

If you are running Nixu SNS and have enabled automatic updates, your DNS servers will be updated/patched automatically and you do not have to take any further actions.

If you are running Nixu NameSurfer as the (hidden) DNS master but not Nixu SNS, and are affected by this vulnerability, you should manually patch/upgrade the secondary BIND servers used in the DNS installation. We will also include a secure version of BIND in the next Nixu NameSurfer release / software package.

To see the advisory, please click here.

To download a patched version of BIND from ISC, please click here.

I don’t think I have ever seen the words ‘ecological’ and ‘Domain Name System’ used in the same sentence. That could well be because the two are not generally perceived to share much in common. At least I didn’t think so.

But after a friend of mine from the UK went to see An Inconvenient Truth featuring Al Gore and sent out a worried message to everyone in his address book, and as another friend from the US abandoned his huge SUV and started driving around in a rather ecological Toyota Prius almost in parallel, I couldn’t help but to start thinking about DNS from the ecological point of view:

What could we do to enable the networking community to run their DNS implementations on a smaller ecological footprint?

The first thing that came to mind was the energy consumption of servers. As we all know, servers generate quite a lot of heat and to cool them down, one oftentimes has to use air conditioning. That’s actually not very surprising, as the world uses more energy to cool places and things down than they do to warm them up. But as I’m sure there are organizations much better equipped to address these issues (we’re neither hardware component manufacturer nor air-conditioning vendor – let alone a utility company) this thought ended up being a bit of a dead-end.

And then it hit me: software appliances are more ecological than hardware-based appliances because they can be downloaded from the Internet and installed locally, whereas hardware-based appliances get shipped around a lot – usually by air. And so, adopting the software appliance approach actually does make an ecological difference as there are less airplanes involved in the supply chain.

Of course, one does need a general purpose server on which the software appliance is installed. But as the supply chain for general purpose servers is significantly shorter and more efficient than it is for hardware-based appliances, general purpose servers are more environmentally friendly. So from the ecological point of view, it would be best to either continue running the existing, software-based DNS servers, or alternatively switch to a DNS software appliance. Hardware-based DNS appliances are not in par with the two in terms of ecological footprint because of their long supply chains.

When we started thinking about developing a DNS software appliance – Nixu SNS – I have to admit that we were not thinking about energy-efficient supply chain. No ma’m, we were thinking about a cost-efficient supply chain instead. But it’s actually quite rewarding to notice that sometimes, cost-efficient and ecological do shake hands.