-
Notifications
You must be signed in to change notification settings - Fork 29
General Usage
For most query values, the query type is inferred. However, some types of queries
cannot be inferred and so the -t parameter must be used. The domain search by name
(dsbyname) and entity search by name (esbyname) queries can take wildcards ('*'),
but these must be quoted or escaped to avoid processing by the invoking OS shell
on Unix-like operating systems.
When this program is run for the first time, it creates a directory called .NicInfo
(on Unix style platforms) or NicInfo (on Windows) in the users home directory. The
home directory is determined by the $HOME environment variable on Unix style platforms
and $APPDATA on Windows.
A configuration file is created in this directory called config.yaml. This is a YAML
file and contains a means for specifying most of the features of this program (instead
of needing to specify them on the command line as options). To set the configuration
back to the installation defaults, use the --reset option. This maybe desirable when
updating versions of this program.
A directory called rdap_cache is also created inside this directory. It holds cached
values from previously executed queries.
This program will write query responses to a cache. By default, answers are pulled
from the cache if present. This can be turned on or off with the --cache parameter or
using the cache/use_cache value in the configuration file.
Expiration of items in the cache and eviction of items from the cache can also be
controlled. The cache can be manually emptied using the --empty-cache parameter.
Bootstrapping is the process of finding an appropriate RDAP server in which to send queries. This program has a three tier bootstrapping process.
The first tier looks up the most appropriate server using internal tables compiled from IANA registries. If an appropriate server cannot be found, bootstrapping falls to the second tier.
The second tier has a default server for each type of RDAP query (domain, ip, autnum,
nameserver, and entity). If this program cannot determine the type of query, bootstrapping
falls to the third tier.
The third tier is a default server for all queries.
All bootstrap URLs are specified in the configuration file. Bootstrapping maybe
bypassed using the -b or --base option (or by setting the bootstrap/base_url in the
configuration file).
For usage with shell scripting, there are a couple of useful command line switches.
The --json option suppresses the human-readable output and instead emits the JSON
returned by the server. When not writing to an output file, this options should be
used with the -Q option to suppress the pager and program runtime messages so that
the JSON maybe run through a JSON parser.
The --jv option instructs this program to parse the JSON and emit specific JSON
values. This option is also useful in combination with the -Q option to feed the
JSON values into other programs. The syntax for specifying a JSON value is a
list of JSON object member names or integers signifying JSON array indexes separated
by a period, such as name1.name2.3.name4.5. For example, entities.0.handle would
be useful for getting at the "handle" value from the following JSON:
{ "entities" : [ { "handle": "foo" } ] }
Multiple --jv options may be specified.
There are several built-in demonstration queries that may be exercised to show the
utility of RDAP. To use these queries, the --demo parameter must be used to populate
the query answers into the cache. If the cache is already populated with items, it
may be necessary to clean the cache using the --empty-cache parameter.
When the --demo parameter is given, the list of demonstration queries will be printed
out.
This program has built-in checks for verifying the validity of RDAP responses.
Beyond these normal built-in checks, it can also JSON Content Rules to check
the validity of the responses using the --jcr parameter, which requires either
the standard (i.e. --jcr standard) or strict (i.e. --jcr strict) parameter
options.