ドメインの頂点（ルート）でCNAMEレコードを使用できないのはなぜですか？

これは、ゾーンの頂点（またはルート）のCNAME に関する標準的な質問です。

CNAMEドメインの頂点での記録はタブーの慣習であることは比較的一般的な知識です。

例： example.com. IN CNAME ithurts.example.net.

最良の場合、ネームサーバーソフトウェアは構成のロードを拒否する場合があり、最悪の場合、この構成を受け入れ、example.comの構成を無効にする場合があります。

最近、ドメインの頂点を新しいレコードにCNAMEするために必要な指示をウェブホスティング会社からビジネスユニットに渡しました。これがBINDに送られると自殺の構成になることを知って、私は彼らが従うことができず、これは一般的に二段アドバイスであることを彼らにアドバイスしました。ウェブホスティング会社は、RFCを定義する標準によって完全に禁止されておらず、自社のソフトウェアがそれをサポートしているというスタンスを取りました。頂点をCNAMEできなかった場合、彼らのアドバイスは頂点レコードをまったく持たないことであり、リダイレクトWebサーバーを提供しませんでした。...何？

私たちのほとんどは、RFC1912がそれを主張していることを知ってA CNAME record is not allowed to coexist with any other data.いますが、ここで自分自身に正直にしましょう、RFCは単なる情報です。私が慣習を禁止していることを私が知っている言葉遣いに最も近いのはRFC1034からです：

CNAME RRがノードに存在する場合、他のデータは存在しないはずです。これにより、正規名とそのエイリアスのデータが異なることはありません。

残念ながら、私はこの業界に「あるべきではない」と「あるべきではない」と同じではないことを知っており、ほとんどのソフトウェア設計者にとってはそれで十分です。スラムダンクへの簡潔なリンク以外のものは時間の無駄になることを知っていたので、適切な開示なしに一般的に使用されているソフトウェアを破壊する可能性のある構成を推奨するために会社を怒らせました。

これにより、Q＆Aにアクセスできます。一度、私は、頂点CNAMEの狂気について本当に技術的になってほしいです。そして、誰かが主題について投稿するとき、私たちが通常するように問題を回避しません。RFC1912は、私が考えもしなかった他の情報RFCと同様に、立ち入り禁止です。この赤ちゃんをシャットダウンしましょう。

CNAMEレコードは元々、同じリソースを提供する複数の名前がリソースの単一の「正規名」にエイリアスされることを許可するために作成されました。名前ベースの仮想ホスティングの出現により、それらを一般的な形式のIPアドレスエイリアシングとして使用することが一般的になりました。残念ながら、Webホスティングのバックグラウンドから来たほとんどの人は、CNAMEレコードがDNSの同等性を示していることを期待しています。頂点には、標準的なホストリソース（、）の識別には明らかに使用されないレコードタイプが含まれます。（特にゾーンカットに関して）NSSOA

残念なことに、元のDNS標準は、一貫した動作（RFC 2119）を定義するために明示的な言葉遣いが必要であることに気づく前に、標準を管理する標準が作成されました。RFC 2181を作成して、あいまいな言葉遣いによるいくつかのコーナーケースを明確にする必要があり、更新された言葉遣いは、標準を破らずにapexエイリアシングを達成するために使用CNAME できないことを明確にします。

6.1。ゾーン権限

ゾーンの権限のあるサーバーは、ゾーンの発信元のNSレコードに列挙されます。これは、Start of Authority（SOA）レコードとともに、すべてのゾーンの必須レコードです。 このようなサーバーは、ゾーン内の別のゾーンにないすべてのリソースレコードに対して権限があります。ゾーンカットを示すNSレコードは、作成された子ゾーンのプロパティであり、その子ゾーンまたはそのサブドメインの発信元の他のレコードも同様です。ゾーンのサーバーは、他のゾーンのサーバーでもある場合を除き、ゾーンカットのNSレコード（おそらくAレコード）を含む別のゾーンの名前に関連するクエリに対して信頼できる回答を返さないでください。

これによりSOA、NSレコードが必須であることが確立されますが、ここには何も表示されないAか、他のタイプが表示されます。その場合、これを引用することは不要に思えるかもしれませんが、すぐに関連性が増します。

RFC 1034は、a CNAMEが他のレコードタイプと一緒に存在する場合に発生する可能性のある問題についてやや曖昧でした。RFC 2181は、あいまいさを取り除き、それらのそばに存在することが許可されているレコードタイプを明示的に述べています。

