How to Interact with a Whois++ Mesh
How a client walks a mesh of Whois++ directory servers without going round in circles.
Faltstrom, P., Schoultz, R., and C. Weider, "How to Interact with a Whois++ Mesh", RFC 1914, DOI 10.17487/RFC1914, February 1996, <https://www.rfc-editor.org/info/rfc1914>.
@misc{rfc1914,
series = {Request for Comments},
number = 1914,
howpublished = {RFC 1914},
publisher = {RFC Editor},
doi = {10.17487/RFC1914},
url = {https://www.rfc-editor.org/info/rfc1914},
author = {P. Faltstrom and R. Schoultz and C. Weider},
title = {{How to Interact with a Whois++ Mesh}},
pagetotal = 10,
year = 1996,
month = feb,
} RFC text
Contents
Network Working Group P. Faltstrom
Request for Comments: 1914 Bunyip Information Systems, Inc.
Category: Standards Track R. Schoultz
KTHNOC
C. Weider
Bunyip Information Systems, Inc.
February 1996
How to Interact with a Whois++ Mesh
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
1. Overview
In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is
done by the client, since each server 'refers' the client to the next
appropriate server(s). The protocol is simple. The client opens a
connection to a server, sends a query, receives a reply, closes the
connection, and after parsing the response the client decides which
server to contact next, if necessary.
So, the client needs to have an algorithm to follow when it interacts
with the Whois++ mesh so that referral loops can be detected, cost is
minimised, and appropriate servers are rapidly and effectively
contacted.
2. Basic functionality
Each Whois++ client should be configured to automatically send
queries to a specific Whois++ server. The deault Whois++ server can
vary depending on which template is desired, and the location of the
client with respect to the WHOIS++ index mesh, but as a rule the
server should be as local as possible.
A
/ \
B C
/ \ \
Z -----> D E F
/ \
G H
Fig 1: The client Z is configured to first query server D
After getting responses from a server, the client can act in several
ways. If the number of hits is greater than zero, the response is
just presented to the user. If the client gets one or many servers-
to-ask answers, the client should be able to automatically resolve
these pointers, i.e. query these servers in turn.
A
/ \
B C
/ \ \
Z <----- D E F
\ / \
--> G H
Fig 2: The client Z gets a "servers-to-ask G" response from D and
therefore may automatically queries server G.
3. How to navigate in the mesh
A client can use several different strategies when traversing or
navigating around in the mesh. The automatic way of doing this is to
just "expand the search" (described in 3.1) and a second method is to
use the "Directory of Servers" (described in 3.2).
3.1. Expansion of searches
If the number of hits is zero, or if the user in some way wants to
expand the search, it is recommended for the client to issue a
'polled-by' and 'polled-for' query to the server. The client can then
repeat the original query to the new servers indicated.
A
/ \
/-----> B C
/ / \ \
Z <----- D E F
/ \
G H
Fig 3: The client Z gets a "polled-by B" response from D and therefore
queries server B.
The client must always keep track of which servers it has queried
because it must itself detect loops in the mesh by not querying the
same server more than once.
A
/ \
/- B C
/ / \ \
Z <---/ D E F
/ \
G H
Fig 4: The client Z gets a "servers-to-ask D" response from B but Z
does not query D because the server D has already been queried.
So, the default expansion of a query by a client causes increasingly
more comprenhensive index servers to be queried; the forward
knowledge contained in the index server mesh allows rapid pruning of
these larger trees.
All loop detection and elimination is done in the client, rather than
in the server mesh. This decision was made because loop detection and
elimination are quite difficult to build into the mesh if we are to
continue to allow each server to participate in multiple hierarchies
within the mesh.
3.1.1. Optimising the mesh
If organization A tends to use organization B's WHOIS++ server
frequently, for example if A is cooperating in a project with B, A
may wish to make B's server locally available by creating a local
index server which retrieves the centroid for both organizations.
When A's client then expands a query which is looking for someone at
B, the client can much more rapidly resolve the query, as it does not
have to find the top level servers for the tree to which A and B both
belong.
A
/ \
B C
/ \ \
Z D --> F
/ \
G H
Fig 5: The server B gets a centroid from server F
A
/ \
B C
/ \ \
Z <----> D --- F
/ \
G H
Fig 6: The client queries server D, gets zero hits back, expands the
search and gets a "polled-by B" response back.
A
/ \
/--> B C
/ / \ \
Z <-/ D --- F
/ \
G H
Fig 7: The client Z queries server B and gets "servers-to-ask F"
response back.
A
/ \
B C
/ \ \
D --- F <-----> Z
/ \
G H
Fig 8: The client Z queries server F and gets the answer.
The example given in Fig 5-8 shows that the algorithm works even
though the Whois++ mesh is not a tree. There are many reasons why a
given index server mesh might be 'short-circuited'. For example, in
the case of a multinational company, the Swedish branch of Acme Inc.,
is polled both by the national server in Sweden and the headquarters
server in the USA. By querying the Swedish server, one finds all
persons working at the Swedish branch of Acme Inc., but by querying
the Acme Inc. server in the USA, you will find all employees in the
company, including those in Sweden.
Note that the location of a server does not implicitly narrow the
search, i.e. you have to specify all information when sending a query
to a server. In the example above, one can see that by just querying
a server for companies in the USA, you will not implicitly only get
hits from records in the states, because the Acme Inc. server in the
states has polled a server in Sweden. So, in this case you have to
explicitly include "country=USA" in the query if you are only
interested in those records.
Although the WHOIS++ index service has been designed to make searches
at any location in the index mesh quite effective and efficient,
blindly expanding the query can incur an exponentially growing cost
in resources, and, as charging for responses is implemented in parts
of the WHOIS++ index service mesh, growing cost, automatic expansion
is not recommended. More sophisticated clients should also be
configurable to "cut off" some servers from a search, i.e. a
blacklist of servers. This might be needed when searching for records
and one server might have a very high cost (in dollars) so one might
want to explicitly forbid the client to send queries to that server.
3.1.2. The algorithm used by the client
By following this algorithm a client finds all records in a mesh
which the first Whois++ server queried belongs to.
The algorithm for the client follows:
Query := data to search for;
QueriedServers := {};
AnswerList := {};
OriginalServers := { known servers to this client };
while OriginalServers is not empty do:
ServerList = OriginalServers;
while ServerList is not empty do:
Server := ServerList[1];
if Server is not in QueriedServers then do:
send Query to Server;
Answer := answer from Server;
append ServersToAsk to ServerList;
remove Server from ServerList;
append Answers to AnswerList;
end;
done;
if query should be expanded then do:
ServerList := OriginalServers;
OriginalServers := {};
while ServerList is not empty do:
Server := ServerList[1];
send Polled-For-Query to Server;
Answer := answer from Server;
append Answer to OriginalServers;
remove Server from ServerList;
end;
done;
done;
display AnswerList to user;
3.2. The Directory of Servers
A second way of finding the correct server to query is to use a
separate service we call the Directory of Servers. The Directory of
Servers is a special Whois++ server which polls every Whois++ server
for information about common information among the records on that
perticular server.
3.2.1. How should a client use the Directory of Servers?
A client that want to very quickly find what servers serves USER
templates in Sweden, should do it this way:
1) The hostname and portnumber of the directory of Servers have
to be preconfigured in the current version of the protocol.
2) Query the Directory of Servers for serverhandle records for
country sweden. This gives information of all these servers.
By presenting this information to the user the user should be
able to start the search at some closer server.
Note that we at this moment doesn't think this should be an autmatic
process in the client. The Directory of Servers should be used for
giving the user information about what Whois++ servers that exists.
In the future a technique might have developed that makes it possible
for a client to do this selection automatically depending on the
query the user issues.
3.2.2. What does the serverhandle record look like?
The attributes that must be in all serverhandle records are:
Server-Handle: The handle for this server.
Host-Name: The (current) hostname of this server.
Host-Port: The (current) portnumber for this server.
Part from that information, the record can include other attributes
like:
Admin-Name: Patrik Faltstrom
Admin-Email: paf@bunyip.com
Admin-Phone: +1-514-875-8611
Organization-Name: Bunyip Information Systems Inc.
Description: USER information
Menu-Item: World (Bunyip Information Systems inc)
City: Montreal
State: Quebec
Country: Canada
:
:
(Other attributes that can identify all records on this server, for
example domainname)
The information in the Navigation record is intended to be presented
to a user.
3.2.3. Example
An example of how an interaction with the Directory of Servers is
done follows. The characters '<' and '>' displays if it is the client
('<') or responding server ('>') which is responsible for the output:
> % 220-This is services.bunyip.com running Bunyip-Whois++: DIGGER 1.0.5
> % 220 Ready to go!
< template=serverhandle and bunyip
> % 200 Search is executing
> # FULL SERVERHANDLE BUNYIPCOM01 BUNYIPCOM01
> SERVER-HANDLE: BUNYIPCOM01
> HOST-NAME: services.bunyip.com
> HOST-PORT: 63
> ADMIN-NAME: Patrik Faltstrom
> ADMIN-EMAIL: paf@bunyip.com
> ORGANIZATION-NAME: Bunyip Information Systems Inc.
> DESCRIPTION: USER information
> DESCRIPTION: Directory of Servers
> DESCRIPTION: Toplevel Index server in the world
> MENU-ITEM: World (Bunyip Information Systems inc)
> CITY: Montreal
> COUNTRY: Canada
> # END
>
> # FULL SERVERHANDLE BUNYIPCOM01 BUNYIPCOM02
> SERVER-HANDLE: BUNYIPCOM02
> HOST-NAME: services.bunyip.com
> HOST-PORT: 7778
> ADMIN-NAME: Patrik Faltstrom
> ADMIN-EMAIL: paf@bunyip.com
> ORGANIZATION-NAME: Bunyip Information Systems Inc.
> DESCRIPTION: USER information
> MENU-ITEM: Bunyip Information Systems
> CITY: Montreal
> COUNTRY: Canada
> # END
>
> % 226 Transaction complete
> % 203 Bye, bye
4. Caching
A client can cache all information it gets from a server for some
time. For example records, IP-addresses of Whois++ servers, the
Directory of Services server etc.
A client can itself choose for how long it should cache the
information.
The IP-address of the Directory of Services server might not change
for a day or two, and neither might any other information.
4.1. Caching a Whois++ servers hostname
An example of cached information that might change is the chached
hostname, IP-address and portnumber which a client gets back in a
servers-to-ask response. That information is cached in the server
since the last poll, which might occurred several weeks ago.
Therefore, when such a connection fails, the client should fall back
to use the serverhandle insted, which means that it contacts the
Directory of Services server and queries for a server with that
serverhandle. By doing this, the client should always get the last
known hostname.
An algorithm for this might be:
response := servers-to-ask response from server A
IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber
if connection fails {
connect to Directory of Services server
query for host with serverhandle response.serverhandle
response := response from Directory of Services server
IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber
if connection fails {
exit with error message
}
}
Query this new server
5. Security Considerations
Security considerations when using the Whois++ protocol is described
in [Deutsch94].
A client should be able to have a "blacklist" of servers it should
not query, because it might happen that fake Whois++ servers is put
up on the net. When such a fake Whois++ servers is found, a user
should be able to configure it's client to never query this server.
Note that a client should be careful when expanding a query by either
using normal expansion or using the directory of servers. A query
might take a long time, so a user should be able to quit in the
middle of such a transaction. This is though more a question of user
interaction than a plain security issue.
6. References
[Deutsch94] Deutsch P., Schoultz R., Faltstrom P., and C. Weider,
"Architecture of the Whois++ service", RFC 1835,
August 1995.
[Weider94] Weider C., Fullton J., and S. Spero, "Architecture of
the WHOIS++ Index Service", RFC 1913, February 1996.
7. Authors' Addresses
Patrik Faltstrom
BUNYIP INFORMATION SYSTEMS, inc
310 St Catherine St West, Suite 300
Montreal, Quebec
CANADA H2X 2A1
EMail: paf@bunyip.com
Rickard Schoultz
KTHNOC, SUNET/NORDUnet/Ebone Operations Centre
S-100 44 STOCKHOLM
SWEDEN
EMail: schoultz@sunet.se
Chris Weider
BUNYIP INFORMATION SYSTEMS, inc
310 St Catherine St West, Suite 300
Montreal, Quebec
CANADA H2X 2A1
EMail: clw@bunyip.com
ISO Plain Language
On this page
§1Overview and Basic Exchange
In the Whois++ architecture, mesh traversal is done by the client, because each server refers the client to the next appropriate server or servers. The exchange itself is simple: the client opens a connection to a server, sends a query, receives a reply, closes the connection, and then decides which server to contact next, if any.
Because the client makes every step of the decision, it needs a written algorithm. The RFC states three goals for that algorithm: referral loops must be detected, cost must be minimised, and the appropriate servers must be contacted rapidly and effectively.
Each client is configured to send queries automatically to one specific Whois++ server. That default server can vary with the template wanted and with the client's place in the index mesh, but the rule is that it should be as local as possible. After a reply arrives, the client has two things it can do. If the number of hits is greater than zero, the response is presented to the user. If the client receives one or many servers-to-ask answers, it should be able to resolve these pointers automatically, which means querying those servers in turn.
Whois++ keeps one directory spread across many servers. Each server tells the client which other servers to try, so the client, not the servers, decides where to go next. RFC 1914 sets out the rules the client follows so it avoids going round in circles and keeps the search affordable.
- Server A Top of the index mesh in the RFC's Figure 1
- Server B
- Server D The first server client Z queries
- Server G
- Server H
- Server E
- Server D The first server client Z queries
- Server C
- Server F Linked to D in the later example, so the mesh is not a tree
- Server B
§3.1Expanding a Search
When a query returns no hits, or when the user asks to widen the search, the client should issue a polled-by and a polled-for query to the server it is talking to. The reply names other servers in the mesh, and the client repeats the original query to those servers.
The client must always keep track of which servers it has queried, because it has to detect loops itself by never querying the same server more than once. The RFC puts loop detection in the client rather than in the servers, because it is hard to build into a mesh where each server may take part in several hierarchies at once. Because expansion reaches larger and more comprehensive index servers, the forward knowledge held in the mesh lets the client prune those larger trees quickly.
Blind expansion, however, grows the cost of the search exponentially, and some parts of the mesh charge for responses, so the RFC does not recommend automatic expansion. More sophisticated clients can hold a blacklist of servers to cut off. A server's location does not narrow the search either: a query for companies in the USA does not return only records in US states when the USA server has polled a server in Sweden, so the query has to say country=USA explicitly.
The RFC also describes how an organisation can shorten the path to a partner's records. If organisation A often uses organisation B's server, A can create a local index server that holds the centroid for both organisations, so that a client expanding a search for someone at B resolves the query without first finding the top-level servers of the tree that A and B share.
When the first server has no answer, the client asks that server which other servers hold records of the same kind, then repeats the original query to each of them. The client remembers what it has already asked so it never asks the same server twice. The RFC warns that widening a search this way can get expensive, so a client should be able to stop and to block servers it does not want to contact.
- QUERYThe client asks for the record it wants.
- REPLY: 0 HITSServer D holds no matching record.
- polled-by / polled-forThe client expands the search by asking D which other servers it knows.
- REPLY: polled-by BServer D names server B.
- QUERYThe client repeats the original query at B.
- REPLY: servers-to-ask FServer B names server F.
- QUERYThe client repeats the original query at F.
- REPLY: THE ANSWERServer F holds the record.
§3.1.2The Client Algorithm
The RFC gives the algorithm as a list of steps over four working variables: Query, the data to search for; QueriedServers, the servers already contacted; AnswerList, the answers gathered so far; and OriginalServers, the servers known to the client.
The outer loop runs while there are servers to work through. The inner loop takes the first server on the list, and if that server is not in QueriedServers, sends it the query, adds the servers it refers to as servers-to-ask, and appends the answers to AnswerList. When the list empties and the query should be expanded, the client sends a polled-for query to each server it has contacted and puts the replies into a fresh set of original servers for the next pass. At the end it displays AnswerList to the user.
Following this algorithm finds all the records in the mesh that the first Whois++ server queried belongs to. The worked example in the RFC shows that it still works when the mesh is not a tree, because a server such as the Swedish branch of a multinational company can be polled both by the national server in Sweden and by the head-office server in the United States.
The RFC lists the client's steps in order. It keeps a list of servers it has asked, a list of servers it still has to ask, and a list of answers collected so far. It works through the list, skips any server already asked, and after each pass asks every contacted server which other servers it knows about. When nothing is left, it shows the collected answers.
Query := data to search for;
QueriedServers := {};
AnswerList := {};
OriginalServers := { known servers to this client };
while OriginalServers is not empty do:
ServerList = OriginalServers;
while ServerList is not empty do:
Server := ServerList[1];
if Server is not in QueriedServers then do:
send Query to Server;
Answer := answer from Server;
append ServersToAsk to ServerList;
remove Server from ServerList;
append Answers to AnswerList;
end;
done;
if query should be expanded then do:
ServerList := OriginalServers;
OriginalServers := {};
while ServerList is not empty do:
Server := ServerList[1];
send Polled-For-Query to Server;
Answer := answer from Server;
append Answer to OriginalServers;
remove Server from ServerList;
done;
end;
done;
display AnswerList to user;§3.2The Directory of Servers
The second way to find the right server is a separate service, the Directory of Servers. It is a special Whois++ server that polls every other Whois++ server for information about the records that server holds.
The client uses it in two steps. The hostname and port number of the Directory of Servers have to be preconfigured in this version of the protocol. The client then queries it for serverhandle records, for example for country sweden, which returns information on all the servers that serve that template and country. Presenting that list to the user lets the search start at a closer server.
Every serverhandle record must carry the server's Server-Handle, its current Host-Name and its current Host-Port. A record may also carry contact and descriptive attributes such as Admin-Name, Admin-Email, Admin-Phone, Organization-Name, Description, Menu-Item, City, State and Country, plus any other attribute that identifies the records on that server. The RFC says this information is meant to be shown to a user, and it does not think the selection should be automatic in the client. A future technique might make the choice automatic, depending on the query the user issues.
One special server keeps a list of the other servers and what each one holds. A client asks it which servers deal with a particular template and country, and shows that list so the user can begin closer to the answer. The RFC says this choice should stay with the user for now.
§4Caching and Cost Control
A client can cache everything it gets from a server, for example records, the IP addresses of Whois++ servers and the address of the Directory of Servers, and it chooses for how long to hold each item. The IP address of the Directory of Servers might not change for a day or two, and neither might other information.
The hostname, IP address and port number returned in a servers-to-ask reply are the values cached at the server's last poll, which might have been several weeks earlier. When such a connection fails, the client should fall back on the server handle: it contacts the Directory of Servers, asks for the server with that handle, and gets the last known hostname before retrying.
The client can keep the records, addresses and server details it has already received instead of asking again. Because a referral can name a hostname that is weeks old, a failed connection sends the client back to the Directory of Servers, which supplies the current hostname for that server.
§5Security Considerations
The RFC refers the reader to the Whois++ architecture document for the security considerations of the protocol itself. What it adds here is about the client. A client should be able to hold a blacklist of servers it must not query, because fake Whois++ servers can be put up on the network; once such a server is found, the user should be able to configure the client never to query it.
The RFC also asks the client to be careful when expanding a query, whether by normal expansion or through the Directory of Servers. A query can take a long time, so the user should be able to quit in the middle of such a transaction. The RFC describes this as a question of user interaction more than a plain security issue.
The RFC leaves the security of the service to another document and concentrates on what the client must be able to do. It must be able to block a server that turns out to be fake, and it must be able to abandon a long-running search at the user's request.