☰

當您執行 whois 時，Linux 會詢問誰？

tag-icon • tag-icon dns whois
當您執行 whois 時，Linux 會詢問誰？

當你這樣做時：

$ whois stackoverflow.com

你的Linux是否先進行DNS查詢，找到stackoverflow.com的IP，然後直接在那裡詢問資訊？

或者它是否詢問“根”whois 伺服器（“根 whois 伺服器”的 IP 是否以類似的方式硬編碼在 Linux 發行版中/etc/bind/db.root？），然後委託給另一個提供資訊的 whois 伺服器？

連結流程是怎麼樣的？

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

或者

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

答案1

如果您正在使用馬可·德伊特里whois，您可以新增--verbose選項來查看它正在做什麼。對於 stackoverflow.com，它首先詢問 whois.verisign-grs.com（請參閱其WHOIS 伺服器列表），其中提供了許多信息，包括 Stack Overflow 的註冊商是 Name.com，其 WHOIS 伺服器是 whois.name.com；然後它會繼續詢問 whois.name.com。

該協議記錄在RFC 3912。這whois線上說明頁還有有用的指針。

答案2

史蒂芬回答了核心部分，但我還有其他一些問題需要解決：

  1. Whois 是一個定義不明確的協議。沒有層次結構，沒有根whois 等。也應該將它們完全分開。
  2. 每個 TLD 註冊管理機構在這方面的運作方式都不同。 gTLD 本身就是一個例子：根據 ICANN 合同，目前每個註冊商都有義務擁有一個 whois 伺服器來回答其處理的所有網域。註冊管理機構也有相同的要求。註冊表whois 輸出列出了註冊商whois 伺服器（但正如我在上面的評論中所寫的那樣，最近情況略有變化- 事實上沒有充分的理由- 這破壞了許多whois 客戶端）主要是由於一個很快就會消失的歷史原因：在過去（現在仍然是 .COM/.NET - .JOBS 最近發生了切換，但之前處於同一條船上，請參閱https://www.icann.org/resources/pages/thick-whois-transition-policy-2017-02-01-en) 註冊機構為“thin”，這意味著註冊機構不儲存有關聯絡人的數據，只有註冊商儲存。這意味著，如果您確實想要獲得有關網域的資料並找到出現問題時的聯絡人（這曾經是，現在仍然是 whois 協議的最初目標），您需要先查詢註冊機構 whois 伺服器以取得基本資訊集並發現註冊商whois 伺服器，然後聯絡該註冊商whois 伺服器以存取所有聯絡資訊。這解釋了為什麼今天 .COM/.NET 的註冊表輸出只為您提供有關網域名稱伺服器、日期和狀態的資料。以及註冊商 whois 伺服器名稱，whois 用戶端嘗試遵循但有時不能，因為事情發生了變化（請參閱上面的評論）
  3. ccTLD 幾乎總是不會這樣工作，即使使用註冊商，查詢註冊管理機構的whois 伺服器也會讓您返回所需的所有結果，即使某些結果丟失（例如出於隱私原因），您也不需要查詢註冊商的whois 伺服器，因為註冊管理機構並未強制要求他們為自己管理的 ccTLD 運行該服務（但有些註冊服務商仍然這樣做）。.fr例如，這解釋了您對網域的觀察。
  4. 一些whois客戶端硬編碼whois伺服器的位址，有些嘗試預設whois.nic.$TLD通常作為註冊表$TLD作為nic.$TLD主要操作網域名稱。
  5. IANA 處理註冊管理機構列表https://www.iana.org/domains/root/db並在每個註冊表頁面中，例如https://www.iana.org/domains/root/db/fr.html您將看到一行WHOIS Server列出與所選註冊表相關的 whois 伺服器。但請注意，有時它可能會過時或錯誤。您還可以透過對 TLD 進行 whois 查詢來存取此數據whois.iana.org，它將為您提供有關相關註冊管理機構的數據，包括金鑰中的 whois 伺服器whois。
  6. 還有一個技巧。如果您進行 DNS 查詢（但請記住，這一點不會使第一點無效），$TLD.whois-servers.net它將為您提供 對應的 whois 伺服器的名稱$TLD，作為 CNAME 記錄。一些 whois 用戶端可能會使用這項技巧，但我對此表示懷疑（GNUwhois客戶端可能是其中之一，也可能是 FreeBSD 用戶端）。請注意，該舉措純粹是私人的，即使應該如此，也不是由參與所有這一切的最高機構（例如 ICANN 或 IANA）處理的。例如dig uk.whois-servers.net +short會給你：whois.nic.uk.。這樣做的魅力在於，如果這種情況發生變化（非常罕見）或（更常見）當新註冊管理機構/頂級網域 (TLD) 上線時，它應該進行更新。
  7. 一些註冊管理機構使用專用 DNS 記錄類型來發布其 whois 伺服器位址端點，SRV以指定網域名稱在何處處理特定服務。因此，如果您這樣做，dig _nicname._tcp.fr +short您確實會得到0 0 43 whois.nic.fr.除了兩個未使用的前兩個數字（但可用於負載平衡/故障轉移）之外，還提供了要聯繫以獲取的連接埠號碼（ 43）和伺服器名稱，即其下的服務正式註冊名稱（whois.nic.frnicnamewhoishttps://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml)，對於fr域。它沒有被很多註冊管理機構使用，但它應該被使用，SRV 記錄準確地提供了這種分散式自動發現機制，甚至可以在DNS 樹的任何層級上工作，因此它適用於註冊管理機構和「子”註冊管理機構等。

請注意，一旦 RDAP（一種較新的協議）取代 whois，上述許多內容都會改變。它已由多個RFC 定義並由一些註冊管理機構使用（在RIR 的生產中，在某些網域註冊管理機構的實驗中），但尚未透過合約強制註冊管理機構和註冊服務商（出於非技術原因）在通用頂級網域(gTLD) 中使用它世界，而 ccTLD 註冊管理機構似乎不願意放棄目前的 whois 伺服器而轉而使用 RDAP 伺服器。

答案3

您的 WHOIS 用戶端詢問 WHOIS 伺服器（在 TCP 連接埠 43 上），它會直接回應。Debian 的 WHOIS 用戶端有一個硬編碼的伺服器列表它會自動從中選擇。IANA 也提供 WHOIS 服務。

來源：RFC 3912

相關內容