Re: usr/bin/whois: Query terms are ambiguous
Hi Markus, On 07.01.20 at 21:19, Markus Lude wrote: > The server on the other hand could handle different record types, for > example "n ..." for network address space, but there are more. > If the record type is missing the server assumes (in this case) the > record type is n and notifies you of this assumption. > So it may be the other way around, "n " may be missing here in the > query to the ARIN whois server. Okay, didn't know that at this time. Currently I know three query formats: whois on Linux: -V Md5.2 62.46.172.92 \r\n whois (sysinternals.com - Microsoft) on Windows -> This query doesn't like NIC.AT (invalid request): 62-46-172-92.ADSL.HIGHWAY.TELEKOM.AT\r\n whois on OpenBSD: 62.46.172.92\r\n > Compare the output of the following two: > > telnet whois.arin.net 43 > 62.46.172.92 > > which is also what you get with "whois 62.46.172.92" > and this: > > telnet whois.arin.net 43 > n 62.46.172.92 > > and if you want to see the mentioned help above: > > telnet whois.arin.net 43 > ? > > whois.apnic.net and whois.ripe.net understand "help" to display options. > > There seem to be no "standard" about options in queries to whois > servers. Okay, thanks! Nice, to learn something new. :)
Re: usr/bin/whois: Query terms are ambiguous
On Tue, Jan 07, 2020 at 06:49:40PM +0100, Johannes Krottmayer wrote: > Hi, Hi Johannes, > I have a strange issue, when using the "whois" client. > > Always get the following as example: > [...] > # > # Query terms are ambiguous. The query is assumed to be: > # "n 62.46.172.92" > # > # Use "?" to get help. > # > [...] > > I have OpenBSD 6.6 installed on two systems. The issue exists > on all those systems. > > Have looked for a bug (for a leading "n " string) in the > source of whois. But didn't find anything. I have also installed > OpenBSD on a vbox and analyzed the query with wireshark. I think you misunderstood the message. The whois binary only send "62.46.172.92" to the whois server, as you may see in you trace below. > But I think the query is correct (Ethernet frame): > 60 38 e0 c2 bd 30 08 00 27 06 0f 2d 08 00 45 00 `8...0..'..-..E. > 0010 00 42 62 43 40 00 40 06 dc 7c 0a 2a 2a 57 c7 47 .BbC@.@..|.**W.G > 0020 00 2e 60 1a 00 2b c7 76 ec 0f 9b fd 95 79 80 18 ..`..+.v.y.. > 0030 01 00 d3 cf 00 00 01 01 08 0a 00 13 e6 e0 a4 51 ...Q > 0040 91 22 36 32 2e 34 36 2e 31 37 32 2e 39 32 0d 0a ."62.46.172.92.. > > No leading "n " string. > > Has somebody noticed the same issue? The server on the other hand could handle different record types, for example "n ..." for network address space, but there are more. If the record type is missing the server assumes (in this case) the record type is n and notifies you of this assumption. So it may be the other way around, "n " may be missing here in the query to the ARIN whois server. Compare the output of the following two: telnet whois.arin.net 43 62.46.172.92 which is also what you get with "whois 62.46.172.92" and this: telnet whois.arin.net 43 n 62.46.172.92 and if you want to see the mentioned help above: telnet whois.arin.net 43 ? whois.apnic.net and whois.ripe.net understand "help" to display options. There seem to be no "standard" about options in queries to whois servers. Regards, Markus
usr/bin/whois: Query terms are ambiguous
Hi, I have a strange issue, when using the "whois" client. Always get the following as example: [...] # # Query terms are ambiguous. The query is assumed to be: # "n 62.46.172.92" # # Use "?" to get help. # [...] I have OpenBSD 6.6 installed on two systems. The issue exists on all those systems. Have looked for a bug (for a leading "n " string) in the source of whois. But didn't find anything. I have also installed OpenBSD on a vbox and analyzed the query with wireshark. But I think the query is correct (Ethernet frame): 60 38 e0 c2 bd 30 08 00 27 06 0f 2d 08 00 45 00 `8...0..'..-..E. 0010 00 42 62 43 40 00 40 06 dc 7c 0a 2a 2a 57 c7 47 .BbC@.@..|.**W.G 0020 00 2e 60 1a 00 2b c7 76 ec 0f 9b fd 95 79 80 18 ..`..+.v.y.. 0030 01 00 d3 cf 00 00 01 01 08 0a 00 13 e6 e0 a4 51 ...Q 0040 91 22 36 32 2e 34 36 2e 31 37 32 2e 39 32 0d 0a ."62.46.172.92.. No leading "n " string. Has somebody noticed the same issue? -- Best regards, Johannes K.
