RFC 1834

Whois and Network Information Lookup Service, Whois++

πŸ“… published August 1995, from ietf

RFC 1834: Whois and Network Information Lookup Service πŸŽ€

Okay bestie, let's get into RFC 1834 πŸ’…. It's titled Whois and Network Information Lookup Service, which is also called Whois++ πŸ’œ. It came out of the Network Working Group and was written by J. Gargano and K. Weiss from the University of California, Davis πŸŽ“. The date is August 1995 πŸ“…. It's categorized as Informational, so it's not an Internet standard. The header doesn't list anything it obsoletes or updates, so there's no drama there 🫢.


Status of this Memo πŸ“œ

This memo is basically info for the Internet community 🌸. It doesn't specify an Internet standard of any kind, and distribution of it is unlimited πŸ¦‹.

I. Introduction ✨

So the OG NICNAME/WHOIS [HARR85] service is a TCP transaction based query/response server πŸ–₯️. It runs on a few specific central machines and gives the whole internet a directory service 🌐. The Network Information Center (NIC) keeps the central NICNAME database and server (defined in RFC 954), so you can look up individuals, network organizations, key host machines, and other info you might want πŸ”.

Its usefulness led to other distributed directory information servers and information retrieval tools, and it's anticipated that more will be created πŸš€. Lots of sites now run their own local directory servers with info about individuals, departments, and services at that specific site 🧚.

These directory servers are typically network accessible 🌐. But local development has been doing its own thing, so there are wide variations in the type of data stored, the access methods, the search schemes, and the user interfaces πŸ™ˆ. That's the mess the Whois and Network Information Lookup Service Working Group (WNILS) wants to clean up 🧹. Their goal is to expand and define the standard for WHOIS types of services, resolve issues from those variations in access, and provide a consistent and predictable service across the network 🫢. This memo describes new features for WHOIS to meet those goals πŸ’–.

II. Architecture πŸ—οΈ

The WHOIS service should be provided in a client/server model πŸ’–. There are no restrictions on the design of the client, as long as it can pass queries to the server in the proper format and capture the server's response in some useful format 🧠. Existing WHOIS specs want clients to display responses in human-readable form, but this more general proposal doesn't force that one πŸ™Œ.

This paper knows there are tons of distributed information servers out there, and it expects even more 🌸. To help users find 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 is the face of the WHOIS system πŸ’…. It gives the user the interface, generates the query, and displays the response πŸ‘€. The client is responsible for paging long output from the server, and all clients must provide this service πŸ“–. The server won't add any special characters or try to control output to a screen πŸ™…β€β™€οΈ.

Special search criteria may be specified with keywords or special characters, some of which are defined in RFC 954 πŸ”. Clients should be designed so that support for quoted strings is unnecessary πŸŽ€.

IV. Server Design and Behavior 🧚

The server should return the same information for a given query, consistently, no matter what client software or hardware the query came from πŸ’…. Queries should be evaluated case-insensitively, and spaces should not be considered in searches πŸ™ˆ. So 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 πŸ§β€β™€οΈ

Here's the lineup for individual records. Check which fields are required and which are optional πŸ“‹.

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 πŸ–₯️

Next up are 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
                        (i.e. anonymous FTP)

Domain records 🌍

And last but not least, 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


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 πŸ”Ž

Every record in the server database must be given a unique handle so you can target specific records for display 🎯. Say you've got three people: A. La Russo, B. LaRusso, and C. Larusso. A search for "LA RUSSO" would return all three as matches πŸ‘―. But each record gets its own unique handle, LARUSSO1, LARUSSO2, and LARUSSO3, and searching for any one of those handles gives you 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 completes that specific query and returns the results, even if there are 0 matches 🫠. If no keywords are specified, the server interprets 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 πŸ“„. And a query yielding no matches should return context-sensitive help on expanding the search criteria πŸ†˜.

On-line Help πŸŽ€

okay so 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 give the user instructions for getting more detailed help screens πŸ“– this is the bare minimum, bestie ✨

extra help should show up in special situations too 🧚. the server should recognize queries that return zero matches and give 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 sent back 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 be detailed enough that the user can understand and access all the features of WHOIS service main character energy, literally πŸ‘‘


V. Extensibility ✨

this RFC defines a limited set of data records and fields for reliable whois queries πŸ’– there are mechanisms that let whois clients 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. so yes, we love a service that can grow 🫢

VI. References πŸ“Ž

[Harr85] Harrenstein, K., Stahl, M., and E. Feinler, E., "NICNAME/WHOIS", RFC 954, SRI, October 1985.

VII. Security Considerations πŸ’€

okay, serious moment πŸ™ˆ security issues are not discussed in this memo. not a single word. so keep that in mind when you're building anything on top of it πŸ”₯

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 πŸ’œ

πŸ“¦ where this page comes from