10.1。CNAMEリソースレコード

DNS CNAME（ "正規名"）レコードは、エイリアス名に関連付けられた正規名を提供するために存在します。1つのエイリアスには、そのような正規名が1つだけ存在する場合があります。通常、その名前はDNSの他の場所に存在する名前である必要がありますが、DNSで未定義の付随する正規名を持つエイリアスのまれなアプリケーションがいくつかあります。 エイリアス名（CNAMEレコードのラベル）は、DNSSECが使用されている場合、SIG、NXT、およびKEY RRを持つことができますが、他のデータがない場合があります。 つまり、DNSのラベル（任意のドメイン名）に対して、次のいずれか1つが当てはまります。

• オプションでSIG、NXT、およびKEY RRを伴う1つのCNAMEレコードが存在します。
• 1つ以上のレコードが存在しますが、CNAMEレコードではありません。
• 名前は存在しますが、どのタイプのRRも関連付けられていません。
• 名前はまったく存在しません。

このコンテキストでの「エイリアス名」は、CNAMEレコードの左側を指します。箇条書きリストは、それが明示的に明確にしSOA、NS、およびAレコードはノードで見ることができないCNAMEにも表示されます。これをセクション6.1と組み合わせると、a CNAMEが必須レコードSOAおよびNSレコードと共存する必要があるため、頂点に存在することは不可能です。

（これは仕事をしているようですが、誰かが証明するためのより短い道を持っているなら、それにクラックを与えてください。）

更新：

最近の混乱は、Aレコードを合成するドメインの頂点で違法なCNAMEレコードを定義できるようにするというCloudflareの最近の決定によるものと思われます。リンクされた記事で説明されている「RFC準拠」とは、Cloudflareによって合成されたレコードがDNSで適切に再生されるという事実を指します。これは、完全にカスタムの動作であるという事実を変更するものではありません。

私の意見では、これは大規模なDNSコミュニティへの不利益です。実際にはCNAMEレコードではなく、他のソフトウェアがそれを許可しないために不十分であると人々を信じ込ませます。（私の質問が示すように）

Internet Systems Consortiumは最近、ゾーンの頂点にあるCNAMEについての記事、この制限が存在する理由、および多くの代替案を投稿しました。悲しいことに、これはいつでもすぐには変更されないでしょう。

世界のすべてのDNSサーバー実装を同時に変更しない限り、特別なCNAMEレコードの使用方法を変更することはできません。これは、その意味と解釈がDNSプロトコルで厳密に定義されていたためです。現在のDNSクライアントとサーバーの実装はすべて、この仕様に準拠しています。現在動作中のすべてのDNSリゾルバーを同時に変更せずにCNAMEを信頼できるサーバーで使用する方法を「緩和」しようとすると、名前解決が中断します（そして、「緩和された」信頼できるサーバーソリューションを実装している組織では、Webおよび電子メールサービスが断続的に使用できなくなります）。

しかし、希望があります：

現在議論されている別の潜在的なソリューションは、ブラウザが検索する新しいdnsリソースレコードタイプを追加します。これは頂点に存在する可能性があります。これは、httpリクエストのアプリケーション固有のホスト名になります（MXの動作に似ています）。

長所：これはDNSの設計と完全に一致しています。
短所：これはまだ利用できません。ブラウザークライアントの更新が必要です。

ゾーン全体をリダイレクトする場合は、DNAMEを使用する必要があります。RFC 6672によると、

DNAME RRとCNAME RR [RFC1034]により、ルックアップは（潜在的に）照会されたドメイン名とは異なるドメイン名に対応するデータを返します。2つのリソースレコードの違いは、CNAME RRがその所有者のデータのルックアップを別の単一の名前に向けるのに対して、DNAME RRはその所有者の名前の子孫のデータのルックアップを別の（単一の）ノードの下の対応する名前に向けることですツリー。

たとえば、ドメイン名「foo.example.com」のゾーン（RFC 1034 [RFC1034]、セクション4.3.2、ステップ3を参照）を調べると、「example.com」でDNAMEリソースレコードが見つかります。 「example.com」の下のすべてのクエリが「example.net」に転送されること。検索プロセスは、「foo.example.net」という新しいクエリ名でステップ1に戻ります。クエリ名が「www.foo.example.com」だった場合、新しいクエリ名は「www.foo.example.net」になります。