The third loss we experience as a result of using external DNS resolution servers instead of operating such servers locally on our own campus is in monitoring. Most malware and most botnets make use of the DNS to reach their command and control operators, and some use the DNS as a steganographic exfiltration channel for the victim's personal information. Every modern DNS resolution service has some way to monitor "outbound" traffic to detect insider threats. However, to get the benefit of such monitoring, it's necessary to see your own traffic. If every application running inside the network has a direct relationship with an external DNS resolution service, then only the operator of that service — not the organization's IT administrator himself — will be able to monitor that traffic for threats. Some of these resolution service operators offer monitoring to their users, but most do not, and those that do sometimes monetize their observations of that traffic. (This is known as "surveillance capitalism." For example, the DNS queries coming from the customer of an ISP might be data mined for keywords that are then used to send focused advertising content to that customer.)
The fourth loss we can experience from using an external rather than a local DNS resolution service is control. Modern DNS technology includes the capability of policy enforcement, whereby malicious DNS patterns are rejected by the resolution server based on policy settings (from the local security operations center) and policy subscriptions (from external security information providers). Policy of this kind can reject resolutions based on known-bad domain names, name server names, name server addresses, or distant mail/web/content server addresses. However, this incredibly powerful capability is available only to operators of local DNS resolution servers. Some external DNS resolution providers offer this kind of policy filtering but without the fine-grained control that a locally operated server can provide.
Despite this growing shift toward external DNS resolution services, it's not necessary to completely choose only one way that DNS resolution is provided to all local users and servers. A mixture of internal and external DNS resolution consumers is not only possible but quite common. The DNS resolution service to be used by a server is usually set in its control panel or in the private cloud's control panel, whereas for a desktop or laptop or mobile device, it is set in the control panel of the DHCP server. So, it's possible to experiment and to experience a very gradual and surprise-free transition from use of external DNS resolution servers to internal ones.
Every open source server platform, such as Linux or BSD, offers many free implementations of the DNS resolution service. The oldest of these is called BIND, but newer implementations such as PowerDNS, Unbound, and Knot are also well-trusted, production-ready software packages. Most will offer some kind of template configuration that includes local DNS resolution. While you certainly will tune and enhance that configuration over time, the "jumping in" cost is extremely low. Commercial products are also available for DNS resolution, from vendors such as Microsoft, Infoblox, Nominum, BlueCat, and others.
Diversity is essential. Every campus needs at least two independent DNS resolution servers, ideally situated on different LAN segments with different power sources. Safe configuration is also essential — operators must ensure that no query coming from outside the network will be answered because this is a well-known and quite popular method for attackers to amplify their distributed denial-of-service capacity. It's worth spending half a day studying documentation, HOWTO files, and forums before turning up any new service — but that's especially true for a DNS resolution service.
The general outline of activities related to establishing and operating a local DNS resolution service on your campus is as follows:
- Research and experiment to find a solution and configuration you can live with initially.
- Deploy at least two diversified internal servers, which are probably virtual servers.
- Configure management to cause software, configurations, and updates to be automated.
- Conduct testing, from both on-campus and off-campus, to ensure correct (and only correct) operation.
- Monitor, including both operational events like reachability, but also transaction logging.
- Reconfigure a small set of test subjects, including some servers and some end users.
- Maintain a watchful settling-in period to gain measurable confidence about the new methodology.
- Reconfigure a larger set of test subjects or, perhaps, the remainder of the campus.
- Deploy a testing server for experimenting with automated logging and policy filtering.
- Research and experiment on different alternatives for transaction monitoring.
- Research and experiment on different alternatives for resolution policy filtering.
- Perform a gradual rollout into production of new solutions that have good results from experimentation.
Operating one's own local DNS resolution servers is one of the simplest and lowest-cost things an IT administrator can do to monitor and protect their applications, services, and users from potential risks. These risks — including surveillance capitalism, unmanageable external dependencies, attacks carried via DNS, and attacks that could be detected via DNS — have a much higher potential cost than the mitigation strategy outlined here. Additionally, the DNS resolution service is so central to every other IT-related activity that any and all IT administrators who take the time to investigate and master this technology will amplify their effectiveness and the value they bring to their enterprise.
Black Hat Europe returns to London Dec. 3-6, 2018, with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.