idnits 2.17.00 (12 Aug 2021) /tmp/idnits44384/draft-mglt-dprive-add-dofoo-discovery-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 2 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 23, 2020) is 842 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop D. Migault 3 Internet-Draft Ericsson 4 Intended status: Informational January 23, 2020 5 Expires: July 26, 2020 7 DNS over Foo Discovery Mechanism 8 draft-mglt-dprive-add-dofoo-discovery-00 10 Abstract 12 This document describes a mechanism that enables a DNS client to 13 discover other DNS alternatives such as DoT or DoH for one specific 14 domain. This document also extends this discovery mechanism to an 15 Internet wide of open resolvers search - though this is expected to 16 be described further in a separate document. While search are always 17 initiated by the DNS client, this document also indicates how a 18 resolver MAY indicate a DNS client its preference for using 19 alternative flavors of transport layer. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 26, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Discovery mechanism associated to one domain . . . . . . . . 2 58 3.1. Infering domain from resolvers IP address . . . . . . . . 5 59 4. Resolver advertising other service sub type . . . . . . . . . 5 60 5. Migration to service sub types . . . . . . . . . . . . . . . 6 61 6. Service discovery over the Internet . . . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 7.1. Use of protected channel is RECOMMENDED . . . . . . . . . 7 64 7.2. DNSSEC is RECOMMENDED . . . . . . . . . . . . . . . . . . 8 65 7.3. TLSA is RECOMMENDED . . . . . . . . . . . . . . . . . . . 8 66 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 11. Normative References . . . . . . . . . . . . . . . . . . . . 11 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Requirements Notation 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 76 "OPTIONAL" in this document are to be interpreted as described BCP 14 77 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 78 as shown here. 80 2. Introduction 82 3. Discovery mechanism associated to one domain 84 The discovery mechanism is intended to enable a DNS client to 85 discover what are the resolvers options available as well as how to 86 further use these resolvers. 88 The procedure is based on service discovery [RFC8145] and the overall 89 procedure consists in finding various instances of the service 90 "rdns". The resolution service is designated as "rdns" and differs 91 from the service "domain" defined by IANA. The motivation for 92 creating a new service is that "domain" is associated to port 53 as 93 well as TCP and UDP and designates both the authoritative as well as 94 the resoling service. On the other hand the service "rdns" is 95 expected to be limited to the DNS resolution service that can have 96 various transport flavors including using different ports. 98 In this document, the service "rdns" is associated to a domain such 99 as example.com. This means that the discovery process is performed 100 over a specific portion of the internet, and resolvers that have no 101 relation to that domain are not expected to be found. It is expected 102 that the domain may be provisioned as a configuration parameter in 103 the DNS client. It is expected that the domain provides a good 104 meaning of the administrative entity managing the resolver, as it 105 reflects the trust/mistrust the end user puts in the resolution. 106 This configuration parameters differs from the one that is currently 107 provisioned and discussion on how to proceed to resolver discovery 108 from a legacy provisioning is described in more details in 109 Section 3.1. 111 The DNS client then searches for the rdns service associated to the 112 domain example.com by querying PTR RRsets associated to 113 _rdns_udp.example.com. This query corresponds to the general case of 114 DNS service discovery. While tcp is reserved for TCP only and DNS is 115 not only running on top of TCP we use _udp as a representation of 116 _srv. 118 The difference with service discovery is that the response is 119 expected to return instances of the service type. These instances 120 may offer completely different services, but the end user is expected 121 to select them according to their human readable name. In our case, 122 the rdns service type can be implemented into different sub services 123 types that are in our cases (DOT, DOH DNS). DOT, DOH and DNS are 124 only example and any other designation may have been provided. 125 Possible ways to distinguish these services could have been to adopt 126 a convention in the service instance names or to have standard value 127 for the service names. We prefer not to take that path and remove 128 any constraints on the service name as it usually appears to the end 129 user and we want to leave it free to contain what is going to be 130 meaningful for the end user. Typically, DOT, DOH or DNS are unlikely 131 to be meaningful to the waste majority of the internet users. 132 Instead we used the DNS-SD capabilities to specify sub services by 133 prefixing with _dot, _doh and _dns53 the dns._udp service type. 135 DNS client --> Resolver 136 _rdns.example.com PTR ? 138 <-- 139 _rdns_udp.example.com PTR DOT._dot._sub._rdns._udp.example.com 140 _rdns_udp.example.com PTR DOH._doh_sub._rdns._udp.example.com 141 _rdns_udp.example.com PTR DNS._dns53_sub._rdns._udp.example.com 143 Note that "DOT", "DOH" and "DNS" are the strings that may be shown to 144 the end user. The main difference with DNS-SD is that the sub type 145 was initially designed so the end user can narrow down its search. 146 More explicitly its purpose was to enable an end user to narrow down 147 the search on services providing DNS resolution over HTTPS with 148 _doh._sub._rdns._udp.example.com. The purpose was not to split a 149 generic service into multiple sub types of services. 151 Note that the user interface is expected to interpret and present to 152 the end user the different services by interpreting the _dot, _doh or 153 _dns53 sub service types and easing the understanding of the end 154 user. If the DNS client is implementing a specific configuration, it 155 will also have to interprete the sub types according to the 156 configuration of the end user. 158 Now that the end user has the various services available ("DOH", 159 "DOT" and "DNS") with there associated types, the selection can 160 occur, and the DNS client can request additional information about 161 the service itself to set up a session with the chosen service. In 162 our case this is mostly the host name, ports, the ip address, the 163 certificates, .... If the DNS client choses to use DoH, for example, 164 it will request the SRV RRsets associated to that service. 166 Note that in our case, the sub service type carries sufficient 167 information and no additional information is needed. There is no 168 need to request the TXT reccord. Note also that carrying the sub 169 type into the TXT RRsets would not be appropriated as this is believe 170 to be a sufficiently important information to prevent a DNS client to 171 browse thought all the different service instances. 173 While the TXT RRset is not necessary now, it MAY contain additional 174 information that may be usefull to the DNS client as well. 176 It is expected these exchanges are protected with DNSSEC as these 177 could be performed over an untrusted channel as well as through semi 178 trusted resolver. The additional section SHOULD also carry the 179 necessary information to set up the session between the DNS client 180 and the resolver. This includes the IP addresses (A and AAAA) 181 RRsets, for services implemented over TLS the necessary security 182 credentials (TLSA RRsets). 184 DNS client --> Resolver 185 DOH._doh_sub._rdns._udp.example.com SRV ? 186 <-- 187 DOH._doh_sub_rdns.example.com SRV priority=0, weight=0, 188 port=443 host=resolver.example.com 189 DOH._doh_sub_rdns.example.com SRV priority=0, weight=1, 190 port=443 host=resolver.example.com 191 DOH._doh_sub_rdns.example.com RRSIG (SRV) 192 resolver.example.com AAAA 193 resolver.example.com AAAA 194 resolver.example.com RRSIG (A) 195 resolver.example.com TLSA 196 resolver.example.com RRSIG (TLSA) 198 3.1. Infering domain from resolvers IP address 200 When an application such as an web browser has a DNS client as part 201 of its components, the configuration of that DNS client can be part 202 of the application configuration. In such case, the domain may be 203 provisioned in the configuration either by the software vendor or 204 manually by the end user. On the other hand, a non negligible part 205 of the systems the resolver is automatically provided by the network 206 and designated by an IP address [RFC3646]. In such cases, there is a 207 need to derive the domain associated to that domain name. 209 This section describes a procedure performed by the DNS client to 210 derive the domain from the IP address. It is also expected that 211 resolver adapt their naming convention so that the procedure works. 212 More precisely, the domain will be derived from the IP address by: 214 1. performing a reverse resolution 216 2. assuming the resulting FQDN is composed of a hostname and the 217 domain name. For example, if resolver.example.com is the 218 resulting FQDN from the reverse resolution, then the domain will 219 be example.com. 221 4. Resolver advertising other service sub type 223 A resolver receiving a DNS request over a service sub type MAY be 224 willing to advertise the DNS client that other sub service type are 225 available. This is especially useful, when, for example, a resolver 226 wants that the DNS resolver switches to other service sub types that 227 are more secure. 229 In order to do so the resolver MAY provide in the additional data 230 field the appropriated SRV RRsets. As an example, if the resolver 231 wants to advertise the existence of resolver using dot or doh sub 232 service type, the resolver would add the following RRsets. 233 Additional RRSets such as A, AAAA or TLSA RRSets MAY also be added. 235 DOH._doh._sub_rdns.example.com SRV priority=0, weight=0, 236 port=443 host=resolver.example.com 237 DOH._doh._sub_rdns.example.com SRV priority=0, weight=1, 238 port=443 host=resolver.example.com 239 DOH._doh._sub_rdns.example.com RRSIG (SRV) 240 DOT._dot._sub_rdns.example.com SRV priority=0, weight=0, 241 port=443 host=resolver.example.com 242 DOT._dot._sub_rdns.example.com SRV priority=0, weight=1, 243 port=443 host=resolver.example.com 244 DOT._dot._sub_rdns.example.com RRSIG (SRV) 246 5. Migration to service sub types 248 The principle of the discovery mechanism is that the resolver 249 indicates the available service sub types and let the DNS client 250 chose which sub type it prefers. On the other hand, the resolver MAY 251 also indicate a preference using the priority and weight fields 252 however, there is no mechanisms that could permit an indirection from 253 one service sub type to another service sub type. Redirection MAY 254 especially be needed when a DNS client is using the dns53 sub type 255 and the resolver would liek to upgrade the DNS client session to a 256 more secure session. The MAY require a specific ERROR code that will 257 request the DNS client to perform service discovery. 259 It is expected that dns53 sub type MUST always be provided to perform 260 resolver discovery. In other words, resolver discovery MUST be 261 available though the non confidential channels designated by the sub 262 service type dns53. However, this does not mean that a resolver is 263 expected to implement the dns53 sub type service for resolutions. 264 The availability of the sub service types for resolution. If a 265 resolver chose not to provide the dns53 sub service type, that 266 service MUST NOT be pointed by the _rdns.example.com search. 268 6. Service discovery over the Internet 270 THIS SECTION NEEDS PROBABLY TO THE TOPIC OF A DEDICATED DRAFT. 272 The current document describes a search mechanism over a single 273 domain. This is mostly useful for one resolver to anounce 274 availability of other sub service types as well as for resolver to 275 discover available alternatives. However, this requires the 276 knowledge of a domain. The domain can be provisionned out-of band 277 and results from a configuration setting. In the case of local scope 278 resolver, it can also be derived from a provisioned IP address. This 279 section aims at extending the ability for one DNS client to learn 280 about the different available domain associated to a resolver on the 281 Internet. This section will list open resolvers that are available. 283 The mechanism involves the creation of a special domain name 284 rdns.arpa that will list the various rdns domains. This mechanism 285 remains valid as long as the list of rdns domain name remains 286 relatively limited. The number of rdns domain that can fit into a 287 payload will depend on the length of the rnds domain, so rdns domains 288 are expected to have limited length. However the compactness is not 289 expected to match the one achieved for the root servers that are 290 designated by a one character size identity. The reason for it is 291 that the identity of the resolver is expected to carry some meaning 292 to the DNS client as opposed to the root servers. 294 That said, a UDP packet of 4096 bytes is expected to contain a 295 significant amount of resolvers. The number of open resolver is not 296 expected to reach that limit and if so the list can be retrieved 297 through TCP. 299 The traffic associated to that domain is expected to be limited as 300 most applications are expected to be provisioned with that RRset. 302 b._rdns.rdns.arpa PTR 303 b._rdns.rdns.arpa PTR 304 [...] 306 TBD: * IANA procedure to register * criterias that needs to be met to 307 appear in the list 309 QUESTION: * Do we need to add some criteria for the search ? 311 7. Security Considerations 313 7.1. Use of protected channel is RECOMMENDED 315 When available, it is recommended to chose a protected version of the 316 rdns service. More specifically, the use of end-to-end protection 317 ensures that the DNS client is connected to the expected platform and 318 that its traffic cannot be intercepted on path. Typically, the 319 selection of resolver on the Internet (and not on your ISP network) 320 and the use of a non protected channel enables an attacker to monitor 321 your DNS traffic. The similar observation remains true if you are 322 connected to the resolver of your ISP. It is commonly believed that 323 trusting your ISP (that is your first hop) makes encryption 324 unecessary. Trusting your ISP is mandatory in any case, but the 325 associated level of trust with an protected channel is restricted to 326 the operation of the DNS platform. With non protected channel the 327 trust is extended to any segment between the DNS client and the 328 resolver, which is consequently larger. The use of a protected 329 channel is recommended as it will prevent anyone on path to monitor 330 your traffic. 332 7.2. DNSSEC is RECOMMENDED 334 The exchanges SHOULD be protected with DNSSEC to ensure integrity of 335 the information between the authoritative servers and the DNS client. 336 Without DNSSEC protection, DNS messages may be tampered typically 337 when they are transmitted over an unprotected channel either between 338 the DNS client and the resolver or between the resolver and the 339 authoritative servers. The messages may be tampered by an online 340 attacker intercepting the messages or by the intermediary devices. 341 It is important to realize that protection provided by TLS is limited 342 to the channel between the DNS client and the resolver. There are a 343 number of cases were the trust in the resolver is not sufficient 344 which justify the generalization of the use of DNSSEC. The following 345 examples are illustrative and are intended to be exhaustive. 347 First, the discovery exchanges may happen over an unprotected 348 channel, in which case, the messages exchanged may be tampered by 349 anyone on-path between the DNS client and the resolver as well as 350 between the resolver and the authoritative servers - including the 351 resolver. When TLS is used between the DNS client and the resolver, 352 this does not necessarily mean the DNS client trusts the resolver. 353 Typically, the TLS session may be established with a self-signed 354 certificate in which case the session is basically protected by a 355 proof-of-ownership. In other cases, the session may be established 356 based on Certificate Authorities (CA) that have been configured into 357 the TLS client, but that are not necessarily trusted by the DNS 358 client. In such cases, the connected resolver may be used to 359 discover resolvers from another domain. In this case, the resolver 360 is probably interacting with authoritative servers using untrusted 361 and unprotected channels. Integrity protection relies on DNSSEC. 363 7.3. TLSA is RECOMMENDED 365 When TLS is used to protect the DNS exchanges, certificates or 366 fingerprint SHOULD be provided to implement trust into the 367 communication between the DNS client and the resolver. The TLS 368 session and the association of the private key to a specific identity 369 can be based on two different trust model. The Web PKI that will 370 rely on CA provisioned in the TLS library or the TA provided to the 371 DNS client. A DNS client SHOULD be able to validate the trust of a 372 TLS session based on the DNSSEC trust model using DANE. 374 When the DNS client is protecting its session to the resolver via 375 TLS, the DNS client may initiate an TLS session that is not validated 376 by a CA or a TLSA RRsets. The DNS client MUST proceed to the 377 discovery process and validate the certificate match the TLSA RRset. 378 In case of mismatch the DNS client MUST abort the session. 380 8. Privacy Considerations 382 When the discovery protocol is performed using a resolver that 383 belongs to one domain for another domain, or over an unprotected 384 channel, the DNS client must be conscious that its is revealing to 385 the resolver its intention to use another resolver. More 386 specifically, suppose an resolver is complying some legal 387 requirements that DNS traffic must be unencrypted. Using this 388 resolver to perform a resolver discovery reveals the intention of 389 potentially using alternative resolvers. Alternatively, narrowing 390 down the discovery over a specific sub type of resolver (DoT, or DoH) 391 may reveal to that resolver the type of communication. As result, 392 when performing a discovery over a domain that differs to the domain 393 the resolver belongs to, it is RECOMMENDED to request the SRV RRsets 394 associated to all different sub type of proposed services. 396 The absence of traffic that results from switching completely to a 397 newly discovered resolver right after the discovery process provides 398 an indication to the resolver the DNS client is switching to. It is 399 hard to make that switch unnoticed to the initial resolver and the 400 DNS resolver MUST assume this will be noticed. The information of 401 switching may be limited by sharing the traffic between different 402 resolvers, however, the traffic pattern associated to each resolver 403 may also reveal the switch. In addition, when the initial resolver 404 is provided by the ISP, the ISP is also able to monitor the IP 405 traffic and infer the switch. As a result, the DNS client SHOULD 406 assume the switch will be detected. 408 With DoT or DoH, the selection of port 443 will make the traffic 409 indistinguishable from HTTPS traffic. This means that an observer 410 will not be able to tell whether the traffic carries web traffic or 411 DNS traffic. Note that it presents an interest if the server offers 412 both a web service as well as a resolution service. Note that many 413 resolvers have a dedicated IP address for the resolution service, in 414 which case, the information will be inferred from the IP address. 415 Note also that traffic analysis may infer this as well. Typically 416 suppose an IP address hosts one or multiple web sites that are not 417 popular as well as a resolving service. If this IP address is 418 associated frequent short size exchanges, it is likely that these 419 exchanges will be DNS exchanges rather than Web traffic. The size of 420 the packet may also be used as well as many other patterns. As a 421 result, the use port 443 to hide the DNS traffic over web traffic 422 should be considered as providing limited privacy. 424 9. IANA Considerations 426 This document requests the IANA the creation of a new service name in 427 the Service Name and Transport Protocol Port Number Registry 428 https://www.iana.org/assignments/service-names-port-numbers/service- 429 names-port-numbers.xml 431 Fields Port Number, Transport Protocol, Assignee, Contact, 432 Modification Date, Service Unauthorized Use Report, Assignment Notes 433 are void. 435 Service | Description | Registration | Reference | 436 Name | | Date | | 437 --------+----------------+--------------+-----------+ 438 rdns | DNS resolution | TBD1 | RFC-TBD | 440 This document requests the IANA the creation of the following 441 underscored node names in the Underscored and Globally Scoped DNS 442 Node Names registry https://www.iana.org/assignments/dns-parameters/ 443 dns-parameters.xhtml#dns-parameters-14 445 RR Type | _NODE NAME | Reference 446 --------+------------+---------- 447 SRV | _rdn | RFC-TBD 448 SRV | _dot | RFC-TBD 449 SRV | _doh | RFC-TBD 450 SRV | _dns53 | RFC-TBD 452 10. Appendix 454 Example of a file. 456 _rdns_udp.example.com PTR DOT._dot._sub._rdns._udp.example.com 457 _rdns_udp.example.com PTR DOH._doh_sub._rdns._udp.example.com 458 _rdns_udp.example.com PTR DNS._dns53_sub._rdns._udp.example.com 460 _dot_sub_rdns.example.com PTR DOT._dot_sub_rdns._udp.example.com 461 _doh_sub_rdns.example.com PTR DOH._doh_sub_rdns._udp.example.com 462 _dns53_sub_rdns.example.com PTR DNS._dns53_sub_rdns._udp.example.com 464 DOT._dot_sub_rdns.example.com SRV port=443 host=dns.example.com 465 DOT._dot_sub_rdns.example.com SRV port=53 host=dns.example.com 466 DOH._dot_sub_rdns.example.com SRV port=443 host=dns-dot.example.com 467 DNS._dns53_sub_rdns.example.com SRV port=53 host=dns53.example.com 469 dns.example.com AAAA 470 dns.example.com TLSA 471 dns.example.com RRSIG 473 dns53.example.com AAAA 474 dns53.example.com RRSIG 476 11. Normative References 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, 480 DOI 10.17487/RFC2119, March 1997, 481 . 483 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 484 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 485 DOI 10.17487/RFC3646, December 2003, 486 . 488 [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust 489 Anchor Knowledge in DNS Security Extensions (DNSSEC)", 490 RFC 8145, DOI 10.17487/RFC8145, April 2017, 491 . 493 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 494 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 495 May 2017, . 497 Author's Address 498 Daniel Migault 499 Ericsson 500 8275 Trans Canada Route 501 Saint Laurent, QC 4S 0B6 502 Canada 504 EMail: daniel.migault@ericsson.com