RIPE Whois Database Query Reference Manual

João Luis Silva Damas
Andrei Robachevsky
Denis Walker

Document ID: ripe-358
Date: October 2005
Partly Obsoletes: ripe-252

Abstract

This document describes how queries work in version 3.2 of the RIPE Whois Database. This version uses the Routing Policy Specification Language (RPSL) [1] to represent many of the database objects. It uses the Routing Policy System Security (RPSS) [2] for authorisation. This means better security for Internet Routing Registries (IRR). It makes use of RPSL next generation specifications [14]. This means that you can register multicast and IPv6 routing policies. Though this document is self-contained, you may also wish to read the RPSL [1] and RPSS [2] specifications. For a tutorial on RPSL, you can read the RPSL applications document [3].

Intended Audience

This reference manual is for casual and advanced users who query the RIPE Whois Database. If you are new to this database, you might find the “RIPE Whois Database User Manual – Getting Started” [5] to be a more helpful place to start.

Conventions Used in This Document

We use <label> for a placeholder or to indicate syntax.
We use [option] to indicate an optional text or command argument.
We use a BOLD font to indicate an object type.
We use “attribute:” to indicate an attribute of an object.
"RIPE Whois Database" usually means the interface software rather than the information in the database. Where there may be any doubt, this manual will make clear what is being discussed.

Table of Contents

Introduction
1.0 Database Objects and Attributes
1.1 Object Representation
1.2 Object Types
1.2.1 as-block
1.2.2 as-set
1.2.3 aut-num
1.2.4 domain
1.2.5 filter-set
1.2.6 inet6num
1.2.7 inetnum
1.2.8 inet-rtr
1.2.9 irt
1.2.10 key-cert
1.2.11 mntner
1.2.12 organisation
1.2.13 peering-set
1.2.14 person
1.2.15 poem
1.2.16 poetic-form
1.2.17 role
1.2.18 route
1.2.19 route6
1.2.20 route-set
1.2.21 rtr-set
2.0 Querying the RIPE Whois Database
2.1 Queries Using Primary and Lookup Keys
2.2 Queries for IP Networks
2.2.1 Default Queries for IP Networks
2.2.2 Exact Match Queries
2.2.3 More and Less Specific Queries
2.2.3.1 More Specific Queries
2.2.3.2 Less Specific Queries Error
2.2.4 Less Specific Queries Referencing irt Objects
2.3 Inverse Queries
2.4 Abuse Contacts
2.5 Grouping the Whois Output
2.6 Filtering the Whois Output
2.7 Query Support for Tools
2.7.1 IRRToolset Support
2.7.2 Persistent Connections and Keeping State
2.8 Getting All the Members of Set Objects
2.9 More and Less Specific Lookups For Reverse Domains
2.10 Referral Mechanism for Domains
2.10.1 The “refer:” Attribute
2.10.2 Domain Name Stripping
2.10.3 The “-R” query flag
2.10.4 The Referral Process
2.11 Access Control for Queries
2.12 Other Server Features
2.12.1 Mirroring Other Databases
2.12.2 The “–q” Query Flag
2.12.3. The “-t” Query Flag
2.12.4. The “-v” Query Flag
2.12.5. The “-F” Query Flag
2.12.6. The “-K” Query Flag
2.12.7. The “-T” Query Flag
2.12.8. The “-a” Query Flag
Tables of Query Types Supported by the RIPE Whois Database
Table 2.1 Queries Using Primary and Lookup Keys
Table 2.2 Queries For IP Networks
Table 2.3 Query Flag Arguments to the "-i" Query Flag and the Corresponding Inverse Keys
Table 2.4 Query Support For Tools
Table 2.5 Miscellaneous Queries
Table 2.6 Informational Queries
Appendices
A1. Object Attributes
A2. RIPE Whois Database Query Server Response Codes and Messages
A2.1 Query Errors
A2.2 Access Errors
A2.3 Connection Errors
A2.4 NRTM Errors
A2.5 Warnings
A2.6 Referral Text
A3. Copyright Information
A3.1 RIPE Whois Database Copyright
A3.2 RIPE NCC Copyright
Addendum
Acknowledgements
References

Introduction

The RIPE Network Management Database (often called the "RIPE Whois Database") contains information about IP address space allocations and assignments, routing policies, reverse delegations, contacts in the RIPE NCC service region [16] and ENUM delegations worldwide.

The information in the RIPE Whois Database is available to the public for agreed Internet operation purposes, but it is copyright. See Appendix A3 "Copyright Information".
This document describes how queries work in version 3.2 of the RIPE Whois Database. This version uses the Routing Policy Specification Language (RPSL) [1] to represent all database objects. It uses the Routing Policy System Security (RPSS) [2] for authorisation. This means better security for Internet Routing Registries (IRR). The RIPE Whois Database includes an IRR. It makes use of RPSL next generation specifications [14]. This means that you can register multicast and IPv6 routing policies.

