Re: Merging RRP and Whois

On Wed, 31 Jan 2001, Mark Kosters wrote:

> On Mon, Jan 29, 2001 at 05:12:24PM +0100, Shane Kerr wrote:
> > Not necessarily.  HTTP+HTML implements a distributed database with an
> > extremely simple client (until you decide to render the HTML, I
> > suppose) - not that it can't be done wrong (see "RWhois").
>
> I wounder if you could explain in a little more detail why RWhois
> was done wrong?

Well, I guess there's only two problems: the client and the server.  :)

<disclaimer>
These may have been fixed while I wasn't looking.
</disclaimer>

As I understand it, the client does not follow referrals.  This kind of
puts a damper on the whole Referral Whois.

Other issues involve the server software.

First, if you look at the rwhois mailing lists, you'll see a common
problem is people not reindexing the database files and having the
server give incorrect results.  While you can attribute this to human
error ("this sort of thing has happened before, Dave, and it has always
been attributable to human error"), the fact that it happens again and
again implies that the software should validate these files before
loading and giving bogus results.

The server software used to incorrectly track child processes, causing
the server to refuse connections after extended use (I patched this at
ARIN, did I ever send the patches?).

Unlike the Whois protocol, the RWhois connection is persistent (well, it
can be).  This means that cheap methods of preventing clients from
overloading the server (i.e. max connections per time) don't work.
What we saw at ARIN was that an abusive client could crush the server
(admittedly only a Sparc Ultra2 300 or something like that) when
attempting to mine the database.  The server needs to be restarted to
reload the access lists, right?

Plus, there's not any standard for what information should appear in an
RWhois database.  This means that a client has to be prepared for
basically ANYTHING.  At least the format of the output is specified.
Actually, the ability to dynamically query the schema used by a
particular server is nice, but without a "core" set of guaranteed
values, it doesn't actually buy you much (ever written a TIFF viewer? -
same problem).

Also, the root for the RWhois tree doesn't appear to be well-maintained:

>From http://www.rwhois.net/rwhois/prwhois.html

  Query Error

  A connection could not be made to the RWhois server running at
  root.rwhois.net:4321

$ ping root.rwhois.net
PING root.rwhois.net (216.168.227.19): 56 data bytes
bounced at 10.192.16.65: Access prohibited
bounced at 10.192.16.65: Access prohibited
bounced at 10.192.16.65: Access prohibited
no reply from root.rwhois.net
no reply from root.rwhois.net
bounced at 10.192.16.65: Access prohibited
bounced at 10.192.16.65: Access prohibited
^C

$ traceroute root.rwhois.net
traceroute to root.rwhois.net (216.168.227.19): 1-30 hops, 38 byte packets
 1  e10.overtoom.ripe.net (193.0.1.126), 2.13 ms, 2.79 ms, 1.76 ms
 2  Asd-nr02.NL.kpnqwest.net (134.222.249.81), 8.38 ms, 2.19 ms, 2.88 ms
<snip/>
19  sl-gw2-rly-4-0-0.sprintlink.net (144.232.14.46), 93.8 ms (ttl=240!), 94.4 ms (ttl=240!), 93.6 ms (ttl=240!)
20  sl-netsolut-2-0-0.sprintlink.net (144.232.184.78), 98.6 ms (ttl=239!), 102 ms (ttl=239!), 96.5 ms (ttl=239!)
21  10.192.16.65 (10.192.16.65), 95.4 ms (ttl=238!), 95.9 ms (ttl=238!), 95.5 ms (ttl=238!)
22  10.192.16.65 (10.192.16.65), 95.6 ms (ttl=238!) !U *, 96.2 ms (ttl=238!) !U

Hmm...wasn't there a discussion about exposing private IP addresses on
NANOG recently?  Anyway, even when the root WAS working, it didn't
actually refer IP queries to ARIN, which would have been the logical
thing to do.  At least, for the "referral" in RWhois to mean anything.

Then there's the issue of acceptance and use in the wider community.
Maintenance of RWhois software always seemed sporadic to me - but is
that really unfair, considering the only ones who really need and/or use
the protocol and software are ARIN and some of ARIN's larger ISP
members.

Admittedly, most of these items have nothing at all to do with the
RWhois protocol itself.  But with only a single implementation and a
user base I can count on my toes, it's hard to separate the
implementation problems from the protocol problems.

Perhaps a modern, threaded RWhois server using an SQL back-end, with a
client dropped into popular Linux distributions and on a web page would
make my concerns seem silly.  But would something like that actually
allow Randy Bush to have a globally unique nic-handle?  (That is why
this list is here, right?)

--
Shane