ドメイン名はWHOISデータベースにどのように取り込まれ、どのデータベースが各ドメインで更新されますか？
WHOISクエリおよび応答プロトコルは、IPv4割り当て、IPv6割り当て、AS番号、RIRなどのさまざまなインターネットリソースを保持するデータベースに広く使用されています（たとえば、米国のARINや欧州のRIPE）。メンバーは、それらのデータベースにレコードを保持する必要があります（詳細はRIRに依存します）。
さらに、ISPの世界では、これらのRIR WHOISデータベースのオブジェクトに基づいて多くの自動化が行われます。たとえば、RIPEリージョンの場合はwhois.ripe.net、APNICリージョンの場合はwhois.apnic.netです。
どのWHOISデータベースにドメイン名が保持されますか？ドメインレジストラは、このWHOISデータベースにレコードを作成することが必須ですか？そうでなければ、他のドメインレジスタはドメインが使用中であることを認識しないため、「はい」と推測します。このデータベースに送信されるドメイン名以外の情報を定義するRFCはありますか？
whoisは、 RFC 3912 のみで、非常に不十分に定義されたプロトコルです（より正確には、使用開始時点で十分に定義されていますが、階層アクセスやフォーマット出力など、今日必要とされている明らかに時代遅れで欠落している重要な要素）それをカバーする（ RFC 954 を廃止）、ほとんど何も言っていません：1行でクエリを送信すると、サーバーはテキストのblobで応答します。
ドメイン名のコンテキストに入れて、歴史に戻って説明します。
- Network Solutions別名NSI（およびその後のVerisign）は、すべての.COM/.NET/.ORGドメイン名のレジストリでした。それは薄いレジストリでした。つまり、ドメイン名の連絡先に関するデータは保存されず、基本的には名前、日付、ネームサーバーのみが含まれていました（そして、レジストラが誰であるか、ステータスが何であるかなど、 ）。レジストリには
whoisサーバーがあり、出力の特定の「フィールド」は、他のデータ、主に連絡先情報（名前、郵便番号、電話番号、FAX番号）にアクセスするために照会されるレジストラーwhoisサーバーの名前を与えていました、登録者のメールアドレス、管理者、請求先、ドメイン名の技術担当者）。 whoisプロトコルには自動検出の概念がないため（ドメイン名に基づいてレジストリwhoisサーバーを検索するため、当時はccTLDなどの他のレジストリにもwhoisサーバーがありました）、「リダイレクト」（レジストリwhoisからホップする必要があるため）サーバーからレジストラwhoisサーバー）whoisクライアントは、多くの場合、接続するサーバーの値をハードコードしています（たとえば、 https://github.com/rfc1036/whois/blob/next/tld_serv_list または https：//を参照） raw.githubusercontent.com/whois-server-list/whois-server-list/master/whois-server-list.xml ）、最初はレジストリ用、場合によってはレジストラ用。ここでの他の回答を参照してください： https://unix.stackexchange.com/a/407030/21183 代替方法の詳細、特に最後のポイント。それ以外は、レジストリwhoisサーバーの応答を読み取り、さらに関連する適切なレジストラーwhoisサーバーを見つけるために関連するフィールドを抽出し、それに接続して同じクエリをやり直してより多くのデータを取得するようにプログラムされています。 「リダイレクション」のこの最後のステップは、クライアントの制御下にあることに注意してください（使用するソフトウェアに依存する可能性があります）。これを定義するwhoisプロトコル標準には何もありません。また、特にレジストラwhoisサーバー名を保持するフィールドで、レジストリwhois出力にICANNによって義務付けられた最近の変更があり、これにより、レジストリwhois出力の中からレジストラーwhoisサーバーを見つけることができなかった（更新されるまで）複数のwhoisクライアントが壊れたことにも注意してください。- GTLDについては、レジストラとレジストリはICANNと契約しています（ https://www.icann.org/resources/pages/registries/registries-agreements-en および https：//www.icannを参照してください。 org/resources/pages/registrars/registrars-en ）;これらの契約は、
whoisサーバーを実行することを義務付けています。各サーバーは、スポンサーとなっているドメイン名のレベルで（具体的には、レジストリ契約とレジストラの仕様4を参照してください： https://www.icann.org/resources/pages/approved -with-specs-2013-09-17-en＃whois ）。それどころか、ccTLDでは、当時レジストラを使用したものはほとんどなく、それでもレジストリにすべての情報があったため、レジストリwhoisの出力には必要なすべてのデータが表示されていました。 - その後、.ORGを入札プロセスに入れることが決定されました（ https://www.icann.org/resources/board-material/prelim-report-2002-03-14-en#orgReassignment を参照）。最終的にPIRに委任され（ https://www.icann.org/resources/board-material/prelim-report-2002-10-14-en#SuccessorOperatorfororgRegistry を参照）、その後すぐに切り替えられました（RRPから） EPPへ（これは入札の一部でした。 https://archive.icann.org/en/tlds/org/applications/isoc/section5.html#c27A を参照してください。 EPPは、レジストラ-レジストリ通信のRFCとしてまだ完全に公開されていませんでしたが、これは、シックモデルへの切り替えの結果もありました。レジストリは、連絡先を含むすべてのデータを格納するため、.ORGの
whois出力が開始されますレジストラwhoisサーバーに実際に照会する必要なく、すべてを表示します。ただし、契約は変更されていないため、レジストラには、レジストリにすべてのデータが既にある場合でも、.ORGで管理するドメイン名に対してwhoisサーバーを実行する権限がまだあります。ちなみに、最初は、Verisign以外の人に.NETを提供するために入札プロセスにも.NETを追加する計画もありました（たとえば、 https://afilias.info/news/2005/01/19/afilias- bids-rights-run-net-registry または http://www.core-plusplus.net/faq.do ）が、アクションのコースの変更により、.NETは予見可能な未来。 - ICANNは、最初にレジストリレベルで、次にレジストラで、
whois出力形式の標準化を開始しました。最初は、whoisプロトコル自体が応答の構造を定義しないため、各whoisサーバーには、単純なキー値（解析しやすい）から非常に複雑なもの（一部のwhoisサーバーは形式-同じクエリの場合-ある応答から別の応答まで、このすべてのデータの自動スクレイピングを抑止します）。 gTLDのレジストラにとって、特に転送の場合、ドメインの連絡先の電子メールアドレスとデータの最適なソースを知るために、whois出力（そして、上記の内容に従った場合、これはレジストリとしてレジストラwhois出力に移動します-キングのままである.COM/.NETの場合-出力には関連データがありませんでした）。しかしそれと同時に、多くの人々がさまざまな目的でwhoisデータをスクレイピングしていました。合法で有用なもの（IP保護など）から合法ではなく有用なもの（登録されたドメイン名にWebホスティングサービスを提供するスパムなど）まで。 - .COM/.NETも時々EPPに切り替えました（2005-2006年、 http://www.circleid.com/posts/additional_domain_name_transfer_requirement/ および http://web.archive.org/webを参照してください） /20061017164241/http://www.verisign.com/Resources/Naming_Services_Resources/Registrar_Connections/page_038962.html#01000005 ）ですが、まだ薄いレジストリのままです。
- しかし、最後のgTLDシンレジストリ（.COM/.NETおよび.JOBS）をシックレジストリに変換するプロセスが進行中です。プロセスは少し遅れましたが、目標はまだここにあります。 https://www.icann.org/resources/pages/thick-whois-transition-policy-2017-02-01-en を参照してください。これが達成されると、レジストラがwhoisサーバーにレジストリがすべてのデータを保持する（技術的な）理由はなくなりますが、レジストラがそれを行うことを停止する具体的な計画はまだありません（逆に、契約義務続行します）。ただし、2018年には、個人の個人データを表示する
whoisなどのサービスに直接影響するプライバシーに関する新しい欧州規制であるGDPRの導入により、状況が変わる可能性があります。 RDAPプロトコルはIETFで定義されました（ RFC 748 、 RFC 7481 、 RFC 7482 、 RFC 748 、 RFC 7484 、および RFC 8056 ）whoisの複数の欠点を解決するため、将来的にwhoisを置き換える：構造化出力（JSONの使用のおかげ）、可能なリダイレクト（HTTPの使用のおかげ）および認証機能（再びHTTPのおかげ）、国際化（たとえば、whoisプロトコルは、エンコーディングに関連するものを何も定義しません。これは、非ASCIIベースのレジストリの課題であり、相互運用性の悪夢です）、それを拡張し、あらゆる種類のレジストリに適応する可能性など、bootstrapメカニズムにより、RDAPクライアントは、クエリするRDAPサーバーのハードコードされた値の種類を持たずに動作できます。- 現在、ICANNで、すべてのレジストリ（および場合によってはレジストラ）にRDAPを実装し、
whoisを廃止する計画をスケジュールするように議論しています。これ以上の技術的な議論はありませんが、何をどの公開に正確に表示するかを定義する政治的な問題があります（ https://www.icann.org/resources/pages/rdap-operational-profile-2016-07-26-を参照してください） en ）、そしてこれは、新しいGDPRのような国の規制や法律の影響を再び受けます。現時点では、ドメイン名レジストリのパイロットのみがあります（RDAPは既に実稼働環境のRIRで使用されています）： https://community.icann.org/display/RP/RDAP+Pilot および有用なデータと https://about.rdap.org/で利用可能なリンク
具体的にあなたのポイントに返信するには：レジストラがwhois/RDAPサーバーを持っていなくても、物事は機能します。これは、誰がどのドメイン名のスポンサーであるかに関する信頼できる情報がどこにあるかではなく、これはレジストリレベルであり、誰がどのドメインを管理するかを知るために純粋に技術的にwhois/RDAPサーバーが必要なのです。レジストラが、特に今日gTLDでいくつかを実行しているという事実は、ICANNとの契約によって実行するように契約で義務付けられているためです。しかし、それは時々混乱の原因でさえあります。ここに私の他の返信を見てください： https://serverfault.com/a/885149/396475 例。
また、「whoisデータベース」という用語は使用しないでください。技術的に正しくなく、誤解を招く恐れもあります。関係するTLDの下のすべてのドメイン名に関するさまざまなデータを含むレジストリによって維持される「データベース」があります。このデータベースのコンテンツは、異なるクライアントおよび用途に応じて、さまざまなプロトコルを介して変更またはクエリすることができます：レジストラはEPPを使用してプロビジョニングし、レジストリでwhoisプロトコルを介してクエリを使用できるようにします（gTLDでは、場合によってはccTLDでクエリできることに注意してください）連絡先データやネームサーバーデータなど、ドメイン名以外のデータ用のレジストリwhoisサーバー。これはめったに使用されませんが、存在します）、レジストリは権限のあるネームサーバーでゾーンを公開するために使用します。
これについてウィキペディアを引用しますが、この場合、情報は信頼できると信じています。
地域インターネットレジストリ（RIR）が運営するWHOISサーバーは、特定のリソースを担当するインターネットサービスプロバイダーを決定するために直接照会できます。
これらの各レジストリのレコードは相互参照されるため、RIPEに属するレコードのARINへのクエリは、RIPE WHOISサーバーを指すプレースホルダーを返します。これにより、WHOISユーザーはクエリを作成して、詳細情報がRIPEサーバーにあることを知ることができます。 RIRサーバーに加えて、一部の大規模ネットワーク（たとえば、いくつかのRIRエリアで他のISPを買収した大規模なインターネットプロバイダー）が使用するルーティング資産データベースなどの商用サービスが存在します。
サーバー発見について、彼らはこう言います：
現在、DNSドメインの責任WHOISサーバーを決定するための標準はありませんが、トップレベルドメイン（TLD）には多くの方法が一般的に使用されています。一部のWHOISルックアップでは、ドメイン所有者の詳細を表示するために調達ドメインレジストラを検索する必要があります。
ソース： Whois