シーネーム‐レコード【CNAME record】
CNAMEレコード
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2025/09/26 09:28 UTC 版)
CNAMEレコード（Canonical Nameレコード、正準名レコード、英語：Canonical Name Record）は、ドメインネームシステム（DNS）におけるリソースレコードの一種で、あるドメイン名（エイリアス）を別のドメイン名（正準名）に対応付けるものである。[1]
これは、単一のIPアドレスから複数のサービス（例えば、それぞれ異なるポートで動作するFTPサーバ と Webサーバ）を運用する際に便利である。例えば、CNAMEレコードを使用して ftp.example.com と www.example.com を example.com のDNSエントリに向けることができる。そして、その example.com は、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ゾーンを考える。
NAME TYPE VALUE
--------------------------------------------------
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.」（左辺）側が誤って「CNAME」または「a CNAME」と呼ばれることがある。しかし、これは不正確である。bar.example.comの正準（真の）名はfoo.example.comである。CNAMEはCanonical Name（正準名）の略であるため、右辺が実際の「CNAME」であり、アドレス「A」と同じ側にある。
この混乱は、RFC 2181「Clarifications to the DNS Specification」で特に言及されている。左辺のラベルは右辺（RDATA部）のエイリアスであり、右辺こそが正準名である（または、あるべきである）。[2] 言い換えれば、以下のCNAMEレコードを考える。
bar.example.com. CNAME foo.example.com.
これは、「bar.example.com」は正準名（CNAME）である「foo.example.com」のエイリアスであると解釈できる。クライアントは「bar.example.com」を要求し、その応答は「foo.example.com」となる。
制限
CNAMEレコードは常に他のドメイン名を指す必要があり、IPアドレスを指してはならない。あるノードにCNAMEレコードが存在する場合、他のデータを存在させてはならない。これは、正準名とそのエイリアスのデータが異ならないようにするためである (RFC 1034 section 3.6.2, RFC 1912 section 2.4)。例外はDNSSECが使用されている場合で、その場合はRRSIG、NSECなどのDNSSEC関連レコードが存在することがある (RFC 2181 section 10.1)。他のCNAMEレコードを指すCNAMEレコードは、効率が良くないため避けるべきであるが、エラーではない。[3] したがって、以下のようにCNAMEレコードで解決不可能なループを作成することが可能である。
foo.example.com. CNAME bar.example.com. bar.example.com. CNAME foo.example.com.
CNAMEレコードはゾーンの頂点（zone apex）に存在することはできない。RFC 1034セクション4.2.1[4]では、すべてのドメイン（ゾーン）の頂点には、そのドメイン（ゾーン）の責任者や管理情報を示すSOA (Start of Authority) レコードが必ず１つだけ存在しなければないと規定されている。これは、いわばその土地の「登記情報」のようなもので、DNSの基本ルールである。また、CNAME レコードは、あるドメイン名を別のドメイン名の「別名（エイリアス）」として定義するものなので、ある名前にCNAMEレコードを設定した場合、その名前には他の種類のレコード（SOA、MX、NSなど）を一切置くことができないという厳格なルールがある（RFC 1034セクション3.6.2[5]）。これは、途中にCNAMEを挟んで、メール配送（MX）やドメイン全体の名前解決（NS）を入れると余計な問い合わせ（ステップ）が発生し、時間がかかってしまうからである。
example.com. MX 0 foo.example.com. foo.example.com. CNAME host.example.com. host.example.com. A 192.0.2.1
SMTPのMAILコマンドやRCPTコマンドで使用されるドメインは、CNAMEレコードを持つことができない。[6] 実際にはこれは機能するかもしれないが、メールサーバによって挙動が異なる場合があり、望ましくない影響を及ぼす可能性がある。[7]
DNAMEレコード
DNAMEレコードまたはDelegation Name recordは、 RFC 6672（元のRFC 2672は廃止）によって定義されている。DNAMEレコードは、DNS内のドメイン名ツリーのサブツリーに対してリダイレクト（エイリアス）を提供する。つまり、特定のサフィックスで終わるすべての名前が、DNSの別の部分にリダイレクトされる。対照的に、CNAMEレコードは単一の名前に対してエイリアスを作成し、そのサブドメインには影響しない。CNAMEレコードと同様に、DNSルックアップは新しい名前でルックアップを再試行することで継続される。ネームサーバは、要求された名前にDNAMEレコードを実際に適用するためにCNAMEレコードを合成する。サブツリー上のすべてのノードに対するCNAMEは、サブツリー全体に対するDNAMEと同じ効果を持つ。
例えば、以下のようなDNSゾーンが存在する場合を考える。
foo.example.com. DNAME bar.example.com.
bar.example.com. A 192.0.2.23
.bar.example.com. A 192.0.2.24
*.bar.example.com. A 192.0.2.25
foo.example.com の A レコードルックアップは、DNAMEはCNAMEではなく、foo に直接Aレコードがないため、データを返さない。
しかし、x.foo.example.com のルックアップはDNAMEマッピングされ、x.bar.example.com の A レコード、つまり192.0.2.24を返す。もしDNAMEレコードがCNAMEレコードであった場合、このリクエストは「名前が見つかりません」を返しただろう。
最後に、foobar.foo.example.com のリクエストはDNAMEマッピングされ、192.0.2.25を返す。
ANAMEレコード
いくつかのマネージドDNSプラットフォームは、非標準のALIAS[8]またはANAME[9]レコードタイプを実装している。これらの疑似レコードは、DNS管理者によってCNAMEレコードのように管理されるが、（一部の）DNSクライアントによってAレコードのように公開および解決される。ANAMEレコードは通常、別のドメインを指すように設定されるが、クライアントからクエリされるとIPアドレスで応答する。ANAMEレコードタイプは標準化のために提出されたが[10]、他にも準拠していない実装が存在するため、DNSプラットフォームの所有者が選択した任意の動作をすることができる。これには、ゾーンの頂点に存在することや、メールを受信するドメインに対して存在することが含まれる。
ANAMEレコードがCNAMEレコードよりも優れている主な利点は、ゾーンの頂点で使用できることである。一方、標準に準拠したリゾルバは、CNAMEレコードを持つドメイン名をゾーンの頂点として扱わない。[11] また、DNSクライアントがCNAMEをAレコードに解決してIPアドレスを得るには少なくとも2つのクエリが必要だが、ANAMEは2番目以降のクエリをサーバ側にシフトさせる。DNSサーバが、そのDNSクライアントよりも効率的かつ低遅延でAレコードを解決し、要求されたIPアドレスをキャッシュできる場合、DNSクライアントはクエリをより速く解決できる。
ANAMEレコードタイプはIETFに標準化草案として提出された。しかし、最新の草案文書は2020年1月に失効し[10]、一連の提案に取って代わられた。その最新のものはSVCBおよびHTTPSレコードタイプの提案である。[12]
関連項目
脚注
- ^ “RFC 1035 - Domain names - implementation and specification”. Internet Engineering Task Force (1987年11月). 2025年9月26日閲覧。
- ^ “RFC 2181: Clarifications to the DNS Specification”. IETF (1997年7月). 2025年9月26日閲覧。
- ^ Mockapetris, P. (1987年11月). “RFC 1034 - Domain names - concepts and facilities”. Internet Engineering Task Force. 2025年9月26日閲覧。
- ^ Mockapetris, P. (1987年11月). “RFC 1034 section 4.2.1”. 2025年9月26日閲覧。
- ^ Mockapetris, P. (1987年11月). “RFC 1034 section 3.6.2”. 2025年9月26日閲覧。
- ^ Braden, R. (1989年10月). “RFC1123 - MAIL - SMTP & RFC-822”. 2025年9月26日閲覧。
- ^ Bernstein, D. J.. “CNAME records in mail”. 2025年9月26日閲覧。
- ^ “ALIAS Records”. 2025年9月26日閲覧。
- ^ “ANAME Records”. 2025年9月26日閲覧。
- ^ a b “Address-specific DNS aliases (ANAME)” (2019年7月8日). 2025年9月26日閲覧。
- ^ “CNAME at the apex of a zone”. ISC's Open Source Knowledgebase. Internet Systems Consortium. 2025年9月26日閲覧。
- ^ “Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)” (2023年3月11日). 2025年9月26日閲覧。
外部リンク
- RFC 2219 – Use of DNS Aliases for Network Services
- CNAMEレコードのページへのリンク
