idnits 2.17.00 (12 Aug 2021) /tmp/idnits40278/draft-mglt-add-rdp-03.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 7 instances of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 10 instances 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 == Line 123 has weird spacing: '... client the c...' == Line 129 has weird spacing: '...Service desig...' == Line 136 has weird spacing: '...ansport desig...' == Line 139 has weird spacing: '... Domain a DNS...' == Line 321 has weird spacing: '...display indic...' == (6 more instances...) -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: All subsets MUST share the same resolving domain and be listed with a PTR RRsets. The DNS client MAY NOT performed a DNS query of type PTR, for example, if it has a previous knowledge of the existence of the subset or if indicated by its policy. In this it MAY directly proceed to the SRVCB resolution. -- The document date (July 28, 2020) is 655 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-btw-add-home-07 -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 add D. Migault 3 Internet-Draft Ericsson 4 Intended status: Informational July 28, 2020 5 Expires: January 29, 2021 7 DNS Resolving service Discovery Protocol (DRDP) 8 draft-mglt-add-rdp-03 10 Abstract 12 This document describes the DNS Resolver Discovery Protocol (DRDP) 13 that enables a DNS client to discover various available local and 14 global resolving service. The discovery is primarily initiated by a 15 DNS client, but a resolving service may also inform the DNS client 16 other resolving services are available and eventually preferred. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 29, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Pointer to a list of Resolving Domains . . . . . . . . . . . 5 57 6. Discovery of Resolving Services . . . . . . . . . . . . . . . 6 58 7. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 8. SvcParamKey . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 9. Resolver advertising other service sub type . . . . . . . . . 8 61 10. Migration to service sub types . . . . . . . . . . . . . . . 8 62 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 11.1. Use of protected channel is RECOMMENDED . . . . . . . . 8 64 11.2. DNSSEC is RECOMMENDED . . . . . . . . . . . . . . . . . 9 65 11.3. TLSA is RECOMMENDED . . . . . . . . . . . . . . . . . . 10 66 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 67 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 69 15. Appendices . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 15.1. DRDP Requirements . . . . . . . . . . . . . . . . . . . 12 71 15.2. Discovery of specific service instance . . . . . . . . . 13 72 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 16.1. Normative References . . . . . . . . . . . . . . . . . . 14 74 16.2. Informative References . . . . . . . . . . . . . . . . . 14 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Requirements Notation 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 82 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 83 capitals, as shown here. 85 2. Introduction 87 A DNS client can proceed to DNS resolution using various resolving 88 services. These services can be local or global and can use a wide 89 range of DNS transport protocols such as, for example, standard DNS 90 [RFC1035], DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484]. The 91 local scope of these services may take various forms. For example, 92 it could be associated to a network perspective ( restricted to the 93 network the DNS client is connected to ) or to an application 94 perspective ( restricted to some domain names ). 96 The purpose of the DNS Resolving service Discovery Protocol (DRDP) is 97 to discover resolving services available to the DNS client. These 98 available resolving services to a given DNS client may highly depend 99 on its location or browsing activity. The number of resolving 100 services available to the DNS client is expected to remain quite 101 consequent and evolve over time. Similarly, characteristics 102 associated to these resolving services may also evolve over time. As 103 a result, the DNS client is unlikely willing to synchronize such a 104 huge data base of resolving services. DRDP proposes an alternative 105 that consists in adaptively discovering the available resolving 106 services based on the DNS client context. 108 DRDP adopts a hierarchical approach where the DNS client (or DRDP 109 client) discovers the resolving services from resolving domains (RD) 110 or a pointer to a list of resolving domains (Pointer). 112 The document does not describe how the DNS client is provisioned with 113 RD or RD_list. The DNS client may obtain the contextual resolving 114 domains via various way, including a configuration, via DHCP Options 115 [I-D.btw-add-home] or derived from specific procedures [I-D.mglt-add- 116 drdp-isp]. The DNS client is expected to discover resolving services 117 from all RD or RD_list before proceeding to a selection process. The 118 selection process of the resolving service is out of scope of this 119 document. 121 3. Terminology 123 DNS client the client that sends DNS queries fro resolution. In 124 this document the DNS client designates also the end entity that 125 is collecting information about the available Resolving Services 126 and then proceed to the selection of a subset them. The selection 127 is processed according to the DNS client's policy. 129 Resolving Service designates a service that receives DNS queries 130 from a DNS client and resolves them. A Resolving Service is 131 implemented by one or multiple resolvers. 133 Resolver: A resolver designates the software or hardware handling the 134 DNS exchange. See [RFC7719] for more details. 136 DNS transport designates the necessary parameters a DNS client needs 137 to establish a session with a Resolving Service. 139 Resolving Domain a DNS domain that hosts one or multiple resolving 140 services. 142 4. Overview 144 DRDP is a DNS based protocol that addresses the requirements listed 145 in Section 15.1. The figure below represents provides a high level 146 description of DRDP. 148 1. The DRDP client considers the source of resolving domains (RD). 149 This document defines two ways to collect RDs: RD are directly 150 provisioned - in our case rd.org) , or RD are retrieved from a 151 Pointer - in our case rd_pointer.org. In the later case RD are 152 collected from a DNS request of type PTR. In the case of Pointer 153 being rd_pointer.org, the QNAME of the PTR request would be 154 b._dns.rd_pointer.org. 156 2. The DRDP client collects the resolving services and associated 157 parameters under the umbrella of each RD. The resolving services 158 offered by the RD are collected via a DNS request of type SVCB 159 and the associated parameters are provided through SvcParameters. 160 In the case of the RD being rd.org, the QNAME of the SVCB request 161 would be _dns.rd.org. 163 +---------------------------------------------+ 164 +---------------->| source of Resolving Domains | 165 | +---------------------------------------------+ 166 1. collect | * resolving domains (rd.org) | 167 Resolving Domains | * list of resolving domains (rd_pointer.net)| 168 | | * other means: configuration, DHCP, | 169 | | Website co-hosting, derived | 170 | +---------------------------------------------+ 171 | 172 +-------------+ +---------------------------------------------+ 173 | DRDP client |----->| Resolving Domain | 174 +-------------+ +---------------------------------------------+ 175 2. collect | rd.1.com, ..., rd.i.com, ..., rd.n.com | 176 Resolving Services +---------------------|------------------|----+ 177 and associated | | | 178 parameters +---------------------|------------------|----+ 179 | Resolving Services | | | 180 +---------------------v------------------v----+ 181 | +-------------------+ +--------------+ | 182 3. Proceed | | doh.resolver.net | | doh.isp.com | | 183 Selection | +-------------------+ ... +--------------+ | 184 | | dot.resolver.net | | do53.isp.com | | 185 | +-------------------+ +--------------+ | 186 | | do53.resolver.net | | 187 | +-------------------+ | 188 +---------------------------------------------+ 190 5. Pointer to a list of Resolving Domains 192 A Pointer is a FQDN that points to a list of FQDN that designates RD. 193 If Pointer is represented by rd_pointer.net, the associated RDs are 194 retrieved by the DNS query of type PTR for b._dns.rd_pointer.org. 196 The zone file below is inspired from DNS-SD where b indicates a 197 browsing domain, _dns indicates the DNS resolving service, 198 rd_pointer.org the Pointer and rd.1.com, ... rd.i.com the associated 199 RDs. Note that they do not necessarily need to share a TLD. The 200 order of the resolving domains is irrelevant, and the zone 201 administrator SHOULD regularly reorder them. The RRsets MUST be 202 signed with DNSSEC. 204 b._dns.rd_pointer.net PTR rd.1.com 205 [...] 206 b._dns.rd_pointer.net PTR rd.n.com 208 Using the DNS provides the advantage to retrieve the resolving domain 209 without requiring other libraries than DNS as well as benefit from 210 the DNS caching infrastructure including the use of the TTL. 212 An EDNS buffer size of 1232 bytes will avoid fragmentation on nearly 213 all current networks. This is based on an MTU of 1280, which is 214 required by the IPv6 specification, minus 48 bytes for the IPv6 and 215 UDP headers. This document RECOMMENDS that the number of RDs 216 associated to a Pointer do not generate fragmentation of the DNS UDP 217 packet. It is believed to address most common needs or expectation 218 from a vast majority of stub DNS client. 220 When the number of RD exceeds this limit, the DNS client may carry 221 this over TCP which is likely to be supported by DNS client wiling to 222 upgrade to DoH or DoT resolving services. However, the transfer of 223 large number of RDs is considered as an application specificity that 224 would benefit benefit from the compression of the transferred data 225 provided by ftp or http. In such case, these application may define 226 there own specific mechanism to provision the RDs. 228 As of July 27 2020, 1232 bytes correspond to the 94 first most 229 popular FQDN listed by [moz.com]. The current size of such lists 230 [curl][dnsprivacy.org] have less than 50 resolving domains. Other 231 lists such as [public-dns.info] have as much as 11.000 entries, but 232 such lists seems to contain open resolvers which is out side of the 233 scope of a selection process. 234 Web browser (Google Chrome) also have lists over 10.000 entries, but 235 in case a significant number of entries seems to be IP addresses that 236 have a very limited network scope ( e.g. limited to the ISP ). The 237 length of the list in scope to the DNS client is in fact significant 238 smaller in term of IP addresses and even smaller if resolving domain 239 are able to represent multiple IP addresses. Overall, the size of 240 such lists are currently due to the absence of discovery protocols. 242 6. Discovery of Resolving Services 244 The discovery of resolving services is performed by the RDP client 245 with all the available RDs. Given a RD rd.org, a DRDP client sends a 246 DNS request of type SVCB for _dns.rd.org. 248 The example below presents the use of an AliasForm followed by a 249 ServiceForm which allows an indirection. The Alias form is not 250 madatory and instead only ServiceForm associated to _dns.rd.org could 251 have been used instead. 253 The SvcFieldPriority indicates the preference of the RD. It 254 typically enables an operator to indicate that an encrypted DNS is 255 preferred. 257 The SvcParamKey alpn MUST be present when TLS is used as its presence 258 and value indicates the DNS transport. The absence of the alpn 259 SvcParamKey indicates Do53, alpn set to dot indicates DoT is served 260 while h* indicates DoH is served. Note that the port value (53, 853, 261 443) is not used to determine the DNS transport as non standard port 262 MAY be used. The example below uses an non standard port 5353 for 263 illustrative purpose. 265 Other SvcParam are detailed in Section 8 and are optional. A 266 SvcParam not understood by the DNS client MUST be ignored. 268 The RRsets MUST be protected with DNSSEC and when alpn is provided a 269 TLSA RRset SHOULD be present. These RRsets have been omitted for 270 clarity. 272 ## Discovery of all service instances 273 _dns.rd.org. 7200 IN SVCB 0 svc.example.com. 274 svc.example.com. 7200 IN SVCB 12 ( svc0.example.net. 275 port="5353" user-display="Legacy Resolver" ) 276 svc.example.com. 7200 IN SVCB 1 ( svc1.example.net. alpn="dot" 277 port="5353" esniconfig="..." 278 user-display="Preferred Example's Choice" ) 279 svc.example.com. 7200 IN SVCB 3 ( svc2.example.net. alpn="h2" 280 port="5353" esniconfig="..." user-display= ) 281 svc.example.com. 7200 IN SVCB 2 ( svc3.example.net. alpn="h3" 282 port="5353" esniconfig="..." user-display= ) 284 Note that Section 15.2 provides another variant to perform RDP. Such 285 variant is left for further discussion and address the need to be 286 able to narrow down the discovery to a subset of resolving services 287 such as DoH-only or DoT-only services. 289 Some notes: 291 1. _domain uses SVCB but does not have TLS. While SVCB has been 292 created essentially for TLS based service, this does not appear 293 to be mandatory. 295 2. Should we have some constraints regarding the SvcDomainName and 296 QNAME ? 298 3. do we need the service subsets 300 7. TTL 302 The DNS client SHOULD perform DRDP at regular intervals as indicated 303 by its policy. 305 The selection process MAY remove resolving services with short TTL 306 lower than a day as it indicates some source of instalbility. Given 307 a subset of selected resolving services, the DNS client may perform 308 DRDP 1 hour before an SVB RRset expires. 310 8. SvcParamKey 312 This section defines a set of SvcParamKey that MAY be use to carry 313 the necessary informations for the selection process. 315 alpn : 317 esniconfig : 319 port : 321 user-display indicates a strings in UTF-8 that is expected to be 322 representative to a potential end user. Though there is no 323 restriction in the scope of that string. The string is likely to 324 represent the service within the resolving domain. 326 uri_template designates the URI template for DoH. This key MUST NOT 327 be present on non DoH services and MUST be ignored by the DNS 328 client on non DoH resolving Services. 330 auth_domain indicates the list of authoritative domain name the 331 resolving service has strong relation with. It is expected that a 332 resolving service may prefer to perform DNS resolution over these 333 domains to that specific resolving service as to preserve its 334 privacy. This information MUST be verified and validated. 336 scope_domain indicates the limitation of resolved domains. When 337 present DNS request sent to the resolution service MUST belong to 338 that domain. 340 filtering indicates the presence of a filtering service 342 ip_subnet indicates a subnetwork restriction. This is mostly useful 343 for resolving services that are not globally. 345 dnssec indicates whether dnssec is enabled or not. 347 9. Resolver advertising other service sub type 349 A resolving service receiving a DNS request over a service sub type 350 MAY be willing to advertise the DNS client that other sub service 351 type are available. This is especially useful, when, for example, a 352 resolver wants that the DNS resolver switches to other service sub 353 types that are more secure. 355 In order to do so the resolver MAY provide in the additional data 356 field the _dns SRVCB of ServiceForm. 358 10. Migration to service sub types 360 The principle of the discovery mechanism is that the resolver 361 indicates the available service sub types and let the DNS client 362 chose which sub type it prefers. On the other hand, the resolver MAY 363 also indicate a preference using the priority and weight fields. 364 Redirection MAY especially be needed when a DNS client is using the 365 Do53 and the resolver would like to upgrade the DNS client session to 366 a more secure session. This MAY require a specific ERROR code that 367 will request the DNS client to perform service discovery. 369 It is expected that DRDP MUST always be available via Do53. However, 370 this does not mean that a resolver is expected to implement the Do53 371 sub type service for a resolving service. 373 11. Security Considerations 375 11.1. Use of protected channel is RECOMMENDED 377 When available, it is recommended to chose a protected version of the 378 rdns service. More specifically, the use of end-to-end protection 379 ensures that the DNS client is connected to the expected platform and 380 that its traffic cannot be intercepted on path. Typically, the 381 selection of resolver on the Internet (and not on your ISP network) 382 and the use of a non protected channel enables an attacker to monitor 383 your DNS traffic. The similar observation remains true if you are 384 connected to the resolver of your ISP. It is commonly believed that 385 trusting your ISP (that is your first hop) makes encryption 386 unecessary. Trusting your ISP is mandatory in any case, but the 387 associated level of trust with an protected channel is restricted to 388 the operation of the DNS platform. With non protected channel the 389 trust is extended to any segment between the DNS client and the 390 resolver, which is consequently larger. The use of a protected 391 channel is recommended as it will prevent anyone on path to monitor 392 your traffic. 394 11.2. DNSSEC is RECOMMENDED 396 The exchanges SHOULD be protected with DNSSEC to ensure integrity of 397 the information between the authoritative servers and the DNS client. 398 Without DNSSEC protection, DNS messages may be tampered typically 399 when they are transmitted over an unprotected channel either between 400 the DNS client and the resolver or between the resolver and the 401 authoritative servers. The messages may be tampered by an online 402 attacker intercepting the messages or by the intermediary devices. 403 It is important to realize that protection provided by TLS is limited 404 to the channel between the DNS client and the resolver. There are a 405 number of cases were the trust in the resolver is not sufficient 406 which justify the generalization of the use of DNSSEC. The following 407 examples are illustrative and are intended to be exhaustive. 409 First, the discovery exchanges may happen over an unprotected 410 channel, in which case, the messages exchanged may be tampered by 411 anyone on-path between the DNS client and the resolver as well as 412 between the resolver and the authoritative servers - including the 413 resolver. When TLS is used between the DNS client and the resolver, 414 this does not necessarily mean the DNS client trusts the resolver. 415 Typically, the TLS session may be established with a self-signed 416 certificate in which case the session is basically protected by a 417 proof-of-ownership. In other cases, the session may be established 418 based on Certificate Authorities (CA) that have been configured into 419 the TLS client, but that are not necessarily trusted by the DNS 420 client. In such cases, the connected resolver may be used to 421 discover resolvers from another domain. In this case, the resolver 422 is probably interacting with authoritative servers using untrusted 423 and unprotected channels. Integrity protection relies on DNSSEC. 425 11.3. TLSA is RECOMMENDED 427 When TLS is used to protect the DNS exchanges, certificates or 428 fingerprint SHOULD be provided to implement trust into the 429 communication between the DNS client and the resolver. The TLS 430 session and the association of the private key to a specific identity 431 can be based on two different trust model. The Web PKI that will 432 rely on CA provisioned in the TLS library or the TA provided to the 433 DNS client. A DNS client SHOULD be able to validate the trust of a 434 TLS session based on the DNSSEC trust model using DANE. 436 When the DNS client is protecting its session to the resolver via 437 TLS, the DNS client may initiate an TLS session that is not validated 438 by a CA or a TLSA RRsets. The DNS client MUST proceed to the 439 discovery process and validate the certificate match the TLSA RRset. 440 In case of mismatch the DNS client MUST abort the session. 442 12. Privacy Considerations 444 When the discovery protocol is performed using a resolver that 445 belongs to one domain for another domain, or over an unprotected 446 channel, the DNS client must be conscious that its is revealing to 447 the resolver its intention to use another resolver. More 448 specifically, suppose an resolver is complying some legal 449 requirements that DNS traffic must be unencrypted. Using this 450 resolver to perform a resolver discovery reveals the intention of 451 potentially using alternative resolvers. Alternatively, narrowing 452 down the discovery over a specific sub type of resolver (DoT, or DoH) 453 may reveal to that resolver the type of communication. As result, 454 when performing a discovery over a domain that differs to the domain 455 the resolver belongs to, it is RECOMMENDED to request the SRV RRsets 456 associated to all different sub type of proposed services. 458 The absence of traffic that results from switching completely to a 459 newly discovered resolver right after the discovery process provides 460 an indication to the resolver the DNS client is switching to. It is 461 hard to make that switch unnoticed to the initial resolver and the 462 DNS resolver MUST assume this will be noticed. The information of 463 switching may be limited by sharing the traffic between different 464 resolvers, however, the traffic pattern associated to each resolver 465 may also reveal the switch. In addition, when the initial resolver 466 is provided by the ISP, the ISP is also able to monitor the IP 467 traffic and infer the switch. As a result, the DNS client SHOULD 468 assume the switch will be detected. 470 With DoT or DoH, the selection of port 443 will make the traffic 471 indistinguishable from HTTPS traffic. This means that an observer 472 will not be able to tell whether the traffic carries web traffic or 473 DNS traffic. Note that it presents an interest if the server offers 474 both a web service as well as a resolution service. Note that many 475 resolvers have a dedicated IP address for the resolution service, in 476 which case, the information will be inferred from the IP address. 477 Note also that traffic analysis may infer this as well. Typically 478 suppose an IP address hosts one or multiple web sites that are not 479 popular as well as a resolving service. If this IP address is 480 associated frequent short size exchanges, it is likely that these 481 exchanges will be DNS exchanges rather than Web traffic. The size of 482 the packet may also be used as well as many other patterns. As a 483 result, the use port 443 to hide the DNS traffic over web traffic 484 should be considered as providing limited privacy. 486 13. IANA Considerations 488 This document requests the IANA the creation of the following 489 underscored node names in the Underscored and Globally Scoped DNS 490 Node Names registry https://www.iana.org/assignments/dns-parameters/ 491 dns-parameters.xhtml#dns-parameters-14 493 RR Type | _NODE NAME | Reference 494 --------+------------+---------- 495 SRVCB | _dns | RFC-TBD 497 SvcParamKey | NAME | Meaning | Reference 498 ------------+--------------+-----------------------------+----------- 499 7 | user-display | User friendly string (UTF8) | RFC-TBD 500 | | to represent the resolver | 501 | uri_template | URI template | 502 | auth_domain | Domains the resolving | 503 | | service is authoritative | 504 | filetring | Filetring services provided | 505 | ip_subnet | ip ranges accepted. | 506 | dnssec | DNSSEC validation enabled | 508 14. Acknowledgments 510 We would like thank Mirja Kuehlewind as well as the GSMA IG for their 511 comments. We also thank Ted Hardie and Paul Hoffman for their feed 512 backs regarding the dns schemes for DoT and DoH. 513 We thank Ben Schwartz for the comments on the list size. We thank 514 Harald Alvestrand for its recommendation on having a model that 515 enable multiple third party providers to provide their own list of 516 resolving domains. We thank Stephan Bortzmeyer, Ralf Weber, Chris 517 Box for its clarifications. 519 15. Appendices 521 15.1. DRDP Requirements 523 This section lists the DRDP requirements. 525 REQ 1: DRDP MUST enable a DNS client to discover the available 526 resolving services with their associated characteristics in order to 527 proceeds to a selection process. The selection process takes 528 resolving services identities and associated parameters and proceed 529 to the selection. 530 Any sort of resolving service selection is outside the scope of DRDP. 532 REQ 2: While the discovery process is triggered by the DNS client, a 533 third party MUST be able to provide necessary input information so a 534 resolving service discovery process can be triggered within a 535 specific context. 536 Provisioning protocols to provide this information is not as per say 537 in scope of DRDP. DRDP defines the format of the format for such 538 input as well as a set of such inputs. 540 REQ 3: Any information used in DRDP MUST be authenticated by its 541 owner. In particular, the characteristics associated to the 542 resolving service MUST be certified by the resolving service operator 543 / owner and MUST be associated a validity period. In addition, a 544 third party providing a set of inputs MUST authenticate that set. 546 REQ 4: Information associated to the resolving services is intended 547 to enable the selection process that is assumed to match the end user 548 or application policy. The selection process is out of scope of 549 DRDP. Information may carry some characteristics of a resolving 550 service or hints that will help the selection. In particular an 551 operator of multiple resolving service MUST be able to associate a 552 preference to the proposed resolving services. To ease automation of 553 the selection as well as to make multiple applications benefit from 554 DRDP the information MUST be carried over a standardized format. 556 REQ 5: DRDP MUST be designed to be used indifferently by a DNS client 557 using any DNS transport protocol (Do53, DoT, DoH, ...). However, 558 DRDP SHOULD be able to restrict the information retrieved to a 559 certain type of resolving service, i.e. Do53, DoT, DoH. 561 REQ 6: DRDP deployment MUST NOT be disruptive for the legacy DNS 562 client or infrastructure and legacy client SHOULD be able to 563 incrementally include DRDP. 565 15.2. Discovery of specific service instance 567 To reduce the size of the messages, the DNS client MAY also prefer to 568 query information of resolving services using a specific transport 569 (DNS, DoT, DoH) that are designated as sub sets. A DNS client MAY 570 list the different subsets of that resolving domain with a PTR query. 571 This document defines the following subsets _53._dns for DNS, 572 _853._dns for DoT and _443.__dns for DoH. Other subsets MAY be 573 defined in the future. A DNS client that does not understand a 574 subset SHOULD ignore it and maybe proceed to the discovery as defined 575 in Section 6. 577 All subsets MUST share the same resolving domain and be listed with a 578 PTR RRsets. The DNS client MAY NOT performed a DNS query of type 579 PTR, for example, if it has a previous knowledge of the existence of 580 the subset or if indicated by its policy. In this it MAY directly 581 proceed to the SRVCB resolution. 583 The same restrictions as defined in section Section 6 apply. 585 Note that while the SvcFieldPriority indicates the priority within a 586 subservice, this field MUST have a coherence across subservices. The 587 priority provided SHOULD be coherent with the case of a _dns SRVCB 588 query of section Section 6. 590 The figure below illustrates an example of zone file. RRSIG and TLSA 591 have been omitted for the purpose of clarity. 593 ### Definition of the resolving service subsets 594 _dns.example.com PTR _53._dns.example.com 595 _dns.example.com PTR _853._dns.example.com 596 _dns.example.com PTR _443._dns.example.com 598 ### services instances per service subset 599 _53._dns.example.com. 7200 IN SVCB 0 svc0.example.com. 600 svc0.example.com. 7200 IN SVCB 12 ( svc0.example.net. 601 port="5353" user-display="Legacy Resolver" ) 602 _853._dns.example.com. 7200 IN SVCB 0 svc1.example.com. 603 svc1.example.com. 7200 IN SVCB 1 ( svc1.example.net. alpn="dot" 604 port="5353" esniconfig="..." 605 user-display="Preferred Example's Choice" ) 607 _443_dns.example.com. 7200 IN SVCB 0 svc4.example.net. 608 svc4.example.com. 7200 IN SVCB 3 ( svc2.example.net. alpn="h2" 609 port="5353" esniconfig="..." user-display= ) 610 svc4.example.com. 7200 IN SVCB 2 ( svc3.example.net. alpn="h3" 611 port="5353" esniconfig="..." 612 user-display="Testing QUIC") 614 16. References 616 16.1. Normative References 618 [RFC1035] Mockapetris, P., "Domain names - implementation and 619 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 620 November 1987, . 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, 624 DOI 10.17487/RFC2119, March 1997, 625 . 627 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 628 and P. Hoffman, "Specification for DNS over Transport 629 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 630 2016, . 632 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 633 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 634 May 2017, . 636 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 637 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 638 . 640 16.2. Informative References 642 [curl] "Publicly available servers", n.d., 643 . 646 [dnsprivacy.org] 647 "DNS Privacy Test Servers", n.d., 648 . 652 [I-D.btw-add-home] 653 Boucadair, M., Reddy.K, T., Wing, D., and N. Cook, 654 "Encrypted DNS Discovery and Deployment Considerations for 655 Home Networks", draft-btw-add-home-07 (work in progress), 656 July 2020. 658 [moz.com] "The Moz Top 500 Websites", n.d., 659 . 661 [public-dns.info] 662 "Public DNS Server List", n.d., 663 . 665 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 666 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 667 2015, . 669 Author's Address 671 Daniel Migault 672 Ericsson 673 8275 Trans Canada Route 674 Saint Laurent, QC 4S 0B6 675 Canada 677 EMail: daniel.migault@ericsson.com