whoisを実行するときにLinuxは誰に尋ねますか？

あなたがするとき：

$ whois stackoverflow.com

Linuxは最初にDNSクエリを実行し、stackoverflow.comのIPを検索して、そこに直接情報を要求しますか？

または、「ルート」whoisサーバー（Linuxディストリビューションで「ルートwhoisサーバー」のIPは、同様の方法でハードコーディングされてい/etc/bind/db.rootますか）を要求しますか？

接続フローとは何ですか？

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

または

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

Marco d'Itri'swhoisを使用している場合は、--verboseオプションを追加して、機能を確認できます。stackoverflow.comの場合、whois.verisign-grs.com（WHOISサーバーのリストを参照）に問い合わせることから始めます。これにより、Stack OverflowのレジストラーがName.comであるという事実、およびそのWHOISサーバーはwhois.name.comです。そのため、whois.name.comへの問い合わせに進みます。

プロトコルはRFC 3912で文書化されています。whoisマニュアルページはまた、便利なポインタを持っています。

スティーブンは主要な部分に答えましたが、あなたが私が対処したい他のいくつかのポイントがあります：

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に対してそれを実行することをレジストリから義務付けられていません（ただし、一部のレジストラはそれにもかかわらず行います）。これは、.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サーバーの名前が$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に置き換わると変更されることに注意してください。これはすでに複数のRFCで定義されており、一部のレジストリ（RIRの本番環境、一部のドメイン名レジストリの実験）で使用されていますが、gTLDのレジストリおよびレジストラ（技術的な理由以外）による契約での使用は強制されていません世界とccTLDレジストリは、現在のwhoisサーバーを破棄してRDAPサーバーを配置することに消極的です。

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

出典：RFC 3912