ドメインの頂点（別名root）で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の同等性を示すことを期待していますが、これは意図されていません。頂点には、明確なレコードタイプnotが正規のホストリソース（NS、SOA）の識別に使用されています。基本的なレベル。 （特に ゾーンカット に関して）
残念ながら、元のDNS標準は、一貫した動作を定義するには明示的な言い回しが必要であることを管理団体が理解する前に作成されました（ RFC 2119 ）。 RFC 2181 を作成する必要があり、あいまいな表現によるいくつかのコーナーケースを明確にしました。更新された表現により、CNAMEcannotを使用して標準を破ることなく頂点エイリアシングを実現します。
6.1。ゾーンオーソリティ
ゾーンの権威サーバーは、ゾーンのオリジンのNSレコードに列挙されています。これは、Start of Authority（SOA）レコードとともに、すべてのゾーンの必須レコード。そのようなサーバーは、別のゾーンにないゾーンのすべてのリソースレコードに対して権限があります。NSゾーンカットは、作成された子ゾーンのプロパティであり、その子ゾーンのOriginまたはそのサブドメインの他のレコードと同様です。ゾーンのサーバーは、別のゾーンの名前に関連するクエリに対して信頼できる応答を返すべきではありませんNSとおそらくAを含むゾーンカットのレコード（他のゾーンのサーバーでもない限り）。
これは、SOAおよびNSレコードが必須であることを確立しますが、Aまたはここに表示される他のタイプについては何も述べていません。そのとき私がこれを引用することは不必要に思えるかもしれませんが、それはすぐにより関連性が高くなるでしょう。
RFC 1034 は、他のレコードタイプとともにCNAMEが存在する場合に発生する可能性がある問題について、やや曖昧でした。 RFC 2181 はあいまいさを取り除き、それらと一緒に存在できるレコードタイプを明示的に示します。
10.1 CNAMEリソースレコード
DNS CNAME（「正規名」）レコードは、エイリアス名に関連付けられた正規名を提供するために存在します。 1つのエイリアスに対して、このような正規名が1つだけ存在する場合があります。この名前は、DNSの他の場所に存在する名前である必要がありますが、DNSで定義されていない正規名が付随するエイリアスのまれなアプリケーションがいくつかあります。 エイリアス名（CNAMEレコードのラベル）は、DNSSECが使用されている場合、SIG、NXT、およびKEY RRを持つことができますが、他のデータがない場合があります。つまり、DNS（任意のドメイン名）のすべてのラベルについて、次のいずれかが正確に当てはまります。
- 1つのCNAMEレコードが存在し、オプションでSIG、NXT、およびKEY RRが付随します。
- 1つ以上のレコードが存在し、どれもCNAMEレコードではない
- 名前は存在しますが、どのタイプのRRも関連付けられていません。
- 名前はまったく存在しません。
このコンテキストでの「エイリアス名」は、CNAMEレコードの左側を指します。箇条書きのリストは、SOA、NS、およびAレコードが、CNAMEも出現するノードでは表示されないことを明確に示しています。これをセクション6.1と組み合わせると、必須のCNAMEおよびSOAレコードと一緒に存在する必要があるため、頂点にNSが存在することは不可能です。
（これでうまくいくようですが、誰かが証明へのより短いパスを持っている場合は、それをクラックしてください。）
更新：
最近の混乱は Cloudflareの最近の決定 から来ているようです。ドメインの頂点で違法なCNAMEレコードを定義できるようにしており、ドメインのAレコードを合成します。リンク先の記事で説明されている「RFC準拠」とは、Cloudflareによって合成されたレコードがDNSで適切に機能するという事実を指します。これは、完全にカスタムの動作であるという事実を変更しません。
私の意見では、これはより大規模なDNSコミュニティへの悪影響です。これは実際にはCNAMEレコードではなく、他のソフトウェアがそれを許可しないと不十分であると人々に誤解させることになります。 （私の質問が示すように）
インターネットシステムコンソーシアムは最近 ゾーンの頂点にある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」になります。