This document is self-contained, but does not contain examples of usage and illustrations of how the RIPE Whois Database works. If this is what you want, you should read the RPSL [1] and RPSS [2] specifications. If you are looking for a tutorial on RPSL, you should read the RPSL applications document [3]. The “RIPE Whois Database User Manual – Getting Started”[5] contains some examples. You may also want to read the “RIPE Whois Database Update Reference Manual” [19]. It explains how updates work in the RIPE Whois Database. There is also a single page “Whois Queries Reference Card” [18].

1.0 Database Objects and Attributes

The RIPE Whois Database contains records of:

• allocations and assignments of IP address space (the IP address registry);
• domain names (mainly for reverse domains);
• routing policy information (the routing registry);
• contact information (details of people who are responsible for the operation of networks or routers. As the RIPE NCC does not maintain the contents of the database, you can find contact details here of the people who do).

The RIPE NCC defines a database object as a list of attribute-value pairs in plain text form. Attributes can be mandatory, optional or generated. Mandatory attributes will always be present in an instance of an object. Optional attributes may be present if considered necessary or useful by the creator of the object. Generated attributes can be included by the creator of the object, but their values will always be checked and included, when necessary, by the database software.

The attributes are indexed in a number of ways to allow the queries to search the database. An attribute can be a primary key, lookup key, inverse key, or a combination of these.

The characteristics of an attribute are determined by the type of object the attribute appears in. These are shown for each object in the object templates. They can be listed using the query:

 whois –t <object-type>

1.1 Object Representation

The records in the RIPE Whois Database are known as objects. RPSL [1] defines the syntax of these database objects (how they are written). An object belongs to one of the object types or classes. We use the two terms - ‘type’ and ‘class’ - interchangeably throughout this document.

Object Types Supported by the RIPE Whois Database:

All objects contain at least one “changed:” attribute. The information in this attribute shows who created or modified the object and when. It is not reliable as a full audit trail. The only database software conditions are that there is at least one of these attributes and if there is more than one, the dates must be in ascending order. It is for the maintainer of the object to decide how to use this attribute. In some cases it may be a full audit trail. In other objects it may only have one attribute that is modified each time the object is modified. It may also have just the one attribute that represents the original creation or any one of many modifications made to the object over a period of time. It is used as a reference for the benefit of the maintainer of the object. It is not intended to give any reliable information to a user who queries for an object.

Some objects contain a “country:” attribute. It is difficult to strictly define what this value means. It may be the country where the IP address is used, or the country from where it was assigned. It could be the country where the head office of the organisation is based. As with the “changed:” attribute, it is not intended to give any reliable information to a user who queries for an object.

There are a number of attributes used for notifications. For example, “notify:”, “mnt-nfy:”, “upd-to:”. These are used for administration of the data in the database. They show who is to be notified of changes to objects, or incorrectly authorised attempts to make changes.

There are a number of attributes used for the authorisation of changes to the data in the database. For example, “mnt-by:”, “mnt-lower:”. These contain references to objects containing the authentication tokens needed to make changes.

1.2 Object Types

This section describes the object types (classes) that the RIPE Whois Database supports.

1.2.1 as-block

An as-block object delegates a range of AS Numbers to a given RIR [21]. These objects are created by the Database Administration. They are used to authorise creation of aut-num objects within the range specified by the "as-block:" attribute.

1.2.2 as-set

An as-set object defines a set of aut-num objects. The "as-set:" attribute defines the name of the set. It is an RPSL name that starts with "as-".
The "members:" attribute lists the members of the set. It can be either a list of AS Numbers, or other as-set names.

The name of an as-set object can be hierarchical. A hierarchical as-set name is a sequence of as-set names and AS Numbers separated by colons. The first component must be an actual as-set name (that means that it should start with "as-").

1.2.3 aut-num

The aut-num object specifies routing policies. It refers to a group of IP networks that have a single and clearly defined external routing policy, operated by one or more network operators – an Autonomous System (AS).

