Who does Linux ask when you perform a whois?

Question

When you do:

$ whois stackoverflow.com

does your Linux first do a DNS query, find the IP of stackoverflow.com, and then ask the information directly there?

Or does it ask a "root" whois server (is the IP of the "root whois server" hardcoded in a Linux distribution, in a similar fashion to /etc/bind/db.root?), which then delegates to another whois server who gives the information?

What is the connection flow?

my computer doing `whois ...` ---> root whois server ---> another whois server ---> information

or

my computer doing `whois ...` ---> DNS server (?) ---> ... ?

Answer 1

If you’re using Marco d’Itri’s whois, you can add the --verbose option to see what it’s doing. For stackoverflow.com, it starts by asking whois.verisign-grs.com (see its list of WHOIS servers), which gives it a number of pieces of information, including the fact that Stack Overflow’s registrar is Name.com, and its WHOIS server is whois.name.com; so it then proceeds to ask whois.name.com.

The protocol is documented in RFC 3912. The whois manpage also has useful pointers.

Answer 2

Stephen answered the core parts but you have some other points that I want to address:

1. Whois is a poorly defined protocol. There is no hierarchy, no root whois, etc. In fact there is nothing related to DNS in whois systems, you should start by completely separate them in your mind as, beside the fact that they take their data from the same source (the registry database) they operate completely independently.
2. Each TLD registry operates differently in this regard. gTLDs are a case on their own: per ICANN contract, for now, each registrar has the obligation to have a whois server answering for all names it handles. The registries have the same requirement. The registry whois output lists the registrar whois server (but as I wrote in a comment above, this changed slightly recently - for no good reason in fact - which broke many whois clients) mainly for an historical reason that will soon disappear: in the past (and still now for .COM/.NET - .JOBS kind of switched recently but was previously in the same boat, see https://www.icann.org/resources/pages/thick-whois-transition-policy-2017-02-01-en) registries where 'thin' which mean that the registry does not store data about the contacts, only the registrar does. Which mean that if you really want to have data about the domain name and find who to contact in case of problems (which was - and still is - the original goal of the whois protocol), you need to first query the registry whois server to get the basic set of information and to discover the registrar whois server and then contact this registrar whois server to get access to all contact information. This explains why the registry output of .COM/.NET today gives you only data about domain nameservers, dates and statuses. And the registrar whois server name, which whois client try to follow but sometimes can't because things change (see my comment above)
3. ccTLDs almost always do not work like that, even if using registrars, querying the registry whois server gets you back all results needed and even if some are missing (for privacy reasons for example), you do not need to query registrars' whois server as they are not mandated by registries to run it for the ccTLDs they handle (but some registrars do nevertheless). This explains your observation for a .fr domain name for example.
4. some whois clients hardcode addresses of whois servers, some try whois.nic.$TLD by default which often works as registry of $TLD often has nic.$TLD as primary operating domain name.
5. IANA handles the list of registries at https://www.iana.org/domains/root/db and in each registry page, such as https://www.iana.org/domains/root/db/fr.html you will have a line WHOIS Server listing the whois server related to the selected registry. Please note however it may get outdated or wrong sometimes. You can also access this data by doing a whois query for a TLD towards whois.iana.org, it will give you data about the relevant registry, including its whois server in the whois key.
6. There is also another trick. If you do a DNS query (but please remember that this point does not invalidate the first point) for $TLD.whois-servers.net it will give you the name of the corresponding whois server for $TLD, as a CNAME record. Some whois clients may use this trick, but I doubt it (GNU whois client may be one of them though, or it is the FreeBSD one maybe). Note that this initiative is purely private and, even if it should have been, is not handled by top authorities involved in all of this, like ICANN or IANA. For example dig uk.whois-servers.net +short will give you: whois.nic.uk.. The charm of this is that it should be updated if this changes (very rare) or (more often) when new registries/TLDs get live.
7. Some registries publish their whois server address endpoint using SRV which is the dedicated DNS record type to specify where a domain name handles specific service. So if you do dig _nicname._tcp.fr +short you will indeed get 0 0 43 whois.nic.fr. which gives, besides two first numbers that are not used (but could be used for load balancing/fail over), the port number (43) and server name whois.nic.fr to contact to get nicname, that is whois service under its official registered name (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml), for the fr domain. It is not used by a lot of registries, but it should have been, SRV records exactly provide this distributed auto-discovery mechanism which even works at any level of the DNS tree so that it works for registries and "sub"-registries, etc.

Note that a lot of the above will change once RDAP, a newer protocol, will replace whois. It is already defined by multiple RFCs and in use by some registries (in production for RIRs, in experiments for some domain name registries) but it is not yet contractually forced to be used by registries and registrars (for non technical reasons) in the gTLD world, and ccTLD registries seem reluctant to ditch their current whois servers to put RDAP servers instead.

Answer 3

Your WHOIS client asks a WHOIS server (on TCP port 43) and it responds directly. Debian's WHOIS client has a hardcoded list of servers which it automatically picks from. IANA also has a WHOIS service.

Source: RFC 3912