解決策
Cloudflare にログイン：https://www.cloudflare.com/
Cloudflare アカウントを登録
ホスティングするドメイン名を追加
Namesilo のドメイン管理画面に入る
必ず元のドメインプロバイダーの DNS を削除する
少し待つ
NS レコードが Cloudflare のサーバーに変更されたか確認する
送信をクリックした後、数分待つと Cloudflare でネームサーバーが有効になっているか確認できるようになります。有効になったら操作を開始できます。
[Cloudflare]：登録したアカウントにメールが送信されます
- カスタムドメインの設定
Xlog はカスタムドメインプランを無料で提供しています。ここでは私の Xlog ブログの設定を例にします
方法は次の通りです：Xlog コンソールに入り、設定をクリック —— ドメイン —— カスタムドメイン、あなたのドメイン名を入力します（例：igdux.com、https:// または http:// は入力しないでください）。この時、Xlog はドメインの所有権を確認するよう求めます。
解析に入力
元の cloudflare.com サーバーアドレスは不要で、自分の解析 DNS を追加してください
- 301 裸ドメインリダイレクトの設定
裸ドメインリダイレクトとは、www.igdux.com ドメインにアクセスすると、www なしのドメイン igdux.com にリダイレクトされることを指します。301 は永久リダイレクトを設定するもので、一時的なものではなく、探索エンジンが認識しやすくするためです。
Cloudflare アカウントの下で、xlog.app サブドメインにバインドされたカスタムドメインを選択します。例えば、私のカスタムドメインは igdux.com です。ドメインを選択 —— ルール —— ページルールを設定します。
URL：あなたのドメイン /（例：google.com/）
設定を選択：URL を転送； ステータスコードを選択：301
宛先 URL（ターゲット URL）：https:// あなたのドメイン
クラウド解析 DNS
後に Cloudflare の公式説明に従い、ドメインを 1.1.1.1 に指向させた顧客は現在 1034 エラーに直面しています。これは、Cloudflare システムが新しいエッジ検証チェックを導入したためで、設定ミスや潜在的な悪用を防ぐことを目的としています。
クッキーを有効にしてください。
エラー 1034
Ray ID: 8cac8b6698368a63 • 2024-09-29 14:08:18 UTC
エッジ IP 制限
何が起こったのですか？
Cloudflare ネットワークの一部であるウェブサイトのページをリクエストしました。ホスト（ladfenemies.cc）は、ウェブサイトの所有者がアクセスできない IP アドレスに解決されました。
私は何をすればよいですか？
このウェブサイトの訪問者の場合：
数分後に再試行してください。
このウェブサイトの所有者の場合：
DNS レコードを確認して、登録時に割り当てられた IP アドレスに指向していることを確認してください。
このページは役に立ちましたか？ はい いいえ
フィードバックありがとうございます！
Cloudflare Ray ID: 8cac8b6698368a63
解決策
公式説明：DNS レコードがあなたが制御する IP アドレスを指していることを確認してください。「無発信」設定を行うには、プレースホルダー IP アドレスが必要な場合は、IPv6 の予約アドレス 100:: または IPv4 の予約アドレス 192.0.2.0 を使用してください。
簡単に言うと、DNS パネルで選択した IP を別の IP に変更するだけで、公式の 1.1.1.1 や現在使用しているものを使用しないでください。
なぜ DNSSEC を有効にする必要がありますか？#
非常に
明らかに、有効にするとより安全です。どこがより安全かは私にもわかりません。そして無料です！
一部の偽造を防ぐことができるはずです……
どうやって有効にしますか？
まず Cloudflare ダッシュボードにアクセスし、「ゾーン」に入り、サイドバーで DNS を見つけ、DNS → 設定に移動します：
この時点で非常に明確な「DNSSEC を有効にする」が表示されます。「DNSSEC を有効にする」をクリックします。少し待つと、Cloudflare が追加する必要のある DS レコードを提供します。
次に、自分の DS レコードを追加できます。
Namesilo のフィールドと Cloudflare が表示するフィールドの対応関係は次のようになります：
Namesilo Cloudflare
ダイジェスト 摘要
キータグ 密钥标记
ダイジェストタイプ 摘要类型 – 2
アルゴリズム 算法
DNS 解析における A レコード、AAAA レコード、CNAME レコード、MX レコード、NS レコード、TXT レコード、SRV レコード、URL 転送など#
A
A レコード：ドメイン名を IPv4 アドレス（例：100.100.100.100）に指向させるため、A レコードを追加する必要があります。
NS
NS レコード：ドメイン名解決サーバーレコードで、サブドメインを特定のドメイン名サーバーに指定して解決する必要がある場合、NS レコードを設定する必要があります。
SOA
SOA レコード：SOA は開始権限機関レコードを指し、NS は複数のドメイン名解決サーバーを識別するために使用され、SOA レコードは多くの NS レコードの中でどれが主サーバーであるかを示します。
MX
MX レコード：電子メールサービスを構築し、メールサーバーアドレスを指向させるため、MX レコードを設定する必要があります。メールボックスを作成する際、通常はメールサービスプロバイダーが提供する MX レコードに基づいてこのレコードを記入します。
TXT
TXT レコード：任意に記入でき、空でも構いません。一般的に、いくつかの検証レコードを作成する際に使用されます。例えば、SPF（スパム対策）レコードを作成する際に使用されます。
ドメイン名解決は、ドメイン名から IP アドレスへの変換プロセスであり、DNS サーバーによって実行されます。DNS サーバーは、ドメイン名を IP アドレスに解決し、その IP アドレスのホスト上でサブディレクトリをドメイン名にバインドします。ドメイン名解決時には解析レコードが追加され、これらのレコードには A レコード、AAAA レコード、CNAME レコード、MX レコード、NS レコード、TXT レコード、SRV レコード、URL 転送が含まれます。
- DNS ドメイン解決に追加される各種解析レコード
A レコード：ドメイン名を IPv4 アドレス（例：100.100.100.100）に指向させるため、A レコードを追加する必要があります。
CNAME レコード：ドメイン名を別のドメイン名に指向させ、指向されたドメイン名と同じアクセス効果を実現するため、CNAME レコードを追加する必要があります。このドメイン名は通常、ホスティングサービスプロバイダーが提供するドメイン名です。
MX レコード：電子メールサービスを構築し、メールサーバーアドレスを指向させるため、MX レコードを設定する必要があります。メールボックスを作成する際、通常はメールサービスプロバイダーが提供する MX レコードに基づいてこのレコードを記入します。
NS レコード：ドメイン名解決サーバーレコードで、サブドメインを特定のドメイン名サーバーに指定して解決する必要がある場合、NS レコードを設定する必要があります。
TXT レコード：任意に記入でき、空でも構いません。一般的に、いくつかの検証レコードを作成する際に使用されます。例えば、SPF（スパム対策）レコードを作成する際に使用されます。
AAAA レコード：ホスト名（またはドメイン名）を IPv6 アドレス（例：ff03:0:0:0:0:0:0）に指向させるため、AAAA レコードを追加する必要があります。
SRV レコード：サービスレコードを追加する際にこの項目が追加され、SRV レコードはどのコンピュータがどのサービスを提供しているかを示します。形式は：サービス名。プロトコルタイプ（例：_example-server._tcp）。
SOA レコード：SOA は開始権限機関レコードを指し、NS は複数のドメイン名解決サーバーを識別するために使用され、SOA レコードは多くの NS レコードの中でどれが主サーバーであるかを示します。
PTR レコード：PTR レコードは A レコードの逆向きレコードで、IP 逆引きレコードまたはポインタレコードとも呼ばれ、IP を逆にドメイン名に解決する役割を果たします。
明示的 URL 転送レコード：ドメイン名を http (s) プロトコルアドレスに指向させ、ドメイン名にアクセスすると自動的にターゲットアドレスにリダイレクトされます。例えば：www.liuht.cn を明示的に www.itbilu.com に転送すると、www.liuht.cn にアクセスした際、アドレスバーに表示されるアドレスは：www.itbilu.com になります。
暗黙的 URL 転送レコード：ドメイン名を http (s) プロトコルアドレスに指向させ、ドメイン名にアクセスすると自動的にターゲットアドレスにリダイレクトされ、暗黙的転送は実際のターゲットアドレスを隠します。例えば：www.liuht.cn を明示的に www.itbilu.com に転送すると、www.liuht.cn にアクセスした際、アドレスバーに表示されるアドレスは依然として：www.liuht.cn になります。
- DNS 解析に関するいくつかの問題
2.1 A レコードと CNAME レコード
A レコードはドメイン名を IP アドレスに解決し、CNAME レコードはドメイン名を別のドメイン名に解決します。この別のドメイン名は最終的に A レコードを指向します。機能的には A レコードと CNAME レコードに違いはありません。
CNAME レコードは IP アドレスの変更時に A レコードよりも便利です。CNAME レコードは複数の名前を同じコンピュータにマッピングすることを許可します。複数のドメイン名が同じサーバー IP を指向する必要がある場合、1 つのドメイン名を A レコードとしてサーバー IP に指向させ、他のドメイン名をその A レコードのドメイン名にエイリアス（すなわち CNAME）として設定できます。サーバー IP アドレスが変更された場合、A レコードのドメイン名を新しい IP に変更するだけで、他のエイリアスのドメイン名は自動的に新しい IP アドレスに変更され、各ドメイン名を変更する必要はありません。
2.2 A レコードと AAAA レコード
両者は IP アドレスを指向しますが、対応する IP バージョンが異なります。A レコードは IPv4 アドレスを指向し、AAAA レコードは IPv6 アドレスを指向します。AAAA レコードは A レコードのアップグレード版です。
2.3 IPv4 と IPv6
IPv4 はインターネットプロトコル（Internet Protocol、IP）の第 4 版であり、最初に広く使用されたバージョンであり、現在のインターネット技術の基礎プロトコルを構成しています。IPv4 の次のバージョンは IPv6 であり、将来的には現在広く使用されている IPv4 に取って代わるでしょう。
IPv4 では IP アドレスの長さが 32 ビット（TCP/IP 参照モデルに基づく）であり、2^32-1 個のアドレスがあります。IPv6 の提案は、インターネットの急速な発展に伴い IPv4 アドレス空間が枯渇する問題を解決するために行われました。アドレス空間を拡大するために、IPv6 は IP アドレスの長さを 32 ビットから 128 ビットに増加させました。IPv6 の設計過程では、アドレス不足の問題を一度で解決するだけでなく、IPv4 の他の問題（エンドツーエンドの IP 接続、サービス品質（QoS）、セキュリティ、マルチキャスト、モビリティ、プラグアンドプレイなど）も解決しました。
2.4 TTL 値
TTL－生存時間（Time To Live）は、解析レコードが DNS サーバー内でキャッシュされる時間を示します。TTL の時間単位は秒で、一般的には 3600 秒です。例えば：www.itbilu.com にアクセスする際、DNS サーバーのキャッシュにそのレコードがない場合、特定の NS サーバーにリクエストを送信し、そのレコードを取得した後、そのレコードは DNS サーバーに TTL の時間長さで保存されます。TTL の有効期限内に www.itbilu.com にアクセスすると、DNS サーバーはキャッシュから先ほどのレコードを直接返します。
以下に DNS の SOA レコードについて簡単に紹介します：
すべての DNS レコードファイル（Domain Name System (DNS) Zone file）は、SOA（Start of Authority）レコードから始まります。SOA リソースレコードは、この DNS 名サーバーがその DNS ドメイン内のデータに関する情報の最良のソースであることを示します。SOA レコードと NS レコードの違い：簡単に言うと、NS レコードはドメイン名サーバーレコードであり、どの DNS サーバーがそのドメイン名を解決するかを指定するために使用されます。SOA レコードは、データのバージョン、更新、期限切れの情報を設定します。
SOA レコードは次のとおりです：
プライマリネームサーバー：ns51.domaincontrol.com
ホストマスターのメールアドレス：dns.jomax.net
シリアル番号：2010123100
リフレッシュ：28800
リトライ：7200
期限切れ：604800 1 週間
デフォルト TTL：86400
プライマリネームサーバー：
DNS レコードファイルが存在するホストの位置。
連絡先メールアドレス：
レコードのホスト管理者の連絡先で、最初のドットは @を示します。
シリアル番号：
形式は yyyymmddnn で、nn はその日が何回目の修正であるかを示します。補助ネームサーバーはこのシリアル番号を比較して新しいゾーンデータのコピーをロードします。
リフレッシュ（Refresh）：
そのゾーンの補助ネームサーバーがどれくらいの頻度でそのゾーンのデータが最新であるかを確認するかを示します。
リトライ（Retry）：
補助ネームサーバーがリフレッシュ間隔の時間を超えてプライマリサーバーにアクセスできない場合、一定の時間が経過した後に再接続を試みます。この時間は通常リフレッシュ時間よりも短いですが、必ずしもそうである必要はありません。
期限切れ（Expire）：
期限切れの時間内に補助ネームサーバーがプライマリサーバーに接続できない場合、補助ネームサーバーはこのゾーンの回答を停止します。これは、これらのゾーンデータが古くなり、もはや使用できないことを意味します。設定時間はリフレッシュとリトライの時間よりも長く、週単位で設定するのが合理的です。
否定キャッシュ TTL（生存期間）：
この値は、このゾーンの権威あるネームサーバーからの否定的な応答に適用されます。
Microsoft DNS サーバーの SOA レコードのデータ構造は次のようになります：
@ IN SOA nameserver.place.dom. postmaster.place.dom. (
1 ; シリアル番号
3600 ; リフレッシュ [1h]
600 ; リトライ [10m]
86400 ; 期限切れ [1d]
3600 )