GeekTools update Part 1 - whois-servers.net

Mailman List Mirror (Read Only)
1

Based on suggestions, we've now added a new set of nameservers which
will serve up data on known whois servers.

Requests in the form:

dig xxx.whois-servers.net
where xxx = tld (de, jp, com, ch, int, etcetera)
will return a record with the correct CNAME and dns values.

dig xxx.whois-servers.net any
will return additional TXT records with the 'common' name for the TLD,
for logic checking (Germany, Japan, Switzerland, International,
etcetera).

Obviously these answers will only be valid for the whois servers we are
aware of.

nslookup xxx.whois-servers.net
will return the valid ip address and aliases, of course.

Additionally, zone transfers (axfr) may be made for whois-servers.net if
you prefer to proxy this data internally. I suggest you do this at least
once to see which tld's we know about.

I will also post the latest updates and features to the
whois.geektools.com proxy shortly. These include:

- AS numbers via APNIC, RIPE, and ARIN. Queries are routed to the
  proper server.

- ARIN, RIPE, and APNIC "handle" and netblock lookups

- RADB queries

- Queries can be forced to specific NIC servers if needed while still
  using the proxy.

- IP block lookups using the correct registry.

- Self-contained - no external programs (unix whois or other lookup
  utility) required.

- "Smart" whois server handling for those servers that tend to spew
  output in strange forms.

The same features will also appear in the web-based whois tool at
www.geektools.com.

Finally, as usual, please send updates, feature requests and comments to
complaints@centergate.com

Rodney Joffe
CenterGate Research Group
www.centergate.com
www.geektools.com

2

[ On Sunday, April 25, 1999 at 22:24:41 (-0700), Rodney Joffe wrote: ]

Subject: GeekTools update Part 1 - whois-servers.net

Based on suggestions, we've now added a new set of nameservers which
will serve up data on known whois servers.

Cool! I was wondering when someone would do this.

You're seemingly missing a few TLDs that I've had listed in my awhois
script for some time though (some are just additional pointers to
whois.ripe.net, but they seemed to work last time I tested them). Have
a peek at (which I updated today to fall back on your list!):

  ftp://ftp.planix.com/pub/Planix/awhois.sh

You should probably have mentioned the obvious too -- i.e. how to use
your list with a simple whois client:

  whois -h TLD.whois-servers.net QUERY-STRING

dig xxx.whois-servers.net any
will return additional TXT records with the 'common' name for the TLD,
for logic checking (Germany, Japan, Switzerland, International,
etcetera).

Ah, that's not going to work very well for most folks. It's illegal to
have any other records with CNAME records.

My own tests show that host(1) [Version 980903], and probably other
tools, get extremely confused with this -- it won't return just the TXT
RR, even if asked for explicitly. (Actually I'm surprised host doesn't
flag it as illegal right away, but perhaps the problem's with the server
at your end, not with host.) I'm surprised you even got your BIND-8.1.1
and BIND-8.1.2 named's to load that zone -- I thought they would reject
zones with illegal data. I would agree that TXT RRs are much less
confusing when seen with CNAMEs than most any other RR would be, but I
don't really see any way to work around the rules.

It would be far better to split off a sub-zone for additional
information, such as {TLD}.info.whois-servers.net. You could even split
the CNAMEs into their own zone {TLD}.cname.whois-servers.net, but that
defeats the convenience a bit for those using it by hand I suppose. It
does have the advantage of forever avoiding any possible namespace
collision between the sub-zone and a potential TLD.

- "Smart" whois server handling for those servers that tend to spew
  output in strange forms.

Personally I like the rwhois output format best -- it's even more
machine-friendly than RIPE's format. :wink: