idnits 2.17.1 draft-mglt-add-rdp-02.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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 141 has weird spacing: '... client the c...' == Line 147 has weird spacing: '...Service desig...' == Line 154 has weird spacing: '...ansport desig...' == Line 157 has weird spacing: '... Domain a DNS...' == Line 465 has weird spacing: '...display indic...' == (5 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 (May 29, 2020) is 1421 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-06 -- 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 May 29, 2020 5 Expires: November 30, 2020 7 DNS Resolver Discovery Protocol (DRDP) 8 draft-mglt-add-rdp-02 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 November 30, 2020. 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. DRDP Requirements . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Resolving Domains . . . . . . . . . . . . . . . . . . . . . . 5 57 5.1. Resolving Domain and Resolving Service Identity . . . . . 5 58 5.2. List of Resolving Domains . . . . . . . . . . . . . . . . 6 59 5.3. Local Network Resolving Domain . . . . . . . . . . . . . 7 60 6. Resolving Service Discovery . . . . . . . . . . . . . . . . . 8 61 6.1. Discovery of all service instances . . . . . . . . . . . 8 62 6.2. Discovery of specific service instances . . . . . . . . . 9 63 6.3. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 6.4. SvcParamKey . . . . . . . . . . . . . . . . . . . . . . . 10 65 7. Resolver advertising other service sub type . . . . . . . . . 11 66 8. Migration to service sub types . . . . . . . . . . . . . . . 11 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 9.1. Use of protected channel is RECOMMENDED . . . . . . . . . 11 69 9.2. DNSSEC is RECOMMENDED . . . . . . . . . . . . . . . . . . 12 70 9.3. TLSA is RECOMMENDED . . . . . . . . . . . . . . . . . . . 12 71 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 72 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 74 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 76 13.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Requirements Notation 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 83 "OPTIONAL" in this document are to be interpreted as described in 84 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 85 capitals, as shown here. 87 2. Introduction 89 A DNS client can proceed to DNS resolution using various resolving 90 services. These services can be local or global and can use a wide 91 range of DNS transport protocols such as, for example, standard DNS 92 [RFC1035], DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484]. The 93 local scope of these services may take various forms. For example, 94 it could be associated to a network perspective ( restricted to the 95 network the DNS client is connected to ) or to an application 96 perspective ( restricted to some domain names ). 98 The purpose of the DNS Resolving service Protocol (DRDP) is to 99 discover resolving services available to the DNS client. These 100 available resolving services to a given DNS client may highly depend 101 on its location or browsing activity. The number of resolving 102 services available to the DNS client is expected to remain quite 103 consequent and evolve over time. Similarly, characteristics 104 associated to these resolving services may also evolve over time. As 105 a result, the DNS client is unlikely willing to synchronize such a 106 huge data base of resolving services. DRDP proposes an alternative 107 that consists in adaptively discovering the available resolving 108 services based on the DNS client context. 110 DRDP adopts a hierarchical approach where the DNS client gets 111 _resolving domains_ from the context. These _resolving domains_ are 112 entry points for resolving services ( associated to each of these 113 resolving domains ). 115 The DNS client may obtain the contextual resolving domains via 116 various way, including a configuration or via DHCP Options 117 [I-D.btw-add-home]. 119 This document describes two mechanisms for a DNS client to retrieve 120 resolving domains. Firstly, it is envisioned that these resolving 121 domains will be provided by multiple third party providers which 122 could designate a set of resolving domains. This set is designated 123 by a pointer used by the DNS client to retrieve the resolving 124 domains. 126 Secondly, resolving domain may be derived from the IP address of the 127 legacy resolving service provided via the Recursive Name Server 128 option [RFC3646]. Such a resolving domain can be seen as a network 129 local scope resolving domain. This resolving domain may then be used 130 by the DNS client to discover he various flavors of resolving 131 services provided by the ISP (DoH, DoT for example), while the legacy 132 IP address provided is reserved to the legacy resolving service. 134 The discovery process is expected to be followed by a selection 135 process by which the DNS client selects the resolving service it is 136 willing to use for the DNS resolution of the end user or application. 137 How the selection is performed is out of scope of this document. 139 3. Terminology 141 DNS client the client that sends DNS queries fro resolution. In 142 this document the DNS client designates also the end entity that 143 is collecting information about the available Resolving Services 144 and then proceed to the selection of a subset them. The selection 145 is processed according to the DNS client's policy. 147 Resolving Service designates a service that receives DNS queries 148 from a DNS client and resolves them. A Resolving Service is 149 implemented by one or multiple resolvers. 151 Resolver: A resolver designates the software or hardware handling the 152 DNS exchange. See [RFC7719] for more details. 154 DNS transport designates the necessary parameters a DNS client needs 155 to establish a session with a Resolving Service. 157 Resolving Domain a DNS domain that hosts one or multiple resolving 158 services. 160 4. DRDP Requirements 162 This section lists the DRDP requirements. 164 REQ 1: DRDP MUST enable a DNS client to discover the available 165 resolving services with their associated characteristics in order to 166 proceeds to a selection process. The selection process takes 167 resolving services identities and associated parameters and proceed 168 to the selection. 169 Any sort of resolving service selection is outside the scope of DRDP. 171 REQ 2: While the discovery process is triggered by the DNS client, a 172 third party MUST be able to provide necessary input information so a 173 resolving service discovery process can be triggered within a 174 specific context. 175 Provisioning protocols to provide this information is not as per say 176 in scope of DRDP. DRDP defines the format of the format for such 177 input as well as a set of such inputs. 179 REQ 3: Any information used in DRDP MUST be authenticated by its 180 owner. In particular, the characteristics associated to the 181 resolving service MUST be certified by the resolving service operator 182 / owner and MUST be associated a validity period. In addition, a 183 third party providing a set of inputs MUST authenticate that set. 185 REQ 4: Information associated to the resolving services is intended 186 to enable the selection process that is assumed to match the end user 187 or application policy. The selection process is out of scope of 188 DRDP. Information may carry some characteristics of a resolving 189 service or hints that will help the selection. In particular an 190 operator of multiple resolving service MUST be able to associate a 191 preference to the proposed resolving services. To ease automation of 192 the selection as well as to make multiple applications benefit from 193 DRDP the information MUST be carried over a standardized format. 195 REQ 5: DRDP MUST be designed to be used indifferently by a DNS client 196 using any DNS transport protocol (Do53, DoT, DoH, ...). However, 197 DRDP SHOULD be able to restrict the information retrieved to a 198 certain type of resolving service, i.e. Do53, DoT, DoH. 200 REQ 6: DRDP deployment MUST NOT be disruptive for the legacy DNS 201 client or infrastructure and legacy client SHOULD be able to 202 incrementally include DRDP. 204 5. Resolving Domains 206 The resolving domain is the input of a discovery process. 207 Section Section 5.1 defines the format resolving domain and exposes 208 why resolving domains seem convenient pointers to resolving service 209 as well as how the relates to resolving service identities. 210 Section Section 5.2 defines the format of a pointer to a set of 211 resolving domains as well as how to retrieve how to handle such set. 212 Such pointer are expected to be used by third party providers to 213 indicate a subset of resolving domains that match a certain context. 214 The use of a pointer is expected to ease the management of the set as 215 opposed to a explicit list. The definition of such a format is 216 expected to favor interoperability with third party providers. 218 Finally, section Section 5.3 defines a procedure to derive a 219 resolving domain from the IP address provided by Recursive Name 220 Server option [RFC3646]. Such procedure is expected to leverage from 221 the existing and legacy infrastructure. 223 5.1. Resolving Domain and Resolving Service Identity 225 A resolving service is identified by a FQDN - such as 226 resolver.example.com - and the domain part ( example.com ) is 227 designated as the resolving domain. Note that the hostname 228 (resolver) is only considered as a way to distinguish different 229 resolving services but it is not expected to carry any specific 230 information that will be useful for the selection process. 232 The resolving domain is expected to be representative to the end user 233 of the brand or legal entity of the institution the end user sends 234 its data to. The end user is likely to select a given resolving 235 domain based on the trust he puts into the associated legal entity. 236 The resolving domain follows some DNS encoding rules and as such may 237 not be believed to be so user friendly. On the other hand, the end 238 user may also be familiar with that format and the use or a 239 standardize format helps automation in the selection. Typically, it 240 might be ericsson.com or ericsson which is different from Ericsson 241 (with appropriated police character and color) which would be more 242 meaningful for the end user. Note that a user interface may also use 243 the resolving domain to derive more user friendly and additional 244 specific information that will be presented to the user. This could 245 include for example additional RDAP queries, favicons of web sites 246 that are shown to the end users. What is presented to the end user 247 is out of scope of this document, but the resolving domain can be 248 used as the key. 250 The hostname part is only meaningful within the resolving domain. 251 While, it may carry some information that may be interpreted to the 252 end user, the constraint provided by the DNS format may be too 253 restricting. As a result, it is expected that a more user friendly 254 string might be associated with the hostname and that the hostname 255 remain reserved for networking administrators. 257 5.2. List of Resolving Domains 259 A resolving domain list is designated by a FQDN example.com and the 260 resolving domains contained in that list are retrieved by sending a 261 query of type PTR for b._dns.example.com. 263 The zone file below is inspired from DNS-SD where b indicates a 264 browsing domain, _dns indicates the DNS resolving service, 265 example.com designates the list of the resolving domains. 266 resolving domain_0, resolving_domain_n indicates the various 267 resolving domains. The order of the resolving domains is irrelevant, 268 and the zone administrator SHOULD regularly reorder them. The RRsets 269 MUST be signed with DNSSEC. 271 b._dns.example.com PTR 272 [...] 273 b._dns.example.com PTR 275 Using the DNS provides the advantage to retrieve the resolving domain 276 without requiring other libraries than DNS as well as benefit from 277 the DNS caching infrastructure including the use of the TTL. 279 An EDNS buffer size of 1232 bytes will avoid fragmentation on nearly 280 all current networks. This is based on an MTU of 1280, which is 281 required by the IPv6 specification, minus 48 bytes for the IPv6 and 282 UDP headers. Such size makes lists of a 100 names viable over UDP 283 without fragmentation. Larger lists will require the DNS exchange to 284 be performed over TCP. While there is no hard limits, downloading 285 the full list every TTL may not be appropriated for very large lists 286 where the synchronization mechanisms may be needed. 288 The current size of such lists [curl][dnsprivacy.org] have less than 289 50 resolving domains. Other lists such as [public-dns.info] have as 290 much as 11.000 entries, but such lists seems to contain open 291 resolvers which is out side of the scope of a selection process. 292 Web browser (Google Chrome) also have lists over 10.000 entries, but 293 in case a significant number of entries seems to be IP addresses that 294 have a very limited network scope ( e.g. limited to the ISP ). The 295 length of the list in scope to the DNS client is in fact significant 296 smaller in term of IP addresses and even smaller if resolving domain 297 are able to represent multiple IP addresses. Overall, the size of 298 such lists are currently due to the absence of discovery protocols. 300 5.3. Local Network Resolving Domain 302 Resolving service are currently configured or advertised via IP 303 addresses rather than a FQDN as a DNS resolution would be needed to 304 resolve the IP address. More specifically, networks usually 305 advertise the resolving service via a Recursive Name Server option 306 [RFC3646] that contains an IP address. Similarly application usually 307 configures their resolving services with IP addresses (8.8.8.8, 308 1.1.1.1, 9.9.9.9,...). As a result, this section indicates a 309 mechanism that would enable a DNS client to derive a resolving domain 310 of a resolver from an IP address of an advertised resolver. The 311 mechanism described here is expected to be used as an hint. 313 The resolving domain will be derived from the IP address by: 315 1. performing a reverse resolution 317 2. assume the resulting FQDN is composed of a hostname appended to 318 the resolving domain. For example, if resolver.example.com is 319 the resulting FQDN from the reverse resolution, then the rdns 320 domain will be example.com. 322 In most cases local resolving services uses global IP address which 323 does not limit the reverse resolution to an associated local 324 resolver. However the zone associated to the resolving domain might 325 not be available globally and instead be restricted to the local 326 network. As a result, DNS client SHOULD perform DNS resolution 327 associated to the local resolving domain using the local resolver, 328 and resolving service operator SHOULD publish the resolving domain 329 zone to the global Internet. 331 Legacy DNS client will not be impacted. Upon receiving the IP 332 address they will send their DNS queries to that IP address. DRDP 333 aware DNS client will derive the resolving domain and attempt to 334 perform a discovery within the resolving domain. 336 If other mechanisms as used to advertise the resolving domains such 337 as those described in [I-D.btw-add-home], and the resolving domain 338 are different, the DNS client should perform DRDP with both resolving 339 domains. 341 6. Resolving Service Discovery 343 6.1. Discovery of all service instances 345 Given a resolving domain example.com, a DNS client MAY request all 346 possible resolving service instances with a query of type SVCB with 347 the service _dns. 349 The example below presents the use of an AliasForm followed by a 350 ServiceForm which allows an indirection. The Alias form is not 351 madatory and instead only ServiceForm associated to _dns.example.com 352 could have been used instead. 354 The SvcFieldPriority indicates the preference of the resolving 355 service instance. 357 The SvcParamKey alpn MUST be present when TLS is used as its presence 358 and value indicates the DNS transport. The absence of the alpn 359 SvcParamKey indicates Do53, alpn set to dot indicates DoT is served 360 while h* indicates DoH is served. Note that the port value (53, 853, 361 443) is not used to determine the DNS transport as non standard port 362 MAY be used. The example below uses an non standard port 5353 for 363 illustrative purpose. 365 Other SvcParam are detailed in Section 6.4 and are optional. A 366 SvcParam not understood by the DNS client MUST be ignored. 368 The RRsets MUST be protected with DNSSEC and when alpn is provided a 369 TLSA RRset SHOULD be present. These RRsets have been omitted for 370 clarity. 372 ## Discovery of all service instances 373 _dns.example.com. 7200 IN SVCB 0 svc.example.com. 374 svc.example.com. 7200 IN SVCB 12 ( svc0.example.net. 375 port="5353" user-display="Legacy Resolver" ) 376 svc.example.com. 7200 IN SVCB 1 ( svc1.example.net. alpn="dot" 377 port="5353" esniconfig="..." 378 user-display="Preferred Example's Choice" ) 379 svc.example.com. 7200 IN SVCB 3 ( svc2.example.net. alpn="h2" 380 port="5353" esniconfig="..." user-display= ) 381 svc.example.com. 7200 IN SVCB 2 ( svc3.example.net. alpn="h3" 382 port="5353" esniconfig="..." user-display= ) 384 6.2. Discovery of specific service instances 386 To reduce the size of the messages, the DNS client MAY also prefer to 387 query information of resolving services using a specific transport 388 (DNS, DoT, DoH) that are designated as sub sets. A DNS client MAY 389 list the different subsets of that resolving domain with a PTR query. 390 This document defines the following subsets _53._dns for DNS, 391 _853._dns for DoT and _443.__dns for DoH. Other subsets MAY be 392 defined in the future. A DNS client that does not understand a 393 subset SHOULD ignore it and maybe proceed to the discovery as defined 394 in Section 6.1. 396 All subsets MUST share the same resolving domain and be listed with a 397 PTR RRsets. The DNS client MAY NOT performed a DNS query of type 398 PTR, for example, if it has a previous knowledge of the existence of 399 the subset or if indicated by its policy. In this it MAY directly 400 proceed to the SRVCB resolution. 402 The same restrictions as defined in section Section 6.1 apply. 404 Note that while the SvcFieldPriority indicates the priority within a 405 subservice, this field MUST have a coherence across subservices. The 406 priority provided SHOULD be coherent with the case of a _dns SRVCB 407 query of section Section 6.1. 409 The figure below illustrates an example of zone file. RRSIG and TLSA 410 have been omitted for the purpose of clarity. 412 ### Definition of the resolving service subsets 413 _dns.example.com PTR _53._dns.example.com 414 _dns.example.com PTR _853._dns.example.com 415 _dns.example.com PTR _443._dns.example.com 417 ### services instances per service subset 418 _53._dns.example.com. 7200 IN SVCB 0 svc0.example.com. 419 svc0.example.com. 7200 IN SVCB 12 ( svc0.example.net. 420 port="5353" user-display="Legacy Resolver" ) 421 _853._dns.example.com. 7200 IN SVCB 0 svc1.example.com. 422 svc1.example.com. 7200 IN SVCB 1 ( svc1.example.net. alpn="dot" 423 port="5353" esniconfig="..." 424 user-display="Preferred Example's Choice" ) 426 _443_dns.example.com. 7200 IN SVCB 0 svc4.example.net. 427 svc4.example.com. 7200 IN SVCB 3 ( svc2.example.net. alpn="h2" 428 port="5353" esniconfig="..." user-display= ) 429 svc4.example.com. 7200 IN SVCB 2 ( svc3.example.net. alpn="h3" 430 port="5353" esniconfig="..." 431 user-display="Testing QUIC") 433 Some notes: 435 1. _domain uses SVCB but does not have TLS. While SVCB has been 436 created essentially for TLS based service, this does not appear 437 to be mandatory. 439 2. Should we have some constraints regarding the SvcDomainName and 440 QNAME ? 442 3. do we need the service subsets 444 6.3. TTL 446 The DNS client SHOULD perform DRDP at regular intervals as indicated 447 by its policy. 449 The selection process MAY remove resolving services with short TTL 450 lower than a day as it indicates some source of instalbility. Given 451 a subset of selected resolving services, the DNS client may perform 452 DRDP 1 hour before an SVB RRset expires. 454 6.4. SvcParamKey 456 This section defines a set of SvcParamKey that MAY be use to carry 457 the necessary informations for the selection process. 459 alpn : 461 esniconfig : 463 port : 465 user-display indicates a strings in UTF-8 that is expected to be 466 representative to a potential end user. Though there is no 467 restriction in the scope of that string. The string is likely to 468 represent the service within the resolving domain. 470 uri_template designates the URI template for DoH. This key MUST NOT 471 be present on non DoH services and MUST be ignored by the DNS 472 client on non DoH resolving Services. 474 auth_domain indicates the list of authoritative domain name the 475 resolving service has strong relation with. It is expected that a 476 resolving service may prefer to perform DNS resolution over these 477 domains to that specific resolving service as to preserve its 478 privacy. This information MUST be verified and validated. 480 filtering indicates the presence of a filtering service 481 ip_subnet indicates a subnetwork restriction. This is mostly useful 482 for resolving services that are not globally. 484 dnssec indicates whether dnssec is enabled or not. 486 7. Resolver advertising other service sub type 488 A resolving service receiving a DNS request over a service sub type 489 MAY be willing to advertise the DNS client that other sub service 490 type are available. This is especially useful, when, for example, a 491 resolver wants that the DNS resolver switches to other service sub 492 types that are more secure. 494 In order to do so the resolver MAY provide in the additional data 495 field the _dns SRVCB of ServiceForm. 497 8. Migration to service sub types 499 The principle of the discovery mechanism is that the resolver 500 indicates the available service sub types and let the DNS client 501 chose which sub type it prefers. On the other hand, the resolver MAY 502 also indicate a preference using the priority and weight fields. 503 However, there is no mechanisms that could permit an indirection from 504 one service sub type to another service sub type. This document 505 specifies that weight needs to be considered across sub types. 506 Redirection MAY especially be needed when a DNS client is using the 507 Do53 and the resolver would like to upgrade the DNS client session to 508 a more secure session. This MAY require a specific ERROR code that 509 will request the DNS client to perform service discovery. 511 It is expected that DRDP MUST always be available via Do53. However, 512 this does not mean that a resolver is expected to implement the Do53 513 sub type service for a resolving service. If a resolving service 514 provider chooses not to provide a resolving service using Do53, that 515 service MUST NOT be pointed by the _53._dns.example.com search and 516 MUST NOT provide _dns.example.com SRVCB RRsets with no SvcParamKey 517 alpn. 519 9. Security Considerations 521 9.1. Use of protected channel is RECOMMENDED 523 When available, it is recommended to chose a protected version of the 524 rdns service. More specifically, the use of end-to-end protection 525 ensures that the DNS client is connected to the expected platform and 526 that its traffic cannot be intercepted on path. Typically, the 527 selection of resolver on the Internet (and not on your ISP network) 528 and the use of a non protected channel enables an attacker to monitor 529 your DNS traffic. The similar observation remains true if you are 530 connected to the resolver of your ISP. It is commonly believed that 531 trusting your ISP (that is your first hop) makes encryption 532 unecessary. Trusting your ISP is mandatory in any case, but the 533 associated level of trust with an protected channel is restricted to 534 the operation of the DNS platform. With non protected channel the 535 trust is extended to any segment between the DNS client and the 536 resolver, which is consequently larger. The use of a protected 537 channel is recommended as it will prevent anyone on path to monitor 538 your traffic. 540 9.2. DNSSEC is RECOMMENDED 542 The exchanges SHOULD be protected with DNSSEC to ensure integrity of 543 the information between the authoritative servers and the DNS client. 544 Without DNSSEC protection, DNS messages may be tampered typically 545 when they are transmitted over an unprotected channel either between 546 the DNS client and the resolver or between the resolver and the 547 authoritative servers. The messages may be tampered by an online 548 attacker intercepting the messages or by the intermediary devices. 549 It is important to realize that protection provided by TLS is limited 550 to the channel between the DNS client and the resolver. There are a 551 number of cases were the trust in the resolver is not sufficient 552 which justify the generalization of the use of DNSSEC. The following 553 examples are illustrative and are intended to be exhaustive. 555 First, the discovery exchanges may happen over an unprotected 556 channel, in which case, the messages exchanged may be tampered by 557 anyone on-path between the DNS client and the resolver as well as 558 between the resolver and the authoritative servers - including the 559 resolver. When TLS is used between the DNS client and the resolver, 560 this does not necessarily mean the DNS client trusts the resolver. 561 Typically, the TLS session may be established with a self-signed 562 certificate in which case the session is basically protected by a 563 proof-of-ownership. In other cases, the session may be established 564 based on Certificate Authorities (CA) that have been configured into 565 the TLS client, but that are not necessarily trusted by the DNS 566 client. In such cases, the connected resolver may be used to 567 discover resolvers from another domain. In this case, the resolver 568 is probably interacting with authoritative servers using untrusted 569 and unprotected channels. Integrity protection relies on DNSSEC. 571 9.3. TLSA is RECOMMENDED 573 When TLS is used to protect the DNS exchanges, certificates or 574 fingerprint SHOULD be provided to implement trust into the 575 communication between the DNS client and the resolver. The TLS 576 session and the association of the private key to a specific identity 577 can be based on two different trust model. The Web PKI that will 578 rely on CA provisioned in the TLS library or the TA provided to the 579 DNS client. A DNS client SHOULD be able to validate the trust of a 580 TLS session based on the DNSSEC trust model using DANE. 582 When the DNS client is protecting its session to the resolver via 583 TLS, the DNS client may initiate an TLS session that is not validated 584 by a CA or a TLSA RRsets. The DNS client MUST proceed to the 585 discovery process and validate the certificate match the TLSA RRset. 586 In case of mismatch the DNS client MUST abort the session. 588 10. Privacy Considerations 590 When the discovery protocol is performed using a resolver that 591 belongs to one domain for another domain, or over an unprotected 592 channel, the DNS client must be conscious that its is revealing to 593 the resolver its intention to use another resolver. More 594 specifically, suppose an resolver is complying some legal 595 requirements that DNS traffic must be unencrypted. Using this 596 resolver to perform a resolver discovery reveals the intention of 597 potentially using alternative resolvers. Alternatively, narrowing 598 down the discovery over a specific sub type of resolver (DoT, or DoH) 599 may reveal to that resolver the type of communication. As result, 600 when performing a discovery over a domain that differs to the domain 601 the resolver belongs to, it is RECOMMENDED to request the SRV RRsets 602 associated to all different sub type of proposed services. 604 The absence of traffic that results from switching completely to a 605 newly discovered resolver right after the discovery process provides 606 an indication to the resolver the DNS client is switching to. It is 607 hard to make that switch unnoticed to the initial resolver and the 608 DNS resolver MUST assume this will be noticed. The information of 609 switching may be limited by sharing the traffic between different 610 resolvers, however, the traffic pattern associated to each resolver 611 may also reveal the switch. In addition, when the initial resolver 612 is provided by the ISP, the ISP is also able to monitor the IP 613 traffic and infer the switch. As a result, the DNS client SHOULD 614 assume the switch will be detected. 616 With DoT or DoH, the selection of port 443 will make the traffic 617 indistinguishable from HTTPS traffic. This means that an observer 618 will not be able to tell whether the traffic carries web traffic or 619 DNS traffic. Note that it presents an interest if the server offers 620 both a web service as well as a resolution service. Note that many 621 resolvers have a dedicated IP address for the resolution service, in 622 which case, the information will be inferred from the IP address. 623 Note also that traffic analysis may infer this as well. Typically 624 suppose an IP address hosts one or multiple web sites that are not 625 popular as well as a resolving service. If this IP address is 626 associated frequent short size exchanges, it is likely that these 627 exchanges will be DNS exchanges rather than Web traffic. The size of 628 the packet may also be used as well as many other patterns. As a 629 result, the use port 443 to hide the DNS traffic over web traffic 630 should be considered as providing limited privacy. 632 11. IANA Considerations 634 This document requests the IANA the creation of the following 635 underscored node names in the Underscored and Globally Scoped DNS 636 Node Names registry https://www.iana.org/assignments/dns-parameters/ 637 dns-parameters.xhtml#dns-parameters-14 639 RR Type | _NODE NAME | Reference 640 --------+------------+---------- 641 SRVCB | _dns | RFC-TBD 643 SvcParamKey | NAME | Meaning | Reference 644 ------------+--------------+-----------------------------+----------- 645 7 | user-display | User friendly string (UTF8) | RFC-TBD 646 | | to represent the resolver | 647 | uri_template | URI template | 648 | auth_domain | Domains the resolving | 649 | | service is authoritative | 650 | filetring | Filetring services provided | 651 | ip_subnet | ip ranges accepted. | 652 | dnssec | DNSSEC validation enabled | 654 12. Acknowledgments 656 We would like thank Mirja Kuehlewind as well as the GSMA IG for their 657 comments. We also thank Ted Hardie and Paul Hoffman for their feed 658 backs regarding the dns schemes for DoT and DoH. 659 We thank Ben Schwartz for the comments on the list size. We thank 660 Harald Alvestrand for its recommendation on having a model that 661 enable multiple third party providers to provide their own list of 662 resolving domains. 664 13. References 666 13.1. Normative References 668 [RFC1035] Mockapetris, P., "Domain names - implementation and 669 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 670 November 1987, . 672 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 673 Requirement Levels", BCP 14, RFC 2119, 674 DOI 10.17487/RFC2119, March 1997, 675 . 677 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 678 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 679 DOI 10.17487/RFC3646, December 2003, 680 . 682 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 683 and P. Hoffman, "Specification for DNS over Transport 684 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 685 2016, . 687 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 688 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 689 May 2017, . 691 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 692 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 693 . 695 13.2. Informative References 697 [curl] "Publicly available servers", n.d., 698 . 701 [dnsprivacy.org] 702 "DNS Privacy Test Servers", n.d., 703 . 707 [I-D.btw-add-home] 708 Boucadair, M., Reddy.K, T., Wing, D., and N. Cook, 709 "Encrypted DNS Discovery and Deployment Considerations for 710 Home Networks", draft-btw-add-home-06 (work in progress), 711 May 2020. 713 [public-dns.info] 714 "Public DNS Server List", n.d., 715 . 717 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 718 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 719 2015, . 721 Author's Address 723 Daniel Migault 724 Ericsson 725 8275 Trans Canada Route 726 Saint Laurent, QC 4S 0B6 727 Canada 729 EMail: daniel.migault@ericsson.com