Trading SWIP for rWHOIS - final steps?

Kris Deugau kdeugau at vianet.ca
Thu Aug 3 13:38:37 EDT 2006


I'm hoping to finalize the configuration for our rWHOIS server, and 
clear out any unnecessary/old/outdated SWIP data still lurking in ARIN's 
WHOIS database.

However, it's not completely clear to me what information is required 
where in order for various services and lookups to behave properly while 
keeping use of SWIP limited to /24 in-addr.arpa delegations.  (I'd like 
to get rid of that, too, but I don't think that's possible until we grow 
big enough to get a /16.)

I know that SWIP feeds ARIN's WHOIS database, and that rWHOIS is in 
theory a complete replacement for SWIP.  However, lookups for data 
supposedly provided by rWHOIS don't seem to show up in a consistent manner.

Right now, we have a /18 that's full of old and outdated SWIP data.

We have an rWHOIS server that's been announcing our current netblock 
reassignments for about a year, and which we submitted to ARIN in the 
spring (IIRC).

We have other netblocks that I'm not worried about at the moment because 
they're all bulk residential DSL/dialup/cable, so any mislabelling is 
minimal.

Within than /18, we have at least one /24 which currently has 
in-addr.arpa lookups delegated to the customer.  We also have a handful 
of smaller blocks reassigned to customers trying to get digital 
certificates of some kind - and the cert issuers are relying on and/or 
crosschecking with WHOIS data.  (How/where those lookups are done is 
something I haven't been able to find out.)

It looks like the following two general steps will produce the best 
possible results:

===
-> Remove all SWIP records except the /24(s) that include in-addr.arpa 
delegation

(Alternate:   Remove all but /24 and "must-be-SWIP-reassigned for 
digital certs" blocks.  This is safer but somewhat more complex - both 
now and for the long term.)

-> Add a comment in the ARIN data for the /18 noting that lookups should 
use rwhois for complete, current data on reassignment details.  Just in 
case someone doing a lookup misses the ReferralServer field.
===

WHOIS clients bright enough to follow referrals should get something
resembling correct data anyway.  (jwhois and whois from RHEL4 and its 
clones appear to follow referrals;  the same programs on RHEL3&clones 
and Debian Sarge do not appear to follow referrals.)

-kgd


More information about the Rwhois mailing list