Smart DNS for the New Network Edge: Emerging Requirements for DNS Encryption
This blog post — the fourth in a series — will discuss how smart DNS resolvers can enhance ongoing ISP and MNO network transformation efforts, such as the transition to 5G, better integration of Wi-Fi, and new network designs that optimize the edge to improve service delivery and network efficiency.
Extensive publicity about the gathering and use (and misuse) of personal data by popular online services has made internet users increasingly concerned about constant inspection of their lives and trade in their personal information. As part of a broader privacy effort in late 2018, the Internet Engineering Task Force (IETF) finalized initial standards DNS over TLS (DoT) and DNS over HTTPS (DoH) to encrypt DNS traffic between clients (stub resolvers) and resolvers.
Service providers are motivated to understand these new standards and the ecosystems that surround them since they may fundamentally change the way subscribers perceive DNS and how DNS operates in provider networks.
- Public or open DNS resolvers have been around for many years and their operators have always heavily promoted performance of their services. Their support of DNS encryption creates the perception of a privacy benefit for end users. (See this blog to learn more about subscriber experience and provider DNS resolution.) Subscribers may choose public DNS alternatives if they think they’re “better” than what their ISP or MNO offers.
- The client ecosystem for DoT and DoH continues to evolve and a broad representation of operating system, browser, application and CPE implementations exists today. Underlying details of today’s client implementations impact operation of DNS resolution infrastructure in many ways. Providers need to understand how to evolve their infrastructure to ensure it delivers a great subscriber experience.
- There’s encouraging activity in the IETF as a new group is working on defining the automated discovery and provisioning of encrypted resolvers by clients. If this work paves the way for ISPs and MNOs to use DHCP or similar widely used protocols it will increase pressure on providers to deploy the new protocols.
Understanding DoH and DoT
DoH and DoT run over connection-oriented TCP. This will change the way resolution infrastructure scales and introduce different failover considerations. New testing and configuration methodologies will need to be developed, and providers will want to understand the new protocols in light of sizing requirements, operational considerations, monitoring and management tools, and costs.
As suggested above, accounting for client behaviors will be critical. A blog post on akamai.com, DNS Encryption at DNS OARC 32, covers the results of testing of several clients that support DNS encryption presented at a conference in San Francisco in February 2020. It characterizes the impact of session reuse and duration and certificate validation failures.
Another blog post on akamai.com, Simplifying the ISP Transition to DNS Encryption offers an overview of Akamai DNSi CacheServe support for the new protocols. It also has guidance on actions providers can take to maintain their trusted position and help ensure subscribers prefer their resolvers even as awareness of open public DNS resolvers and DNS Encryption increases.
DoH and DoT clients
Thus far, DNS encryption standards only define how to use secure transport for DNS so there’s currently considerable diversity in DoH and DoT client behaviors. This means developers have made their own choices about how (or whether) their clients connect to an encrypted resolver. In most cases today, in order to enable DNS encryption end users need to take some action: navigate to a configuration interface and accept defaults and/or enter information, or load an app that connects to its preferred resolver or prompts the user to configure/select one.
This is a critical limitation for service providers. Manual configuration by users is completely incompatible with operation at scale. Fortunately, there’s progress on the standards front; a new working group in the IETF, Adaptive DNS Discovery (ADD), is defining requirements for how clients can “automatically discover and select encrypted DNS resolvers in a wide variety of network environments.” The requirements currently account for the use of DHCP v4 and v6, IPv6 Router Advertisements, and Point-to-Point Protocol (PPP) — protocols that are compatible with provider provisioning systems and processes.
Client developers also discovered they need to account for the presence of security and parental control services offered by ISPs or MNOs. When these services are knowingly chosen by end users (opted in) or mandated by local regulations, clients can’t arbitrarily prevent access to provider resolvers that support them. Client algorithms to detect local network conditions add complexity and can be imperfect, but when support for automated provisioning methods is built-in, providers will be able offer end users connections to their own encrypted resolvers that natively support their DNS-based services.
Summary
Providers should implement best practices for DNS resolution and regularly benchmark their resolvers against public DNS services to ensure local resolvers always exceed the performance and availability of public alternatives. The delivery of high-performance, low-latency resolution is a high ROI proposition; a relatively modest investment can improve overall network responsiveness.
In the future, subscribers may expect that their DNS traffic is encrypted while they’re on a provider’s network. Encryption seems unnecessary when provider networks are highly secure, and it’s challenging for adversaries to infiltrate them and intercept traffic; however, subscriber perceptions and preferences may prevail. More important, client developers have proceeded with implementing DoH and DoT, and they’re eager for users to have access to encrypted resolvers. At some point, applications will probably signal when they’re not using an encrypted resolver.
DNS operations teams need to begin diligence efforts to support the new protocols in their networks, especially since it appears likely that standards and client implementations will address provisioning issues so that subscriber connections to resolvers that support encryption will “just work” without any intervention by the subscriber.
Akamai has implemented DoH and DoT in licensed (on-premise) cloud and managed solutions so providers will be able to deploy the protocols at scale, with all of the requisite visibility and other features needed to operationalize them.
DNS encryption also creates opportunity for providers. Akamai Security and Personalization Services (SPS) are designed expressly for ISPs and MNOs to deliver security and web filtering capabilities to residential and small to midsize business customers. SPS operates the same whether or not subscribers are connected to provider resolvers that use encrypted transport (DoH or DoT). A new cloud-based offering, SPS Remote, enhances SPS Secure Business, by connecting subscribers to SPS-aware resolvers over DoH secure transport whenever they leave a provider’s network, such as when they use Wi-Fi hotspots at untrusted venues.
*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Bruce Van Nice. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/Uc3XjkuiKS4/smart-dns-for-the-new-network-edge-emerging-requirements-for-dns-encryption.html
