OpenDNS allows us to maintain low network resource overhead on our (relatively) small network. Intuitive, flexible web filtering controls also help us enforce compliance over logically separated networks at our school for teachers, students, and non-academic staff.
Given the small to medium scale of our network architecture, our current gateway/firewall DMZ infrastructure is specced too low, and our budget too limited to accommodate more fully featured security appliances. While some organisations may utilise higher specced security appliances with powerful software features available directly on the device including user management, granular IP filtering and more, we must make do with lower spec appliances.
Furthermore, while our network is based around a gigabit fibre core, we have seen bandwidth utilisation increase greatly over the past several years due to cloud hybridisation of our infrastructure (AWS, Google Nearline, et.al.), and as a result are currently stretching the performance limits of what our current hardware stack can do. Given these limitations, the granular control which OpenDNS provides us for Web Content Filtering, malware protection and data logging are crucial in filling gaps in our network security stance.
To add, we are also an educational institution. Our standards for compliance, both internal and external, can be quite strict. We are beholden to security and compliance standards enforced by the Government of Japan, its Ministry of Education, as well as internal compliance enforced by our own Business Administration department.
This is not to mention the sort of 'soft compliance' which comes from the families of our students regarding how we handle sensitive data and personal records.
It has been our experience that the following features available within OpenDNS have helped us meet compliance reporting requirements quite readily:
- Botnet Protection
- Malware Protection
- Internet-Scale Malware/Botnet Protection- Phishing Protection
- Stats and Logs
The management interface for these features is highly user friendly and it is simple and easy to make configuration changes on the fly. This is important to us as specific security policies can and do change on a weekly or even daily basis. The size of our department also dictates that we do not have any single engineer dedicated to network security (or even networking) and so it is crucial that each of our members have the ability to log in and manage this service when needed.
All in all, I can not recommend OpenDNS as a one-size-fits-all solution for security and compliance, especially for larger organisations. I can, however, strongly recommend that any Systems and Network Engineering team consider this product on its merits regardless of scope. Personally speaking, this tool has proven itself invaluable in allowing myself and my team to perform our duties efficiently and securely.
Because we have a small sysadmin team, the less time we need to devote to responding to threats, parsing data logs and putting out fires, the better. OpenDNS saves us time in this regard, as well as providing fast and easy configuration control.
Difficult to answer as we haven't yet pushed the outer limits of what this product can do.
Nonetheless, one thing to keep in mind when using OpenDNS is how it will interact with your internal network and DNS architecture. You run the risk of breaking any local subnet DNS lookups in a domain-bound enterprise environment. While this criticism can be applied to other third-party DNS providers, it is nonetheless one reason for withholding a perfect rating.
Additionally, OpenDNS will handle server caching differently than your local service provider. This can cause service slowdown or interruptions, and generally prevents OpenDNS from becoming the "one-size-fits-all" solution that some would like it to be.
Finally, although this has never posed a problem in our environment specifically, OpenDNS has been known to grab NXDOMAIN records and redirect traffic to their own internal ad pages. Some people may find this unethical; however, that might depend upon whether you are utilising paid or unpaid services from OpenDNS as well.
I have been using for over a year.
We currently have OpenDNS deployed across two sites providing coverage to more than 500 active clients. No problems so far. We will be further expanding this year and hope to leverage OpenDNS web filtering at our new sites as well.
On the rare occasions we have used it, technical support has been prompt and professional, if a bit lacking in personal touch.
Previous infrastructure relied on router/gateway-installed software for filtering and security. It simply isn't enough for a modern network, especially not one as complicated and security-conscious as education.
With a basic understanding of networking, implementation should be straightforward. For non-technical people, there is probably enough documentation floating around that basic configuration is possible for anybody motivated enough.
An in-house team implemented it.
Implementation was a no-brainer. We do recommend notifying and educating users in advance of implementation to avoid potential headaches caused by sudden changes to filtering policies and such.
ROI for OpenDNS: time saved, checkboxes ticked, and organizational leadership satisfied.
Get a quote! You also need to weigh any licensing costs against potential risk factors. (I.e., what is the potential cost factor of not implementing this or other solutions?) OpenDNS licensing structure and policy is generally straightforward and easy to understand. In our case, managing a network in use by students, many of them younger, necessitates certain compliance and security implementations not found in typical corporate environments.
Plan out your security coverage and filtering strategy in advance of purchasing and implementation. Think about what role you expect OpenDNS to fill in your security architecture. Do you have Layer 3 security in place? Where do your vulnerabilities lie and what threats can you expect to counter?
"You run the risk of breaking any local subnet DNS lookups in a domain-bound enterprise environment."
Surely that's simply a matter of only routing *external* DNS requests to Umbrella?