Sfdwhf

I seem to be having an issue with whois it appears to be duplicating the output, this is unfortunately interfering with one of my scripts.

I have tested this both on my personal laptop as well as my Ubuntu server, I have also tested this on a fresh install of Ubuntu as well.

This is not an issue on my CentOs7 servers. I have however not tested this on a different distribution.

My knowledge of ubuntu us not that much in comparison to CentOs however I don't believe there would be that large of a difference between these utilities.

Here's a sample of what it looks like when I run a whois:

╔═══[Date: Sat Apr 27 Time: 05:04 AM]═[arctic@Sevastopol.foxdale.net]

╠══[Total Commands: 977]═[Issued Commands: 4]=[Logins: 2]

╠═[~]

╚[λ]-[$]>-➤ whois foxdale.net

   Domain Name: FOXDALE.NET

   Registry Domain ID: 1830382905_DOMAIN_NET-VRSN

   Registrar WHOIS Server: whois.namecheap.com

   Registrar URL: http://www.namecheap.com

   Updated Date: 2018-09-08T06:15:03Z

   Creation Date: 2013-10-08T18:25:51Z

   Registry Expiry Date: 2019-10-08T18:25:51Z

   Registrar: NameCheap, Inc.

   Registrar IANA ID: 1068

   Registrar Abuse Contact Email: abuse@namecheap.com

   Registrar Abuse Contact Phone: +1.6613102107

   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited

   Name Server: NS1.FOXDALE.NET

   Name Server: NS2.FOXDALE.NET

   DNSSEC: unsigned

   URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/

>>> Last update of whois database: 2019-04-27T10:37:41Z <<<



For more information on Whois status codes, please visit https://icann.org/epp



NOTICE: The expiration date displayed in this record is the date the

registrar's sponsorship of the domain name registration in the registry is

currently set to expire. This date does not necessarily reflect the expiration

date of the domain name registrant's agreement with the sponsoring

registrar.  Users may consult the sponsoring registrar's Whois database to

view the registrar's reported date of expiration for this registration.



TERMS OF USE: You are not authorized to access or query our Whois

database through the use of electronic processes that are high-volume and

automated except as reasonably necessary to register domain names or

modify existing registrations; the Data in VeriSign Global Registry

Services' ("VeriSign") Whois database is provided by VeriSign for

information purposes only, and to assist persons in obtaining information

about or related to a domain name registration record. VeriSign does not

guarantee its accuracy. By submitting a Whois query, you agree to abide

by the following terms of use: You agree that you may use this Data only

for lawful purposes and that under no circumstances will you use this Data

to: (1) allow, enable, or otherwise support the transmission of mass

unsolicited, commercial advertising or solicitations via e-mail, telephone,

or facsimile; or (2) enable high volume, automated, electronic processes

that apply to VeriSign (or its computer systems). The compilation,

repackaging, dissemination or other use of this Data is expressly

prohibited without the prior written consent of VeriSign. You agree not to

use electronic processes that are automated and high-volume to access or

query the Whois database except as reasonably necessary to register

domain names or modify existing registrations. VeriSign reserves the right

to restrict your access to the Whois database in its sole discretion to ensure

operational stability.  VeriSign may restrict or terminate your access to the

Whois database for failure to abide by these terms of use. VeriSign

reserves the right to modify these terms at any time.



The Registry database contains ONLY .COM, .NET, .EDU domains and

Registrars.

Domain name: foxdale.net

Registry Domain ID: 1830382905_DOMAIN_NET-VRSN

Registrar WHOIS Server: whois.namecheap.com

Registrar URL: http://www.namecheap.com

Updated Date: 2018-09-08T06:15:03.74Z

Creation Date: 2013-10-08T18:25:51.00Z

Registrar Registration Expiration Date: 2019-10-08T18:25:51.00Z

Registrar: NAMECHEAP INC

Registrar IANA ID: 1068

Registrar Abuse Contact Email: abuse@namecheap.com

