CNAMEレコード

CNAMEレコード（Canonical Nameレコード、正準名レコード、英語：Canonical Name Record）は、ドメインネームシステム（DNS）におけるリソースレコードの一種で、あるドメイン名（エイリアス）を別のドメイン名（正準名）に対応付けるものである。

これは、単一の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レコードはで規定され、のセクション10で明確化されている。

CNAMEレコードはドメインネームシステム内で特別に扱われ、その使用にはいくつかの制限がある。DNSリゾルバが通常のリソースレコードを検索中にCNAMEレコードに遭遇すると、元の名前の代わりに正準名を使用してクエリを再開する。しかし、リゾルバがCNAMEレコードを検索するように明示的に指示された場合は、クエリを再開するのではなく、正準名（右辺）が返される。CNAMEレコードが指す正準名は、ローカルであれ、異なるDNSゾーンのリモートサーバ上であれ、DNS内のどこにでも存在できる。

例えば、以下のようなDNSゾーンを考える。

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部）のエイリアスであり、右辺こそが正準名である（または、あるべきである）。 言い換えれば、以下のCNAMEレコードを考える。

これは、「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レコードは、効率が良くないため避けるべきであるが、エラーではない。 したがって、以下のようにCNAMEレコードで解決不可能なループを作成することが可能である。  CNAMEレコードはゾーンの頂点（zone apex）に存在することはできない。RFC 1034セクション4.2.1では、すべてのドメイン（ゾーン）の頂点には、そのドメイン（ゾーン）の責任者や管理情報を示すSOA (Start of Authority) レコードが必ず１つだけ存在しなければないと規定されている。これは、いわばその土地の「登記情報」のようなもので、DNSの基本ルールである。また、CNAME レコードは、あるドメイン名を別のドメイン名の「別名（エイリアス）」として定義するものなので、ある名前にCNAMEレコードを設定した場合、その名前には他の種類のレコード（SOA、MX、NSなど）を一切置くことができないという厳格なルールがある（RFC 1034セクション3.6.2）。これは、途中にCNAMEを挟んで、メール配送（MX）やドメイン全体の名前解決（NS）を入れると余計な問い合わせ（ステップ）が発生し、時間がかかってしまうからである。  SMTPのMAILコマンドやRCPTコマンドで使用されるドメインは、CNAMEレコードを持つことができない。 実際にはこれは機能するかもしれないが、メールサーバによって挙動が異なる場合があり、望ましくない影響を及ぼす可能性がある。

 DNAMEレコード 

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

例えば、以下のようなDNSゾーンが存在する場合を考える。

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またはANAMEレコードタイプを実装している。これらの疑似レコードは、DNS管理者によってCNAMEレコードのように管理されるが、（一部の）DNSクライアントによってAレコードのように公開および解決される。ANAMEレコードは通常、別のドメインを指すように設定されるが、クライアントからクエリされるとIPアドレスで応答する。ANAMEレコードタイプは標準化のために提出されたが、他にも準拠していない実装が存在するため、DNSプラットフォームの所有者が選択した任意の動作をすることができる。これには、ゾーンの頂点に存在することや、メールを受信するドメインに対して存在することが含まれる。

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

ANAMEレコードタイプはIETFに標準化草案として提出された。しかし、最新の草案文書は2020年1月に失効し、一連の提案に取って代わられた。その最新のものはSVCBおよびHTTPSレコードタイプの提案である。

 関連項目 

 DNSレコードタイプの一覧
 IANA
 ICANN

 脚注 

 外部リンク 

  – Use of DNS Aliases for Network Services

Category:DNSレコードタイプ