This whitepaper describes the challenges that hybrid, multi-cloud architectures present for network teams, specifically related to IP address management, DNS and DHCP (DDI). These include: 1) Achieving and maintaining universal, 360 degree visibility into an organization’s IP space, namespace and DNS records without hindering rapid innovation and application development by cloud and devops teams; 2) Establishing control of DNS resolution paths to provide the best end-user experience and optimal network performance while minimizing architectural complexity and data conflicts that result in costly downtime; 3) Securing access to critical applications and data at the DNS layer by establishing intelligent least privilege security policies.
This whitepaper explores how emerging network technologies are driving digital transformation forward. We consider how disruptive network technology trends, modern network needs and gaps, a vision for future-ready services, and how organizations – even those lagging behind – can catch-up and take the lead in delivering an improved customer experience both now and in the future.
High-availability Global Server Load Balancing of general Internet browser based services is best accomplished by including the use of multiple A records, but the use of multiple A records debilitates DNS based global server “load balancing”.
PCN is proud to announce the launch of our new website at https://pcn-inc.com. Our goal is to create a user-friendly browsing experience for clients, partners, and prospects visiting our site. With a mix of articles, videos, and service offerings, our website serves as a resource for DDI (DNS, DHCP, IP Address Management), GRC, Service Desk and Staffing information. We are also excited to have launched a blog and look forward to sharing ideas and resources with you.
Routine activities such as managing DNS and DHCP, assigning IP addresses, creating and managing subnets and reporting and auditing device connection history can take more than their fair share of time and resources. Moreover, concentration of DNS, DHCP and IP address management expertise in fewer hands makes organizations heavily dependent on a few individuals without adequate backup.
DOT and DOH, the two technologies that have emerged out of a desire to encrypt DNS traffic, take different approaches. DOT is typically implemented at the device layer so that all DNS communication is encrypted, regardless of the application. A DOT-enabled DNS resolver can be deployed internally within the organization, but more commonly they are hosted externally on the Internet so that they can be used by anyone to encrypt all DNS traffic originating from the client as it navigates the Internet. How these DOT resolvers are configured within the operating system is still the subject of much debate, and efforts are underway to define an automated discovery mechanism so that users can take advantage of DOT (or DOH) without having to perform any manual configuration.
DOH is similar but application specific. Commonly DOH is used by web browsers that nominate a trusted resolver to provide a DOH service. Some browsers (such as Firefox) will have these trusted resolvers hard-coded by default (but can be changed) and can result in DNS queries being sent to an unauthorized DOH resolver operated by an external company with whom you have no commercial or legal relationship. Other browsers (such as Chrome) may perform tests to see if the operating system has been configured with any DOH enabled resolvers, and if so then use those. The important thing to remember is that the mechanism for selecting a DOH resolver is determined by the application, not the operating system. As more DOH-enabled applications are installed, it is conceivable that numerous unauthorized DOH resolvers could be utilized, not all of which are necessarily trustworthy.
In both DOT and DOH cases, all DNS traffic is now encrypted all the way through the enterprise network and out to these external DOT or DOH-enabled resolvers. Devices and browsers that use DOT and DOH completely bypass the internal corporate DNS servers, communicating directly with external DNS resolvers that are not under your organization’s control. IT administrators have no visibility into this DNS traffic and any DNS security controls that have been implemented are completely bypassed, providing no protection whatsoever. Attackers can exploit this by developing malware that utilizes these encrypted security channels to bypass the corporate security infrastructure. An recent example includes a piece of malware called PsiXbot which uses DOH to communicate with a command and control server, completely bypassing all security controls. This attack method can be used to exfiltrate data or deliver additional exploits into the network.
To prevent DOT and DOH protocols from being abused is not as simple as it might seem. DOT can be blocked relatively easily at the perimeter as it uses a well-known port (853), however DOH uses port 443, which is also used for https traffic – blocking it will also block a very large percentage of web traffic. Because DOH DNS queries are embedded inside encrypted https requests, it can quickly get very expensive and troublesome if the perimeter security firewall has to decrypt these https packets, inspect the embedded DOH queries and then remove or substitute them whilst finally re-encrypting the packet and forwarding it onto its intended destination.
Browser vendors are introducing signaling mechanisms to control whether DOH is enabled or not. Firefox introduced the concept of a “canary domain” to control whether it performs DOH enabled queries – if the domain is resolvable and a specific type of response received, then DOH will be disabled. But each application can provide a different signaling mechanism, or none at all, in the case of malicious applications.
DDI vendors in the security ecosystem like Infoblox and BlueCat Networks are beginning to publish lists of public DOH servers that can be used to block queries to specific IP addresses and URLs so that DOH enabled applications cannot contact unauthorized DOH resolvers. This can be a little like “whack-a-mole” as new servers could spring up undetected or potentially change IP address – all it takes is for a new app to be published that people download onto their phones and when they use the company WiFi they could already be using an external DOH-enabled DNS server. Unfortunately, this is not a complete solution and relies on timely discovery of new DOH resolvers and rapid distribution of block lists. However, until a standardized mechanism is agreed that addresses these problems (which will never happen because there will be application authors that do not wish to comply), there isn’t really any other viable solution available, apart from https inspection, which can be very expensive in terms of performance impact and cost.
ISC (the developer of the popular BIND DNS server) resources include Alan Clegg’s webinar and Vicky Risk’s blog post.
Finally, a fantastic overview article describing what is at stake from Wired magazine.
“RFC 8484 (which adopted DNS-over-HTTPS as a standard ) is a cluster duck for internet security. Sorry to rain on your parade. The inmates have taken over the asylum.” Paul Vickie – Internet Pioneer, DNS Authority
DNS, one of the most important and overlooked technologies powering the Internet, is experiencing more change with the introduction of DOT and DOH than it has in the last 30 years. Established enterprise security controls are being bypassed, a situation that can be exploited by attackers. Elegant scalable solutions beyond lists of DOH servers to block queries are not yet available as industry adapts to the new multi-verse world of DNS.
A significant number of your employees are now working from home as the pandemic continues to spread globally and the need to protect people’s health takes number one priority. In this situation, companies have had very little time to prepare for such large scale remote work and think about how to secure these devices that are now accessing corporate resources from outside the perimeter. But work from home doesn’t mean you have to compromise on security. Read this white paper to learn about:
Top security challenges around teleworking
Evolving threat landscape in the current scenario and top attacks that could target your remote users
How to secure your work from home users using foundational network services