idnits 2.17.1 draft-blanchet-regext-rdap-deployfindings-05.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 236: '... says "it is RECOMMENDED that server...' RFC 2119 keyword, line 336: '...al text "The "href" JSON value MUST be...' RFC 2119 keyword, line 338: '... MUST be specified."...' RFC 2119 keyword, line 466: '... [RFC7484] section 3 says: "Base RDAP URLs MUST have a trailing "/"...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 13, 2019) is 1779 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 537 -- Looks like a reference, but probably isn't: '2' on line 540 -- Looks like a reference, but probably isn't: '3' on line 543 -- Looks like a reference, but probably isn't: '4' on line 546 == Missing Reference: 'RFC1166' is mentioned on line 449, but not defined == Missing Reference: 'RFC5952' is mentioned on line 449, but not defined ** Obsolete normative reference: RFC 7482 (Obsoleted by RFC 9082) ** Obsolete normative reference: RFC 7483 (Obsoleted by RFC 9083) ** Obsolete normative reference: RFC 7484 (Obsoleted by RFC 9224) -- Obsolete informational reference (is this intentional?): RFC 5988 (Obsoleted by RFC 8288) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft Viagenie 4 Intended status: Informational June 13, 2019 5 Expires: December 15, 2019 7 RDAP Deployment Findings and Update 8 draft-blanchet-regext-rdap-deployfindings-05 10 Abstract 12 Registration Access Data Protocol(RDAP) is being deployed in domain 13 and IP address registries. This document describes issues and 14 findings while interfacing with the known server implementations and 15 deployments. It also provides recommendations for the 16 specifications. 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 December 15, 2019. 35 Copyright Notice 37 Copyright (c) 2019 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. IANA RDAP Registries Related Issues . . . . . . . . . . . . . 2 54 2.1. Values not Registered or Similar . . . . . . . . . . . . 3 55 2.1.1. Registry Entity . . . . . . . . . . . . . . . . . . . 4 56 2.2. RDAP Extensions not Registered . . . . . . . . . . . . . 4 57 3. RDAP Responses . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Cross-origin resource sharing(CORS) . . . . . . . . . . . 6 59 3.2. Object Class Name empty . . . . . . . . . . . . . . . . . 6 60 3.3. Links Relation Values . . . . . . . . . . . . . . . . . . 6 61 3.4. Related link pointing to self causes infinite loop . . . 7 62 3.5. Link without rel . . . . . . . . . . . . . . . . . . . . 8 63 3.6. Value and href for IDNs in links . . . . . . . . . . . . 8 64 3.7. Registrant Entity Too Deep . . . . . . . . . . . . . . . 9 65 4. Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4.1. URL encoding of : . . . . . . . . . . . . . . . . . . . . 10 67 5. Domain Registrar RDAP Server Location . . . . . . . . . . . . 10 68 6. Issues related to RFC7482 . . . . . . . . . . . . . . . . . . 10 69 6.1. Search patterns that are not . . . . . . . . . . . . . . 10 70 7. IANA RDAP Bootstrap Registries Related Issues . . . . . . . . 11 71 7.1. Missing Trailing Char in Bootstrap Registries . . . . . . 11 72 7.2. Single target value . . . . . . . . . . . . . . . . . . . 11 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 11.2. Informative References . . . . . . . . . . . . . . . . . 12 79 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 While developing various tools and software related to RDAP, issues 85 have been found and are documented below. This document should help 86 in writing future version of the specifications and provide better 87 conformant deployment. It is split in various sections based on 88 where the fix should be applied. Obviously, there are different 89 levels of severity of the issues, including nits or very minor. The 90 actual instances and organisations running the RDAP servers where the 91 issues were found are not listed. 93 2. IANA RDAP Registries Related Issues 95 This section describes issues related to the IANA non-Bootstrap 96 registries as specified in [RFC7483]. 98 2.1. Values not Registered or Similar 100 The IANA RDAP JSON Values registry [1] contains various values 101 expected in JSON responses. The following table shows values not 102 registered in the registry but seen in the field. The second column 103 shows the possible corresponding values already registered. 105 Recommendation: implementations should replace their custom values 106 with the registered ones, when one exist. Implementors should 107 register their values when there is no corresponding registered one. 109 Remarks Type 111 +---------------------------------+---------------------------------+ 112 | Unregistered Values | Possibly Corresponding | 113 | | Registered Values | 114 +---------------------------------+---------------------------------+ 115 | object truncated due to server | object truncated due to | 116 | policy | authorization | 117 | Response truncated due to | object truncated due to | 118 | authorization | authorization | 119 | Object truncated due to | object truncated due to | 120 | authorization | authorization | 121 | object redacted due to | object truncated due to | 122 | authorization | authorization | 123 +---------------------------------+---------------------------------+ 125 Event Action 127 +-----------------------------+-------------------------------------+ 128 | Unregistered Values | Possibly Corresponding Registered | 129 | | Values | 130 +-----------------------------+-------------------------------------+ 131 | delegation check | | 132 | last correct delegation | | 133 | check | | 134 | last update | last changed | 135 +-----------------------------+-------------------------------------+ 136 Status Value 138 +--------------------------+----------------------------------------+ 139 | Unregistered Values | Possibly Corresponding Registered | 140 | | Values | 141 +--------------------------+----------------------------------------+ 142 | server deleted | server delete prohibited | 143 | prohibited | | 144 | ok | active | 145 +--------------------------+----------------------------------------+ 147 Role Value 149 +---------------------+------------------------------------------+ 150 | Unregistered Values | Possibly Corresponding Registered Values | 151 +---------------------+------------------------------------------+ 152 | owner | registrant | 153 +---------------------+------------------------------------------+ 155 2.1.1. Registry Entity 157 The (domain or IP) registry itself is currently not modeled in 158 entities in RDAP. In an whois query for a TLD itself, the Remarks 159 contains the URL of the registry entity (for registration 160 information) and the whois entry of the registry is returned. In 161 RDAP context, the RDAP server URL of the TLD registry should also be 162 returned. Therefore, IANA RDAP server should send this data for the 163 TLDs as part of its RDAP response. These semantics are currently not 164 modeled. 166 This document proposes that RDAP servers may send an entity with role 167 "registry" in the top-level of the RDAP response. This entity would 168 have embedded [links] to its web server ("rel": "self", "type": 169 "text/html") and rdap server ("rel": "self", "type": "application/ 170 rdap+json"). 172 IANA Action: add a new row "registry", "role" to the RDAP JSON Values 173 registry. 175 2.2. RDAP Extensions not Registered 177 The IANA RDAP Extensions registry [2] contains various extensions 178 values expected in RDAP JSON responses in the rdapCconformance 179 member. It is our understanding from [RFC7483] section 4.1 and 180 [RFC7480] section 8.1 that only the prefix of the extension (i.e. 181 "rdap_ObjectTag"), not the whole string ("rdap_objectTag_level_0"), 182 need to be registered in the IANA registry. However, some entries in 183 the IANA RDAP extensions registry seem to imply a 0 version as part 184 of the registered value. 186 The following table shows values seen in the field in the first 187 column, corresponding prefix (guessed as there is no normalized 188 delimiter) in the second column and if the prefix is registered in 189 IANA registry in the third column. 191 This registry may end up listing all names of all registries if each 192 one has his own extension. Moreover, there is no normalized 193 delimiter of the prefix in the full string, which may not help the 194 RDAP client to parse and interpret correctly. As with [RFC6350], we 195 may instead use the First Come First Serve(FCFS) private enterprise 196 numbers (PEN) registry to automatically have an organisation prefix 197 defined without creating another set of org names within this 198 registry and have the delimiter be "_" following the PEN. 200 Recommendation (short term): implementations should replace their 201 custom values with the registered ones, when one exist. Implementors 202 should register their values when there is no corresponding 203 registered one. 205 +----------------------------+----------------------------+---------+ 206 | Values Seen | Corresponding Assumed | Prefix | 207 | | Prefix | Already | 208 | | | Registe | 209 | | | red in | 210 | | | IANA | 211 +----------------------------+----------------------------+---------+ 212 | rdap_objectTag_level_0 | rdap_objectTag | Y | 213 | fred_version_0 | fred | Y | 214 | rdap_openidc_level_0 | rdap_openidc | N | 215 | icann_rdap_technical_imple | icann_rdap_technical_imple | N | 216 | mentation_guide_0 | mentation_guide | | 217 | icann_rdap_response_profil | icann_rdap_response_profil | N | 218 | e_0 | e | | 219 | itNic_level_0 | itNic | N | 220 | nicbr_level_0 | nicbr | N | 221 | ur_domain_check_level_0 | | N | 222 | history_version_0 | | N | 223 | registrar_api_0 | | N | 224 +----------------------------+----------------------------+---------+ 226 3. RDAP Responses 228 This section discusses issues found related to RDAP responses, 229 specified in [RFC7483]. 231 3.1. Cross-origin resource sharing(CORS) 233 As specified in [RFC7480], the HTTP "Access-Control-Allow-Origin: *" 234 header should be included in the responses, to enable Web clients to 235 work properly. Some RDAP servers do not set this header. RFC7480 236 says "it is RECOMMENDED that servers". It should be updated to "for 237 any public Internet deployment, servers MUST". 239 3.2. Object Class Name empty 241 A non-conformant server sends the following answer, where the value 242 of "objectClassName" is an empty string (as well as "handle" also 243 empty). As per [RFC7483] section 4.9, this "objectClassName" value 244 is required. Extract of the seen response: 246 { 247 entities: [ 248 { 249 "entities": [ 250 { 251 "objectClassName": "", 252 "handle": "", 253 } 254 ], 255 ], 256 } 258 3.3. Links Relation Values 260 The links relation values as specified in [RFC7483] section 4.3 refer 261 to [RFC5988] which creates the IANA Link Relations registry [3]. 262 This registry contains a large number of values where most of them do 263 not apply to the RDAP deployment. As seen with other values above 264 that are similar to registered ones but not used, we list here the 265 ones we have seen. It would be appropriate to further describes the 266 main ones in the RFC so implementors focus on ones that are expected 267 instead of picking the wrong ones in the IANA registry or to define 268 new ones and do not register them. 270 Links Relation Values Seen 272 +---------------------------+-----------------------------+ 273 | Values | Registered in IANA registry | 274 +---------------------------+-----------------------------+ 275 | about | Y | 276 | alternate | Y | 277 | copyright | Y | 278 | describedBy | Y | 279 | help | Y | 280 | related | Y | 281 | self | Y | 282 | terms-of-service | Y | 283 | up | Y | 284 | https://restOfURLRedacted | N | 285 +---------------------------+-----------------------------+ 287 As shown in the table, an implementation put an URL as the value of 288 the "rel", instead of an actual registered value. 290 3.4. Related link pointing to self causes infinite loop 292 An RDAP server returns a link of "rel": "related" is pointing to 293 itself, therefore causing the RDAP client to fetch the object again, 294 then read the related link and then fetch again, creating an infinite 295 loop. Extract of the seen response: 297 { 298 "links": [ 299 { 300 "title": "Self", 301 "rel": "self", 302 "type": "application/rdap+json", 303 "href": "https://rdapserver.example.com/domain/example.net" 304 }, 305 { 306 "title": "Registrar Data for this object", 307 "rel": "related", 308 "href": "https://rdapserver.example.com/domain/example.net", 309 "type": "application/rdap+json" 310 } 311 ], 312 } 314 Recommendation: do not put related link same as self. RFC7483 315 section 4.2 should be updated to add the following text: "A link of 316 "rel": "related" should not have the "href" value the same as the 317 value of "href" of link of "rel": "self". 319 3.5. Link without rel 321 An RDAP server returns a link with no "rel" property, so the client 322 parser has no clue what is this data and what to do with it. Extract 323 of the seen response: 325 { 326 "links": [ 327 { 328 title: "My Corporation", 329 href: "http://mycorp.mytld" 330 } 331 ], 332 } 334 Recommendation: Any link must have a "rel" value. RFC7483 says that 335 only href is mandatory. RFC7483 should be updated to have both rel 336 and href mandatory. The original text "The "href" JSON value MUST be 337 specified." should be changed to "The "href" and "rel" JSON values 338 MUST be specified." 340 3.6. Value and href for IDNs in links 342 An RDAP server should return a link with "rel": "self" with a href 343 corresponding to the target URL and value as context URI. In case of 344 idn, there are at least two possible representations of the URI: with 345 the A-label or U-label in the URI, the latter known as IRI 346 ([RFC3987]). Moreover, the query may be of a U-Label or A-Label or 347 combination of these types of labels. Therefore, there is an 348 ambiguity in which representation should be the canonical one sent. 349 This also applies to any type of "rel" for links. Extract of the 350 seen response: 352 { 353 "links": [ 354 { 355 "rel": "self", 356 "href": "http://myrdapserver.xn--abcd/domain/example.ULABEL" 357 } 358 ], 359 } 361 Recommendation: All links of any "rel" types should always be 362 returned in the A-Label form for IDNs in the href or value members, 363 independent of if the query was a U-Label or A-Label or a mix. This 364 should be added to [RFC7483]. 366 3.7. Registrant Entity Too Deep 368 An RDAP server returns the registrant entity in a subentity, which 369 makes difficult to parse given the expectation is the registrant 370 would be at the top level. Extract of the seen response: 372 { 373 entities: [ 374 { 375 "objectClassName": "entity", 376 "handle": "HANDLE1", 377 "roles": [ "abuse" ], 378 "vcardArray": [ ... ], 379 "entities": [ 380 { 381 "objectClassName": "entity", 382 "handle": "HANDLE2", 383 "roles": [ "registrant" ], 384 "vcardArray": [ ... ], 385 } 386 ], 387 ], 389 Recommendation: put the registrant in the top-level entities as 390 follows: 392 { 393 entities: [ 394 { 395 "objectClassName": "entity", 396 "handle": "HANDLE1", 397 "roles": [ "abuse" ], 398 "vcardArray": [ ... ] 399 }, 400 { 401 "objectClassName": "entity", 402 "handle": "HANDLE2", 403 "roles": [ "registrant" ], 404 "vcardArray": [ ... ], 405 } 406 ], 408 4. Queries 410 This section talks about support of RFC7482 queries and the RDAP 411 server behaviors seen. 413 4.1. URL encoding of : 415 For RIR registries, the ip query may include an IPv6 address which 416 then includes one or many ":". Clients may decide to do percent- 417 encoding of the query. In one RDAP server, the server rejected the 418 percent-encoded query of an IPv6 address. For example, 419 https://rdapserver.example.com/ip/2001%3Adb8%3A0%3A%3A/48 is 420 rejected, while https://rdapserver.example.com/ip/2001:db8:0::/48 is 421 accepted. 423 Recommendation: accept both percent-encoded queries or non-percent 424 encoded queries. 426 5. Domain Registrar RDAP Server Location 428 The ICANN RDAP Profile [4] section 3.2 requires the domain registries 429 who do not have registrant information (so-called thin registries) to 430 put a specific link of "rel": "related" pointing to the domain 431 registrar responsible for the domain being queried, so that a client 432 can get the registrant information using a second query to the 433 related link. However, the semantics seems ambiguous as other RDAP 434 servers may use the "rel": "related" for other related means, but not 435 the specific semantic of finding the registrant data. Therefore, a 436 possible mitigation is to define a new "rel" type of "registrantInfo" 437 (mnemonic TBD) to carry the specific semantic of registrant info. 439 6. Issues related to RFC7482 441 6.1. Search patterns that are not 443 Section 3.2.1 of [RFC7482] says: "domains?nsIp=ZZZZ. ZZZZ is a 444 search pattern representing an IPv4 [RFC1166] or IPv6 [RFC5952] 445 address.". Search pattern has been used throughout the document as 446 something that can include '*', while here, it does not. The syntax 447 statement is also misleading. Similarly, section 3.2.2 says: 448 "nameservers?ip=YYYY YYYY is a search pattern representing an IPv4 449 [RFC1166] or IPv6 [RFC5952] address." 451 Recommendation: in [RFC7482], replace: "ZZZZ is a search pattern 452 representing an IPv4" by "ZZZZ is an IPv4", "Syntax: 453 domains?nsIp=" by "Syntax: 454 domains?nsIp=", "YYYY is a search pattern 455 representing an IPv4" by "YYYY is an IPv4", "Syntax: 456 nameservers?ip=" by "Syntax: 457 nameservers?ip=" 459 7. IANA RDAP Bootstrap Registries Related Issues 461 This section describes issues related to the IANA Bootstrap 462 registries as specified in [RFC7484]. 464 7.1. Missing Trailing Char in Bootstrap Registries 466 [RFC7484] section 3 says: "Base RDAP URLs MUST have a trailing "/" 467 character". However, some values in the various IANA Bootstrap 468 registries do not have the trailing "/" character. These should be 469 added to provide consistency. 471 7.2. Single target value 473 [RFC7484] provides a way to list multiple RDAP servers for an entry. 474 This flexibility was designed initially to support multiple URI 475 types, such as http: and https, and to provide some level of 476 redundancy. However, given that security deployment policy is to use 477 https everywhere and redundancy can be accomplished in other ways, 478 deployment has shown that all entries in all bootstrap registries 479 have a single target RDAP URL value. Therefore, we can consider 480 updating the RFC to provide only one target value. However, this 481 should be done carefully to avoid breaking current deployed clients. 483 8. Security Considerations 485 Proper conformance to specifications helps security. However, no 486 security issues have been found in the context of this draft. 488 9. IANA Considerations 490 This document request IANA to add the following values to this 491 registry. TBD. See 'IANA Action:' within the document. 493 10. Acknowledgements 495 Audric Schiltknecht, Mario Loffredo, Justin Mack, James Gould have 496 provided input and suggestions to this document. 498 11. References 500 11.1. Normative References 502 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 503 Registration Data Access Protocol (RDAP)", RFC 7480, 504 DOI 10.17487/RFC7480, March 2015, 505 . 507 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 508 Protocol (RDAP) Query Format", RFC 7482, 509 DOI 10.17487/RFC7482, March 2015, 510 . 512 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 513 Registration Data Access Protocol (RDAP)", RFC 7483, 514 DOI 10.17487/RFC7483, March 2015, 515 . 517 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 518 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 519 2015, . 521 11.2. Informative References 523 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 524 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 525 January 2005, . 527 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 528 DOI 10.17487/RFC5988, October 2010, 529 . 531 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 532 DOI 10.17487/RFC6350, August 2011, 533 . 535 11.3. URIs 537 [1] https://www.iana.org/assignments/rdap-json-values/rdap-json- 538 values.xhtml 540 [2] https://www.iana.org/assignments/rdap-extensions/rdap- 541 extensions.xhtml 543 [3] https://www.iana.org/assignments/link-relations/link- 544 relations.xhtml 546 [4] https://www.icann.org/en/system/files/files/rdap-technical- 547 implementation-guide-15feb19-en.pdf 549 Author's Address 550 Marc Blanchet 551 Viagenie 552 246 Aberdeen 553 Quebec, QC G1R 2E1 554 Canada 556 Email: marc.blanchet@viagenie.ca 557 URI: http://viagenie.ca