WHOIS
View on WikipediaWHOIS (pronounced as the phrase "who is") is a query and response protocol that is used for querying databases that store an Internet resource's registered users or assignees. These resources include domain names, IP address blocks and autonomous systems, but it is also used for a wider range of other information. The protocol stores and delivers database content in a human-readable format.[1] The current iteration of the WHOIS protocol was drafted by the Internet Society, and is documented in RFC 3912.
Whois is also the name of the command-line utility on most UNIX systems used to make WHOIS protocol queries.[2] In addition, WHOIS has a sister protocol called Referral Whois (RWhois).
History
[edit]This section needs additional citations for verification. (February 2017) |
Elizabeth Feinler and her team (who had created the Resource Directory for ARPANET) were responsible for creating the first WHOIS directory in the early 1970s.[3] Feinler set up a server in Stanford's Network Information Center (NIC) which acted as a directory that could retrieve relevant information about people or entities.[4] She and the team created domains, with Feinler's suggestion that domains be divided into categories based on the physical address of the computer.[5]
The process of registration was established in RFC 920. WHOIS was standardized in the early 1980s to look up domains, people, and other resources related to domain and number registrations. As all registration was done by one organization at that time, one centralized server was used for WHOIS queries. This made looking up such information very easy.
At the time of the emergence of the internet from the ARPANET, the only organization that handled all domain registrations was the Defense Advanced Research Projects Agency (DARPA) of the United States government (created during 1958.[6]). The responsibility of domain registration remained with DARPA as the ARPANET became the Internet during the 1980s. UUNET began offering domain registration service; however, they simply handled the paperwork which they forwarded to the DARPA Network Information Center (NIC). Then the National Science Foundation directed that commercial, third-party entities would handle the management of Internet domain registration. InterNIC was formed in 1993 under contract with the NSF, consisting of Network Solutions, Inc., General Atomics and AT&T. The General Atomics contract was canceled after several years due to performance issues.
20th-century WHOIS servers were highly permissive and would allow wild-card searches. A WHOIS query of a person's last name would yield all individuals with that name. A query with a given keyword returned all registered domains containing that keyword. A query for a given administrative contact returned all domains the administrator was associated with. Since the advent of the commercialized Internet, multiple registrars and unethical spammers, such permissive searching is no longer available.
On December 1, 1999, management of the top-level domains (TLDs) com, net, and org was assigned to ICANN. At the time, these TLDs were converted to a thin WHOIS model. Existing WHOIS clients stopped working at that time. A month later, it had self-detecting Common Gateway Interface support so that the same program could operate a web-based WHOIS lookup, and an external TLD table to support multiple WHOIS servers based on the TLD of the request. This eventually became the model of the modern WHOIS client.
By 2005, there were many more generic top-level domains than there had been in the early 1980s. There are also many more country-code top-level domains. This has led to a complex network of domain name registrars and registrar associations, especially as the management of Internet infrastructure has become more internationalized. As such, performing a WHOIS query on a domain requires knowing the correct, authoritative WHOIS server to use. Tools to do WHOIS domain searches have become common and are offered by providers such as IONOS and Namecheap.[7]
CRISP and IRIS
[edit]In 2003, an IETF committee was formed to create a new standard for looking up information on domain names and network numbers: Cross Registry Information Service Protocol (CRISP).[8] Between January 2005 and July 2006, the working name for this proposed new standard was Internet Registry Information Service (IRIS) [9][10] The initial IETF Proposed Standards RFCs for IRIS can be found in the Further reading section of this article.
The status of RFCs this group worked on can be found on the
As of March 2009,[update] the CRISP IETF Working Group concluded,[11] after a final RFC 5144 was published by the group.[12]
Note: The IETF CRISP working group is not to be confused with the Number Resource Organization's (NRO) Team of the same name "Consolidated RIR IANA Stewardship Proposal Team" (CRISP Team).[13]
WEIRDS and RDAP
[edit]In 2013, the IETF acknowledged that IRIS had not been a successful replacement for WHOIS. The primary technical reason for that appeared to be the complexity of IRIS. Further, non-technical reasons were deemed to lie in areas upon which the IETF does not pass judgment. Meanwhile, ARIN and RIPE NCC managed to serve WHOIS data via RESTful web services. The charter (drafted in February 2012) provided for separate specifications, for number registries first and for name registries to follow.[14] The working group produced five proposed standard documents and an informational document.
Protocol
[edit]The WHOIS protocol had its origin in the ARPANET NICNAME protocol and was based on the NAME/FINGER Protocol, described in RFC 742 (1977). The NICNAME/WHOIS protocol was first described in RFC 812 in 1982 by Ken Harrenstien and Vic White of the Network Information Center at SRI International.
WHOIS was originally implemented on the Network Control Protocol (NCP) but found its major use when the TCP/IP suite was standardized across the ARPANET and later the Internet.
The protocol specification is the following (original quote):[15]
Connect to the service host TCP: service port 43 decimal NCP: ICP to socket 43 decimal, establishing two 8-bit connections Send a single "command line", ending with <CRLF>. Receive information in response to the command line. The server closes its connections as soon as the output is finished.
The command line server query is normally a single name specification. i.e. the name of a resource. However, servers accept a query, consisting of only the question mark (?) to return a description of acceptable command line formats. Substitution or wild-card formats also exist, e.g., appending a full-stop (period) to the query name returns all entries beginning with the query name.
On the modern Internet, WHOIS services are typically communicated using the Transmission Control Protocol (TCP). Servers listen to requests on the well-known port number 43. Clients are simple applications that establish a communications channel to the server, transmit a text record with the name of the resource to be queried and await the response in form of a sequence of text records found in the database. This simplicity of the protocol also permits an application, and a command line interface user, to query a WHOIS server using the Telnet protocol.
Augmentations
[edit]In 2014, June ICANN published the recommendation for status codes, the "Extensible Provisioning Protocol (EPP) domain status codes"[16]
| Status Code | Description |
|---|---|
| addPeriod | This grace period is provided after the initial registration of a domain name. If the registrar deletes the domain name during this period, the registry may provide credit to the registrar for the cost of the registration. |
| autoRenewPeriod | This grace period is provided after a domain name registration period expires and is extended (renewed) automatically by the registry. If the registrar deletes the domain name during this period, the registry provides a credit to the registrar for the cost of the renewal. |
| inactive | This status code indicates that delegation information (name servers) has not been associated with the domain. The domain is not activated in the DNS and will not resolve. |
| ok | This is the standard status for a domain, meaning it has no pending operations or prohibitions. |
| pendingCreate | This status code indicates that a request to create the domain has been received and is being processed. |
| pendingDelete | This status code may be mixed with redemptionPeriod or pendingRestore. In such case, depending on the status set in the domain name, otherwise (not combined with other status), the pendingDelete status code indicates that the domain has been in redemptionPeriod status for 30 days and not restored. The domain will remain in this status for several days, after which time the domain will be dropped from the registry database.
Once deletion occurs, the domain is available for re-registration in accordance with the registry's policies. |
| pendingRenew | This status code indicates that a request to renew the domain has been received and is being processed. |
| pendingRestore | This status code indicates that the registrar has asked the registry to restore the domain that was in redemptionPeriod status. The registry holds the domain in this status while waiting for the registrar to provide required restoration documentation. If the registrar fails to provide documentation to the registry operator within a set time period to confirm the restoration request, the domain will revert to redemptionPeriod status. |
| pendingTransfer | This status code indicates that a request to transfer the domain to a new registrar has been received and is being processed. |
| pendingUpdate | This status code indicates that a request to update the domain has been received and is being processed. |
| redemptionPeriod | This status code indicates that the registrar has asked the registry to delete the domain. The domain will be held in this status for 30 days. After five calendar days following the end of the redemptionPeriod, the domain is purged from the registry database and becomes available for registration. |
| renewPeriod | This grace period is provided after a domain name registration period is explicitly extended (renewed) by the registrar. If the registrar deletes the domain name during this period, the registry provides a credit to the registrar for the cost of the renewal. |
| serverDeleteProhibited | This status code prevents the domain from being deleted. It is an uncommon status that is usually enacted during legal disputes, at the registrant's request, or when a redemptionPeriod status is in place. |
| serverHold | This status code is set by the domain's Registry Operator. The domain is not activated in the DNS. |
| serverRenewProhibited | This status code indicates the domain's Registry Operator will not allow the registrar to renew the domain. It is an uncommon status that is usually enacted during legal disputes or when the domain is subject to deletion. |
| serverTransferProhibited | This status code prevents the domain from being transferred from the current registrar to another. It is an uncommon status that is usually enacted during legal or other disputes, at the registrant's request, or when a redemptionPeriod status is in place. |
| serverUpdateProhibited | This status code locks the domain, preventing it from being updated. It is an uncommon status that is usually enacted during legal disputes, at the registrant's request, or when a redemptionPeriod status is in place. |
| transferPeriod | This grace period is provided after the successful transfer of a domain name from one registrar to another. If the new registrar deletes the domain name during this period, the registry provides a credit to the registrar for the cost of the transfer. |
Implementation
[edit]WHOIS lookups were traditionally performed with a command line interface application, but now many alternative web-based tools exist.
A WHOIS database consists of a set of text records for each resource. These text records consists of various items of information about the resource itself, and any associated information of assignees, registrants, administrative information, such as creation and expiration dates.
Two data models exist for storing resource information in a WHOIS database, the thick and the thin model.
Thin and thick lookups
[edit]WHOIS information can be stored and looked up according to either a thick or a thin data model:
- Thick
- A thick WHOIS server stores the complete WHOIS information from all the registrars for the particular set of data (so that one WHOIS server can respond with WHOIS information on all .org domains, for example).
- Thin
- A thin WHOIS server stores only the name of the WHOIS server of the registrar of a domain, which in turn has the full details on the data being looked up (such as the .com WHOIS servers, which refer the WHOIS query to the registrar where the domain was registered).
The thick model usually ensures consistent data and slightly faster queries, since only one WHOIS server needs to be contacted. If a registrar goes out of business, a thick registry contains all important information (if the registrant entered correct data, and privacy features were not used to obscure the data) and registration information can be retained. But with a thin registry, the contact information might not be available, and it could be difficult for the rightful registrant to retain control of the domain.[17]
If a WHOIS client did not understand how to deal with this situation, it would display the full information from the registrar. The WHOIS protocol has no standard for determining how to distinguish the thin model from the thick model.
Specific details of which records are stored vary among domain name registries. Some top-level domains, including com and net, operate a thin WHOIS, requiring domain registrars to maintain their own customers' data. The other global top-level registries, including org, operate a thick model.[18] Each country-code top-level registry has its own national rules.
Software
[edit]| whois | |
|---|---|
| Developers | RIPE NCC (original BSD client), Marco d'Itri (modern Linux client) |
| Stable release | 5.5.23
/ 2024-05-04[19] |
| Written in | C |
| Operating system | Unix, Unix-like, ReactOS[20] |
| Platform | Cross-platform |
| Type | Command |
| License | BSD License (BSD and ReactOS), GPL (Linux) |
| Website | github |
The first applications written for the WHOIS information system were command-line interface tools for Unix and Unix-like operating systems (i.e. Solaris, Linux etc.). WHOIS client and server software is distributed as free open-source software and binary distributions are included with all Unix-like systems. Various commercial Unix implementations may use a proprietary implementation (for example, Solaris 7).
A WHOIS command line client passes a phrase given as an argument directly to the WHOIS server. Various free open source examples can still be found on sites such as sourceforge.net. However, most modern WHOIS tools implement command line flags or options, such as the -h option to access a specific server host, but default servers are preconfigured. Additional options may allow control of the port number to connect on, displaying additional debugging data, or changing recursion/referral behavior.
Like most TCP/IP client–server applications, a WHOIS client takes the user input and then opens an Internet socket to its destination server. The WHOIS protocol manages the transmission of the query and reception of results.
Web
[edit]With the advent of the World Wide Web and especially the loosening up of the Network Solutions monopoly, looking up WHOIS information via the web has become quite common. At present, popular web-based WHOIS-queries may be conducted from ARIN,[21] RIPE[22] and APNIC.[23] Most early web-based WHOIS clients were merely front-ends to a command-line client, where the resulting output just gets displayed on a web page with little, if any, clean-up or formatting.
Currently, web based WHOIS clients usually perform the WHOIS queries directly and then format the results for display. Many such clients are proprietary, authored by domain name registrars.
The need for web-based clients came from the fact that command-line WHOIS clients largely existed only in the Unix and large computing worlds. Microsoft Windows and Macintosh computers had no WHOIS clients installed by default, so registrars had to find a way to provide access to WHOIS data for potential customers. Many end-users still rely on such clients, even though command line and graphical clients exist now for most home PC platforms. Microsoft provides the Sysinternals Suite that includes a whois client at no cost.
CPAN has several Perl modules available that work with WHOIS servers. Many of them are not current and do not fully function with the current (2005) WHOIS server infrastructure. However, there is still much useful functionality to derive including looking up AS numbers and registrant contacts.[citation needed]
Servers
[edit]WHOIS services are mainly run by registrars and registries; for example the Public Interest Registry (PIR) maintains the .ORG registry and associated WHOIS service.[24]
Regional Internet registries
[edit]
WHOIS servers operated by regional Internet registries (RIR) can be queried directly to determine the Internet service provider responsible for a particular resource.
The records of each of these registries are cross-referenced, so that a query to ARIN for a record which belongs to RIPE will return a placeholder pointing to the RIPE WHOIS server. This lets the WHOIS user making the query know that the detailed information resides on the RIPE server. In addition to the RIRs servers, commercial services exist, such as the Routing Assets Database used by some large networks (e.g., large Internet providers that acquired other ISPs in several RIR areas).
Server discovery
[edit]There is currently no widely extended way for determining the responsible WHOIS server for a DNS domain, though a number of methods are in common use for top-level domains (TLDs). Some registries use DNS SRV records (defined in RFC 2782[25]) to allow clients to discover the address of the WHOIS server.[26] Some WHOIS lookups require searching the procuring domain registrar to display domain owner details.
Query examples
[edit]Normally the contact information of the resources assignee is returned. However, some registrars offer private registration, in which case the contact information of the registrar is shown instead.
Some registry operators are wholesalers, meaning that they typically provide domain name services to a large number of retail registrars, who in turn offer them to consumers. For private registration, only the identity of the wholesale registrar may be returned. In this case, the identity of the individual as well as the retail registrar may be hidden.
Below is an example of WHOIS data returned for an individual resource holder. This is the result of a WHOIS query of example.com:
> whois example.com
[Querying whois.verisign-grs.com]
[Redirected to whois.iana.org]
[Querying whois.iana.org]
[whois.iana.org]
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object
domain: EXAMPLE.COM
organisation: Internet Assigned Numbers Authority
created: 1992-01-01
source: IANA
Here is another result of a WHOIS query for the website of Final Fantasy XIV, showing a typical .com WHOIS with registry, registrar, domain status, name servers, and DNSSEC information:
> whois finalfantasyxiv.com
[Querying whois.verisign-grs.com]
Domain Name: FINALFANTASYXIV.COM
Registry Domain ID: 19576356_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.markmonitor.com
Registrar URL: http://www.markmonitor.com
Updated Date: 2024-02-09T05:41:13Z
Creation Date: 2000-02-10T15:58:28Z
Registry Expiry Date: 2026-02-10T15:58:28Z
Registrar: MarkMonitor Inc.
Registrar IANA ID: 292
Registrar Abuse Contact Email: abusecomplaints@markmonitor.com
Registrar Abuse Contact Phone: +1.2086851750
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Name Server: A1-211.AKAM.NET
Name Server: A13-66.AKAM.NET
Name Server: A2-67.AKAM.NET
Name Server: A22-64.AKAM.NET
Name Server: A24-65.AKAM.NET
Name Server: A3-66.AKAM.NET
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
Referral Whois
[edit]Referral Whois (RWhois) is an extension of the original WHOIS protocol and service. RWhois extends the concepts of WHOIS in a scalable, hierarchical fashion, potentially creating a system with a tree-like architecture. Queries are deterministically routed to servers based on hierarchical labels, reducing a query to the primary repository of information.[27]
Lookups of IP address allocations are often limited to the larger Classless Inter-Domain Routing (CIDR) blocks (e.g., /24, /22, /16), because usually only the regional Internet registries (RIRs) and domain registrars run RWhois or WHOIS servers, although RWhois is intended to be run by even smaller local Internet registries, to provide more granular information about IP address assignment.
RWhois is intended to replace WHOIS, providing an organized hierarchy of referral services where one could connect to any RWhois server, request a look-up and be automatically re-directed to the correct server(s). However, while the technical functionality is in place, adoption of the RWhois standard has been weak.
RWhois services are typically communicated using the Transmission Control Protocol (TCP). Servers listen to requests on the well-known port number 4321.
Rwhois was first specified in RFC 1714 in 1994 by Network Solutions,[27] but the specification was superseded in 1997 by RFC 2167.[28]
The referral features of RWhois are different than the feature of a WHOIS server to refer responses to another server, which RWhois also implements.
Criticism
[edit]One criticism of WHOIS is the lack of full access to the data.[29][30] Few parties have realtime access to the complete databases.
Others cite the competing goal of domain privacy as a criticism, although this problem is strongly mitigated by domain privacy services. Currently, the Internet Corporation for Assigned Names and Numbers (ICANN) broadly requires that the mailing address, phone number and e-mail address of those owning or administering a domain name to be made publicly available through the "WHOIS" directories. The registrant's (domain owner's) contact details, such as address and telephone number, are easily accessible to anyone who queries a WHOIS server. However, that policy enables spammers, direct marketers, identity thieves or other attackers to loot the directory for personal information about these people. Although ICANN has been exploring changing WHOIS to enable greater privacy, there is a lack of consensus among major stakeholders as to what type of change should be made.[31] Some domain registrars offer private registrations (also known as domain privacy), by which the contact information of the registrar is shown instead of the customer's. With the offer of private registration from many registrars, some of the risk has been mitigated.[32]
Studies have shown that spammers can and do harvest plain-text email addresses from WHOIS servers.[33][34] For this reason, some WHOIS servers and websites offering WHOIS queries have implemented rate-limiting systems, such as web-based CAPTCHA and limited amounts of search queries per user IP address.[32]
The WHOIS requirements conflict with the General Data Protection Regulation (GDPR), effective in the European Union 25 May 2018, which places strict regulations on the processing and publication of personally identifiable information. ICANN stated in November 2017 that it would not reprimand "noncompliance with contractual obligations related to the handling of registration data" if registrars provide alternative solutions for compliance with its rules, until the WHOIS requirements are updated to take GDPR into account.[32][35]
The WHOIS protocol was not written with an international audience in mind. A WHOIS server and/or client cannot determine the text encoding in effect for the query or the database content. Many servers were originally using US-ASCII and internationalization concerns were not taken into consideration until much later.[36] This might impact the usability or usefulness of the WHOIS protocol in countries outside the USA.[1] In the case of internationalized domain names it is the responsibility of the client application to perform the translation of the domain name between its native language script and the DNS name in punycode.
Accuracy of information
[edit]In cases where the registrant's (Domain Owner) identity is public, anyone can easily confirm the status of a domain via WHOIS.
In the case of private registrations, ascertaining registration information may be more difficult. If a registrant, who acquired a domain name, wants to verify the registrar has completed the registration process, three steps may be required:
- Perform a WHOIS and confirm that the resource is at least registered with ICANN,
- Determine the name of the wholesale registrar, and
- Contact the wholesaler and obtain the name of the retail registrar.
This provides some confidence that the retailer actually registered the name. But if the registrar goes out of business, as with the failure of RegisterFly in 2007, the rightful domain holder with privacy-protected registrations may have difficulty regaining the administration of their domain name.[17] Registrants using "private registration" can attempt to protect themselves by using a registrar that places customer data in escrow with a third party.
ICANN requires that every registrant of a domain name be given the opportunity to correct any inaccurate contact data associated with their domain. For this reason, registrars are required to periodically send the holder the contact information on record for verification, but they do not provide any guarantee about the accuracy of information if the registrant provided inaccurate information.
Law and policy
[edit]The examples and perspective in this section deal primarily with the United States and do not represent a worldwide view of the subject. (May 2018) |
WHOIS has generated policy issues in the United States federal government. As noted above, WHOIS creates a privacy issue which is also tied to free speech and anonymity. However, WHOIS is an important tool for law enforcement officers investigating violations like spam and phishing to track down the holders of domain names. As a result, law enforcement agencies have sought to make WHOIS records both open and verified:[37]
- The Federal Trade Commission has testified about how inaccurate WHOIS records thwart their investigations.[38]
- Congressional hearings have been conducted about the importance of WHOIS in 2001, 2002 and 2006.[39]
- The Fraudulent Online Identity Sanctions Act[40] "make it a violation of trademark and copyright law if a person knowingly provided, or caused to be provided, materially false contact information in making, maintaining, or renewing the registration of a domain name used in connection with the violation,"[41] where the latter "violation" refers to a prior violation of trademark or copyright law. The act does not make the submission of false WHOIS data illegal in itself, only if used to shield oneself from prosecution for crimes committed using that domain name.
ICANN proposal to abolish WHOIS
[edit]The Expert Working Group (EWG) of the Internet Corporation for Assigned Names and Numbers (ICANN) recommended on 24 June 2013 that WHOIS should be scrapped. It recommends that WHOIS be replaced with a system that keeps information secret from most Internet users, and only discloses information for "permissible purposes".[42] ICANN's list of permissible purposes includes domain-name research, domain-name sale and purchase, regulatory enforcement, personal data protection, legal actions, and abuse mitigation.[43] Although WHOIS has been a key tool of journalists in determining who was disseminating certain information on the Internet,[44] the use of WHOIS by the free press is not included in ICANN's proposed list of permissible purposes.
The EWG collected public input on the initial report until 13 September 2013. Its final report was issued on 6 June 2014, without meaningful changes to the recommendations.[45] As of March 2015[update], ICANN is in the "process of re-inventing WHOIS," working on "ICANN WHOIS Beta."[46][47]
On January 19, 2023, ICANN opened voting on a global amendment to all its registry and registrar agreements. In it they defined an RDAP Ramp-Up Period of 180 days starting with the effectiveness of this amendment. 360 days after this period is defined as the WHOIS Services Sunset Date, after which it is not a requirement for registries and registrars to offer a WHOIS service and instead only an RDAP service is required. All voting thresholds were met within the 60 day voting period and the amendment was approved by the ICANN Board. The WHOIS was officially Sunset for gTLDs on 28 January 2025.[48]
Standards documents
[edit]See also
[edit]References
[edit]- ^ a b RFC 3912, WHOIS Protocol Specification, L. Daigle (September 2004)
- ^ "Whois(1) — whois — Debian stretch — Debian Manpages". Archived from the original on 2021-04-01. Retrieved 2020-12-27.
- ^ Evans 2018, p. 116.
- ^ Evans 2018, p. 119.
- ^ Evans 2018, p. 120.
- ^ Innovation at DARPA (PDF) (Report). DARPA. July 2016. Archived (PDF) from the original on August 27, 2021. Retrieved August 7, 2021.
- ^ "Whois Domain Lookup UK » Check detailed info for free | IONOS". ionos.co.uk. Archived from the original on 2022-07-26. Retrieved 2022-07-27.
- ^ Murphy, Cathy (2 October 2003). "CRISP (Cross-Registry Information Service Protocol) Working Group Meeting Minutes". Internet Engineering Task Force. Minneapolis, Minnesota USA: IETF. Archived from the original on 1 June 2015. Retrieved 1 June 2015.
The CRISP (Cross-Registry Information Service Protocol) WG will define a standard mechanism that can be used for finding authoritative information associated with a label, a protocol to transport queries and responses for accessing that information, and a first profile (schema & queries) to support commonly-required queries for domain registration information.
- ^ Newton, Andrew (July 2006). "Replacing the Whois Protocol: IRIS and the IETF's CRISP Working Group". IEEE Internet Computing. 10 (4): 79–84. doi:10.1109/MIC.2006.86. S2CID 8514005. Archived from the original on 2 June 2015. Retrieved 1 June 2015.
The Nicname/Whois protocol has served well, but it remains unchanged since it was first published in the early 1980s, despite great change in the infrastructure and administration of the Internet. There is now more diversity with domain names and IP networks and associated contacts, as well as among the users submitting queries via Whois. The protocol is now so fragmented in terms of information flow and output that queries yield inconsistent results under current conditions. To address the needs of today's Internet, the IETF Cross Registry Internet Service Protocol (CRISP) working group is developing a new protocol, the Internet Registry Information Service (IRIS), to replace Whois.
- ^ Sanz, Marcos; Newton, Andrew; Daigle, Leslie (12 January 2005). "The Internet Registry Information Service (IRIS) Protocol" (PDF). gnso.icann.org. Internet Corporation for Assigned Names and Numbers (ICANN). Archived from the original (PDF) on 1 June 2015. Retrieved 1 June 2015.
CRISP – Cross-Registry Internet Service Protocol: The CRISP Working Group was tasked with finding a solution to the problems that currently infest the Nicname/Whois protocol. The CRISP Working Group created a list of functional requirements. Proposals meeting these requirements were evaluated. IRIS was selected as the protocol to publish as a standard. Now an IETF Proposed Standard: RFCs: 3981, 3982, 3983
- ^ IESG Secretary (26 March 2009). "WG Action: Conclusion of Cross Registry Information Service Protocol (crisp)". IETF CRISP WG: Mail Archive. Archived from the original on 2 June 2015. Retrieved 2 June 2015.
The Cross Registry Information Service Protocol (crisp) working group in the Applications Area has concluded.
- ^ Mevzek, Patrick (21 January 2009). "[CRISP] RFC 5144 up and running". IETF CRISP WG: Mail Archive. Archived from the original on 2 June 2015. Retrieved 2 June 2015.
- ^ "Consolidated RIR IANA Stewardship Proposal Team (CRISP Team)". Number Resource Organization (NRO). Archived from the original on 4 August 2022. Retrieved 4 August 2022.
- ^ "Web Extensible Internet Registration Data Service (weirds) Working Group". IETF-88 Proceedings. IETF. Archived from the original on 9 July 2015. Retrieved 8 July 2015.
- ^ Harrenstien, K.; White, V. (1 March 1982). NICNAME/WHOIS. doi:10.17487/RFC0812. RFC 812.
- ^ "EPP Status Codes - What Do They Mean, and Why Should I Know? - ICANN". www.icann.org. Archived from the original on 2018-03-13. Retrieved 14 March 2018.
- ^ a b ".COM and .NET: Thick Or Thin?". Archived from the original on 2008-01-16. Retrieved 2008-01-17.
- ^ Sarah Stoll (30 May 2009). "Thick vs. Thin Whois for New gTLDs" (PDF). memorandum. ICANN. Archived (PDF) from the original on 18 December 2010. Retrieved 17 September 2011.
Current gTLD registry agreements vary between thin and thick Whois outputs: com, net and jobs are thin; all other gTLD agreements – aero, asia, biz, cat, coop, info, mobi, museum, name, org, pro, tel, travel – are thick.
- ^ "Release v5.5.23 · rfc1036/whois · GitHub". github.com. Retrieved 2025-07-27.
- ^ "reactos/whois.c at master · reactos/reactos · GitHub". GitHub. Archived from the original on 2022-02-01. Retrieved 2019-07-29.
- ^ "Whois-RWS". whois.arin.net. Archived from the original on 2012-09-10. Retrieved 2012-09-10.
- ^ "Webupdates". RIPE Network Coordination Centre.
- ^ "APNIC Whois search". wq.apnic.net. Archived from the original on 2017-10-20. Retrieved 2022-08-04.
- ^ "DNS and WHOIS - How it Works | ICANN WHOIS". Archived from the original on 2021-01-26. Retrieved 2020-12-27.
- ^ Gulbrandsen, Arnt; Esibov, Levon (February 2000). "A DNS RR for specifying the location of services (DNS SRV)". Archived from the original on 2021-07-23. Retrieved 2021-07-26.
- ^ "Getting WHOIS Server Address Directly from Registry". Archived from the original on 2021-07-26. Retrieved 2021-07-26.
- ^ a b Williamson, S.; Kosters, M. (November 1994). Referral Whois Protocol (RWhois). doi:10.17487/RFC1714. RFC 1714.
- ^ Williamson, S.; Kosters, M.; Blacka, D.; Singh, J.; Zeilstra, K. (June 1997). Referral Whois (RWhois) V1.5. doi:10.17487/RFC2167. RFC 2167.
- ^ "Battle Begins Over IP Address Whois Data". Internet Governance Project. 12 February 2011. Archived from the original on 9 April 2015. Retrieved 4 April 2015.
- ^ "WHOIS Privacy Plan Draws Fire". KerbsonSecurity. 16 September 2013. Archived from the original on 16 March 2015. Retrieved 4 April 2015.
- ^ "The Privacy Conundrum in Domain Registration". Act Now Domains. Archived from the original on 7 March 2023. Retrieved 26 March 2013.
- ^ a b c "WHATIS Going to Happen With WHOIS?". Motherboard. 2018-02-02. Archived from the original on 2018-04-29. Retrieved 2018-04-28.
- ^ "SAC 023: Is the WHOIS Service a Source for email Addresses for Spammers?" Archived 2010-12-04 at the Wayback Machine, ICANN Security and Stability Advisory Committee, October 2007
- ^ Sattler, Tobias (2024-12-04). "WHOIS Data Redaction and its Impact on Unsolicited Emails: A Field Experiment". IEEE Access. 12: 182322–182339. Bibcode:2024IEEEA..12r2322S. doi:10.1109/ACCESS.2024.3511269.
- ^ Vaughan-Nichols, Steven J. "ICANN makes last minute WHOIS changes to address GDPR requirements". ZDNet. Archived from the original on 2018-05-24. Retrieved 2018-05-29.
- ^ "WHOIS Internalization Issues" Archived 2012-05-14 at the Wayback Machine, November 2012
- ^ "FTC Calls for Openness, Accessibility in Whois Database System - Federal Trade Commission". www.ftc.gov. 18 July 2006. Archived from the original on 27 September 2006. Retrieved 11 November 2006.
- ^ "Accuracy of "WHOIS" Internet Database Essential to Law Enforcement, FTC Tells Congress - Federal Trade Commission". www.ftc.gov. 2 May 2002. Archived from the original on 16 October 2006. Retrieved 11 November 2006.
- ^ Bowman, Lisa (11 July 2001). "Whois at heart of congressional hearings". CNET. Archived from the original on 27 August 2005.
- ^ "THOMAS". Archived from the original on July 17, 2012.
- ^ "Fraudulent Online Identity Sanctions Act". Archived from the original on July 17, 2012.
- ^ "Initial Report from the Expert Working Group on gTLD Directory Services: A Next Generation Registration Directory Service" (PDF). whois.icann.org. ICANN. 24 June 2013. Archived (PDF) from the original on 3 July 2015. Retrieved 24 March 2015.
- ^ "ICANN earmarks domains record WhoIs for the scrapheap - New Legal Review". Archived from the original on 2014-01-14. Retrieved 2014-01-13.
- ^ "SJMC: COMMON SENSE JOURNALISM". jour.sc.edu. Archived from the original on 2005-01-12.
- ^ "Final Report from the Expert Working Group on gTLD Directory Services: A Next-Generation Registration Directory Service (RDS)" (PDF). whois.icann.org. ICANN. 6 June 2014. Archived (PDF) from the original on 24 February 2015. Retrieved 24 March 2015.
- ^ "About WHOIS". whois.icann.org/. ICANN. Archived from the original on 19 April 2020. Retrieved 24 March 2015.
- ^ "What's on the Horizon?". whois.icann.org. ICANN. Archived from the original on 21 May 2020. Retrieved 24 March 2015.
- ^ "2023 Global Amendments to the Base gTLD Registry Agreement (RA), Specification 13, and 2013 Registrar Accreditation Agreement (RAA) - ICANN". www.icann.org. Archived from the original on 2023-04-07. Retrieved 2023-04-07.
Sources
[edit]- Evans, Claire L. (2018). Broad Band: The Untold Story of the Women Who Made the Internet. New York: Portfolio/Penguin. ISBN 9780735211759.
Further reading
[edit]IRIS
[edit]- 3981 - Newton, A.; Sanz, M. (January 2005). IRIS: The Internet Registry Information Service (IRIS) Core Protocol. IETF. doi:10.17487/RFC3981. STD 8. RFC 3981. Retrieved June 1, 2015.
- 3982 - Newton, A.; Sanz, M. (January 2005). IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS). IETF. doi:10.17487/RFC3982. RFC 3982. Retrieved June 1, 2015.
- 3983 - Newton, A.; Sanz, M. (January 2005). Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP). IETF. doi:10.17487/RFC3983. RFC 3983. Retrieved June 1, 2015.
- 4992 - Newton, A. (August 2007). XML Pipelining with Chunks for the Internet Registry Information Service. IETF. doi:10.17487/RFC4992. RFC 4992. Retrieved June 1, 2015.
- Newton, Andrew; Sanz, Marcos (February 2008). A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS). IETF. doi:10.17487/RFC5144. RFC 5144. Retrieved 1 June 2015.
RDAP
[edit]- 7480 - Newton, Andrew; Ellacott, Byron; Kong, Ning (March 2015). HTTP Usage in the Registration Data Access Protocol (RDAP). IETF. doi:10.17487/RFC7480. RFC 7480. Retrieved July 8, 2015.
- 7481 - Hollenbeck, Scott; Kong, Ning (March 2015). Security Services for the Registration Data Access Protocol (RDAP). IETF. doi:10.17487/RFC7481. RFC 7481. Retrieved July 8, 2015.
- 7482 - Newton, Andrew; Hollenbeck, Scott (March 2015). Registration Data Access Protocol (RDAP) Query Format. IETF. doi:10.17487/RFC7482. RFC 7482. Retrieved July 8, 2015.
- 7483 - Newton, Andrew; Hollenbeck, Scott (March 2015). JSON Responses for the Registration Data Access Protocol (RDAP). IETF. doi:10.17487/RFC7483. RFC 7483. Retrieved July 8, 2015.
- 7484 - Blanchet, Marc (March 2015). Finding the Authoritative Registration Data (RDAP) Service. IETF. doi:10.17487/RFC7484. RFC 7484. Retrieved July 8, 2015.
- 7485 - Zhou, L.; Kong, N.; Shen, S.; Sheng, S.; Servin, A. (March 2015). Inventory and Analysis of WHOIS Registration Objects. IETF. doi:10.17487/RFC7485. RFC 7485. Retrieved July 8, 2015.
External links
[edit]WHOIS
View on GrokipediaHistorical Development
Origins in ARPANET and Early RFCs
The WHOIS protocol emerged in the ARPANET era as a rudimentary directory service for retrieving identification data on network resources. RFC 812, published on March 1, 1982, by Ken Harrenstien, Vic White, and Elizabeth Feinler of SRI International, formally defined the NICNAME/WHOIS server, which interfaced with the NICNAME database to handle queries for host, user, and organizational contact details. This specification built on earlier ARPANET tools like the NAME/FINGER protocol outlined in RFC 742 (November 1977), adapting them into a dedicated query mechanism for the Network Information Center (NIC) at SRI.[7] The primary intent of the NICNAME/WHOIS service was to support operational coordination in the resource-constrained ARPANET environment by enabling administrators and researchers to obtain maintainer contacts, mailing addresses, and phone numbers associated with registered entities, thereby aiding in fault isolation and protocol implementation discussions. Queries were submitted as ASCII strings to the server, which returned unstructured textual responses drawn from the database, emphasizing simplicity over complex formatting to match the era's limited computational capabilities. Unlike subsequent evolutions, early WHOIS lacked hierarchical referrals or domain-specific integrations, focusing solely on flat database lookups within the ARPANET's host registration system managed by the NIC.[3] Implementations were centralized on SRI-NIC hosts, with connections established via TCP to service port 43, a convention that persisted from initial deployments despite not being explicitly mandated in RFC 812 itself.[8] This port assignment, later codified in RFC 954 (January 1986) as an update to RFC 812, reflected the protocol's reliance on the SRI-NIC as the sole authoritative server for ARPANET-wide queries, restricting access to authenticated network participants and underscoring the pre-commercial, research-oriented scope of the service.[8]Expansion to Domain Name System Integration
As the Domain Name System (DNS) emerged in the mid-1980s to address scalability limitations of the flat hosts.txt file, WHOIS transitioned from a host- and user-centric directory service—originally established in 1982 for ARPANET researchers—to a mechanism for querying domain registration data, thereby aligning with the hierarchical structure of DNS.[3] This adaptation involved populating WHOIS databases with registrant details for newly created top-level domains (TLDs) like .com, .net, and .org, mirroring the operational data maintained by early domain administrators to support the growing volume of registrations.[9][10] A pivotal milestone occurred in September 1991, when the U.S. Defense Department subcontracted Network Solutions Inc. (NSI) to handle DNS name server operations and domain registrations for generic TLDs, prompting NSI to deploy dedicated WHOIS servers that provided public access to ownership records for these domains.[11] The Internet Assigned Numbers Authority (IANA), led by Jon Postel, coordinated these efforts by overseeing the allocation of numbering and naming resources, delegating registry functions while ensuring WHOIS data consistency across the evolving infrastructure.[3] From 1991 to 1999, NSI exclusively operated the registries for .com, .net, and .org, centralizing WHOIS queries through port 43 to reflect real-time registration updates.[11] This DNS-WHOIS integration causally facilitated accountability in the Internet's commercialization phase, as public exposure of domain registrant contacts—required under early policies—enabled verification of ownership for business transactions, spam mitigation, and nascent dispute mechanisms amid rising domain demand post-1991 National Science Foundation policy shifts allowing commercial traffic.[3][9] By the mid-1990s, WHOIS had become indispensable for tracing administrative contacts in a decentralized yet queryable registry model, underpinning trust in domain-based online activities without relying on centralized host listings.[10]Standardization Efforts and Initial Protocols
The initial formalization of the WHOIS protocol occurred through Request for Comments (RFC) 954, published in November 1985 by Jon Postel, which established it as a TCP-based transaction-oriented query/response service operating on port 43.[8] This specification outlined basic query syntax—typically a single line of text terminated by a carriage return and line feed—along with response formats consisting of unstructured textual data lines, and included rudimentary error handling such as returning "Unknown host" or "No information" for unsuccessful queries.[8] As an update to the earlier RFC 812 from March 1982, RFC 954 shifted focus from ARPANET-specific directory details to a more generalized netwide service for retrieving information on users, hosts, domains, and networks from the SRI-NIC server.[8] IETF efforts in this period emphasized practical utility over rigid uniformity, reflecting the protocol's ad-hoc origins in ARPANET maintenance needs rather than a comprehensive standards process.[8] The absence of mandates for response structure or extensibility in RFC 954 permitted server-specific variations in output formatting and data fields, as each WHOIS implementation adapted to local database schemas without enforced interoperability.[1] These inconsistencies arose because the protocol prioritized simplicity for low-volume administrative queries in a trust-reliant network environment, where operators manually curated and shared directory data.[8] Empirical evidence of the protocol's effectiveness drove its de facto standardization: by the late 1980s, WHOIS had become a ubiquitous tool for Internet resource lookup, with adoption propelled by its minimal overhead—a single TCP connection sufficing for most transactions—and proven reliability in fulfilling directory functions without requiring sophisticated parsing or authentication. This evolution underscored a causal dynamic where functional adequacy in resource-constrained settings outweighed the drawbacks of variability, as network growth remained modest and query disputes were resolved through direct operator coordination rather than protocol enforcement.[8] The design's reliance on plain-text exchanges aligned with the era's computational limits, enabling broad deployment on diverse systems without proprietary dependencies.[8]Protocol Mechanics
Core Query and Response Format
The WHOIS protocol operates as a simple TCP-based query/response mechanism, where clients establish a connection to a server on port 43 and transmit a plain-text query string terminated by a carriage return line feed (CRLF) sequence.[1] This query typically consists of an ASCII or UTF-8 encoded identifier, such as a domain name or IP address block, without any structured formatting or headers.[12] Upon receipt, the server processes the request and sends back a text-based response, also terminated by CRLF, with the final response boundary marked by an additional CRLF to signal completion.[1] The protocol's design prioritizes minimalism, relying solely on this stateless exchange without session persistence or multi-turn interactions.[12] Responses follow a field-oriented structure, though not rigidly standardized, commonly delineating key registration details via line-based entries such as registrant name, organization, postal address, contact telephone numbers, email addresses, and temporal data including creation date, last update date, and expiration date.[2] These fields are often prefixed with labels followed by colons or hyphens separating values, but variations in delimiters and ordering occur across implementations, reflecting the protocol's origins in early informal specifications.[13] For instance, a domain query might yield lines like "Domain Name: example.com" paired with "Creation Date: 2000-01-01T00:00:00Z", enabling human-readable output but complicating automated extraction.[2] The core protocol incorporates no authentication mechanisms, allowing anonymous queries and exposing data without verification of requester identity, which aligns with its public directory purpose but introduces risks of abuse.[1] Each transaction remains independent, with servers closing the connection post-response, enforcing a single-query-per-session model that avoids state management overhead.[12] This text-centric approach, while efficient for basic retrieval, exhibits limitations including susceptibility to parsing errors from inconsistent field formats and line terminations across servers, as no universal schema enforces uniformity. Additionally, although RFC 3912 extended support to UTF-8 characters for internationalization, legacy ASCII constraints and varying server implementations hinder reliable handling of non-Latin scripts, often resulting in garbled output or fallback encodings.[1][14]Referral and Hierarchical Query Handling
In Referral WHOIS (RWhois), an extension to the core WHOIS protocol specified in RFC 1714 (November 1994), queried servers assess whether the request pertains to their defined authority area; if not, they issue a %referral response containing pointers to alternative servers, such as hostnames, port numbers, and refined query strings tailored to sub-delegations like IP subnetworks or domain subtrees.[15] Referral types include link referrals (where the query matches the authority area), reduction referrals (narrowing the query scope), and punt referrals (escalating to broader authorities), facilitating directed delegation without exhaustive local searches.[15] Hierarchical query handling in RWhois parallels the DNS zone delegation model, partitioning the namespace into authority areas delineated by SOA-like records (including TTL, serial numbers, and refresh intervals) that specify master servers for specific lexical hierarchies, such as IP prefixes or domain labels.[15] Clients iteratively reduce queries—e.g., from "ietf.cnri.reston.va.us" to "us"—by following referrals, loading average metrics via the -load directive to prioritize efficient servers, and querying SOA details with -soa to confirm authority boundaries, thereby distributing load and avoiding over-reliance on root-level servers.[15] This structure supported scalability in early Internet resource management, as evidenced by its deployment for IP reassignments at registries like ARIN, where it enabled precise routing to local ISP databases.[16] While effective for query efficiency in the 1990s expansion phase by minimizing central server traffic, the referral system risks infinite loops from misconfigured cyclic pointers; clients counter this by maintaining a server trail log, detecting recursive referrals (e.g., revisiting the same server-query pair), and terminating with notifications as outlined in RFC 2167 (June 1997), which refined loop handling in protocol version 1.5.[15]Extensions and Augmentations Over Time
In response to growing concerns over spam and malicious online activities, WHOIS records were augmented with dedicated abuse contact fields to enable efficient reporting. The Internet Corporation for Assigned Names and Numbers (ICANN) mandated this addition in its 2013 Registrar Accreditation Agreement (RAA), requiring accredited registrars for generic top-level domains (gTLDs) to include an abuse contact email address and telephone number in publicly accessible WHOIS data. This non-protocol change, implemented without modifying the core TCP-based query format defined in RFC 3912 (March 2004), allowed users to directly contact responsible entities for domains involved in abuse, such as phishing or unauthorized email distribution.[17] By 2016, regional internet registries like the RIPE NCC had incorporated similar fields into their policies, drawing from WHOIS as a primary source for abuse-handling contacts.[18] These fields addressed practical gaps in accountability but relied on voluntary compliance and inconsistent formatting across registries, limiting their effectiveness without enforcing standardized parsing. Support for internationalized domain names (IDNs), which use non-Latin scripts, represented another augmentation attempted through data encoding rather than protocol redesign. Punycode, specified in RFC 3492 (March 2003), enabled representation of Unicode characters as ASCII-compatible strings (e.g., "xn--bcher-kva.de" for "bücher.de"), allowing IDN queries within WHOIS's 7-bit ASCII constraint. RFC 4290 (October 2005) outlined suggested practices for IDN handling in registration systems, advising registries to store native Unicode internally while outputting Punycode in WHOIS responses to maintain compatibility.[19] Despite these measures, adoption faced challenges: inconsistencies in encoding, variant handling (e.g., simplified vs. traditional Chinese characters), and lack of uniform client-side decoding resulted in fragmented support, with many queries yielding incomplete or punycode-only results that hindered usability for non-technical users.[20] RFC 7485 (March 2015) later highlighted WHOIS's inherent internationalization deficits, noting poor consistency in IDN data across 124 analyzed registries.[21] Efforts like WHOIS++ (outlined in RFC 1835, August 1995) proposed broader protocol augmentations, including indexed searches, attribute-value templates, and extensible hierarchies to overcome ad hoc modifications in early WHOIS implementations.[22] However, these enhancements saw minimal deployment, as the internet community favored the simplicity of the base protocol over complex extensions. Such incremental additions—new fields for operational needs and encoding hacks for data diversity—patched immediate symptoms of the protocol's aging design, including its unstructured text format and ASCII exclusivity, without addressing causal roots like the absence of machine-readable schemas or native multilingual capabilities. This approach sustained WHOIS's utility amid evolving internet scale but perpetuated parsing difficulties and scalability issues observed by the mid-2010s.[20]Infrastructure and Servers
Regional Internet Registry Operations
Regional Internet Registries (RIRs) manage the allocation and registration of Internet number resources, including IPv4 and IPv6 address space and Autonomous System Numbers (ASNs), within geographically defined service regions, and they operate dedicated WHOIS servers to provide public access to allocation records for these resources.[23] There are five RIRs: the African Network Information Centre (AFRINIC) serving Africa, the Asia-Pacific Network Information Centre (APNIC) for Asia and the Pacific, the American Registry for Internet Numbers (ARIN) covering North America, the Latin American and Caribbean Network Information Centre (LACNIC) for Latin America and the Caribbean, and the RIPE Network Coordination Centre (RIPE NCC) responsible for Europe, the Middle East, and parts of Central Asia.[23] Each RIR maintains an independent WHOIS database populated with data collected during resource allocation processes, where member organizations—typically local Internet registries (LIRs) or end users—submit organizational details, contact information for points of contact (POCs), and network descriptions as part of their registration requests.[24] These databases emphasize stewardship of finite Internet resources by enabling transparency into how address space and ASNs are distributed, allowing network operators, researchers, and the public to verify allocations, trace routing origins, and ensure compliance with global numbering policies established through the Internet Assigned Numbers Authority (IANA).[25] WHOIS queries to RIR servers, typically via TCP port 43, return structured responses detailing network ranges (e.g., inetnum objects for IP blocks), associated organizations, administrative and technical contacts, creation and update dates, and status flags indicating allocation or assignment types.[24] For instance, ARIN's WHOIS service retrieves information on IP number resources, organizations, POCs, and customers directly from its registry database, which is updated in real-time as allocations occur.[24] The accuracy of RIR WHOIS data is enforced through contractual agreements between RIRs and resource holders, such as ARIN's Registration Services Agreement, which mandates that registrants provide and maintain accurate registration information for themselves and their customers, with non-compliance potentially leading to resource revocation or other enforcement actions.[26] Similar obligations apply across RIRs, where members must update contact details promptly and ensure data reflects current resource usage, supporting the overall integrity of Internet routing and resource management without relying on domain-specific registries.[27]| RIR | Service Region | WHOIS Server Endpoint |
|---|---|---|
| AFRINIC | Africa | whois.afrinic.net |
| APNIC | Asia-Pacific | whois.apnic.net |
| ARIN | North America | whois.arin.net |
| LACNIC | Latin America and Caribbean | whois.lacnic.net |
| RIPE NCC | Europe, Middle East, Central Asia | whois.ripe.net |
Server Discovery and Port Standards
The WHOIS protocol utilizes TCP port 43 as its standard port for client-server communication, an assignment maintained by the Internet Assigned Numbers Authority (IANA) under the service name "whois."[28] This port enables straightforward text-based query transmission from clients to servers, with the server listening for incoming connections to process requests and return responses.[1] The specification in RFC 3912 emphasizes this port without mandating alternatives, ensuring compatibility across implementations, though some specialized or legacy servers have occasionally operated on non-standard ports, requiring client-specific configurations.[17] Server discovery in WHOIS lacks a protocol-native mechanism, obligating clients to employ external methods to identify appropriate servers for domains, IP addresses, or autonomous systems.[1] Primary approaches include static mappings in client software or configuration files that associate top-level domains (TLDs) with designated WHOIS servers, such as whois.verisign-grs.com for .com domains.[29] These mappings, often sourced from IANA's TLD database or registry documentation, must be updated manually for new TLDs to avoid failures. A subset of registries—approximately 36 as of 2023—facilitate dynamic discovery by publishing server hostnames and ports via DNS SRV records under the _whois._tcp service for their TLDs.[30] For IP address queries, discovery typically involves selecting regional Internet registry (RIR) servers based on allocation ranges, with clients using embedded heuristics or referral chains starting from a root server like whois.iana.org.[31] Legacy systems and basic clients often fallback to defaults such as whois.internic.net for unresolved domain queries or whois.arin.net for North American IPs, reflecting early ARPANET conventions.[32] This patchwork of methods has fostered operational inconsistencies, where outdated client mappings or incomplete TLD coverage contribute to user errors, such as querying incorrect servers and receiving null responses or inefficient referrals.[29] Such issues underscore the protocol's dependence on external maintenance rather than automated resolution.Thick and Thin Database Models
In the thin WHOIS database model, the top-level domain (TLD) registry maintains only basic domain registration details, such as the sponsoring registrar, domain status, creation and expiration dates, and name servers, while directing queries for comprehensive registrant contact information to the registrar's WHOIS server.[33][34] This approach requires clients to perform a referral query to the registrar for full data, as seen in registries like .com and .net operated by Verisign.[34][35] Conversely, the thick WHOIS model centralizes all registrant details—including administrative, technical, and owner contact information—at the TLD registry itself, allowing a single query to retrieve complete records without referrals.[33][36] Examples include registries for .org, .info, .biz, and many country-code TLDs such as .uk managed by Nominet, where the registry aggregates and publishes the full dataset.[36][37] The models entail distinct operational trade-offs: thin registries minimize centralized storage of personal data, potentially enhancing privacy by distributing sensitive information across registrars and reducing breach risks in a single repository, though this necessitates multiple queries per lookup.[38][39] Thick models streamline queries by providing exhaustive responses from one source, improving efficiency for high-volume users, but amplify risks of data exposure and compliance burdens from concentrated holdings.[40][34] Adoption has varied empirically by TLD, with thin predominant in legacy gTLDs like .com for legacy compatibility and thin's lighter registry load, while thick prevails in most others for query convenience, despite ICANN's intermittent pushes toward uniformity via thick transitions that faced implementation challenges.[34][41]Implementation and Tools
Command-Line and Software Clients
Thewhois command-line utility, standard in Unix-like operating systems such as Linux, serves as a primary client for querying WHOIS servers over TCP port 43 to retrieve registration details for domains and IP addresses.[42] Installation typically involves package managers like apt install whois on Debian-based systems, enabling direct terminal-based lookups such as whois [example.com](/page/Example.com) for domain ownership data.[43] This tool handles basic referral mechanisms by following server responses to appropriate registries, though it lacks built-in advanced parsing for complex outputs.[44]
For enhanced functionality, jwhois provides a more robust WHOIS client with configurable server selection via a global .jwhoisrc file, supporting queries across multiple databases including those for domains, IP blocks, and autonomous systems.[45] It incorporates caching to store recent query results locally, reducing redundant network requests and improving efficiency in repeated lookups, as configured through options in its documentation. While explicit retry mechanisms are not natively detailed, scripting wrappers can implement them to manage transient server errors or rate limits common in WHOIS interactions.[46]
These clients facilitate automation in shell scripts for tasks like domain availability monitoring, bulk IP validation, or integration into network management pipelines, often via pipes with grep or awk for extracting fields such as registrant organization.[47] Examples include Bash loops processing IP lists from files or Python subprocess calls embedding whois output for programmatic analysis, though users must account for server-imposed query throttling to avoid blocks. Such reliability in scripted environments stems from the protocol's simplicity, allowing consistent text-based responses parseable without proprietary APIs.
Following the WHOIS protocol sunset on January 28, 2025, as declared by ICANN to prioritize RDAP adoption, command-line clients relying on port 43 face widespread server deprecation, rendering many queries ineffective for gTLDs and nTLDs.[48] Legacy usage persists where registries opt to maintain WHOIS services voluntarily, particularly for ccTLDs or internal tools, but overall decline limits automation scalability without migration to RDAP-compatible alternatives.[49]
Web Interfaces and APIs
Web-based WHOIS lookup interfaces emerged to provide accessible, graphical alternatives to command-line queries, enabling users to enter domain names or IP addresses via browser forms and retrieve registration data without specialized software. ICANN's Registration Data Lookup Tool, available at lookup.icann.org since its initial release, supports queries for domain names and Internet number resources, displaying parsed results including registrant details where not redacted.[50] Similarly, major domain registrars such as GoDaddy offer integrated WHOIS search tools on their sites, revealing ownership, expiration dates, and nameserver information for queried domains.[51] Third-party providers like whois.com and DomainTools extend this with additional features, such as historical data previews or IP-specific lookups, aggregating responses from multiple registries.[52][53] Programmatic access via APIs has facilitated integration of WHOIS data into applications, with services like WhoisXML API providing RESTful endpoints for single or bulk domain queries, returning structured JSON or XML outputs including contact fields and registration timestamps.[54] These APIs often enforce throttling—typically limiting requests to prevent overload on upstream WHOIS servers—with free tiers capped at low volumes (e.g., 100-1000 queries per month) and paid plans scaling to millions for enterprise use.[55] Providers such as Whoxy and JsonWhoisAPI emphasize parsed, normalized data to handle variations across top-level domains (TLDs), though accuracy depends on real-time pulls from registrar databases.[56][57] Following the WHOIS protocol's deprecation on port 43 effective January 28, 2025, web interfaces and APIs have increasingly adopted the Registration Data Access Protocol (RDAP) for compliant data retrieval, offering JSON-formatted responses with enhanced search capabilities and privacy redactions under ICANN's policies.[14] ICANN's lookup tool incorporated RDAP querying as early as July 2019, enabling structured outputs for better API compatibility, while third-party services like WhoisXML API updated endpoints to hybrid WHOIS-RDAP modes post-sunset.[58][59] Regional registries, including ARIN, enhanced RDAP APIs in May 2025 to support advanced filters for IP networks and entities, reducing reliance on legacy WHOIS wrappers.[60] This transition prioritizes machine-readable data over plain-text WHOIS responses, though some legacy web tools persist for backward compatibility until full migration.[61]Integration with Domain Validation Processes
WHOIS data has historically facilitated domain control validation (DCV) processes for issuing Domain Validated (DV) SSL/TLS certificates by enabling certificate authorities (CAs) to retrieve registrant or administrative contact emails from public records, to which validation tokens could be sent.[62][63] This method supported rapid, automated verification of domain ownership, often completing within minutes, and extended to email-based proofs in broader security workflows, such as confirming control for domain transfers or anti-abuse investigations.[64][65] Despite these efficiencies, WHOIS-based DCV proved vulnerable to manipulation, including the injection of falsified contact details by malicious actors, which could enable unauthorized certificate issuance.[66] Empirical demonstrations highlighted this risk; for instance, researchers acquired an expired domain associated with a WHOIS server for approximately $20, subsequently observing millions of queries that could have been exploited to spoof validation responses and generate fraudulent TLS certificates.[67] Such exploits underscored the protocol's susceptibility to off-path attacks and data inaccuracies, exacerbated by privacy redactions that obscured verifiable contacts post-GDPR.[68] Major CAs have discontinued WHOIS reliance amid these flaws. Entrust terminated WHOIS-based verification on November 27, 2024, mandating reverification of affected domains by March 31, 2025, citing injected false data as a primary enabler of abuse.[66] DigiCert followed, ceasing WHOIS queries for DCV email validation on May 8, 2025, after which its systems no longer supported the method.[69] Industry-wide, public trusted CAs phased out legacy WHOIS DCV starting January 8, 2025, shifting to alternatives like DNS TXT records or HTTP file uploads for more reliable proofs.[70][71] This transition reflects a consensus on WHOIS's diminished utility for high-stakes validation, prioritizing methods less prone to spoofing and data obfuscation.[72]Data Policies and Access Controls
Pre-GDPR Disclosure Practices
Prior to the General Data Protection Regulation's enforcement on May 25, 2018, WHOIS databases offered unrestricted public access to detailed domain registration records, including the registrant's full name, organization, postal address, email address, telephone number, and fax number, as well as comparable details for administrative and technical contacts, nameserver hostnames, creation dates, expiration dates, and last update timestamps.[73] This comprehensive disclosure was mandated by ICANN's contractual agreements with generic top-level domain (gTLD) registries and accredited registrars, which required the collection, verification, and real-time publication of accurate data through port 43 WHOIS servers or equivalent directory services.[74] Registries operated "thick" WHOIS models in many cases, aggregating and distributing complete datasets centrally, while registrars maintained "thin" records with pointers to registry data, ensuring broad availability without authentication barriers.[2] The foundational rationale for this transparency traced to the WHOIS protocol's inception in RFC 953 (October 1985), designed as a query-response mechanism for retrieving administrative and operational details on Internet resources to support network management and interoperability among early ARPANET participants. For domain names under ICANN's purview since 1998, this evolved into a policy-driven imperative for accountability, enabling direct identification of responsible parties to address DNS propagation issues, configuration errors, and unauthorized transfers.[9] ICANN's Registrar Accreditation Agreement and base registry agreements explicitly obligated parties to provide this data publicly, with accuracy verified through periodic reminders and audits to minimize errors that could impede functionality.[75] Disclosure practices served core operational goals: facilitating Uniform Domain-Name Dispute-Resolution Policy (UDRP) proceedings, initiated in 1999, where complainants required verifiable registrant contacts to notify respondents and enforce arbitration outcomes for cybersquatting cases exceeding 50,000 annually by the mid-2010s. They also supported anti-abuse efforts by allowing network operators, intellectual property holders, and security teams to contact registrants or registrars for rapid takedowns of spam, phishing, or malware-hosting domains, with WHOIS lookups integral to tracing infrastructure in incident response workflows.[76] Empirical assessments, such as ICANN's 2013 commissioned study on data misuse, registered experimental domains to quantify unauthorized contacts and found incidence rates below 1% for sensitive queries, indicating that legitimate operational and enforcement uses predominated without systemic overload from frivolous access.[77][78] Similarly, cybersecurity reports documented WHOIS's role in correlating registrant patterns across threat campaigns, enabling proactive mitigation before privacy redactions diminished visibility.[79] This evidence affirmed the practices' efficacy in upholding DNS integrity through verifiable, low-friction access for authorized inquiries.Regulatory Impacts on Data Redaction
The enforcement of the European Union's General Data Protection Regulation (GDPR) on May 25, 2018, mandated the redaction of personal data in WHOIS records to protect the privacy rights of EU data subjects, resulting in the anonymization or replacement of identifiable information such as names, addresses, and contact details with generic placeholders like "REDACTED FOR PRIVACY." This shift affected domain registrations linked to EU residents or entities, with empirical studies showing that over 85% of large WHOIS providers redacted records associated with European Economic Area (EEA) addresses at scale following the regulation's implementation.[80] By late 2018, public access to full WHOIS records had declined sharply, with analyses indicating that only about 9-20% of queried records remained unredacted, depending on the dataset and timing relative to enforcement.[81][82] The GDPR's requirements created a compliance imperative that extended beyond EU-based registries, prompting non-EU operators to adopt similar redaction practices to mitigate legal risks from processing potentially applicable EU personal data or serving EU customers. Global domain registrars, contractually bound to publish WHOIS data under ICANN agreements, preemptively redacted information worldwide to streamline operations and avoid fragmented policies that could expose them to fines up to 4% of global annual turnover for non-compliance.[83] This ripple effect homogenized WHOIS outputs, reducing the protocol's utility for cross-border investigations into domain ownership and contactability. From a causal standpoint, these redactions have demonstrably impaired the ability to combat domain abuse, as obscured registrant details hinder rapid identification and takedown of malicious sites by security researchers and law enforcement. Surveys by the Anti-Phishing Working Group (APWG) following GDPR enforcement documented increased challenges in responding to phishing incidents, with redacted WHOIS data often resulting in unfulfilled takedown requests and prolonged site lifespans that enable greater harm.[84] Empirical trends align with this, as phishing attack volumes rose significantly post-2018— for instance, APWG reported a 65% year-over-year increase in observed attacks by 2022, partly attributable to over-redaction facilitating under-detection of abusive registrations.[85] While intended to safeguard privacy, the policy's effects prioritize data minimization over transparency, correlating with elevated risks in cybersecurity without equivalent compensatory mechanisms at the time.[86]ICANN's Registration Data Policy Implementation
The ICANN Registration Data Policy, effective August 21, 2025, establishes a standardized framework for contracted parties—ICANN-accredited registrars and registries—to process and disclose generic top-level domain (gTLD) registration data, succeeding the Interim Registration Data Policy that expired on August 20, 2025.[87][88] This transition concluded a one-year preparation period beginning August 21, 2024, during which parties aligned operations with the new requirements, moving beyond GDPR-driven interim measures that emphasized data redaction to a consensus-based approach prioritizing lawful access while protecting registrant privacy.[87][89] Under the policy, access to non-public registration data—such as redacted personal identifiers—requires third-party requesters to submit formal requests demonstrating a legitimate and lawful purpose, including a rationale, basis for disclosure, and any urgency.[89][90] Contracted parties must verify the requester's identity and purpose before granting reasonable access, with responses due within 30 calendar days of acknowledgment unless exceptional circumstances apply; they are obligated to provide website links to submission instructions for standardized handling.[89][91] For gTLD data, ICANN's Registration Data Request Service (RDRS) facilitates such submissions via an ICANN account, targeting users with verifiable interests like law enforcement or intellectual property holders, though casual or unverified inquiries face heightened scrutiny and potential denial due to insufficient justification.[92][93] The framework balances registrant privacy—through continued redaction options and consent mechanisms for organizational data publication—with operational needs for transparency, but imposes procedural burdens on non-verified users, as requests lacking robust evidence of proportionate purpose may be rejected, effectively prioritizing institutional or legally backed requesters over broad public queries.[89][94] Implementation includes updated specifications like the 2025 Registrar Data Escrow and RDAP Response Profile to support compliant data handling across systems.[89]Transition to Successors
Development of IRIS and Early Alternatives
The Cross-Registry Information Service Protocol (CRISP) working group was chartered by the Internet Engineering Task Force (IETF) in 2003 to develop a standardized framework for querying Internet registry data, addressing the limitations of the aging WHOIS protocol, such as its unstructured text output and lack of extensibility.[95] The resulting Internet Registry Information Service (IRIS) protocol, finalized as RFC 3981 in January 2005, introduced an XML-based data serialization format for structured queries and responses, supporting operations like entity lookups across registries via transports including BEEP (Blocks Extensible Exchange Protocol) and even fallback to WHOIS port 43.[96] IRIS aimed to enable more precise, machine-readable data retrieval, including support for domain, IP address, and autonomous system number information, while incorporating features like referrals between registries for federated queries.[96] Development of IRIS extended through additional RFCs, such as RFC 3982 for XML schemas and RFC 3983 for a domain registry entity type, published in the same period to define query types and result structures. However, implementation faced challenges from the protocol's relative complexity, requiring XML parsing and schema validation, which contrasted with WHOIS's simplicity despite its parsing inconsistencies. By the early 2010s, adoption remained minimal, with only two Regional Internet Registries (RIRs)—ARIN and RIPE NCC—deploying limited IRIS services alongside WHOIS, as the protocol's overhead deterred broader rollout among registrars and operators accustomed to the lightweight, text-based status quo.[97] The stalled uptake of IRIS underscored WHOIS's deep entrenchment in operational workflows, where incremental fixes like output formatting improvements were preferred over wholesale protocol shifts, even as IRIS exposed fundamental flaws such as non-standardized responses and scalability issues in WHOIS. IETF evaluations in 2013 confirmed IRIS's failure as a replacement, attributing it primarily to implementation barriers rather than technical deficiencies, prompting renewed efforts for simpler alternatives.[97] Other contemporaneous proposals, like LDAP-based extensions to WHOIS, similarly gained no traction, reinforcing the inertia against disrupting established query tools.[98]Emergence and Adoption of RDAP
The Registration Data Access Protocol (RDAP) was standardized by the Internet Engineering Task Force (IETF) as a modern alternative to WHOIS, with core specifications outlined in RFCs 7480 through 7485, published in March 2015.[99] These documents define RDAP as an HTTP-based protocol that queries registration data—such as domain names, IP networks, and autonomous systems—via RESTful endpoints, returning responses in JSON format for machine readability and extensibility. Unlike legacy text-based protocols, RDAP incorporates content negotiation to allow clients to request preferred media types and supports server-side rate limiting to prevent abuse and ensure service availability.[99] RDAP's design emphasizes technical enhancements for global applicability, including full support for internationalization through Unicode encoding of identifiers and structured fields that accommodate internationalized domain names (IDNs) and multilingual registrant data without legacy character set limitations.[100] Privacy mechanisms are integrated via optional redaction of sensitive fields (e.g., personal contact details) and anonymization proxies, enabling operators to comply with data protection regulations while permitting granular access controls.[100] Additionally, RDAP facilitates authenticated queries using mechanisms like OAuth or API keys, allowing tiered data disclosure—such as full visibility for verified requesters versus redacted views for unauthenticated ones—to balance transparency with individual privacy rights.[101] ICANN mandated RDAP implementation for generic top-level domain (gTLD) registries and registrars, requiring operational services by August 26, 2019, with particular emphasis on new gTLDs to standardize data access across the ecosystem.[101] This requirement, embedded in registry agreements, ensures RDAP endpoints are discoverable via well-known URIs (e.g., /.well-known/rdap) and supports querying hierarchies of related objects, such as linking domains to associated IP resources.[102] By 2023, amendments to base gTLD agreements further aligned RDAP with evolving policies, promoting widespread deployment among operators handling millions of domains annually.[103]WHOIS Sunset Timeline and Effects (2025)
The sunset of WHOIS protocol obligations occurred on January 28, 2025, when the Internet Corporation for Assigned Names and Numbers (ICANN) formally ended requirements for generic top-level domain (gTLD) registries and registrars to maintain Registration Data Directory Services (RDDS) via WHOIS, including port-43 queries and web-based interfaces.[48][104] This date marked the culmination of amendments to the Base gTLD Registry Agreement, adopted 18 months prior, which prioritized the transition to the Registration Data Access Protocol (RDAP) as the successor standard.[105] Prior to this, WHOIS data had already been heavily redacted under ICANN's Temporary Policy on Accurate WHOIS, implemented in May 2018 in response to the European Union's General Data Protection Regulation (GDPR), limiting public access to personal registrant information.[2] Subsequent developments in 2025 included the full enforcement of ICANN's revised Registration Data Policy on August 21, 2025, following a one-year transition period from August 2024, which mandated contracted parties to align with a minimum data set for domain registrations while deleting extraneous personal data not required for operational or legal purposes.[87] This policy shift clarified registrant rights, emphasizing purpose-based justifications for data collection and access, but did not reinstate unredacted WHOIS queries.[106] By mid-2025, several certificate authorities (CAs) phased out reliance on WHOIS for domain control validation (DCV) in SSL/TLS certificate issuance: web-based WHOIS lookups ended on January 8, 2025, followed by email and phone validations derived from WHOIS data on May 8, 2025, due to vulnerabilities in the protocol's accuracy and security.[70][107][71] The effects of the WHOIS sunset have primarily accelerated adoption of RDAP, which offers structured JSON responses, better internationalization support, and rate-limiting to mitigate abuse, though it maintains GDPR-compliant redactions for non-public data.[48][61] This transition has disrupted legacy tools and workflows dependent on port-43 queries, prompting some service providers to deprecate WHOIS access entirely, potentially increasing operational costs for users migrating to RDAP-compatible APIs.[108] In domain security and abuse mitigation, the change has compounded challenges from pre-existing data inaccuracies, as RDAP does not resolve underlying issues of registrar non-compliance or proxy services obscuring ownership, leading to calls for enhanced accreditation-based access to unredacted data.[104] For certificate issuance, the DCV deprecations have shifted reliance to alternative methods like HTTP file uploads or DNS TXT records, reducing validation speed but improving resistance to spoofing.[109] Overall, while RDAP fulfills technical modernization goals, the sunset has not restored transparency lost to privacy mandates, affecting stakeholders in cybersecurity, law enforcement, and competitive intelligence who previously used WHOIS for rapid ownership tracing.[110]Practical Usage
Standard Query Examples
A standard WHOIS query for a domain name, such aswhois example.com, connects to the relevant registry server and returns details including registration status, dates, registrar, and name servers.[17][111]
Domain Name: EXAMPLE.COM
Registry Domain ID: ...
Registrar WHOIS Server: whois.iana.org
Registrar URL: ...
Updated Date: 2025-08-14T00:00:00Z
Creation Date: 1995-08-14T04:00:00Z
Registry Expiry Date: 2026-08-13T04:00:00Z
Registrar: RESERVED-Internet Assigned Numbers Authority
Registrar IANA ID: 376
Registrar Abuse Contact Email: ...
Registrar Abuse Contact Phone: ...
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Name Server: A.IANA-SERVERS.NET
Name Server: B.IANA-SERVERS.NET
DNSSEC: unsigned
For IP addresses, a query like whois 8.8.8.8 targets regional Internet registries (RIRs) such as ARIN, yielding network allocation data including net range, organization, and registration dates.[17][24]
NetRange: 8.8.8.0 - 8.8.8.255
CIDR: 8.8.8.0/24
NetName: GOGL
NetHandle: NET-8-8-8-0-2
Parent: NET8 (NET-8-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Google LLC (GOGL)
RegDate: 2023-12-28
Updated: 2023-12-28
Ref: https://rdap.arin.net/registry/ip/8.8.8.0
OrgName: Google LLC
OrgId: GOGL
Address: 1600 Amphitheatre Parkway
City: Mountain View
StateProv: CA
PostalCode: 94043
Country: [US](/page/United_States)
RegDate: 2000-03-30
Updated: 2019-10-31
Output formats differ across TLDs and RIRs, with generic TLDs (.com, .org) often providing registrar-focused fields while country-code TLDs (ccTLDs) may include localized contact details or restricted data, lacking a uniform structure due to independent registry implementations.[112][113]
Interpreting Responses and Common Fields
WHOIS responses typically include timestamp fields indicating the domain's lifecycle: the creation date marks initial registration, the updated date reflects the most recent modification to the record, and the expiration date specifies the renewal deadline after which the domain enters a grace period before potential deletion.[20] These dates, formatted in ISO 8601 or similar standards, aid in assessing domain age and activity; for instance, a recent update may signal recent ownership changes or renewals.[2] Name server fields list the authoritative DNS servers (e.g., ns1.example.com, ns2.example.com) delegated for the domain, revealing hosting providers or infrastructure details when cross-referenced with public records.[20] Status codes, derived from the Extensible Provisioning Protocol (EPP), are flags that restrict actions like transfers or deletions; client status codes (e.g., clientDeleteProhibited, set by registrars to prevent accidental removal) and server status codes (e.g., serverTransferProhibited, imposed by registries during disputes) indicate locks or holds.[114]| Status Code Type | Example | Effect |
|---|---|---|
| Client | clientDeleteProhibited | Prevents deletion by registrar actions |
| Client | clientHold | Inhibits DNS resolution updates |
| Client | clientTransferProhibited | Blocks transfers to new registrars |
| Client | clientUpdateProhibited | Restricts record modifications |
| Server | serverDeleteProhibited | Blocks deletion by registry actions |
| Server | serverHold | Prevents zone file updates |
| Server | serverTransferProhibited | Forbids inter-registry transfers |
| Server | serverUpdateProhibited | Limits registry-initiated changes |