• The value of the "aut-num:" attribute is the AS Number of the AS that this object describes.
• The "as-name:" attribute is a symbolic name of the AS.
• The import, export and default routing policies of the AS are specified using the "import:", "export:" and "default:" attributes.
• Corresponding attributes with an "mp-" prefix (for example: "mp-import:”) are used to specify IPv6 and multicast routing policies.
• Only a single value for the “org:” attribute is allowed in the aut-num object. This makes sure that only one organisation is responsible for this resource.

1.2.4 domain

The domain object mainly represents reverse DNS delegations. It can also be used to represent Top Level Domain (TLD) and other forward domain registrations. However, the information about forward domain names is for reference only. It has no effect on operations and may not be complete or authoritative. The RIPE Whois Database is not the same as the domain name registries run by the country code Top Level Domain (ccTLD) administrators of Europe and surrounding areas. The IANA ccTLD Database provides a full list of the ccTLD administrators. [17]. You should contact these for authoritative information on forward domains.

You should write the domain name in fully qualified format, without a trailing dot.

1.2.5 filter-set

A filter-set object defines a set of routes that match the criteria that you specify in your ‘filter’ – in other words, it filters routes that you may or may not want to see.
The "filter-set:" attribute defines the name of your filter. It is an RPSL name that starts with "fltr-".

• The "filter:" attribute defines the policy filter of the set. This is a logical expression that, when applied to a set of routes, returns a subset of these routes. These are the ones that you want to filter in or out.
• The "mp-filter:" attribute extends the "filter:" attribute to allow you to specify IPv6 prefixes and prefix ranges.
• The "filter:" and "mp-filter:" attributes are optional. A filter-set object, must contain at least one of these two attributes. It cannot contain both within the same object.
• The name of a filter-set object can be hierarchical. A hierarchical filter-set name is a sequence of filter-set names and AS Numbers separated by colons. The first component of the name must be an actual filter-set name (that is, start with "fltr-").

1.2.6 inet6num

An inet6num object contains information on allocations and assignments of IPv6 address space. Only a single value for the “org:” attribute is allowed in the inet6num object. This is to ensure that only one organisation is responsible for this resource.

The “status:” attribute is used as an administrative tag to register the type of address space.

The “rev-srv:” attribute is for information only. It has no operational use.

1.2.7 inetnum

An inetnum object contains information on allocations and assignments of IPv4 address space. Only a single value for the “org:” attribute is allowed in the inetnum object. This is to ensure that only one organisation is responsible for this resource.

The “status:” attribute is used as an administrative tag to register the type of address space.

The “rev-srv:” attribute is for information only. It has no operational use.

1.2.8 inet-rtr

The inet-rtr object specifies routers.

• The "inet-rtr:" attribute is a valid DNS name for a router, without a trailing ".".
• Each "alias:" attribute, if present, is also a standard DNS name for the specified router.
• The "local-as:" attribute specifies the AS Number of the AS that owns or operates this router.
• The "ifaddr:" attribute specifies the interface address within an Internet router, as well as an optional action to set other parameters on this interface.
• The "interface:" attribute specifies a multi-protocol interface address within an Internet router, optional action and tunnel definition.
• The "peer:" attribute specifies the details of any interior or exterior router peering.
• The "mp-peer:" attribute extends the "peer:" attribute for IPv6 addresses.

1.2.9 irt

An irt object represents a Computer Security Incident Response Team (CSIRT). It includes contact and security information. It can be referenced from inetnum or inet6num objects to show which CSIRT is responsible for handling computer and network incidents for that address range.

The irt object name starts with "irt-".

1.2.10 key-cert

A key-cert object is a database public key certificate that is stored in the RIPE Whois Database. It is used with a mntner object for authentication when performing updates. Currently the RIPE Whois Database supports two types of keys:

• For PGP key-cert objects, the value of the “key-cert:” attribute must be PGP-“key-id”. These keys are compliant with the Open PGP Message Format [RFC 2440].
• For X.509 key-cert objects, the database software assigns this value as X.509-n. Here, ‘n’ is the next available number.

1.2.11 mntner

Using mntner objects protects objects in the RIPE Whois Database. A mntner object contains the information needed to authorise creation, deletion or modification of any objects that it protects.

Objects are protected by a mntner, if they contain a reference to the mntner in the object. This is done by including a “mnt-by:” attribute. Other attributes offer hierarchical protection. The “mnt-by:” attribute is mandatory in all objects except person and role types. Most users set the “mnt-by:’ value in a mntner to reference itself.
The “referral-by:” attribute can refer to the mntner object itself. The database software does not currently use this attribute even though it is mandatory to include it.

1.2.12 organisation

The organisation object provides information about an organisation such as a company, charity or university, that has a network resource stored in the RIPE Whois Database. It was introduced as a means to link together all the resource and administration objects related to one organisation.

• “organisation:” specifies the ID of the organisation object. This is set by the database software. It is used as a label to allow other objects to reference it.
• “org-name:” attribute defines the name of the organisation.
• “org-type:” specifies the type of an organisation and can be IANA, RIR, NIR, LIR or NON-REGISTRY. Users can only set their “org-type:” to NON-REGISTRY. Only the Database Administrator uses all other types.

1.2.13 peering-set

A peering-set object defines the set of peerings that appear in the “peering:” or “mp-peering:” attribute.

The “peering-set:” attribute defines the name of the set. It is an RPSL name that starts with ‘prng-’.

• The name of a peering-set object can be hierarchical. A hierarchical peering-set name is a sequence of peering-set names and AS Numbers separated by colons. At least one part of the name must be an actual peering-set name (that means that it should start with “prng-“).
• The “peering:” attribute defines a peering that you can use to import or export routes.
• The “mp-peering:” attribute extends the “peering:” attribute to use IPv6 addresses.
• The “peering:” and “mp-peering:” attributes are optional. However, a peering-set object must contain at least one of these two attributes. It cannot contain both within the same object.

1.2.14 person

A person object contains information about the technical or administrative contact(s) responsible for an object. After it has been created, the “person:” attribute cannot be changed by users. It can be changed by the Database Administrator.

The person object is identified by the “nic-hdl:” attribute. This is a label, usually made up from the initials of the person’s name and the database “source:” (for example, RIPE).

The “nic-hdl:” is used by other objects to reference the person.

1.2.15 poem

A poem object contains poems that users submit.

1.2.16 poetic-form

A poetic-form object defines the supported poem types.

1.2.17 role

A role object is similar to a person object. However, instead of describing a single person, it describes a role performed by one or more people. This might be a helpdesk, network monitoring centre, system administrator, etc. A role object is useful since often a person performing a specific job may change; however, the role itself remains. The “nic-hdl:” attributes of the person and role objects share the same name space. After it has been created, the “role:” attribute cannot be changed by users. It can be changed by the Database Administrator.

1.2.18 route

Each interAS route (also known as an interdomain route) originated by an AS can be specified by using a route object.

• The “route:” attribute is the address prefix of the route.
• The “origin:” attribute is the AS Number of the AS that originates the route into the interAS routing system.

1.2.19 route6

A route6 object specifies an interAS IPv6 route, originated by an AS.

• The “route6:” attribute is the IPv6 address prefix of the route.
• The “origin:” attribute is the AS Number of the AS that originates the route into the interAS routing system.

1.2.20 route-set

A route-set object is a set of route prefixes, not of database route objects. The “route-set:” attribute defines the name of the set. It is an RPSL name that starts with "rs-". It defines a set of routes that can be represented by route objects or by address prefixes.

• In the first case, the set is populated by means of the “mbrs-by-ref:” attribute, in the latter, the members of the set are explicitly listed in the “members:” attribute.
  • The “members:” attribute is a list of address prefixes or other route-set names.
  • The “mp-members:” attribute is a list of IPv6 address prefixes or other route-set names.
• The name of a route-set object can be hierarchical. A hierarchical route-set name is a sequence of route-set names and AS numbers separated by colons. The first component of such a name must be an actual route-set name (that means that it should start with "rs-").

1.2.21 rtr-set

A rtr-set object defines a set of routers.

A set may be described by the “members:” attribute that is a list of inet-rtr names, IPv4 addresses or other rtr-set names. The “mp-members:” attribute extends the “members:” attribute to use IPv6 addresses.

A set may also be populated by means of the “mbrs-by-ref:” attribute, in which case it is represented by inet-rtr objects.

The “rtr-set:” attribute defines the name of the set. It is an RPSL name that starts with "rtrs-".

The name of a rtr-set object can be hierarchical. A hierarchical rtr-set name is a sequence of rtr-set names and AS Numbers separated by colons. The first component of such a name must be an actual rtr-set name (that means that it should start with "rtrs-").

2.0 Querying the RIPE Whois Database

This section describes how you can query to find information in the RIPE Whois Database. We describe the general format of a query and the query flags that you can use to change the default behaviour of a query.

We also describe how the whois server automatically tracks query responses and limits how much contact information you can take from the RIPE Whois Database. We do this to reduce the chance that someone will use the database to send spam e-mails to addresses that they find. The software does not prevent operational use of the database.
There are three ways to query the database:

• Using a whois client running the whois protocol [12].
• Using the web interface from the RIPE NCC website [20].
• Using telnet to port 43 of the whois.ripe.net host.

There is a set of general rules about server responses:

The same response will be returned from the server for each of the three methods of querying the database shown above.

Output lines starting with the % sign are either a server response code or server messages (a comment, information message or an error with description). A message contains a white space after the % sign, whilst a server response code line starts right after the % sign. See Appendix A2 “RIPE Whois Database Query Server Response Codes and Messages” for more information.

An empty line in the output is used to separate objects. This is a line containing only a newline character (\n).

Two empty lines, each containing only a newline character (\n), mean the end of a server response.

When using the referral mechanism, the output of the referred server is passed to the client without modification.

The general format of a query is:

 [optional query flags] <query argument>

The format of a query flag is:

 -query_flag [optional query flag argument]

You may list each query flag separately as in:

 -B –i tech-c –G ABC999-RIPE

You can also group together query flags. In this case, only the last flag in a list may have a flag argument, as in:

 -BGi tech-c ABC999-RIPE

You can find a list of query flags and query flag arguments in Tables 2.1 to 2.6.

2.1 Queries Using Primary and Lookup Keys

Most queries use the primary and lookup keys of an object as an argument to the query. You can find a list of these queries in Table 2.1 at the end of this section.

2.2 Queries for IP Networks

The RIPE Whois Database provides information about IP networks on the Internet, mainly in the RIPE region [16]. This information is mainly stored as inetnum, inet6num, route and route6 objects. These objects store information about ranges of IP addresses.

The route and route6 objects use ‘prefix notation’ to specify the range of IP addresses about which they contain information.

‘Prefix notation’ specifies ranges using two parts: the prefix and its length.

• For IPv4, the prefix is a 32-bit integer written in dotted quad notation with the value of the lowest IP address in the range. The prefix length is a whole number in the range 0-32 (for example 193.0.0.0/22 specifies the range of 1024 IPv4 addresses starting with, and including, 193.0.0.0)
• For IPv6 address ranges, the prefix length must be in the range 0-128 and is a 128-bit whole number, written in hexadecimal groups of two bytes separated by colons and with the possible use of shorthand notation for strings of consecutive 0s.

The inetnum objects represent an IPv4 address space in range notation where the range is explicitly specified as two 32-bit whole numbers written in dotted quad notation separated by a dash (for example193.0.0.0 - 193.0.3.255, this is the same range as in the above example).

The inet6num objects represent an IPv6 address space. Only the standard IPv6 prefix notation is allowed (as described above).

When you query the database for information about a range of IP addresses, you can specify query arguments as search keys with the following notations:

• a prefix (this has the same meaning as above)
• an explicit range (also as above)
• a single IP number. This is interpreted as a range of just one address for IPv4 or a prefix of length 1 for IPv6.

For IPv4 address space, the query argument can be specified with either prefix or range notation. When prefix notation is used, the server software converts this into range notification before it executes the query. An information message is included in the server output showing the conversions performed.

For IPv6 address space, the query argument can only be specified in prefix notation.

You can find a list of queries for IP networks in Table 2.2 at the end of this section.

The rest of this section describes how you can retrieve different types of information relative to a particular range of IP addresses.

We use three terms in these types of queries. These are all defined relative to your specified (reference) range:

• An exact match refers to a range that is identical to the reference range.
• A more specific range is contained within the reference range and is smaller. It contains fewer IP addresses than the reference range. We also call this a sub range.
• A less specific range contains the whole of the reference range and is bigger. It has a greater number of IP addresses than the reference range. We also call this an encompassing range.

2.2.1 Default Queries for IP Networks

If you do not specify a query flag, and your query argument is a range of IP addresses in any one notation, the RIPE Whois server will try to find an exact match for that range.
The exact match is returned, if found. If it cannot find an exact match, the server looks for the smallest less specific range. This will be the smallest existing, encompassing range.

2.2.2 Exact Match Queries

If you want to change the default behaviour, so that the server returns only an exact match, you need to use the –x query flag. This flag stops the server from looking for any less specific ranges if no exact match exists.

2.2.3 More and Less Specific Queries

If the exact match is not the information you wanted, you can modify the information returned by the whois server, by using one of four query flags.
These flags (“-M”, “-m”, “-L” and “-l” ) provide two generic types of queries known as more and less specific queries.

2.2.3.1 More Specific Queries

These refer to queries qualified by the use of the “-M” and “-m” query flags.

These will return information about ranges of IP addresses that are fully contained in the user-supplied reference range and contain fewer addresses. More specific queries do not return the exact match.

• The “-M” flag requests that the server should return all the sub-ranges completely contained within the reference range. When there are hierarchies of sub-ranges, all of these will be returned down to the smallest sub-ranges.
• The “-m” flag requests that the server should return all sub-ranges that are completely contained within the reference range. When there are hierarchies of sub-ranges, only the top level of the hierarchies will be returned. These are usually called one level more specific ranges.

2.2.3.2 Less Specific Queries

These refer to queries qualified by the use of the “-L” and “-l” query flags.

These will return information about ranges of IP addresses that fully contain the user-supplied reference range and may contain a greater number of addresses.

• The “-L” flag requests that the server returns the exact match, if any, and all encompassing ranges that are bigger than the reference range and that fully contain it.
• The “-l” flag requests that the server does NOT return the exact match. It returns only the smallest of the encompassing ranges that is bigger than the reference range and that fully contains it. This is usually referred to as the ‘one level less specific range’.

2.2.4 Less Specific Queries Referencing irt Objects

In this section, ‘inet(6)num’ is used to mean ‘inetnum or inet6num’. This is to make the text clearer.

An irt object represents a Computer Security Incident Response Team (CSIRT). It includes contact and security information. It may be referenced from inet(6)num objects using the “mnt-irt:” attribute. This shows which CSIRT is responsible for handling computer and network incidents for that address range.

Not every inet(6)num object needs to contain a reference to the irt object that applies to its range.

A reference to an irt object does not apply only to the inet(6)num object that contains the reference. It also applies to all the inet(6)num objects that are 'more specific' to the one containing the reference. The irt reference only needs to be placed in the least specific encompassing object to apply to a whole hierarchy of objects. This makes it easier to apply and maintain.

There may be more than one inet(6)num object in a hierarchy referencing an irt object. In this case, the one referenced from the smallest encompassing object is the one that applies to the range in question.

There is a “-c” query flag to make it easy to find the inet(6)num object containing the reference to an irt object for any specific range.

This flag makes the server search up the hierarchy from the range specified as the query argument. The search will stop when the first object is found containing a reference to an irt object. This can either be the specified range or an encompassinginet(6)num object. The query will return the inet(6)num object found containing the reference. The irt object will also be returned along with the usual contact data objects.

Sometimes, no inet(6)num object is found in the hierarchy containing a reference to an irt object. In this the query will return no objects.

2.3 Inverse Queries

Inverse queries are performed using an object's inverse key as an argument to a query. The query flag "-i" must also be specified with appropriate query flag arguments. Inverse keys are defined in the templates of the RIPE Whois Database objects. These can be listed using the query:

 whois –t <object type>

Table 2.3, at the end of this section, gives a complete listing of the arguments to the "-i" query flag and the corresponding inverse keys.

By performing this type of query, the user requests all objects to be returned by the database that reference the specified query argument in the attribute(s) specified in the query flag arguments.

As an example:

 whois -i admin-c <nic-handle> 

will return all objects where the "admin-c:" attribute contains the <nic-handle> specified as the query argument.

You can specify several query flag arguments to request searches against several attributes in objects. If you want to do this, the query flag arguments should be entered as a comma-separated list with no white spaces. All the attributes searched must contain the same type of value. In other words, all the values must be maintainers or nic-handles or one of the other values listed in Table 2.3.

As an example:

 whois -i mnt-by,mnt-lower <mntner name> 

will return all objects where the "mnt-by:" or the "mnt-lower:" attributes contain the <mntner name> specified as the query argument.

2.4 Abuse Contacts

There are many attributes in objects within the RIPE Whois Database containing e-mail addresses. These addresses cover a number of functions. A growing concern to engineers and administrators that maintain networks is receiving spam and abuse complaints that are sent to every e-mail address displayed. This will get the message to the right person, but it also causes more spam and abuse to people who are not responsible for solving these problems.

To solve this issue, an optional “abuse-mailbox:” attribute is available in the following objects:

• person
• role
• irt
• organisation
• mntner

This optional attribute contains at least one e-mail address. There is a “-b” query flag to make it easy to find the “abuse-mailbox:” attributes for any specific range
This flag will instruct the whois server to first of all do a query as if it had been given a “-c” query flag (See section 2.2.4 Less Specific Queries Referencing irt Objects). If a reference to an irt object is found, the “abuse-mailbox:” e-mail address will be taken from the irt object. The “abuse-mailbox:” e-mail address will also be taken from any of the other objects associated with the inetnum or inet6num object that references the irt object.

The output returned from the server will contain a brief summary. This summary will only include the inetnum or inet6num range (of the object that references the irt object). Also the prefix of any corresponding route or route6 objects, followed by the “abuse-mailbox:” attributes from all of the associated objects.

If no irt object reference is found in any encompassing objects then no object summaries will be returned.

If a summary is returned, it will include the correct e-mail address for complaints about spam and other network abuse. A complaint will not be handled any quicker by copying your message to any other e-mail address found in the database.

The “-b” query flag cannot be used with any of these flags:

 “-KFrGB”

2.5 Grouping the Whois Output

There are two ways to display the results of a query.

One way is for the first part of the results to list the main objects like inetnum and mntner. Then the second part of the results lists all the objects associated with the main objects, like organisation and person. If any of these associated objects, like a person object, is referenced by more than one of the returned objects, it will only be listed once in the returned results.

The other way is to group the returned objects to show the association between them. In this way, each of the main objects is followed immediately by all of its associated objects. The associated objects may appear more than once in this type of output.

The default output is grouped. If you include the “-G” query flag then the output will not be grouped.

2.6 Filtering the Whois Output

A filtering process restricts some data from default query results. This applies to e-mail contact data. When a user is searching for abuse contact data, they sometimes take all e-mail addresses found in all objects returned from a query. This may include the correct address. However, it often also includes many other addresses for people who are not responsible for handling such complaints.

To help overcome this issue, some attributes containing e-mail addresses are filtered out of the default output. Other attributes, also containing e-mail addresses, are filtered if one of the returned objects includes an “abuse-mailbox:” attribute.

The stricter filtering has slightly different behaviour depending on the use of grouping. If the output is grouped (See section 2.5 Grouping the Whois Output), then each group is treated separately. If any object within a group of objects includes an “abuse-mailbox:” attribute, then the stricter filtering will apply to that group. In a group with no objects including an “abuse-mailbox:” attribute, the more basic filtering will apply to that group.

When the output is not grouped (using the “-G” query flag) the whole output is taken as a single group. If any one object includes an “abuse-mailbox:” attribute then the whole output is subject to the more strict filtering.

• The attributes that are always filtered out are “changed:” and “notify:”
• The additional attributes that are filtered out with the more strict case are “e-mail:” and “ref-nfy:”
• The default output is filtered. If you include the “-B” query flag then the output will not be filtered

When any attribute has been filtered out of an object in the query results returned to the user, a “Note:” is added to the output to warn the user. In addition, the “source:” attribute of each filtered object will have a comment added to the end of the line saying “# Filtered”. If this filtered output is cut and pasted into an update message, including this end of line comment on the “source:” attribute, the update will fail. This is because some mandatory attributes will be missing and the “source:” will not be recognised. So filtered output can not be accidentally used for updates.

2.7 Query Support for Tools

There are several query types in the RIPE Whois Server that support various client tools. Other whois clients can also use these.

2.7.1 IRRToolset Support

The IRRToolset [6] is a suite of routing policy analysis tools maintained by the Information Sciences Institute at the University of Southern California. Some of the tools in this set access Routing Registry servers through an authorisation whois interface.

Versions 3.0 and above of the RIPE Whois Server include support for these query types. This section describes the additions to the RIPE Whois user interface that allow it to support the IRRToolset. The required queries are:

• Return the prefixes of all route and route6 objects with a specified origin.
• Return only the primary keys of the route and route6 objects, not full objects.
• Return the prefixes of all route and route6 objects referenced in a given route-set.
• Return all the members (aut-num or as-set object) of a specified as-set.
• Return only the “members:” attributes, not the full object.
• Optionally, include support for expansion of the previous query, if the returned value contains references to as-sets, so that the result contains only a list of aut-num objects.

The RIPE Whois server does not support this and it is up to the client to perform the expansion. The IRRToolset currently does the expansion.

• Return route and route6 objects that exactly match a specified prefix.
• Return route and route6 objects that exactly match a specified prefix (as above), but return only the “route:” or “route6:” attributes.

Table 2.4, at the end of this section, gives details of query support for tools.

2.7.2 Persistent Connections and Keeping State

If you are carrying out batched queries, your whois client can request a persistent connection. The server will not close this connection after sending a reply to your client. This avoids having to set up a new TCP connection for every query.

The client can request this by sending the “-k” query flag to the server. This flag may be sent without a query argument to start the connection. It may also be included as a query flag with the first query.

During a persistent connection, the server operates a 'stop-and-wait' protocol. This means that the next query cannot be sent until the reply has been received to the previous query. If you want to be able to send queries in batch mode, you must use the RIPE Whois3 client.

To exit a persistent connection, send the “-k” flag with no query argument or an empty query (\n) to the server. The connection will also time out after a period of inactivity.

2.8 Getting All the Members of Set Objects

In RPSL [3], an object can be a member of a set object in two ways.

• You can list objects in a “members:” attribute in the set object. This is the kind of member relationship present in “Representation of IP Routing Policies in a Routing Registry”[4]
• You can use the “member-of:” attribute. You can use this in route, route6, aut-num and inet-rtr object types. The value of the “member-of:” attribute identifies a set object that this object wants to be a member of.

However, just specifying “member-of:” is not enough. The set object must also have a “mbrs-by-ref:” attribute. This lists the maintainer of the object that wants to be a member of the set. This means that the set owner must validate the membership claim of an object with a “member-of:” attribute. It does this by matching the “mnt-by” line of the object with one of the maintainers in the “mbrs-by-ref:” attribute of the set object.

2.9 More and Less Specific Lookups For Reverse Domains

Versions 3.0 and above of the RIPE Whois Database support IP network queries including the “-x”, “-M”, “-m”, “-L” and “-l” functionality for reverse delegation domains. To request that reverse delegation domains be queried for with the more (or less) specific query flags, you must also include the “-d” query flag.

2.10 Referral Mechanism for Domains

The referral mechanism is for administrators of domain registries. It allows the whois server to reply to the user by fetching data from the domain registry database rather than from the local whois data. There are three elements to this mechanism. The “refer:” attribute, domain name stripping and the “-R” query flag.

2.10.1 The “refer:” Attribute

This attribute can be included in a domain object in the whois database. When present, it allows the whois software to pass the query on to the authoritative server of a ccTLD. This server can return information about a domain object to the whois server to pass back to the user.

This attribute specifies the hostname, port and referral type that the whois server should use to redirect the query. See Appendix A1 “Object Attributes” for the syntax of this attribute.

2.10.2 Domain Name Stripping

When no matching domain object is found in the RIPE Whois Database with the name specified in the query argument, the domain name is stripped towards higher-level domains (xxx.yyy.zzz becoming yyy.zzz). The query is repeated with the shorter domain name. The cycle of stripping and repeating the query continues until a domain object is found or the search string becomes empty.

2.10.3 The “-R” Query Flag

You can retrieve an object from the whois database without using the referral mechanism. This is done by including the “-R” query flag. When this flag is included in the query to the whois server, no referrals are made, not even if the object returned contains a “refer:” attribute.

2.10.4 The Referral Process

The software follows a specific process when checking the three elements of the referral mechanism. This process is best described by using a flow chart as follows:

2.11 Access Control for Queries

The control mechanism is based on the amount of contact information (contained in person and role objects) that is returned because of queries made from an IP address.
Access is determined by the IP address of a whois client sending queries to the whois server. Sometimes an IP address may be acting as a proxy and submitting queries on behalf of other IP addresses (for example, a web server running cgi interfaces to the RIPE Whois Database). The whois server provides a facility for such proxy clients which allows accounting to be based on the IP address of the clients using the proxy to query the RIPE Whois Database and not on the IP address of the proxy server. This is done using the "-V" flag as follows:

 -V <version>,<ipv4-address>

where

• <version> is a client tag that usually represents the software version that the proxy uses;
• <ipv4-address> is the IPv4 address of the client that queries the database using the proxy.

Not all users can use this "-V" flag. Before you can, you must contact RIPE Whois Database Administration and tell us why you need this facility. If we approve your request, we will add the IP address of the proxy server to an access control list. You can then use the "-V" flag, but only from your stated IP address.

Attempting to use the “-V” flag without approval may result in permanent denial of access to the RIPE Whois Database. This denial of access will apply to the IP address that submits the query.

We restrict access to stop people using the RIPE Whois Database to collect excessive amounts of contact data. A counting algorithm with defined limits temporarily blocks access when limits are reached within certain periods of time. This block will be automatically released as time goes on to allow querying to continue. The count is reduced by half every 12 hours. There is also a limit on the number of times an IP address can be blocked and recover. When this limit is reached, that IP address is permanently blocked from accessing the RIPE Whois Database. This permanent block will not be automatically removed.

There are many reasons why you could find yourself in this position. One is that you are mining the RIPE Whois Database for contact data to use for non-agreed purposes. In this case, the denial of access is justified and your IP address will remain on the blocked list. However, there may be other reasons. Queries for object types other than person and role objects return contact information by default. Using the “-r” flag to prevent the contact data being included in your query results can turn off this default. Alternatively, you may have an error in a script that runs automatically, retrieving contact data that you did not know about. If you believe there was a genuine error or mistake that led to the permanent block, you need to contact RIPE Whois Database Administration. Explain the error and tell us what steps you have taken to stop it happening again. The RIPE Whois Database Administration will decide whether to remove the block. It will remain on record that this IP address has been permanently blocked and unblocked. If another permanent block occurs, we will be less likely to consider removing it a second time.

Each time a person or role object is retrieved, a counter decreases. When it reaches zero, the query execution is aborted and the connection is terminated, displaying an error message to the client (see "Access errors” in Appendix A2 "RIPE Whois Database Query Server Response Codes and Messages"), also a count of denials increases. Retrieving any other object type does not affect these counters.

There is also a limit on the number of simultaneous connections from a host. When this limit is reached, further connections from the same host are refused.

If we block your access, you will not be able to query for any object types. We will not just block your access to contact date alone.

2.12 Other Server Features

2.12.1 Mirroring Other Databases

The whois software allows Near Real Time Mirroring (NRTM) of other databases. This allows queries to the RIPE Whois Database to retrieve information from one of the mirrored databases. A local copy is maintained of each mirrored database. Periodically, updates are requested from the remote servers to keep the local copies up to date. This period is configurable by the Database Administrators and is typically around 15 minutes.

2.12.2 The “–q” Query Flag

The RIPE Whois Database server (Versions 3.0 and higher) supports the retrieval of certain information about itself and the data sets served, using a “-q” query flag.

The “-q” query flag takes arguments that make the server reply with information that is not extracted from the databases that it serves, but rather about the system setup. This query flag can take three arguments:

• version (usage: -q version). This will display version information for the server software.
• types (usage: -q types). This will list all the object types recognised by the RIPE Whois Database.
• sources (usage: -q sources). This will list all available sources. That is, the local RIPE Whois Database and all the mirrored databases. The format of this output is:
  <source>:<NRTM_protocol_version_#>:<mirroring>:<first>-<last>
  where
  <source> is the string that idenifies the database (for example RIPE)
  <NRTM_protocol_version_#> identifies the version of the mirroring protocol
  <mirroring> can take one of the following values:
  -- Y/N/X – can mirror/cannot mirror/obscured
  <first> is the lowest serial number available
  <last> is the most recent serial number available

The following semantics apply for –q sources:

2.12.3. The “-t” Query Flag

This query flag returns to the user a brief description of the specified object type.

2.12.4. The “-v” Query Flag

This query flag returns to the user a verbose description of the specified object type.

2.12.5. The “-F” Query Flag

This query flag changes the format of the returned objects. The attribute names are represented in a short hand notation. For example, “person:” becomes “pn:”. Using the –F query flag includes the non recursive action of the –r query flag.

2.12.6. The “-K” Query Flag

This query flag returns only the primary keys of each object.

There are some exceptions to this:

• With set objects the “members:” attributes will also be returned.
• No information is returned for person, role or organisation objects. If a query would normally only return these types of objects, no data is returned. In this case you do not get the “ERROR:101: no entries found”. The entries were found but filtered as a result of using the “-K” flag.

2.12.7. The “-T” Query Flag

This query flag restricts the type of the objects returned. The query flag argument is a comma separated list of object types.

2.12.8. The “-a” Query Flag

This query flag requests that the server searches all the sources available to it. These are the sources listed by using the ‘–q sources’ query.

Tables of Query Types Supported by the RIPE Whois Database

Table 2.1 Queries Using Primary and Lookup Keys

There are side effects to these type of queries. Other objects may be returned besides the ones that you are expecting. For example, if you enter a netname you may only expect to get back the inetnum and inet6num objects with this netname. You will also get any person, role or mntner objects back whose name matches the netname specified. The query is done as a text search on the primary and lookup keys. So any object with a matching string will be returned. The results can be limited by using the ‘–T’option to specify the object types you are interested in.

Table 2.2 Queries For IP Networks