CNAMEレコード

正規名（CNAME ）レコードは、ドメインネームシステム（DNS）のリソースレコードの一種であり、あるドメイン名（エイリアス）を別のドメイン名（正規名）にマッピングします。^[1]

これは、単一のIP アドレスから複数のサービス (それぞれ異なるポートで実行されているFTP サーバー とWeb サーバーなど) を実行する場合に便利です。たとえば、CNAME レコードを使用して、ftp.example.comとwww.example.com をexample.comの DNS エントリにポイントできます。このエントリには、IP アドレスを指すA レコードがあります。その後、IP アドレスが変更された場合は、ネットワーク内の 1 か所、つまりexample.comのDNS A レコードに変更を記録するだけで済みます。

CNAME レコードは常に別のドメイン名を指す必要があり、IP アドレスを直接指してはいけません。

DNS CNAME レコードはRFC 1034 で規定されており、 RFC 2181 のセクション 10 で明確にされています 。

CNAME レコードは、ドメイン ネーム システムで特別に処理され、使用に関していくつかの制限があります。DNSリゾルバーが通常のリソース レコードを探しているときに CNAME レコードに遭遇すると、元の名前ではなく正規名を使用してクエリを再開します。ただし、リゾルバーに CNAME レコードを探すように明示的に指示されている場合は、クエリを再開するのではなく、正規名 (右側) が返されます。CNAME レコードが指す正規名は、ローカルでも、別のDNS ゾーンのリモート サーバーでも、DNS 内のどこにでも配置できます。

たとえば、次のような DNS ゾーンがあるとします。

名前タイプ値-------------------------------------------------- bar.example.com. CNAME foo.example.com. foo.example.com. A 192.0.2.23                       

          
              

bar.example.comのA レコード検索が実行されると、リゾルバは CNAME レコードを確認し、foo.example.comの検索を再開して、192.0.2.23 を返します。

CNAME レコードを使用すると、「 bar.example.com 」などの名前を「 foo.example.com 」に指定できます。このため、日常会話では、DNS エントリの「bar.example.com.」(左側) が誤って「the CNAME」または「a CNAME」と識別されることがあります。ただし、これは正確ではありません。「bar.example.com」の正規の (本当の) 名前は「foo.example.com」です。CNAME は Canonical Name の略語であるため、右側が実際の「CNAME」であり、アドレス「A」と同じ側にあります。

この混乱は、RFC 2181「DNS仕様の明確化」で具体的に言及されています。左側のラベルは、右側（RDATA部分）の別名であり、正規名である（または正規名であるべき）ものです。^[2]つまり、次のようなCNAMEレコードです。

bar.example.com。CNAME foo.example.com 。          

次のように読むことができます。

「bar.example.com 」は正規名 (CNAME)「 foo.example.com 」の別名です。クライアントは「bar.example.com」を要求し、応答は「foo.example.com」になります。

DNAMEレコードまたは委任名レコードは、 RFC 6672で定義されています (元の RFC 2672 は現在廃止されています)。DNAME レコードは、DNS のドメイン名ツリーのサブツリーのリダイレクト (エイリアス) を提供します。つまり、特定のサフィックスで終わるすべての名前は、DNS の別の部分にリダイレクトされます。対照的に、CNAME レコードは、サブドメインではなく、単一の名前のエイリアスを作成します。CNAME レコードと同様に、DNS ルックアップは、新しい名前でルックアップを再試行することで続行されます。ネーム サーバーは、CNAME レコードを合成して、要求された名前に DNAME レコードを実際に適用します。サブツリー上のすべてのノードの CNAME は、サブツリー全体の DNAME と同じ効果があります。

たとえば、次のような DNS ゾーンがあるとします。

foo.example.com. DNAME bar.example.com. bar.example.com. A 192.0.2.23 xyzzy.bar.example.com. A 192.0.2.24 *.bar.example.com. A 192.0.2.25          
              
        
            

DNAME は CNAME ではなく、fooに直接 A レコードが存在しないため、 foo.example.comのAレコード検索ではデータが返されません。

ただし、 xyzzy. foo .example.comの検索はDNAME マッピングされ、xyzzy. bar .example.comのAレコード(192.0.2.24) を返します。DNAME レコードが CNAME レコードであった場合、この要求は名前が見つからないことを返します。

最後に、 foobar.foo.example.comへのリクエストはDNAME マッピングされ、192.0.2.25 が返されます。

いくつかのマネージドDNSプラットフォームは、非標準のALIAS ^[8]またはANAME ^[9]レコードタイプを実装しています。これらの疑似レコードは、CNAMEレコードのようにDNS管理者によって管理されますが、Aレコードのように（一部の）DNSクライアントによって公開および解決されます。ANAMEレコードは通常、別のドメインを指すように設定されますが、クライアントから照会されると、IPアドレスで応答します。ANAMEレコードタイプは標準化のために提出されましたが、^[10]他の非準拠の実装もあり、ゾーンの頂点に存在することやメールを受信するドメインに存在することなど、DNSプラットフォームの所有者が選択したことを何でも行うことができます。

ANAMEレコードがCNAMEレコードよりも優れている主な点は、ゾーンの頂点で使用できることです。一方、標準に準拠したリゾルバは、CNAMEレコードを持つドメイン名をゾーンの頂点として扱いません。^[11] また、DNSクライアントはCNAMEをAレコードに解決してIPアドレスを取得するために少なくとも2つのクエリを必要としますが、ANAMEは2番目以降のクエリをサーバーに転送します。DNSサーバーがAレコードを解決し、要求されたIPアドレスをDNSクライアントよりも効率的かつ少ない遅延でキャッシュできる場合、DNSクライアントはクエリをより速く解決できます。

ANAMEレコードタイプはIETFに標準案として提出されました。しかし、最新のドラフト文書は2020年1月に期限切れとなり^[10]、一連の提案に置き換えられました。そのうち最新のものはSVCBレコードタイプとHTTPSレコードタイプの提案です。^[12]

• DNSレコードタイプのリスト
• インターネット割り当て番号機関
• ICANN

• RFC 2219 – ネットワーク サービスにおける DNS エイリアスの使用