Internet-Draft Discussion of Requirements for ADD December 2020
Zhang Expires 28 June 2021 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-zhang-add-requirement-discusses-00
Published:
Intended Status:
Informational
Expires:
Author:
M. Zhang

Discussion of Requirements for ADD

Abstract

This document discusses various usage scenarios and corresponding requirements for discovering and using encrypted DNS technology.

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 28 June 2021.

Table of Contents

1. Introduction

Several DNS encryption technologies have been introduced, including DNS-over-TLS and DNS-over-HTTPS and so on. The work of the Adaptive DNS Discovery working group includes supporting client discovery of encrypted DNS resolution services and communication mechanisms for selection decisions.

Since the proposal of the draft plan should be guided by the existing problems, the working group should first reach a consensus on the problems to be solved and the principles applicable to each problem, and then promote follow-up work on this basis.

This document discusses various usage scenarios and corresponding requirements for discovering and using encrypted DNS technology.

2. Conventions Used in This Document

Encrypted DNS: DNS-over-HTTPS[RFC8484], DNS-over-TLS[RFC7858] or any other encrypted DNS technology that the IETF may publish, for example, DNS-over-QUIC [I-D.ietf-dprive-dnsoquic].

3. Discover and use of encrypted DNS services

The DNS client accesses the recursive server with discovery function, and the discussion is divided into the following situations:

3.1. The client automatically obtains DNS resolution service

1) Ordinary DNS resolution service

The client can automatically obtain the common DNS recursive resolution server address through DHCP.

2) Encrypted DNS resolution service

The client can choose several types of encryption resolution services currently provided (such as DOH/DOT, etc.), and accept the default configuration of the recursive server.

The encrypted DNS recursive resolution server address can be automatically set through DHCP/RA/PPP and other protocols.

3.2. The client has been configured with parameters

If the client has been configured with parameters, the following two aspects are initially considered for configuration parameters:

1) For general DNS resolution services, the client can update and configure the encrypted DNS recursive resolution server type and address. This method is suitable for common networks and specific networks.

2) Users can set to use the specified encrypted DNS resolution service when accessing certain specific domain names. Set up a list of mapping relationships between domain names and DNS resolution service addresses.

3.3. Configuration examples


*Normal DNS resolution (single choice)
  -Obtain DNS server address automatically (single choice)
  -Use the following DNS server address (single choice)
    First choice: ____._____.____.____
    Alternative: ____._____.____.____

*Encrypted DNS resolution (single choice)
  -Type: DOT/DOH
  -Obtain DNS server address automatically (single choice)
  -Use the following encrypted DNS server address (single choice)
    First choice: ____._____.____.____
    Alternative: ____._____.____.____




Domain name       Type     Address
www.google.com    DOT      xxx.xxx.xxx.xxx

4. Encrypted DNS resolution service list

4.1. Provide a public encrypted DNS resolution service address list

We can provide an encrypted DNS recursive resolution server address list, which can be publicly maintained and updated regularly. The priority of selecting an encrypted DNS resolver is determined by the server's own design. Currently Mozilla maintains a similar list relationship.

4.2. Provide encrypted DNS resolution configuration for some specific domain names

If some companies or institutions want to use their own encrypted DNS resolution service when accessing their own domain names, they will provide the resolution server through the mapping relationship.

5. IANA Considerations

To be added.

6. Security Considerations

To be added.

7. Acknowledgment

The authors would like to thank Jiankang Yao, and Linlin Zhou for their careful review and valuable comments.

8. Informative References

[I-D.ietf-dprive-dnsoquic]
Huitema, C., Mankin, A., and S. Dickinson, "Specification of DNS over Dedicated QUIC Connections", Work in Progress, Internet-Draft, draft-ietf-dprive-dnsoquic-01, , <http://www.ietf.org/internet-drafts/draft-ietf-dprive-dnsoquic-01.txt>.
[RFC7858]
Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, , <https://www.rfc-editor.org/info/rfc7858>.
[RFC8484]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, , <https://www.rfc-editor.org/info/rfc8484>.

Author's Address

Man Zhang
4 South 4th Street, Zhongguancun, Haidian District
Beijing
Beijing, 100190
China