Referral Whois (RWhois) Mark Kosters Network Solutions Inc., InterNIC RS markk@internic.net Scott Williamson Network Solutions Inc., InterNIC RS scottw@internic.net I. Introduction Network entity data contained in the current InterNIC whois database is hierarchical. This lends itself to easy distribution if controlled and monitored. The core information must still be maintained at the InterNIC with additional information maintained closer to the user of the network entity. With the above facts RWhois resolves some of the problems addressed in the many forums discussing the need for delegated display of information in the Internet. It is not our intent to solve the White pages challenge. Location of non-hierarchical information is a much more complete challenge. However, RWhois as outlined below should work as an element of the larger solution to the non- hierarchical search for distributed information. This project has not been sponsored by any organization. To date the only support for this project is the use of hardware owned by our employers. II. The challenge Back in the arpanet days, the sri-nic established a centralized whois database that provided a host, network, and Email address information of anyone who was on the network. As time passed, the arpanet experiment has evolved into global network with countless people and hundreds of thousands of end systems passing information. Given the sheer size and effort needed to maintain a centralized database, an alternate decentralized approach to the display of this information must be designed. The sri-nic has been transitioned to what is now known as InterNIC Registration Services whose registry charter has been reduced to maintain information only on being the Internet Registry for IP networks, top-level domains, Autonomous System Numbers, and the points of contacts for each of these particular entities. Further, given the global scope of the Internet, the InterNIC in its role as Internet Registrar has delegated IP assignments to Regional Registries such as the RIPE NCC for Europe, the InterNIC for North America, and soon the APNIC for the Asian Pacific region. This has lead to a fragmentation of whois service to the Internet user. Several different solutions have been proposed and worked on by the various regional IR's. Two solutions have been worked on extensively the Shared Whois Project (SWIP) and X.500. The SWIP project has a common exchange format that can be parsed by the various IR's for input/output. Thus one can synchronize their databases with information obtained from the other IR's. This project is showing promise and is now operational. The InterNIC has also been involved in X.500 defining schemas, Directory information tree structures, etc. for the purpose of distributing information amongst the various IR X.500 DSA's. Unfortunately X.500's complexity, resource utilization, and lack of Internet support has made us search for an alternative solution. The information that the various IR's maintain is inherently hierarchical in nature. The InterNIC may not have the information, but will at least be able to point or "refer" the user closer to its goal. This has lead to development of a referral whois server and a referral whois client. The basic premise for this project has been to leave the basic function of the whois server and client making all of the extensions optional. The server must respond to the original whois client, currently included with many operating systems, and the RWhois client must interact with the original whois model servers. III. The Referral Whois Server The referral whois server maintains the traditional whois command set used on the current original InterNIC whois server plus an extended Boolean attribute/value command set. The server is built on a modified CNIDR freeWAIS search engine to provide extensible searching capabilities. A. Traditional Whois Query Command Set The referral whois server will behave closely to the original whois server in terms of display formats and restrictions: Display format Keywords: summary Give a short summary for the query on one to many hits (defaults on multiple hits). full Give the full record output one to many hits (defaults on one hit only). dump Display the record in a parsable format. # same as dump above. Data Restriction Format Keywords: ! Query on Handle only user Query on User records only* host Query on Host records only* domain Query on Domain records only* network Query on Network Records only* asn Query on Autonomous System Numbers Only* * These objects are defined in configuration files that are not hard-coded into the server. New Objects can be easily designed with no code change necessary in the server. B. Extended Whois Query Command Set Using the CNIDR freeWAIS search engine has allowed for additional commands such as Boolean queries and attribute=value query combinations. Additionally partial matches can be found by postfixing a "*" at the end of the search item. Example: last-name=williamson and first-name=scott C. Referral Whois Set and Status Command Set Commands that are specific to the referral whois server will start with a minus sign "-" on the fist column of the line and will be comprised of one command only per line. A few examples of these are: -load Reports the load on the server's host -limit <##> Change the max limit of responses -schema Display the schema for the ???? requested (no argument dumps all) -xfer Dump the objects found for the ??? requested (no argument dumps all) -badref Notifies the server of a bad reference* -recurref Notifies the server of a recursive reference* -refreq Notifies the server of a referral addition/modification request* *not done in this release D. Referral Whois Client Notifications Special notifications for actions on the clients will start with a percent sign "%" on the first column of the line. These directives will be sent to non-RWhois clients as well so that the user can act on the valuable information. The non-RWhois could be redirected toward the server with the desired information. The following are valid responses from the RWhois server to an RWhois client: %referral host:port This refers the query to another whois server (could be whois, RWhois, or whois++) %see-also host:port:query This brings additional information to this particular record. %error There is some sort of error on the server Examples: This record was received by directing the query "netsol.com" to slam.internic.net:3636 for which the following referral was received: %referral netman1.netsol.com:4343 This record was received by doing the query "198.41.0.0" to slam.internic.net:3636 which forwards the RWhois client to diis-dev and pmrd.merit.edu:43 for ASN and routing information: %see-also diis-dev.ddn.mil:3636:handle=asn1 %see-also pmrd.merit.edu:43:198.41.0.0 The critical component of the referral whois server is the ability to reduce the query to find a server that is "closer" to the data. The search algorithm of the server is the following: 1) accept a query, 2) find any local matches - display them 3) find any referrals templates - display them 4) if no local or referral hits, reduce the query and goto 3 Here is an example of the query ietf.cnri.reston.va.us : 1) query whois for ietf.cnri.reston.va.us 2) search rs.internic.net for information (no hits). 3) search referrals for ietf.cnri.reston.va.us (no hits). 4) search referrals for cnri.reston.va.us (no hits). 5) search referrals for reston.va.us (no hits). 6) search referrals for va.us (no hits). 7) search referrals for us (referral found) - referral to isi.edu. [currently on rs.internic.net:4343 for proof of concept]. IV. The Referral Whois Client Considering the basic premise for this project the RWhois client must operate in the default mode exactly as the current whois client. However, in the enhanced mode the RWhois client can do much more based on information received from the RWhois server. The client must be able to interact with the standard Whois, Whois++, and RWhois servers. RWhois Client model: Server <-------> Client START: <------ Connection ( record time to connection ) Wait up to 10 seconds for ------> "%RWhois" if "%RWhois" from server is not received assume that it is not an RWhois server goto QUERY: else if %RWhois is received from server <------- send "-RWhois -VX.X" --------> receive '%ok" COMMAND: if command for server <------- send and commands -------> receive server response if %ok received goto COMMAND: if %error received process error then goto COMMAND: else if no more commands for server goto QUERY: QUERY: --------> send query --------> Receive and display response PROCESS: if %referral received if first referral rebuild server list else add to server list if %see-also received insert server into current list if no directive (%) goto END: goto PROCESS: END: server will disconnect if more servers on Queue. and multi or referral mode active goto START: Every time the RWhois client receives a referral or see-also directive from the RWhois server it must compare the new host:port:query with those already executed. If the client discovers that it is repeating a query to the same server it must stop. The experimental RWhois client maintains a server tail and compares each new directive with the entire list. If a recursive act is about to occur the client will notify the user and exit. The original Whois client would open a TCP connection, send the query, and display the response. The RWhois client must be more robust to handle multiple server queries, servers that do not exist, and recursive referrals. All of these features have been incorporated into the experimental RWhois client. V. RWhois test server network: Slam.internic.net:3636 is currently acting as the root RWhois server. This is the only server without the final referral to the root. All other servers must refer to slam:3636 or to a server believed to have more information if the query can not be resolved. Currently the following RWhois servers have been loaded to test the RWhois concept. There are several intentional bad referral and see-alsos in place to test the error handling requirements of the client. Here is a sampling of our present test senario: Records on slam.internic.net:3636 (the root server): user: Jeff Odum Mark Kosters Peter Klosky Kathy McCollum Robert McCollum Stanley A. Borinski Scott Williamson network: 198.41.0.0 (has routing pointing to asn1 on diis-dev and 198.41.0.0 on prdb.merit.edu) host: NETMAN1.NETSOL.COM RS.INTERNIC.NET domain: NETSOL.COM routing: referral: Referral: diis-dev.ddn.mil:3636 IP-Network: 192.112.38 Referral: rs.internic.net:43 Domain: com Referral: netman1.netsol.com:4343 Domain: netsol.com IP-Network: 192.153.247.0 Referral: rs.internic.net:3636 Domain: looper.test Domain: us. Referral: slam.internic.net:43 Domain: slam.internic.net IP-Network: 198.41.0.20 Referral: nic.ddn.mil:43 Domain: mil IP-Network: 192.112.36 IP-Network: 26 Referral: whois.ripe.net:43 Domain: ripe.net. IP-Network: 193 IP-Network: 194 Scan-For-Users: TRUE -------------------------- Records on diis-dev.ddn.mil:3636 user: network: host: DIIS-DEV.DDN.MIL domain: routing: 1310 (handle = asn1) referral: -------------------------- Records on netman1.netsol.com:4343 user: Butch Corson (butchc@netsol.com) network: host: NETMAN1.NETSOL.COM domain: routing: referral: Referral(52): slam.internic.net:3636 Domain(53): looper.test -------------------------- Records on rs.internic.net:3636 user: network: host: domain: SANTA-CRUZ.CA.US routing: referral: Referral: netman1.netsol.com:4343 Domain: looper.test Several additions to ensure reliablity and direct search are being experimented with on the test network. The changes that prove useful will be incorporated in to the server/client. Some of the issues being reviewed are: server SOA reporting load/hops to server ( server sorting )