簡潔な回答
防御的ドメインをメインサイトにリダイレクトするには?
各防御的ドメインとその www の名前を、恒久的な 301 リダイレクトでメインサイトの HTTPS アドレスにリダイレクトし、curl -I で結果を確認します。Wardmint はすべてのドメインに無料の URL フォワーディングを含むため、6つの拡張子の基本セットは年 $128.94 で、フォワーディング込みで拡張子あたり平均 $21.49 です。
防御的ドメインをメインサイトに送る方法
| 算出方法 | 仕組み | サーバーが必要 | 防御的な名前での HTTPS | 適した用途 |
|---|---|---|---|---|
| レジストラでの URL フォワーディング | レジストラのサービスがリダイレクトで応答する | いいえ | サービスによる。テストしてください | ほとんどの防御的ドメイン |
| 自社のウェブサーバーでのリダイレクト | サーバーのルールがメインサイトへの 301 を返す | はい | はい。自分で管理する証明書で | 完全な制御が必要なドメイン |
| DNS のみ(ホストへの A または CNAME) | 名前がホストを指し、ホストがリダイレクトする | はい、ホスト側で | はい。ホストが証明書を発行する場合 | すでに多数の名前を提供しているホスト |
| リダイレクトなし、メールなしで駐車 | 名前は何にも解決されず、メールも送らない | いいえ | 該当なし | 保有するだけの名前 |
なぜ防御的ドメインはリダイレクトすべきですか?
リダイレクトは入力ミスを本物のサイトへの訪問に変え、名前が空の枠になるのを防ぎます。 ユーザーはアドレスを打ち間違え、不注意に書かれたリンクを辿り、検索でバリエーションに着きます。そのバリエーションが自分のもので応答するなら、ユーザーは公式サイトに着きます。
リダイレクトするドメインは信頼にも役立ちます。エラーページを表示する防御的な名前は放置されたように見え、放置された類似ドメインはユーザーに説明しにくいものです。常に公式サイトに着く名前は、そのアドレスがあなたのものだとユーザーに伝えます。
リダイレクトは作業のウェブ側の半分です。メール側の半分は別のレコードの組で、未使用ドメインのメール偽装を防ぐ方法で扱っています。Wardmint は防御的な手法全体をタイポスクワッティングからブランドを守る方法で説明しています。
どのリダイレクトの種類を使うべきですか?
301 Moved Permanently または 308 Permanent Redirect の恒久的リダイレクトを使用してください。 どちらも RFC 9110 に定義されています。RFC 9110 は HTTP の意味論を定めるもので、どちらも、リソースが Location ヘッダーのアドレスに移動したことをクライアントに伝えます。
恒久的リダイレクトは防御的ドメインに適しています。その関係は長く続くことを前提としているからです。一時的リダイレクト（302 または 307）は、クライアントに古いアドレスを確認し続けるよう伝えるもので、キャンペーンページには合いますが、常設の派生ドメインには合いません。ユーザーは必ず最終的なアドレス、つまりメインサイトの HTTPS アドレスに一度で送ってください。二つ三つのリダイレクトが連鎖すると、攻撃者が割り込む機会が増え、ユーザーの待ち時間も長くなります。
ユーザーはメインページ、または実在するページに送ってください。ウォレット接続や署名を求めるページには決してリダイレクトしないでください。タイプミスは情報ページで終わるべきで、トランザクションで終わるべきではないからです。Wardmint は クライアントエリアからの無料URL転送とメール転送 を提供しています。
リダイレクトするだけのドメインでなぜ HTTPS が重要ですか?
プレーンな HTTP で送られるリダイレクトは、途中で改ざんされうるからです。 バリエーションを入力したユーザーは、まず HTTP 版に着くことがあります。その HTTP 応答がリダイレクトであれば、ネットワーク経路上の誰でも Location ヘッダーを変更できるため、安全な設計は、防御的な名前に有効な証明書を使った HTTPS で応答することです。
これは CAA レコードに影響します。リダイレクトする防御的ドメインには証明書が必要なので、その CAA の設定は発行する認証局を許可する必要があります。何も提供しない駐車ドメインは発行を禁止できます。構文はCAA レコードの設定方法にあります。サービスを通じて転送する場合は、頼る前に HTTPS の名前をテストしてください。対応状況はサービスによって異なります。
2026年11月12日 の Wardmint の調査によると、.com, .net, .org, .io, .xyz, .app の基本セットは6ドメインで年 $128.94、平均 $21.49 で、6つすべてでフォワーディングは無料です。
防御的ドメインをリダイレクトする6つのステップ
宛先を選ぶ
www を使うかどうかを含め、メインサイトの正確な HTTPS アドレスを決め、すべての防御的な名前でそのアドレスを使います。
フォワーディングを設定する
クライアントエリアで、ドメインの URL フォワーディングを宛先に設定します。ドメインの www の名前でも繰り返します。
恒久的なリダイレクトを使う
サービスで選べる場合は、恒久的なリダイレクト(301)を選びます。自社サーバーでリダイレクトする場合は、Location ヘッダー付きで 301 を返します。
証明書を確認する
防御的な名前を HTTPS で開き、リダイレクトの前にブラウザが警告を表示しないことを確認します。
curl でテストする
ドメインとその www の名前の http 版と https 版に対して curl -I を実行し、ステータスと Location ヘッダーを読みます。
「メールなし」レコードを追加する
null MX、SPF、DMARC のレコードを公開して、リダイレクトするドメインでメールを偽装されないようにします。
curl -sI http://example-variant.com | head -n 5
curl -sI https://example-variant.com | head -n 5
curl -sI https://www.example-variant.com | head -n 5防御的リダイレクトを壊す間違いは何ですか?
よくある間違いは、www の名前の漏れ、リダイレクトの連鎖、有効期限の失念です。 多くのユーザーは www を付けて入力するため、ベアドメインと www の名前の両方を転送してください。別の防御的ドメインを経由せず、最終アドレスに直接リダイレクトします。
3つ目の間違いは、ドメインを失効させてしまうことです。期限切れになった防御的な名前は他の人に登録され、かつてユーザーを守っていたリダイレクトが罠になります。ドメインの失効を防ぐ方法で説明しているとおり、残高からの自動更新をオンにして、資金を維持してください。
最後に、すべての防御的ドメインとその宛先のリストを保管し、メインアドレスが変わったときにすべてを更新できるようにしてください。予算を含むリストの作り方は自社ブランドの防御的ドメインリストの作り方にあります。
防御的ドメインのリダイレクトに関する質問
防御的ドメインには 301 と 302 のどちらが良いですか?
関係が恒久的なので 301 のほうが適しています。302 は移転が一時的であることをクライアントに伝えるもので、短期のキャンペーンに向いています。
防御的ドメインごとにホスティングが必要ですか?
いいえ。レジストラの URL フォワーディングはサーバーなしで応答します。応答を細かく制御したい場合のみ、自社サーバーを使ってください。
防御的ドメインはホームページと特定のページのどちらにリダイレクトすべきですか?
ホームページか情報ページに送ってください。ウォレット接続や署名を求めるページは避けてください。
Wardmint は URL フォワーディングに料金がかかりますか?
いいえ。無料の URL フォワーディングはすべてのドメインに含まれ、「メールなし」DNS テンプレートと組み合わせられます。
防御的な名前にウェブのトラフィックを一切受けたくない場合は?
ウェブサービスなしで駐車し、「メールなし」レコードを公開してください。発行を禁止する CAA レコードも検討してください。
まとめ
- 防御的ドメインは、1回の恒久的なリダイレクトでユーザーを本物のサイトに着かせるべきです。
- 正規のメインサイトの HTTPS アドレスへの 301(または 308)を使ってください。
- ベアドメインと www の名前の両方をリダイレクトしてください。
- リダイレクトするドメインには証明書が必要で、駐車したものは CAA で発行を禁止できます。
- http、https、www に対して curl -I でテストしてください。
- Wardmint の URL フォワーディングは無料で、基本セットは拡張子あたり平均 $21.49 です。
- 「メールなし」レコードを追加し、自動更新をオンのままにしてください。
出典 (2)
- RFC 9110: HTTP Semantics — IETF / RFC Editor (確認日 2026-11-12)
- RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record — IETF / RFC Editor (確認日 2026-11-12)