This experimental RDAP service is based on .it Registry public test environment registration data. The response data generated by this server are provided by .it Registry for experimental testing purposes only, and are not, and should not be considered to be, official WHOIS or RDAP query responses or data. This service allows the user to perform all the queries described in RFC 7482. Furthermore, it provides the user with additional capabilities about domain availability, sorting and paging, partial response, reverse search, advanced query and filtering and specification provisioning in OpenAPI 3.0, RAML and APIBlueprint formats.
This extension is described in draft-newton-regext-rdap-domain-availability-00.
If domain is available the response is the same as availabilityCheck=1, otherwise the response is the same as a basic lookup query.
This extension might be inactive.
It is possible to use wildcard character to ask for partial string matching. Search queries are available only to authenticated users.
This extension is described in draft-fregly-regext-rdap-search-regex-03.
To apply Base64 encoding, the user can rely on the online tool at https://www.base64encode.org/
This extension might be inactive.
This extension is described in Technical Report IIT-06-2018.
This server implements the segment path domains/suggestion to enable domain suggestion. The new search is allowed only for the domains?name search path. The search pattern must be a domain name in LDH or U-label formats. Partial matching is not allowed. Some additional parameters could be used:
Here in the following some examples:
This extension might be inactive.
This extension is described in draft-ietf-regext-rdap-sorting-and-paging-06.
The count parameter reports the total number of results in the totalCount field of the paging_metadata section.
The sort parameter allows a client to request a specific sort order for the result set. Sort parameter properties:
Current sort and other available sorts are reported in the response section sorting_metadata.
Here in the following some examples:
This RDAP server implements cursor-based pagination. The server uses the links array of the paging_metadata section to provide the user with a ready-made reference to the next page of the result set.
This extension is described in draft-ietf-regext-rdap-partial-response-04.
The fieldSet parameter allows the user to ask for a server pre-defined set of fields in the response.
Three sets have been defined:
Current field set and other available field sets are reported in the response section subsetting_metadata.
Here in the following an example:
This extension is described in draft-ietf-regext-rdap-reverse-search-03.
This RDAP server implements the segment path domains/reverse/{role} enabling reverse search based on the domains-entities relationship. {role} is a string whose possible values are those detailed in Section 10.2.4 of RFC 7483. In this implementation the allowed values are: registrar, registrant, administrative, technical.
A reverse search query may contain the follwoing alternative parameters:
Here in the following some examples:
This extension might be inactive.
This extension allows the user to submit complex search conditions.
Two new parameters, namely "query" and "filter", have been implemented:
In both cases, the value is a JSON object representing predicates whose complexity ranges from very simple to extremely complicated. In fact, traditionally, a search condition includes a set of predicates joined by the logical operators and, or and not. A predicate contains three components:
Therefore, the structure of a predicate is described by the following JCR (JSON Content Rules) syntax:
@{root} $expression = {
(
$or_expression |
$and_expression |
$not_expression |
[ $predicate + ] |
$predicate
)
}
$or_expression = {
"or" : [ $expression, $expression + ]
}
$and_expression = {
"and" : [ $expression, $expression + ]
}
$not_expression = {
"not" : $expression
}
$predicate = [
/^[A-Za-z]+$/,
(
("isnull"|"isnotnull") |
("eq"|"ne"), $basic_value |
("le"|"lt"|"gt"|"ge"), $not_pattern_value |
"between", [ $not_pattern_value, $not_pattern_value ] |
("in"|"notin"|"any"|"all"|"exactly"), $array_value
)
]
$basic_value = @{not} (
{ // : any * } |
[ any * ] |
null
)
$not_pattern_value = @{not} (
{ // : any * } |
[ any * ] |
null |
$pattern_value
)
$pattern_value = /^[^\*]*\*[^\*]*$/
$array_value = [ $not_pattern_value + ]
Property names that can be used in the case of query parameter:
Property names that can be used in the case of filter parameter:
Together with the logical operators, it is reasonable to expect the presence of commonly used comparison operators like equal, not equal, less than and so on. Specific operators about strings like contains, starts with, ends with can be implemented using the equal operator and the wildcard. Appropriate operators on arrays should be considered too. In the following, a list of the operators is shown:
The any, all and exactly operators are used with the following meaning:
If an array contains only one value, any and all have the same meaning.
isnull and isnotnull are used when the predicate represents, respectively, the absence or the presence of a property in the expected results:
All predicates in an array are implicitly combined by and:
The operator between is a shortcut for two predicates combined by and including the same property:
The operator in is a shortcut for N predicates combined by or including the same property and the eq operator:
Value types can be:
According to the search format and complexity, the solution of providing a link by GET seems to be pretty inefficient. In fact, GET isn't suitable for supporting either very long or URL-unsafe query strings. It would be much more appropriate to send the search pattern and the optional query parameters by POST. As a consequence, this experimental RDAP service provides three new endpoints which can be accessed by POST:
The request body is a JSON string map including all the query parameters. At least one between filter or query parameter MUST be present.
This extension might be inactive.
Here in the following some examples of complex queries and filters that can be subbmitted to https://rdap.pubtest.nic.it/domains/query:
{
"name" : "we*.it",
"filter" : "[\"registrationDate\",\"ge\",\"2018-01-20\"]"
}
{
"name" : "we*.it",
"filter" : "{\"or\":[[\"registrationDate\",\"ge\",\"2018-01-20\"],[\"expirationDate\",\"le\",\"2019-01-20\"]]}"
}
{
"name" : "we*.it",
"filter" : "{\"not\":{\"or\":[[\"registrationDate\",\"ge\",\"2018-01-20\"],[\"expirationDate\",\"le\",\"2019-01-20\"]]}}"
}
{
"name" : "wu*it",
"filter" : "[\"transferDate\",\"isnull\"]"
}
{
"query" : "[[\"name\",\"eq\",\"test-*.it\"],[\"nsLdhName\",\"eq\",\"wns1.rtr-dev.com\"]]"
}
{
"query" : "[[\"name\",\"eq\",\"test-*.it\"],[\"reverse/registrant/cc\",\"eq\",\"be\"]]",
"filter" : "{\"or\":[[\"registrationDate\",\"ge\",\"2018-01-20\"],[\"expirationDate\",\"le\",\"2019-01-20\"]]}"
}
Current filter and other available filters are reported in the response section filtering_metadata.
Here in the following some examples of GET requests:
Here in the following some examples of POST requests to https://rdap.pubtest.nic.it/domains/query:
Search domains whose name starts with we or wu
{
"query" : "{\"or\":[[\"name\",\"eq\",\"we*.it\"],[\"name\",\"eq\",\"wu*.it\"]]}"
}
How many are there ?
{
"query" : "{\"or\":[[\"name\",\"eq\",\"we*.it\"],[\"name\",\"eq\",\"wu*.it\"]]}",
"count": "1"
}
Which is the oldest ?
{
"query" : "{\"or\":[[\"name\",\"eq\",\"we*.it\"],[\"name\",\"eq\",\"wu*.it\"]]}",
"count": "1",
"sort"="registrationDate"
}
What are the domains registered since 2015 ?
{
"query" : "{\"or\":[[\"name\",\"eq\",\"we*.it\"],[\"name\",\"eq\",\"wu*.it\"]]}",
"count": "1",
"sort": "registrationDate",
"filter": "[\"registrationDate\",\"gt\",\"2015-01-01\"]"
}
What are the inactive domains registered since 2015 ?
{
"query" : "{\"or\":[[\"name\",\"eq\",\"we*.it\"],[\"name\",\"eq\",\"wu*.it\"]]}",
"count": "1",
"sort": "registrationDate",
"filter": "[[\"registrationDate\",\"gt\",\"2015-01-01\"],[\"status\",\"any\",[\"inactive\"]]]"
}
Return only a summary fo the full information
{
"query" : "{\"or\":[[\"name\",\"eq\",\"we*.it\"],[\"name\",\"eq\",\"wu*.it\"]]}",
"count": "1",
"sort": "registrationDate",
"filter": "[[\"registrationDate\",\"gt\",\"2015-01-01\"],[\"status\",\"any\",[\"inactive\"]]]",
"fieldSet": "brief"
}
Search queries are available only to .it Registrars via HTTP Basic Authentication by the same credentials used for the authentication to the EPP server. .it Registrars are allowed to search only for their own domains and entities.
This RDAP server includes in the response four metadata sections:
The sorting_metadata section contains the following fields:
The paging_metadata section contains the following fields:
The subsetting_metadata section contains the following fields:
The filtering_metadata section contains the following fields:
The HEAD method can be used only for lookup queries (including help).
This RDAP server implements the bootstrapping capability as described in RFC7484. Here in the following some examples:
Each single bootstrapping capability (i.e. ip, autnum, dns and objectTag) might be inactive.
RDAP servers can provide different capabilities:
How could RDAP clients face with such a diversity?
Servers could provide their own policies via a REST API specification format (OpenAPI, RAML, API Blueprint, JSON API, JSON Schema). This server provides specifications according to OpenAPI 3.0, RAML and ApiBluePrint formats. Bootstrapping based on objectTag as described in RFC8521 can help find the desired specification. This implementation simulate the response coming from some RDAP servers. The query is available to any user.
Here in the following some examples:
This RDAP server implements the extension to vCard parameters as described in RFC8605.
This RDAP server implements a JSON contact representation alternative to vCard as described in draft-stepanek-jscontact-05. Such a representation can be requested by adding to the query string the jscard parameter set to 1/true. The jscard parameter is valid only on the endpoints: entity, domain, entities, domains. Here in the following some examples:
The transition from jCard to JSCard is described in jCard deprecation
This RDAP server provides extensions both to response fields and JSON values:
New fields have been defined to map custom information of .it entities:
itNic_consentForPublishing: this field can appear in an entity object representing a registrant, an administrative or a techincal contact. It is a boolean value showing the consent to the publication of contact's personal data;
itNic_registrant: this field appears only in an entity object representing a registrant. It is an object including the following members:
itNic_DNSSEC: it is a boolean value representing the information that a registrar is "DNSSEC accredited".
New values have been defined for the status field of a domain object in order to map custom statuses:
dns hold: domain name for which the check of the DNS configuration, performed by the Registry after registration, has ended unsuccessfully. It appears in combination with inactive status;
no registrar: domain name whose sponsoring registrar has no more an active contract with the Registry. It can appear in combination with both active (when the domain name is still not expired) and inactive (when the domain name is already expired) statuses;
not renewed: domain name that has reached the expiring date and has not been renewed automatically due to insufficient credit on the part of the Registrar. It appears in combination with inactive status;
to be reassigned: domain name for which a reassignment or challenge procedure has been concluded successfully. It appears in combination with inactive status;
revoked: domain name revoked by the Registry and not immediately available for free assignment. It appears in combination with inactive status;
challenged: domain name contested by a third party. It can appear in combination with every status;
bulk: domain name for which a bulk transfer operation is underway. It appears in combination with pending transfer status.
For any question or remark, please contact hostmaster@nic.it