Registrar Abuse Contact Phone: +1.6613102107

Reseller: NAMECHEAP INC

Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited

Registry Registrant ID:

Registrant Name: WhoisGuard Protected

Registrant Organization:

Registrant Street: P.O. Box 0823-03411

Registrant City: Panama

Registrant State/Province: Panama

Registrant Postal Code:

Registrant Country: PA

Registrant Phone: +507.8365503

Registrant Phone Ext:

Registrant Fax: +51.17057182

Registrant Fax Ext:

Registrant Email: f7a93f5d87af478f876ff6f51b592cb0.protect@whoisguard.com

Registry Admin ID:

Admin Name: WhoisGuard Protected

Admin Organization:

Admin Street: P.O. Box 0823-03411

Admin City: Panama

Admin State/Province: Panama

Admin Postal Code:

Admin Country: PA

Admin Phone: +507.8365503

Admin Phone Ext:

Admin Fax: +51.17057182

Admin Fax Ext:

Admin Email: f7a93f5d87af478f876ff6f51b592cb0.protect@whoisguard.com

Registry Tech ID:

Tech Name: WhoisGuard Protected

Tech Organization:

Tech Street: P.O. Box 0823-03411

Tech City: Panama

Tech State/Province: Panama

Tech Postal Code:

Tech Country: PA

Tech Phone: +507.8365503

Tech Phone Ext:

Tech Fax: +51.17057182

Tech Fax Ext:

Tech Email: f7a93f5d87af478f876ff6f51b592cb0.protect@whoisguard.com

Name Server: ns1.foxdale.net

Name Server: ns2.foxdale.net

DNSSEC: unsigned

URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/

>>> Last update of WHOIS database: 2019-04-27T03:17:32.93Z <<<



!highlight!For more information on Whois status codes, please visit https://icann.org/epp

I ran this command on both my Ubuntu 18.04 machine and a CentOS 7 VM targeting google.com and the outputs were not identical, but I did not experience any issues with duplication. Rather, it appears the Ubuntu instance was performing two queries: first in all uppercase, then in all lowercase. The timestamps also indicate that these were two separate queries. I suggest adding a pipe to your script like so:

whois foxdale.net | tail -n 60

Since the CentOS output is only 60 lines and the first 60 lines or so seem to be identical, you should be able to use this in order to format the output into something useable. You also would be able to reuse the script on your CentOS machines without modification.

I can confirm this behavior on my Arch machine, with whois version 5.4.2. It looks like the developers of whois have decided it is useful to query both upper and lowercase domain names. I don't understand why, the Domain Name implementation specification (RFC 1035) states that (emphasis mine):

2.3.3. Character Case

For all parts of the DNS that are part of the official protocol, all
comparisons between character strings (e.g., labels, domain names,
etc.) are done in a case-insensitive manner. At present, this rule is
in force throughout the domain system without exception. However,
future additions beyond current usage may need to use the full binary
octet capabilities in names, so attempts to store domain names in
7-bit ASCII or use of special bytes to terminate labels, etc., should
be avoided.

When data enters the domain system, its original case should be
preserved whenever possible. In certain circumstances this cannot be
done. For example, if two RRs are stored in a database, one at x.y
and one at X.Y, they are actually stored at the same place in the
database, and hence only one casing would be preserved. The basic
rule is that case can be discarded only when data is used to define
structure in a database, and two names are identical when compared in
a case insensitive manner.

Given the above, the decision of the whois developers seems very strange, but I'm no networking expert so they probably know something I don't.

Presumably, your CentOS has an older version of whois which didn't have this behavior. CentOS is not a cutting edge distribution, and usually lags behind other distros which ship new versions of tools more often. Since I can reproduce this on my Arch system, it does seem like this is an upstream decision made by the whois devs, and not an issue with Ubuntu.

For what it's worth, this seems to have been added to whois v5.2.17, at least, that was the first version I found in the github repository https://github.com/rfc1036/whois which displayed this behavior.