.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 OpenAPI 3.0 specification.

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.

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.

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/

5. Search queries enabling domain suggestion

This extension is described in Technical Report IIT-06-2018.

This server implements the new value suggestion for the query parameter searchtype 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:

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

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

Count parameter

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

Sort parameter

The sort parameter allows a client to request a specific sort order for the result set.

Current sort and other available sorts are reported in the response section sorting_metadata.

Here in the following some examples:

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.

7. Search queries asking for partial response

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:

8. Search queries enabling reverse search

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

This RDAP server implements four query parameters enabling reverse search based on the domains-entities relationship (the classic Reverse Whois scenario):

In this case, the search pattern is a JSON object including two members:

In the case of the entityAddr parameter, the search pattern is a JSON object containing the information described in Section 2.4 of RFC 5733 respectively: street, city, sp, pc and cc. All the members of the postal address object are optional but at least one is required. The constraints on the members are implicitly joined by and.

Here in the following some examples:

9. Search queries including query and/or filter parameters

This extension is described in Technical Report IIT-07-2018.

The query and filter parameters allow the user to submit complex search conditions. In detail:

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_or_object_value                   |
  ("le"|"lt"|"gt"|"ge"), $not_pattern_value             |
  "between", [ $not_pattern_value, $not_pattern_value ] |
  ("in"|"notin"|"any"|"all"|"exactly"), $array_value 
)	
]
$basic_or_object_value = ( 
                          $basic_value  | 
                          $object_value  
                          )

$object_value = { // : any * } 

$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:

Examples

Here in the following some examples:

Current filter and other available filters are reported in the response section filtering_metadata.

10. Search queries mixing the query parameters

Here in the following some examples:

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

Here in the following some examples:

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 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:

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-stepanek-jscontact-04. 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:

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