Whois and Network Information Lookup Service, Whois++
Standardized protocol for network directory lookup with advanced search and filtering
Gargano, J. and K. Weiss, "Whois and Network Information Lookup Service, Whois++", RFC 1834, DOI 10.17487/RFC1834, August 1995, <https://www.rfc-editor.org/info/rfc1834>.
@misc{rfc1834,
series = {Request for Comments},
number = 1834,
howpublished = {RFC 1834},
publisher = {RFC Editor},
doi = {10.17487/RFC1834},
url = {https://www.rfc-editor.org/info/rfc1834},
author = {J. Gargano and K. Weiss},
title = {{Whois and Network Information Lookup Service, Whois++}},
pagetotal = 7,
year = 1995,
month = aug,
} RFC text
Contents
Network Working Group J. Gargano
Request for Comments: 1834 K. Weiss
Category: Informational University of California, Davis
August 1995
Whois and Network Information Lookup Service
Whois++
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
I. Introduction
As currently defined, NICNAME/WHOIS [HARR85] service is a TCP
transaction based query/response server, running on a few specific
central machines, that provides netwide directory service to Internet
users. The Network Information Center (NIC) maintains the central
NICNAME database and server, defined in RFC 954, providing online
look-up of individuals, network organizations, key host machines, and
other information of interest to users of the Internet. The
usefulness of this service has lead to the development of other
distributed directory information servers and information retrieval
tools and it is anticipated more will be created. Many sites now
maintain local directory servers with information about individuals,
departments and services at that specific site.
Typically these directory servers are network accessible. Local
development of these services has resulted in wide variations in the
type of data stored, access methods, search schemes, and user
interfaces. The purpose of the Whois and Network Information Lookup
Service Working Group (WNILS) is to expand and define the standard
for WHOIS types of services, to resolve issues associated with the
variations in access and provide a consistent and predictable service
across the network. This memo describes new features for WHOIS to
meet these goals.
II. Architecture
The WHOIS service should be provided in a client/server model. There
are no restrictions on the design of the client, provided it is
capable of passing queries to the server in the proper format, and
capturing the server's response in some useful format. Existing
WHOIS specifications call for clients to display responses in human-
readable form. This more general proposal does not impose that
restriction.
This paper acknowledges the existence of many distributed information
servers, and anticipates the creation of many more. To help users
locate WHOIS servers, each server should have a nameserver entry in
the form "whois.domain", i.e. whois.internic.net.
III. Client Design and Behavior
The client provides the user interface to the WHOIS system and a
mechanism for query generation and display of the response. The
client is responsible for providing support for paging of long output
from the server. All clients must provide this service. The server
will not include any special characters, or make any efforts to
control output to a screen.
Special search criteria may be specified by the use of keywords or
special characters, some of which are defined in RFC 954. Clients
should be designed to make support for quoted strings unnecessary.
IV. Server Design and Behavior
The server should return the same information in response to a given
query consistently, regardless of the client software or the hardware
used to originate the query. Queries should be evaluated on a case-
insensitive basis. Spaces should not be considered in searches. A
search for "La Russo" should return both "LaRusso" and "La Russo" as
matches.
There are three types of data records supported in this proposal:
records for people, hosts, and domains.
Individual records
Name Name of the individual required
Organization Name of the organization required
Organization-type Type of organization optional
(university, commercial research)
Work-telephone Work telephone number optional
Fax-telephone Fax telephone number optional
Work-address Work postal address optional
Title Working title or position optional
within an organization
Department Department optional
Email-address Email address in RFC 822 optional
format for this individual
Handle A unique identifier for this required
record on the local server
Last-record-update Date this record was last required
updated
Home-telephone Home telephone number optional
Home-address Home postal address optional
Host records
Hostname Full domain name required
IPAddress Address required
Sysadmin-name System administrator name optional
Sysadmin-phone System administrator telephone optional
Sysadmin-address System administrator address optional
Sysadmin-email System admin. e-mail address optional
Machine-type Type of machine optional
OS Operating system optional
MX Mail exchanger optional
Last-update Last update optional
Info Location of additional optional
information (i.e. anonymous FTP)
Domain records
Domain-name Domain name registered with required
the Network Information Center
(NIC)
Network-address Network address associated required
with this domain name
Admin-name Name of the Administrative required
Contact for this domain
Admin-address Postal address of the required
Admintistrative Contact for
this domain
Admin-telephone Telephone number of the required
Admintistrative Contact for
this domain
Admin-email Electronic mail address in required
RFC 1822 format for the
Administrative Contact for
this domain
Tech-name Name of the Technical Contact required
for this domain
Tech-address Postal address of the required
Administrative Contact
for this domain
Tech-telephone Telephone number of the required
Technical Contact for this
domain
Tech-email Electronic mail address in required
RFC 822 format for the
Administrative Contact
for this domain
Nameservers Primary domain nameservers optional
for this domain
Last-update Last date this record was required
updated
Search Options
A unique handle must be provided for every record in the server
database to target specific records for display. For example, if
there are three individuals named, respectively, A. La Russo, B.
LaRusso, and C. Larusso, then a search for "LA RUSSO" would return
all three as matches. However, each record would have a unique
handle, i.e. LARUSSO1, LARUSSO2, and LARUSSO3. A search for any one
of these handles would return a single match for that particular
individual. This is consistent with the RFC 954 query, "whois
!SMITH1"
Other search options which should be supported are:
whois smith exact match on last name
whois smith,j exact match on last name, first name
whois "smith,j" begins with "J"
whois j. Smith
whois "j. Smith"
whois smith, john exact match on last and first names
whois "smith, john"
whois john Smith
whois "john Smith"
whois .john Smith
whois "smith..." all last names beginning
whois smith* with Smith
whois begins smith
whois smith?? all last names beginning with
"Smith" and containing up to two
letters after "Smith", i.e. "Smith",
"Smithy", "Smithey" and "Smithie"
whois ends smith all last names ending in "smith"
whois exact A Martinez exact match for "A Martinez"
whois fuzzy paulson all last names that sound like or
are spelled like "Paulson"
whois first Kazuko exact match on first name "Kazuko"
whois first begins Art all first names beginning with "Art"
whois first fuzzy Kasuko all first names that sound like or are
spelled like "Kasuko"
whois hamlet.ucdavis.edu IP address and other information
whois system hamlet.ucdavis.edu on the computer called
hamlet.ucdavis.edu.Could be served
by a domain name service querytype
(QTYPE) *
whois system hamlet IP address and other
information on the computer called
hamlet with the default domain
appended. Could be served by a
domain name service querytype
(QTYPE) *
whois 128.120.2.9 domain name and other
whois system 128.120.2.9 information on the computer at
specified IP address. Could be served
by a domain name service querytype
(QTYPE) PTR.
whois !ucdavis-dom site contacts and other
whois domain ucdavis.edu information on the site ucdavis
If any keywords are specified in the query, the server will complete
that specific query and return the results, even if 0 matches are
found. If no keywords are specified, the server will interpret the
query based upon the rules above. Optionally, the server may be
configured so that if a search yields no matches, the query will
automatically be run again, but with the keyword begin inserted.
Servers must support multiple levels of detail in response to
queries. A query yielding multiple matches should return a short-
form record for each match. A query yielding a single match should
return a long-form record. A query yielding no matches should return
context-sensitive help on expanding the search criteria.
On-line Help
The client should return a minimal (two line) help message for every
query sent to the server. That message should identify the database
being searched and provide instructions for the user to obtain more
detailed help screens.
Additional help should be provided in special situations. The server
should recognize queries that return zero matches, and provide a
brief help message explaining how to broaden a search. If a search
returns more than 50 matches, the server should take two actions.
First, the user should get a message explaining how to narrow
searches. Second, the user should be offered the option of re-
specifying the search, or receiving all matching responses. When
multiple matches are found and returned to the client, the server
should add a brief help message explaining how to use handles to
narrow the search to a single record.
If the client queries for "help" or "?" then the server should return
a complete help file. The help file should contain information in
sufficient detail for the user to understand and access all the
features of WHOIS service.
V. Extensibility
This RFC defines a limited set of data records and fields for
reliable whois queries. Mechanisms exist for whois clients to
discover extended data records and query for fields not defined in
this memo. It is recommended that Whois clients and servers include
this functionality to maximize the extensibility and usefulness of
this service.
VI. References
[Harr85] Harrenstein, K., Stahl, M., and E. Feinler, E.,
"NICNAME/WHOIS", RFC 954, SRI, October 1985.
VII. Security Considerations
Security issues are not discussed in this memo.
VIII. Authors' Addresses
Joan Gargano
Information Technology
Distributed Computing Analysis and Support
University of California
Davis, CA 95616
EMail: jcgargano@ucdavis.edu
Ken Weiss
Information Technology
Distributed Computing Analysis and Support
University of California
Davis, CA 95616
EMail: krweiss@ucdavis.edu
AI ELI5
On this page
§1From Simple to Standardized
The original NICNAME/WHOIS service, defined in RFC 954, was a simple TCP query-response database run by the Network Information Center. As networks grew, many sites created their own local directory servers for employees, hosts, and services. Each site designed them differently: different data fields, different search schemes, different response formats. The Whois and Network Information Lookup Service (WNILS) working group created Whois++ to bring consistency.
Whois++ maintains the client-server architecture but standardizes what can be searched and what will be returned. The protocol itself says nothing about how clients must be built, only that they must format queries properly and handle paged responses from servers.
Many offices started keeping their own phone books with different formats. Whois++ made them all speak the same language so one tool works everywhere.
§2Three Record Types with Standard Fields
Whois++ defines three types of records. Individual records describe people and include name, organization, title, department, email, phone, postal address, and a unique handle for disambiguation. Host records describe network-connected machines with hostname, IP address, system administrator contact information, machine type, operating system, mail exchanger, and location of additional information. Domain records describe registered domains with domain name, network address, administrative contact, technical contact, nameservers, and last update date.
Each record type has required fields and optional fields. For example, an individual must have a name and organization but may have email or phone. Every record must have a unique handle—like SMITH1, SMITH2—to distinguish multiple people with the same name.
All records follow the same outline: people have name and job info, computers have name and IP address, and domains have contacts and nameservers. Every record gets a unique ID so searches can narrow down to just one match.
| Record Type | Purpose | Key Required Fields |
|---|---|---|
| Individual | People | Name, Organization, Handle |
| Host | Machines | Hostname, IP Address, Handle |
| Domain | Registered domains | Domain Name, Admin, Tech Contact, Handle |
§3Flexible and Powerful Search
Whois++ supports many search styles. A simple whois smith does an exact match on last name. Searches can narrow by first name with whois smith,j. Wildcards let users search whois smith* for all last names starting with Smith, or use whois smith?? to find Smith plus up to two letters. Fuzzy matching searches for names that sound like or are spelled similarly to the query. Exact handle lookup like whois !SMITH1 goes straight to one record.
For systems, queries can search by hostname (whois hamlet.ucdavis.edu), by IP address (whois 128.120.2.9, which returns a reverse lookup), or for domains using special keywords like whois domain ucdavis.edu. The server completes any query containing keywords and returns results; if no keywords are specified, the server infers the query type from context, and may automatically retry with a "begin" search if the first attempt finds no matches.
Search like you naturally would: exact names, partial names with wildcards, fuzzy matching for close spellings, or an exact ID to get one match. For machines and domains, use the hostname or IP or domain name and the server figures out what you want.
§4Context-Aware Responses and Help
Whois++ servers must return results with context and appropriate detail. When a query matches multiple records, the server returns a short-form entry for each. A single match gets the long-form with all available details. A query with zero matches triggers context-sensitive help explaining how to broaden the search (try beginning match, use wildcards, check spelling). When a search returns more than 50 matches, the server warns the user to narrow the search and offers the choice to re-specify or receive all results.
Queries yielding many results also teach the user about handles: explain that each record has a unique handle and searching for a handle will return just that record. Both clients and servers must provide help: a two-line minimal help with every response, detailed help on request, and special help handling for zero and many-result cases.
The server is smart about helping. No results? It tells you how to search better. Too many results? It shows you how to narrow down with handles. One result? You get the full details.
§5Room for Growth
Whois++ acknowledges that different sites may want to store and search other kinds of information beyond the three core record types. The RFC includes mechanisms for clients to discover what extended records exist and to query for fields not defined in the standard. Sites can extend the protocol while remaining compatible with standard queries, and clients can discover and use these extensions to maximize the usefulness of the service across heterogeneous networks.
While everyone agrees on basic record types, local offices can add their own special fields and record types. Clients can discover what extras are available and use them.