2006 has been a really interesting year for both Nixu Software and myself. While we have had a lot of things on our plate, it has been rewarding to notice the positive reception our work has received: after just a little over two months, tens of thousands of people from all over the world have visited our website to learn what we are doing. And yes, we have just annouced the first delivery of our new DNS turnkey solution consisting of Nixu NameSurfer Suite and Nixu Secure Name Server (SNS) to MidtVest Bredbånd, a Danish ISP planning to offer Triple Play services (VoIP, IPTV, Internet) over a fibernet.

And so, I would like to take this opportunity to thank all my readers for following up on my wanderings and the interest you have shown in Nixu Software. For the next week or two, let’s focus on our loved ones instead of DNS!

Happy holidays and all the best for 2007!

Two weeks ago, I attended an industry summit in Southern France. As it happened, I ended up dining next to a person responsible for certain service provisioning key accounts at one of the world’s leading open source software vendors. In the course of our discussion, we ended up touching some aspects of service provisioning business that I had not thought about (or heard of) before.

Apparently, there is a publicly listed Internet Service Provider somewhere in Europe who ended up having a business problem. Namely, during their annual financial audit, one of their auditors realized that this ISP was running their service provisioning platform and certain services on an open Linux OS that was maintained and supported in-house. Long story made short, the auditor was not happy about this at all and decided that all booked revenues that had been earned using these platforms would have to be erased.

According to the auditor, if the revenue is not “insured” (i.e. produced using software supported and maintained by third-parties that can be held accountable), it will not be accounted for either because there are too many uncontrolled variables. The risks are simply too high.

As the open source movement is growing stronger by day and as open source software will find its way into service provisioning platforms and mission critical enterprise networks, it will be rather interesting to see how the auditing industry will react. While small and some mid-sized organizations may perhaps continue using open source software supported and maintained in-house, larger organizations will most certainly require that the software they use – whether proprietary or open source – is supported in order to assure business continuity and to minimize risks. This will require a new ecosystem of companies who do not make their living from proprietary code, but from assuming the responsibility of designing, implementing, supporting, and maintaining solutions based on open source software.

While DNS and BIND have been traditionally supported in-house, I believe the situation may change going forward. This stems from the fact that while BIND has been a general exception to the rule in the world dominated by proprietary O/Ss and applications – I doubt many CEOs or auditors are aware that their organization is running unsupported software – it will most likely be included in the same unsupported category with all the other pieces of open source software when detected by the corporate risk management radar. And at that point, most organizations will require that any open source software used in their network is supported by someone. That’s going to affect also DNS and BIND.

While our mission is to offer DNS solutions that are easier to use, more secure, and have lower total cost of ownership than traditional open source based DNS solutions built in-house, it’s also worth noting that we assume the responsibility for on-going maintenance and support for any DNS and IP address management solutions that we deliver. When all these four considerations are added up, I genuinely believe there are not many companies out there who would offer a better value proposition than we do.

DNS is one the few applications that dates back to the pre-firewall-era of Internet. As some information security experts have recently pointed out, firewall administrators often shun away from interfering it as that could potentially have dire implications on functioning networks. As a result, there are tens of thousands of organizations out there in which no one assumes the full responsibility over DNS security.

The unwillingness to touch DNS servers stems from the fact that protecting them is not quite simple. This is largely because configuring appropriate firewall rules for DNS servers is not a trivial task: while anyone anywhere should be able to do legitimate DNS queries, it is equally important to protect DNS servers from malicious attempts to corrupt data on them or to do port scans, as well as to protect them from Denial of Service attacks. Because of the associated complexities, also firewall vendors try to keep an arm’s length from DNS.

This is not necessarily a bad thing, especially if proactive security measures are being used. For example, if an organization that has implemented an Intrusion Prevention System in their network would also use it to protect their public DNS servers, almost anyone anywhere would have an indirect access to that organization’s firewall rules. Not a very appealing scenario to most network administrators.

At the same time, the number of public DNS servers is growing by 20% per year and many of them are sitting ducks for malicious Black-Hat attackers because of vulnerabilities and misconfigurations. As well-functioning DNS is a prerequisite service for virtually any network-enabled application in the existence, it should be protected accordingly.

Because DNS dates back to the pre-firewall-era, we have come to realize that the best way to secure it is to build DNS servers so that they do not rely on the security measures used in the rest of the network. In practice, this means that firewall rules have to be specifically designed for DNS and that proactive security measures such as Intrusion Prevention System should not interact with other servers within the network.

By taking local security measures on DNS servers and by isolating the Intrusion Prevention System from the rest of the network, we can make sure that the outside world can only impact a single DNS server while other servers and their firewalls remain intact. The higher the number of individual DNS servers within this setup, the more difficult it becomes to cripple an organization’s Domain Name System.

We further believe that the software appliance approach is an ideal model for this approach. This is largely because it provides organizations with an inexpensive way of building DNS redundancy as well as automating the complexities associated with DNS firewall rules and proactive DNS security measures.