Internet DRAFT - draft-blanchet-regext-rdap-deployfindings
draft-blanchet-regext-rdap-deployfindings
Network Working Group M. Blanchet
Internet-Draft Viagenie
Intended status: Informational June 13, 2019
Expires: December 15, 2019
RDAP Deployment Findings and Update
draft-blanchet-regext-rdap-deployfindings-05
Abstract
Registration Access Data Protocol(RDAP) is being deployed in domain
and IP address registries. This document describes issues and
findings while interfacing with the known server implementations and
deployments. It also provides recommendations for the
specifications.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 15, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Blanchet Expires December 15, 2019 [Page 1]
Internet-Draft RDAP Deployment Findings and Update June 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IANA RDAP Registries Related Issues . . . . . . . . . . . . . 2
2.1. Values not Registered or Similar . . . . . . . . . . . . 3
2.1.1. Registry Entity . . . . . . . . . . . . . . . . . . . 4
2.2. RDAP Extensions not Registered . . . . . . . . . . . . . 4
3. RDAP Responses . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Cross-origin resource sharing(CORS) . . . . . . . . . . . 6
3.2. Object Class Name empty . . . . . . . . . . . . . . . . . 6
3.3. Links Relation Values . . . . . . . . . . . . . . . . . . 6
3.4. Related link pointing to self causes infinite loop . . . 7
3.5. Link without rel . . . . . . . . . . . . . . . . . . . . 8
3.6. Value and href for IDNs in links . . . . . . . . . . . . 8
3.7. Registrant Entity Too Deep . . . . . . . . . . . . . . . 9
4. Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. URL encoding of : . . . . . . . . . . . . . . . . . . . . 10
5. Domain Registrar RDAP Server Location . . . . . . . . . . . . 10
6. Issues related to RFC7482 . . . . . . . . . . . . . . . . . . 10
6.1. Search patterns that are not . . . . . . . . . . . . . . 10
7. IANA RDAP Bootstrap Registries Related Issues . . . . . . . . 11
7.1. Missing Trailing Char in Bootstrap Registries . . . . . . 11
7.2. Single target value . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 12
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
While developing various tools and software related to RDAP, issues
have been found and are documented below. This document should help
in writing future version of the specifications and provide better
conformant deployment. It is split in various sections based on
where the fix should be applied. Obviously, there are different
levels of severity of the issues, including nits or very minor. The
actual instances and organisations running the RDAP servers where the
issues were found are not listed.
2. IANA RDAP Registries Related Issues
This section describes issues related to the IANA non-Bootstrap
registries as specified in [RFC7483].
Blanchet Expires December 15, 2019 [Page 2]
Internet-Draft RDAP Deployment Findings and Update June 2019
2.1. Values not Registered or Similar
The IANA RDAP JSON Values registry [1] contains various values
expected in JSON responses. The following table shows values not
registered in the registry but seen in the field. The second column
shows the possible corresponding values already registered.
Recommendation: implementations should replace their custom values
with the registered ones, when one exist. Implementors should
register their values when there is no corresponding registered one.
Remarks Type
+---------------------------------+---------------------------------+
| Unregistered Values | Possibly Corresponding |
| | Registered Values |
+---------------------------------+---------------------------------+
| object truncated due to server | object truncated due to |
| policy | authorization |
| Response truncated due to | object truncated due to |
| authorization | authorization |
| Object truncated due to | object truncated due to |
| authorization | authorization |
| object redacted due to | object truncated due to |
| authorization | authorization |
+---------------------------------+---------------------------------+
Event Action
+-----------------------------+-------------------------------------+
| Unregistered Values | Possibly Corresponding Registered |
| | Values |
+-----------------------------+-------------------------------------+
| delegation check | |
| last correct delegation | |
| check | |
| last update | last changed |
+-----------------------------+-------------------------------------+
Blanchet Expires December 15, 2019 [Page 3]
Internet-Draft RDAP Deployment Findings and Update June 2019
Status Value
+--------------------------+----------------------------------------+
| Unregistered Values | Possibly Corresponding Registered |
| | Values |
+--------------------------+----------------------------------------+
| server deleted | server delete prohibited |
| prohibited | |
| ok | active |
+--------------------------+----------------------------------------+
Role Value
+---------------------+------------------------------------------+
| Unregistered Values | Possibly Corresponding Registered Values |
+---------------------+------------------------------------------+
| owner | registrant |
+---------------------+------------------------------------------+
2.1.1. Registry Entity
The (domain or IP) registry itself is currently not modeled in
entities in RDAP. In an whois query for a TLD itself, the Remarks
contains the URL of the registry entity (for registration
information) and the whois entry of the registry is returned. In
RDAP context, the RDAP server URL of the TLD registry should also be
returned. Therefore, IANA RDAP server should send this data for the
TLDs as part of its RDAP response. These semantics are currently not
modeled.
This document proposes that RDAP servers may send an entity with role
"registry" in the top-level of the RDAP response. This entity would
have embedded [links] to its web server ("rel": "self", "type":
"text/html") and rdap server ("rel": "self", "type": "application/
rdap+json").
IANA Action: add a new row "registry", "role" to the RDAP JSON Values
registry.
2.2. RDAP Extensions not Registered
The IANA RDAP Extensions registry [2] contains various extensions
values expected in RDAP JSON responses in the rdapCconformance
member. It is our understanding from [RFC7483] section 4.1 and
[RFC7480] section 8.1 that only the prefix of the extension (i.e.
"rdap_ObjectTag"), not the whole string ("rdap_objectTag_level_0"),
need to be registered in the IANA registry. However, some entries in
Blanchet Expires December 15, 2019 [Page 4]
Internet-Draft RDAP Deployment Findings and Update June 2019
the IANA RDAP extensions registry seem to imply a 0 version as part
of the registered value.
The following table shows values seen in the field in the first
column, corresponding prefix (guessed as there is no normalized
delimiter) in the second column and if the prefix is registered in
IANA registry in the third column.
This registry may end up listing all names of all registries if each
one has his own extension. Moreover, there is no normalized
delimiter of the prefix in the full string, which may not help the
RDAP client to parse and interpret correctly. As with [RFC6350], we
may instead use the First Come First Serve(FCFS) private enterprise
numbers (PEN) registry to automatically have an organisation prefix
defined without creating another set of org names within this
registry and have the delimiter be "_" following the PEN.
Recommendation (short term): implementations should replace their
custom values with the registered ones, when one exist. Implementors
should register their values when there is no corresponding
registered one.
+----------------------------+----------------------------+---------+
| Values Seen | Corresponding Assumed | Prefix |
| | Prefix | Already |
| | | Registe |
| | | red in |
| | | IANA |
+----------------------------+----------------------------+---------+
| rdap_objectTag_level_0 | rdap_objectTag | Y |
| fred_version_0 | fred | Y |
| rdap_openidc_level_0 | rdap_openidc | N |
| icann_rdap_technical_imple | icann_rdap_technical_imple | N |
| mentation_guide_0 | mentation_guide | |
| icann_rdap_response_profil | icann_rdap_response_profil | N |
| e_0 | e | |
| itNic_level_0 | itNic | N |
| nicbr_level_0 | nicbr | N |
| ur_domain_check_level_0 | | N |
| history_version_0 | | N |
| registrar_api_0 | | N |
+----------------------------+----------------------------+---------+
3. RDAP Responses
This section discusses issues found related to RDAP responses,
specified in [RFC7483].
Blanchet Expires December 15, 2019 [Page 5]
Internet-Draft RDAP Deployment Findings and Update June 2019
3.1. Cross-origin resource sharing(CORS)
As specified in [RFC7480], the HTTP "Access-Control-Allow-Origin: *"
header should be included in the responses, to enable Web clients to
work properly. Some RDAP servers do not set this header. RFC7480
says "it is RECOMMENDED that servers". It should be updated to "for
any public Internet deployment, servers MUST".
3.2. Object Class Name empty
A non-conformant server sends the following answer, where the value
of "objectClassName" is an empty string (as well as "handle" also
empty). As per [RFC7483] section 4.9, this "objectClassName" value
is required. Extract of the seen response:
{
entities: [
{
"entities": [
{
"objectClassName": "",
"handle": "",
}
],
],
}
3.3. Links Relation Values
The links relation values as specified in [RFC7483] section 4.3 refer
to [RFC5988] which creates the IANA Link Relations registry [3].
This registry contains a large number of values where most of them do
not apply to the RDAP deployment. As seen with other values above
that are similar to registered ones but not used, we list here the
ones we have seen. It would be appropriate to further describes the
main ones in the RFC so implementors focus on ones that are expected
instead of picking the wrong ones in the IANA registry or to define
new ones and do not register them.
Blanchet Expires December 15, 2019 [Page 6]
Internet-Draft RDAP Deployment Findings and Update June 2019
Links Relation Values Seen
+---------------------------+-----------------------------+
| Values | Registered in IANA registry |
+---------------------------+-----------------------------+
| about | Y |
| alternate | Y |
| copyright | Y |
| describedBy | Y |
| help | Y |
| related | Y |
| self | Y |
| terms-of-service | Y |
| up | Y |
| https://restOfURLRedacted | N |
+---------------------------+-----------------------------+
As shown in the table, an implementation put an URL as the value of
the "rel", instead of an actual registered value.
3.4. Related link pointing to self causes infinite loop
An RDAP server returns a link of "rel": "related" is pointing to
itself, therefore causing the RDAP client to fetch the object again,
then read the related link and then fetch again, creating an infinite
loop. Extract of the seen response:
{
"links": [
{
"title": "Self",
"rel": "self",
"type": "application/rdap+json",
"href": "https://rdapserver.example.com/domain/example.net"
},
{
"title": "Registrar Data for this object",
"rel": "related",
"href": "https://rdapserver.example.com/domain/example.net",
"type": "application/rdap+json"
}
],
}
Recommendation: do not put related link same as self. RFC7483
section 4.2 should be updated to add the following text: "A link of
"rel": "related" should not have the "href" value the same as the
value of "href" of link of "rel": "self".
Blanchet Expires December 15, 2019 [Page 7]
Internet-Draft RDAP Deployment Findings and Update June 2019
3.5. Link without rel
An RDAP server returns a link with no "rel" property, so the client
parser has no clue what is this data and what to do with it. Extract
of the seen response:
{
"links": [
{
title: "My Corporation",
href: "http://mycorp.mytld"
}
],
}
Recommendation: Any link must have a "rel" value. RFC7483 says that
only href is mandatory. RFC7483 should be updated to have both rel
and href mandatory. The original text "The "href" JSON value MUST be
specified." should be changed to "The "href" and "rel" JSON values
MUST be specified."
3.6. Value and href for IDNs in links
An RDAP server should return a link with "rel": "self" with a href
corresponding to the target URL and value as context URI. In case of
idn, there are at least two possible representations of the URI: with
the A-label or U-label in the URI, the latter known as IRI
([RFC3987]). Moreover, the query may be of a U-Label or A-Label or
combination of these types of labels. Therefore, there is an
ambiguity in which representation should be the canonical one sent.
This also applies to any type of "rel" for links. Extract of the
seen response:
{
"links": [
{
"rel": "self",
"href": "http://myrdapserver.xn--abcd/domain/example.ULABEL"
}
],
}
Recommendation: All links of any "rel" types should always be
returned in the A-Label form for IDNs in the href or value members,
independent of if the query was a U-Label or A-Label or a mix. This
should be added to [RFC7483].
Blanchet Expires December 15, 2019 [Page 8]
Internet-Draft RDAP Deployment Findings and Update June 2019
3.7. Registrant Entity Too Deep
An RDAP server returns the registrant entity in a subentity, which
makes difficult to parse given the expectation is the registrant
would be at the top level. Extract of the seen response:
{
entities: [
{
"objectClassName": "entity",
"handle": "HANDLE1",
"roles": [ "abuse" ],
"vcardArray": [ ... ],
"entities": [
{
"objectClassName": "entity",
"handle": "HANDLE2",
"roles": [ "registrant" ],
"vcardArray": [ ... ],
}
],
],
Recommendation: put the registrant in the top-level entities as
follows:
{
entities: [
{
"objectClassName": "entity",
"handle": "HANDLE1",
"roles": [ "abuse" ],
"vcardArray": [ ... ]
},
{
"objectClassName": "entity",
"handle": "HANDLE2",
"roles": [ "registrant" ],
"vcardArray": [ ... ],
}
],
4. Queries
This section talks about support of RFC7482 queries and the RDAP
server behaviors seen.
Blanchet Expires December 15, 2019 [Page 9]
Internet-Draft RDAP Deployment Findings and Update June 2019
4.1. URL encoding of :
For RIR registries, the ip query may include an IPv6 address which
then includes one or many ":". Clients may decide to do percent-
encoding of the query. In one RDAP server, the server rejected the
percent-encoded query of an IPv6 address. For example,
https://rdapserver.example.com/ip/2001%3Adb8%3A0%3A%3A/48 is
rejected, while https://rdapserver.example.com/ip/2001:db8:0::/48 is
accepted.
Recommendation: accept both percent-encoded queries or non-percent
encoded queries.
5. Domain Registrar RDAP Server Location
The ICANN RDAP Profile [4] section 3.2 requires the domain registries
who do not have registrant information (so-called thin registries) to
put a specific link of "rel": "related" pointing to the domain
registrar responsible for the domain being queried, so that a client
can get the registrant information using a second query to the
related link. However, the semantics seems ambiguous as other RDAP
servers may use the "rel": "related" for other related means, but not
the specific semantic of finding the registrant data. Therefore, a
possible mitigation is to define a new "rel" type of "registrantInfo"
(mnemonic TBD) to carry the specific semantic of registrant info.
6. Issues related to RFC7482
6.1. Search patterns that are not
Section 3.2.1 of [RFC7482] says: "domains?nsIp=ZZZZ. ZZZZ is a
search pattern representing an IPv4 [RFC1166] or IPv6 [RFC5952]
address.". Search pattern has been used throughout the document as
something that can include '*', while here, it does not. The syntax
statement is also misleading. Similarly, section 3.2.2 says:
"nameservers?ip=YYYY YYYY is a search pattern representing an IPv4
[RFC1166] or IPv6 [RFC5952] address."
Recommendation: in [RFC7482], replace: "ZZZZ is a search pattern
representing an IPv4" by "ZZZZ is an IPv4", "Syntax:
domains?nsIp=<domain search pattern>" by "Syntax:
domains?nsIp=<nameserver IP address>", "YYYY is a search pattern
representing an IPv4" by "YYYY is an IPv4", "Syntax:
nameservers?ip=<nameserver search pattern>" by "Syntax:
nameservers?ip=<nameserver IP address>"
Blanchet Expires December 15, 2019 [Page 10]
Internet-Draft RDAP Deployment Findings and Update June 2019
7. IANA RDAP Bootstrap Registries Related Issues
This section describes issues related to the IANA Bootstrap
registries as specified in [RFC7484].
7.1. Missing Trailing Char in Bootstrap Registries
[RFC7484] section 3 says: "Base RDAP URLs MUST have a trailing "/"
character". However, some values in the various IANA Bootstrap
registries do not have the trailing "/" character. These should be
added to provide consistency.
7.2. Single target value
[RFC7484] provides a way to list multiple RDAP servers for an entry.
This flexibility was designed initially to support multiple URI
types, such as http: and https, and to provide some level of
redundancy. However, given that security deployment policy is to use
https everywhere and redundancy can be accomplished in other ways,
deployment has shown that all entries in all bootstrap registries
have a single target RDAP URL value. Therefore, we can consider
updating the RFC to provide only one target value. However, this
should be done carefully to avoid breaking current deployed clients.
8. Security Considerations
Proper conformance to specifications helps security. However, no
security issues have been found in the context of this draft.
9. IANA Considerations
This document request IANA to add the following values to this
registry. TBD. See 'IANA Action:' within the document.
10. Acknowledgements
Audric Schiltknecht, Mario Loffredo, Justin Mack, James Gould have
provided input and suggestions to this document.
11. References
11.1. Normative References
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", RFC 7480,
DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>.
Blanchet Expires December 15, 2019 [Page 11]
Internet-Draft RDAP Deployment Findings and Update June 2019
[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access
Protocol (RDAP) Query Format", RFC 7482,
DOI 10.17487/RFC7482, March 2015,
<https://www.rfc-editor.org/info/rfc7482>.
[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the
Registration Data Access Protocol (RDAP)", RFC 7483,
DOI 10.17487/RFC7483, March 2015,
<https://www.rfc-editor.org/info/rfc7483>.
[RFC7484] Blanchet, M., "Finding the Authoritative Registration Data
(RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March
2015, <https://www.rfc-editor.org/info/rfc7484>.
11.2. Informative References
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
January 2005, <https://www.rfc-editor.org/info/rfc3987>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010,
<https://www.rfc-editor.org/info/rfc5988>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>.
11.3. URIs
[1] https://www.iana.org/assignments/rdap-json-values/rdap-json-
values.xhtml
[2] https://www.iana.org/assignments/rdap-extensions/rdap-
extensions.xhtml
[3] https://www.iana.org/assignments/link-relations/link-
relations.xhtml
[4] https://www.icann.org/en/system/files/files/rdap-technical-
implementation-guide-15feb19-en.pdf
Author's Address
Blanchet Expires December 15, 2019 [Page 12]
Internet-Draft RDAP Deployment Findings and Update June 2019
Marc Blanchet
Viagenie
246 Aberdeen
Quebec, QC G1R 2E1
Canada
Email: marc.blanchet@viagenie.ca
URI: http://viagenie.ca
Blanchet Expires December 15, 2019 [Page 13]
