idnits 2.17.1 draft-sah-resinfo-doh-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 22, 2019) is 1802 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-sah-resolver-information-00 -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Sood 3 Internet-Draft Google 4 Intended status: Standards Track R. Arends 5 Expires: November 23, 2019 P. Hoffman 6 ICANN 7 May 22, 2019 9 DNS Resolver Information: "doh" 10 draft-sah-resinfo-doh-00 12 Abstract 14 This document defines a name-value pair, "doh", for the "DNS Resolver 15 Information Self-publication" protocol described in draft-sah- 16 resolver-information. This name-value pair describes whether the 17 resolver acts as a DoH server and, if so, the URI template for it. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 23, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Definition of the "doh" Name-value Pair . . . . . . . . . . . 2 56 3. Use of Data from the "doh" Name-value Pair . . . . . . . . . 3 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 58 4.1. Entry for the "Registry for DNS Resolver Information" . . 3 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 62 6.2. Informative References . . . . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 65 1. Introduction 67 [I-D.sah-resolver-information] defines a format for information about 68 a DNS resolver and protocols to get that information. Stub resolvers 69 and applications that can act as DoH clients [RFC8484] may want to 70 know the URI templates used by a resolver that is acting as a DoH 71 server. 73 1.1. Definitions 75 In this document, the term "resolver" without qualification means 76 "recursive resolver" as defined in [RFC8499]. Also, the term "stub" 77 is used to mean "stub resolver". 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in BCP 82 14 [RFC2119] [RFC8174] when, and only when, they appear in all 83 capitals, as shown here. 85 2. Definition of the "doh" Name-value Pair 87 The "doh" name has a value of a JSON object. That object has the 88 following name-value pairs. The "templates" name MUST be present; 89 the "domain-to-match" name is OPTIONAL. 91 templates: array of strings. Each string is a URI template for the 92 DoH server. The array MAY have zero values; if so, this indicates 93 that the resolver does not support DoH. The values MUST NOT be 94 empty. 96 domain-to-match: array of strings. Each string is a fully-qualified 97 domain name that is expected to appear in the certificate used for 98 TLS. These names can be used for matching in the TLS handshake if 99 the DoH client accesses the DoH server with a template that has an 100 IP address. The array MAY have zero values; if so, this indicates 101 that the certificate should only be matched using IP addresses as 102 subject names. The values MUST NOT be empty. 104 For example, a pair might look like: 106 { "doh": 107 { "domain-to-match": [ "resolver.example.net" ], 108 "templates: [ "https://resolver.example.net/dns-query{?dns}", 109 "https://192.0.1.2/dns-query{?dns}" ] 110 } 111 } 113 As another example, where the TLS certificate is expected to have 114 identifiers of IP addresses, not domain names: 116 { "doh": 117 { "templates: [ "https://192.0.1.2/dns-query{?dns}" ], 118 "domain-to-match": [ ] 119 } 120 } 122 3. Use of Data from the "doh" Name-value Pair 124 If the "template" array has more than one string, a client can 125 consider them all to be of equal value when finding a DoH server 126 associated with the resolver. 128 4. IANA Considerations 130 4.1. Entry for the "Registry for DNS Resolver Information" 132 This document adds one new entry to the "Registry for DNS Resolver 133 Information". 135 Name: doh 137 Value type: object 139 Specification: This document 141 5. Security Considerations 143 The data in the "doh" object MUST be received from an authoritative 144 source, and MUST be authenticated. Currently, that means either 145 using DNSSEC validation if using DNS to get the data, or TLS 146 certificate validation if using DNS-over-TLS [RFC7858] or DNS-over- 147 HTTPS from the resolver itself. 149 6. References 151 6.1. Normative References 153 [I-D.sah-resolver-information] 154 Sood, P., Arends, R., and P. Hoffman, "DNS Resolver 155 Information Self-publication", draft-sah-resolver- 156 information-00 (work in progress), April 2019. 158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 159 Requirement Levels", BCP 14, RFC 2119, 160 DOI 10.17487/RFC2119, March 1997, 161 . 163 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 164 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 165 May 2017, . 167 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 168 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 169 . 171 6.2. Informative References 173 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 174 and P. Hoffman, "Specification for DNS over Transport 175 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 176 2016, . 178 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 179 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 180 January 2019, . 182 Authors' Addresses 184 Puneet Sood 185 Google 187 Email: puneets@google.com 188 Roy Arends 189 ICANN 191 Email: roy.arends@icann.org 193 Paul Hoffman 194 ICANN 196 Email: paul.hoffman@icann.org