.it RDAP public test server

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.

Table of contents

  1. Basic lookup queries
  2. Lookup queries including domain availability extensions
  3. Basic search queries
  4. Search queries including searchtype=regex extension
  5. Search queries enabling domain suggestion
  6. Search queries including operators for counting, sorting and paging results
  7. Search queries asking for partial response
  8. Search queries enabling reverse search
  9. Search queries including query and/or filter parameters
  10. Search queries mixing the query parameters
  11. Authentication
  12. Metadata
  13. HTTP HEAD method
  14. Bootstrapping
  15. Specification
  16. vCard Format Extensions
  17. jscard Extension
  18. .it Response Extensions
  19. Contact Information

1. Basic lookup queries

Available to any user

Available only to authenticated users

2. Lookup queries including domain availability extensions

This extension is described in draft-newton-regext-rdap-domain-availability-00.

With availabilityCheck extension

With availabilityInformation extension

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. If active, it is available only for authenticated users.

3. Basic search queries

It is possible to use wildcard character to ask for partial string matching. Search queries are available only to authenticated users.

This extension is available only for authenticated users.

4. Search queries including searchtype=regex extension

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. If active, it is available only for authenticated users.

5. Search queries enabling domain suggestion

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. If active, it is available only for authenticated users.

6. Search queries including operators for counting, sorting and paging results

This extension is described in draft-ietf-regext-rdap-sorting-and-paging.

Count parameter

The count parameter reports the total number of results in the totalCount field of the paging_metadata section.

This extension is available only for authenticated users.

Sort parameter

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 extension is available only for authenticated users.

Cursor parameter

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 available only for authenticated users.

7. Search queries asking for partial response

This extension is described in draft-ietf-regext-rdap-partial-response.

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 the other available field sets are included in the response section subsetting_metadata.

The id field set contains the following fields:

The brief field set contains the following fields:

Here in the following an example of query including the fieldSet parameter:

This extension is available only for authenticated users.

8. Search queries enabling reverse search

This extension is described in draft-ietf-regext-rdap-reverse-search.

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. If active, it is available only for authenticated users.

9. Search queries including query and/or filter parameters

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

Operators

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

Value types can be:

Submitting complex queries and filters by POST

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. If active, it is available only for authenticated users.

Examples

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.

10. Search queries mixing the query parameters

By GET

Here in the following some examples of GET requests:

By POST

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"
    }

11. Authentication

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.

12. Metadata

This RDAP server includes in the response four metadata sections:

13. HTTP HEAD method

The HEAD method can be used only for lookup queries (including help).

14. Bootstrapping

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.

15. Specification

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 extension is available only for authenticated users.

16. vCard Format Extensions

This RDAP server implements the extension to vCard parameters as described in RFC8605.

17. jscard Extension

This RDAP server implements a JSON contact representation alternative to vCard as described in draft-ietf-jmap-jscontact. 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 draft-ietf-regext-rdap-jscontact.

18. .it Response Extensions

This RDAP server provides extensions both to response fields and JSON values:

New Fields

New fields have been defined to map custom information of .it entities:

New Values

New values have been defined for the status field of a domain object in order to map custom statuses:

19. Contact Information

For any question or remark, please contact hostmaster@nic.it