☰

whois を実行すると、Linux は誰に問い合わせるのでしょうか?

tag-icon • tag-icon dns whois
whois を実行すると、Linux は誰に問い合わせるのでしょうか?

次の操作を行うと:

$ whois stackoverflow.com

Linux は最初に DNS クエリを実行し、stackoverflow.com の IP を見つけて、そこで直接情報を問い合わせますか?

それとも、「ルート」whois サーバーに問い合わせて (「ルート whois サーバー」の IP は、/etc/bind/db.root? と同様の方法で Linux ディストリビューションにハードコードされていますか?)、その後、情報を提供する別の 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 などはありません。実際、whois システムには DNS に関連するものは何もありません。同じソース (レジストリ データベース) からデータを取得するという事実を除けば、これらは完全に独立して動作するため、まずはこれらを完全に区別して考える必要があります。
  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) レジストリは「薄い」ため、レジストリは連絡先に関するデータを保存せず、レジストラのみが保存します。つまり、ドメイン名に関するデータを本当に取得し、問題が発生した場合に誰に連絡すればよいかを見つけたい場合 (これは、whois プロトコルの当初の目的であり、現在もそうです)、まずレジストリの whois サーバーにクエリを実行して基本的な情報セットを取得し、レジストラの whois サーバーを検出してから、このレジストラの whois サーバーに連絡してすべての連絡先情報にアクセスする必要があります。これが、今日の .COM/.NET のレジストリ出力がドメイン ネームサーバー、日付、およびステータスに関するデータのみを提供する理由です。また、レジストラの whois サーバー名は、whois クライアントが追跡しようとしますが、状況が変化するため追跡できないことがあります (上記の私のコメントを参照してください)。
  3. ccTLD はほとんどの場合そのようには動作しません。レジストラを使用している場合でも、レジストリの whois サーバーを照会すると必要なすべての結果が返され、一部が欠落している場合でも (たとえばプライバシー上の理由で)、レジストラの whois サーバーを照会する必要はありません。これは、レジストリが処理する ccTLD に対して whois サーバーを実行することを義務付けていないためです (ただし、一部のレジストラはそれを実行します)。これは、.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 サーバーの一覧WHOIS Serverが表示されます。ただし、情報が古くなったり、間違っていたりする場合もありますのでご了承ください。 に対して TLD の whois クエリを実行してこのデータにアクセスすることもできます。whois.iana.orgこれにより、キー内の whois サーバーを含む、関連レジストリに関するデータが提供されますwhois。
  6. また、別のトリックもあります。 に対して DNS クエリを実行すると (ただし、この点によって最初のポイントが無効になるわけではないことに注意してください)、$TLD.whois-servers.netに対応する whois サーバーの名前が$TLDCNAME レコードとして返されます。一部の whois クライアントはこのトリックを使用する可能性がありますが、おそらく使用しないでしょう (whoisただし、GNU クライアントがその 1 つである可能性があり、FreeBSD クライアントがそうかもしれません)。この取り組みは完全にプライベートであり、そうあるべきであったとしても、ICANN や IANA など、これらすべてに関与している最高機関によって処理されていないことに注意してください。たとえば、 は次のようになります。dig uk.whois-servers.net +shortこのwhois.nic.uk.方法の魅力は、これが変更された場合 (非常にまれ)、または (より頻繁に) 新しいレジストリ/TLD が稼働したときに更新される必要があることです。
  7. 一部のレジストリは、SRVドメイン名が特定のサービスを処理する場所を指定するための専用 DNS レコード タイプである を使用して、whois サーバー アドレス エンドポイントを公開します。そのため、これを実行すると、dig _nicname._tcp.fr +short実際には0 0 43 whois.nic.fr.、使用されない最初の 2 つの番号 (ただし、負荷分散/フェイルオーバーには使用できます) に加えて、ポート番号 ( 43) と、whois.nic.frを取得するために接続するサーバー名が提供されnicnameます。これは、whois公式登録名 (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml) をfrドメインに対して使用します。これは多くのレジストリでは使用されていませんが、使用されるべきでした。SRV レコードはまさにこの分散自動検出メカニズムを提供し、DNS ツリーのどのレベルでも機能するため、レジストリや「サブ」レジストリなどで機能します。

RDAP という新しいプロトコルが whois に取って代わると、上記の多くが変更されることに注意してください。RDAP はすでに複数の RFC で定義されており、一部のレジストリで使用されています (RIR では運用中、一部のドメイン名レジストリでは実験中)。ただし、gTLD の世界では、レジストリやレジストラによる契約上の使用はまだ強制されておらず (技術的な理由以外)、ccTLD レジストリは、現在の whois サーバーを捨てて RDAP サーバーを代わりに設置することに消極的であるようです。

答え3

WHOIS クライアントは WHOIS サーバー (TCP ポート 43) に問い合わせ、サーバーは直接応答します。Debian の WHOIS クライアントがありますハードコードされたサーバーのリスト自動的に選択されます。IANA には WHOIS サービスもあります。

ソース：RFC 3912

関連情報