idnits 2.17.1 draft-zhang-add-requirement-discusses-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 25, 2020) is 1217 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Zhang 3 Internet-Draft December 25, 2020 4 Intended status: Informational 5 Expires: June 28, 2021 7 Discussion of Requirements for ADD 8 draft-zhang-add-requirement-discusses-00 10 Abstract 12 This document discusses various usage scenarios and corresponding 13 requirements for discovering and using encrypted DNS technology. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on June 28, 2021. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 51 3. Discover and use of encrypted DNS services . . . . . . . . . 2 52 3.1. The client automatically obtains DNS resolution service . 3 53 3.2. The client has been configured with parameters . . . . . 3 54 3.3. Configuration examples . . . . . . . . . . . . . . . . . 3 55 4. Encrypted DNS resolution service list . . . . . . . . . . . . 4 56 4.1. Provide a public encrypted DNS resolution service address 57 list . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. Provide encrypted DNS resolution configuration for some 59 specific domain names . . . . . . . . . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 4 63 8. Informative References . . . . . . . . . . . . . . . . . . . 4 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 Several DNS encryption technologies have been introduced, including 69 DNS-over-TLS and DNS-over-HTTPS and so on. The work of the Adaptive 70 DNS Discovery working group includes supporting client discovery of 71 encrypted DNS resolution services and communication mechanisms for 72 selection decisions. 74 Since the proposal of the draft plan should be guided by the existing 75 problems, the working group should first reach a consensus on the 76 problems to be solved and the principles applicable to each problem, 77 and then promote follow-up work on this basis. 79 This document discusses various usage scenarios and corresponding 80 requirements for discovering and using encrypted DNS technology. 82 2. Conventions Used in This Document 84 Encrypted DNS: DNS-over-HTTPS[RFC8484], DNS-over-TLS[RFC7858] or any 85 other encrypted DNS technology that the IETF may publish, for 86 example, DNS-over-QUIC [I-D.ietf-dprive-dnsoquic]. 88 3. Discover and use of encrypted DNS services 90 The DNS client accesses the recursive server with discovery function, 91 and the discussion is divided into the following situations: 93 3.1. The client automatically obtains DNS resolution service 95 1) Ordinary DNS resolution service 97 The client can automatically obtain the common DNS recursive 98 resolution server address through DHCP. 100 2) Encrypted DNS resolution service 102 The client can choose several types of encryption resolution services 103 currently provided (such as DOH/DOT, etc.), and accept the default 104 configuration of the recursive server. 106 The encrypted DNS recursive resolution server address can be 107 automatically set through DHCP/RA/PPP and other protocols. 109 3.2. The client has been configured with parameters 111 If the client has been configured with parameters, the following two 112 aspects are initially considered for configuration parameters: 114 1) For general DNS resolution services, the client can update and 115 configure the encrypted DNS recursive resolution server type and 116 address. This method is suitable for common networks and specific 117 networks. 119 2) Users can set to use the specified encrypted DNS resolution 120 service when accessing certain specific domain names. Set up a list 121 of mapping relationships between domain names and DNS resolution 122 service addresses. 124 3.3. Configuration examples 126 *Normal DNS resolution (single choice) 127 -Obtain DNS server address automatically (single choice) 128 -Use the following DNS server address (single choice) 129 First choice: ____._____.____.____ 130 Alternative: ____._____.____.____ 132 *Encrypted DNS resolution (single choice) 133 -Type: DOT/DOH 134 -Obtain DNS server address automatically (single choice) 135 -Use the following encrypted DNS server address (single choice) 136 First choice: ____._____.____.____ 137 Alternative: ____._____.____.____ 139 Domain name Type Address 140 www.google.com DOT xxx.xxx.xxx.xxx 142 4. Encrypted DNS resolution service list 144 4.1. Provide a public encrypted DNS resolution service address list 146 We can provide an encrypted DNS recursive resolution server address 147 list, which can be publicly maintained and updated regularly. The 148 priority of selecting an encrypted DNS resolver is determined by the 149 server's own design. Currently Mozilla maintains a similar list 150 relationship. 152 4.2. Provide encrypted DNS resolution configuration for some specific 153 domain names 155 If some companies or institutions want to use their own encrypted DNS 156 resolution service when accessing their own domain names, they will 157 provide the resolution server through the mapping relationship. 159 5. IANA Considerations 161 To be added. 163 6. Security Considerations 165 To be added. 167 7. Acknowledgment 169 The authors would like to thank Jiankang Yao, and Linlin Zhou for 170 their careful review and valuable comments. 172 8. Informative References 174 [I-D.ietf-dprive-dnsoquic] 175 Huitema, C., Mankin, A., and S. Dickinson, "Specification 176 of DNS over Dedicated QUIC Connections", draft-ietf- 177 dprive-dnsoquic-01 (work in progress), October 2020. 179 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 180 and P. Hoffman, "Specification for DNS over Transport 181 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 182 2016, . 184 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 185 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 186 . 188 Author's Address 190 Man Zhang 191 4 South 4th Street, Zhongguancun, Haidian District 192 Beijing, Beijing 100190 193 China 195 Email: zhangman@cnnic.cn