Mitigation Options against Centralization in DNS Resolvers

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 19 November 2021.¶

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1. Abstract

Centralization and consolidation of various Internet services are major trends. While these trends have some benefits - for instance in deployment of new technology - they also have serious drawbacks in terms of resilience, privacy, and other aspects. This extended abstract focuses on the question of centralization related to DNS [RFC1035] resolver services.¶

DNS resolver services are also a good example of centralization and approaches to dealing with it. The approaches may be applicable in other contexts as well.¶

DNS resolver services have evolved in recent years largely due to two trends:¶

• Availability of new technology protect the communications relating to queries with TLS [RFC7858] [RFC8484] [I-D.ietf-dprive-dnsoquic].¶
• Introduction of general-purpose resolver services in the Internet, such as Google's 8.8.8.8 and Cloudflare's 1.1.1.1 service.¶

It is interesting that privacy of DNS queries has only surfaced as an issue in recent years [RFC7626] [RFC8324]. The original DNS protocols had no support whatsover for security, and later designs such as DNSSEC addressed another problem, reliability of the information, but not privacy. Yet, DNS queries reveal potentially the users' entire browsing histories.¶

However, even when DNS queries are hidden inside communications, any DNS resolvers still have the potential too see the users' actions. This is particularly problematic, given that commonly used large public or operator resolver services are an obviously attractive target, for both attacks and for commercial or other use of information visible to them of the users. The use of information garnered from centralized services is particularly concerning in light of possible pervasive surveillance [RFC7258].¶

While these services are run by highly competent organizations and for the benefit of users, in general, it is undesirable to create Internet architectures or infrastructure that collects massive amount of information about users in few locations. Over longer time scales, the danger is that it will not be possible to withstand legal or commercial pressures to employ such information base in a way that is actually not in line with the interests of the users.¶

The full paper for the workshop will discuss the reasons for centralization in the DNS case, the problems it causes, and outlines a number of directions for solutions.¶

Solutions address the privacy problems either by reducing the centralization, reducing the information given to the centralized solutions, or make it hard to use the information collected in the centralized solutions. The solution directions include:¶

• Avoidance of centralized resolvers, and the introduction of sufficiently large number of resolvers (e.g., in ISP networks).¶
• Improved practices, expectations, and contracts (e.g., [RFC8932], Mozilla's trusted recursive resolver requirements [MozTRR])¶
• Discovery mechanisms. These may enable a bigger fraction of DNS query traffic to move to encrypted protocols, and may also help distributed queries to different parties to avoid concentrating all information in one place. The IETF working group ADD is addressing these mechanisms.¶
• Service distribution through making users employ several services such that only part of information is available in each service (e.g,, [I-D.arkko-abcd-distributed-resolver-selection]).¶
• Splitting information generated by queries into parts that are handled by different parties in a way that either part is useless for data collection (unless the parties co-operate). Oblivious DNS ([Oblivious]) is an example of this.¶
• Confidential computing mechanisms that set up technical boundaries for even service or server hardware owners to peek into the DNS resolver process (e.g., [PDoT] [I-D.arkko-dns-confidential]). For the base confidential computing technology, see, e.g., [CC] [CCC-Deepdive] [SGX] [Efficient] [Innovative] [Mem] [I-D.ietf-rats-architecture] [I-D.ietf-rats-eat].¶

Addressing the resiliency problems associated with centralization is harder. This further discussed in [I-D.arkko-arch-infrastructure-centralisation].¶

Author's Address