.in WHOIS検索

調べられません。応答には登録者の氏名、組織、住所、電話番号、メールアドレスの行が定義されていますが、計測したレコードではそれらの値がプライバシー保護のため非公開でした。管理、技術、請求の各担当も同じです。RDAPのエンドポイントでも役割はエンティティとして並びますが、氏名の項目はやはり公開されません。連絡を取るなら、応答の中で名前と不正利用（abuse）窓口が公開されているレジストラが、実際に届く宛先です。

スキーマが4つの連絡先の役割を別々に定義し、それぞれに10行ほどを割り当てているからです。登録者、管理担当、技術担当、請求担当が、識別子、氏名、組織、住所、電話番号、メールアドレスとともに登場します。項目があることは、レコードの構造を示しているにすぎません。値が公開されているかどうかは別の問題で、.inではその大半が公開されていません。

確認できます。日付は非公開の対象になっていません。応答では、登録日がCreation Date、最後の変更がUpdated Date、登録期間の終わりがRegistry Expiry Dateに記載され、どれもUTCです。計測したレコードは10年の期間で登録されており、分野別ドメインでよく見る1年単位を大きく超えていました。当サイトの結果画面は、この3つの値からドメインの年数と残りの期間を算出します。

rdap.nixiregistry.inのエンドポイントは同じレコードをJSONで返し、4つの連絡先の役割を別々のエンティティとして並べます。イベントには登録、有効期限、最終変更が含まれます。身元についてはWHOISと違いがなく、氏名の項目はこちらでも非公開で返ってきます。違うのは形式です。自動化したシステムでは、プレーンテキストを解析するより、構造化された応答を使うほうが安全です。

レジストリがその行を応答に残したまま、プライバシー保護のために値を空にしたという意味です。計測したレコードでは、身元と連絡先の行にこの文言が入っており、内部のレコード識別子も同様でした。項目が埋まって見えても、データが公開されているわけではありません。この文言は値ではなく、値がない理由の説明です。この違いを見落とすツールは、非公開（REDACTED）の文言を登録者の身元であるかのように保存してしまいます。

コードはICANNの共通のEPP語彙から来ており、接頭辞を見れば誰が設定したかが分かります。clientで始まるコードは、ドメインを管理するレジストラが設定し、依頼に応じてそのレジストラが解除します。serverで始まるコードはレジストリが設定したもので、レジストラには解除できません。当サイトの結果画面では各コードが何を止めているかを表示するので、コードを覚えていなくても、ドメインを移管できない理由を読み取れます。

署名されています。ルートゾーンには.inのDSレコードがあり、2026年8月12日の計測でこれを確認しました。ただし、これはドメイン全体のレベルの事実です。個々のドメインが署名されているかどうかは別の問題で、そのドメイン名のDSレコードによって決まります。当サイトの結果画面ではこの2つを分けて表示しているので、署名済みのゾーンを署名済みのドメインと取り違えることはありません。

誰も保有していないドメインを問い合わせると、レジストリは一致するものがないと返し、58の項目はひとつも出てきません。そのドメインは登録できる状態に見えるということです。こうした結果を当サイトが保持するのは5分間だけで、登録済みのドメインなら6時間保持します。空いて見えるドメインはすぐ誰かに取得されることがあるので、保持時間を短くしているのです。