14

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 (?) ---> ... ?
Basj
  • 2,519

3 Answers3

14

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.

Community
  • 1
Stephen Kitt
  • 434,908
  • Thanks (it seems that Debian's default whois is Marco d'Itri's). Is there a command to tell whois to use another WHOIS server than verisign-grs? I didn't find it in man whois. – Basj Nov 24 '17 at 10:50
  • Something else: you said it then queries whois.name.com. Does this mean that every registrar has to have a registrar-whois server? When doing whois google.fr it doesn't seem to query another whois than the hardcoded-in-whois one, i.e. whois.nic.fr. Is that right? – Basj Nov 24 '17 at 10:51
  • Right, Debian’s default whois is Marco d’Itri (Marco is a Debian developer). The option you’re looking for is -h (see whois -h whois.name.com stackoverflow.com). Registrars don’t all have to have a WHOIS server; only the “authoritative” registrar for a TLD does AFAIK. Thus in google.fr’s case, the registrar is MARKMONITOR, but the information comes from AFNIC which is the TLD registrar for .fr. – Stephen Kitt Nov 24 '17 at 12:47
  • Thanks a lot. The funny thing is: when doing whois stackoverflow.com I get very few information, but when doing whois -h whois.name.com stackoverflow.com I get much more informations (Admin Organization: Stack Exchange, Inc., street address, etc.) that I don't get when doing whois stackoverflow.com. Is it the expected behaviour of whois, i.e. you have to first do whois domain.com, then looking at the whois server, you have to redo a whois -h ... domain.com to have more informations? Shouldn't whois do all of this directly when he finds a registrar whois? – Basj Nov 24 '17 at 13:27
  • You should get the same information, because whois stackoverflow.com does go and ask whois.name.com itself (at least, it does in version 5.2.17). You might be running into rate limiting issues, whois.name.com blocks you temporarily if you issue too many requests (but you get an error message). If I dump whois stackoverflow.com and whois -h whois.name.com stackoverflow.com and compare them, I get exactly the same name.com output in both cases. – Stephen Kitt Nov 24 '17 at 13:55
  • The key name of the registrar whois server at the registry whois output has recently changed. This broke many whois clients. If it is not updated, it will not be able to query the registrar whois server just with the registry whois output. – Patrick Mevzek Nov 25 '17 at 19:37
  • Good point @Patrick, thanks for pointing it out — this is described here, and was fixed in whois 5.2.17 (which is the current version in Debian 9). – Stephen Kitt Nov 25 '17 at 19:42
14

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.

Patrick Mevzek
  • 3,180
4

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

Community
  • 1
gmarmstrong
  • 1,233
  • 1
  • 16
  • 36
  • Thanks. Is the tld_serv_list file not available in a Debian? I searched on my filesystem but cannot find it. Does this mean it's compiled inside the whois binary /usr/bin/whois? – Basj Nov 24 '17 at 10:41
  • 1
    It is indeed compiled into the binary (see the output of strings /usr/bin/whois). – Stephen Kitt Nov 24 '17 at 12:44