On 08/03/2017 07:11, Tor Arntsen via cctalk wrote:
I tested 'whois -h whois.denic.de uni-stuttgart.de'
from Oslo, London, Tokyo, and it seems to work fine - I got all
expected whois output. Tested yesterday too.
Sounds like it may be the whois client instead - what OS are you guys
using, and which 'whois' version?
This is rather intriguing.
No, not the fault of the whois client. I repeated yesterday's tests and
a few more because I'd closed the terminal windows I used yesterday, and
also to try to eliminate any temporary aberrations. I did wonder if
whois.denic.de is actually a load-balanced server farm and I just
happened to be hitting a broken member of the farm and some of you guys
weren't. But that does not seem to be the case.
FWIW I was using linux whois-4.5.17 originally from www.linux.it, based
on the RIPE whois client, compiled locally from source under IRIX. It's
part of various Linux distributions and it works on hundreds of other
whois servers; I use it frequently (part of my job) and never had a
problem before. That's important because when I eventually found the
"DENIC Public-Whois Documentation" I noted that it recommends the RIPE
whois client. So just to be thorough I downloaded and compiled the
latest RIPE whois on an Ubuntu Linux system and get a similar result
with a standard query. I also downloaded and tested Microsoft's whois
for Windows and got the same broken result, same "Error: 55000000007
Request not clearly specified" message.
More importantly, I tested connecting directly using telnet to port 43,
exactly as specified in RFCs 3912 and 954. Here it is again, showing
the output of the (required) HELP command:
$ telnet whois.denic.de 43
Trying 81.91.170.6...
Connected to whois.denic.de.
Escape character is '^]'.
?
% SYNTAX: whois [-r] [-T types] [-C charset] key
%
% where our server understands the following options:
%
% -r turn off recursive lookups (default: on)
% -T ace ACE input for domain lookup
% -T domain (dn) only look for objects of type domain
% -T status (st) only look for domain status
% -C charset specify character set for the input/output
% Available charsets: US-ASCII, ISO-8859-1,
UTF-8 (default)
%
% NOTE: Read the detailed documentation for valid argument combinations.
There are two special queries
%
% [?, HELP, help] displays this text
% alive@whois returns 'alive' if whois server runs properly
%
% Detailed documentation under https://www.denic.de/webwhois/?lang=en
%
Connection closed by foreign host.
$
Notice that - unlike normal whois servers - this one apparently requires
some other stuff, possibly including the text "whois", as part of the
query. That may explain why a normal whois client gets an error, because
the standard way to make a query is simply to send the string to query
(eg, "uni-stuttgart.de" or "dunnington.cx"):
$ whois -h whois.denic.de uni-stuttgart.de
% Error: 55000000007 Request not clearly specified
OK, so back to telnet, and try it with the syntax DENIC claims to want:
$ telnet whois.denic.de 43
Trying 81.91.170.6...
Connected to whois.denic.de.
Escape character is '^]'.
-T dn uni-stuttgart.de
[lots of output]
$
Aha! That works. But I can't replicate it with most whois clients.
However, it /does/ work with the jwhois client, which some linux systems
have, and which seems to have some special method to deal with DENIC. It
doesn't work with the RIPE client - despite DENIC recommending that -
unless you construct a rather odd-looking query by adding at least "--T dn":
gleek:whois3-3.2.2 $ ./whois -h whois.denic.de uni-stuttgart.de Domain:
uni-stuttgart.de
Status: connect
gleek:whois3-3.2.2 $
gleek:whois3-3.2.2 $ ./whois -h whois.denic.de --T dn uni-stuttgart.de
[lots of output]
gleek:whois3-3.2.2 $
So IMHO it's broken; it doesn't respond to a standard query format as
defined in the RFCs, but only to a modified query string, one which some
perfectly good clients can't correctly format.
Just for comparison, I also tested the RIPE client, Microsoft client,
and telnet with some .co.uk, .ac.uk, .com, .cn and .cx domains using
several whois servers, and found a standard query worked every time.
Obviously that's not exhaustive but so far whois.denic.de is the only
one I've found with this odd behaviour.
--
Pete
Pete Turnbull
