CNAMEレコード

正規名（CNAME）レコードは、ドメインネームシステム（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 ゾーンを考えます。 

名前タイプ値-------------------------------------------------- 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部分）の別名であり、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 セクション3.6.2、RFC 1912 セクション2.4) 例外はDNSSECが使用されている場合です。この場合は、RRSIG、NSECなどのDNSSEC関連レコードが存在する可能性があります。(RFC 2181 セクション10.1)
  • 他のCNAMEレコードを指すCNAMEレコードは効率が悪いため避けるべきですが、エラーではありません。[ 3 ]そのため、次のようにCNAMEレコードで解決できないループが発生する可能性があります。 
    foo.example.com。CNAME bar.example.com。bar.example.com。CNAME foo.example.com 。​​
  • CNAMEレコードはゾーン頂点には存在できません。RFC 1034 セクション 4.2.1 [ 4 ]ではゾーン頂点にSOAレコードが存在することが要求されており、RFC 1034 セクション 3.6.2 [ 5 ]ではCNAMEレコードが存在する場合は他のレコードが存在してはならないことが要求されています。したがって、CNAMEレコードはゾーン頂点には存在しません。
  • DNAME レコードによって提供される CNAME レコードは、古いリゾルバで再帰ループを引き起こす可能性があります。
  • MXレコードとNSレコードはCNAMEエイリアスを指してはなりません（RFC 2181 セクション10.3）。例えば、ゾーンには次のような構造を含める ことはできません。
    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レコードまたは委任名レコードは、 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 が返されます。

ANAMEレコード

いくつかのマネージド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 ] 。

参照

参考文献

  1. ^ Mockapetris, P. (1987年11月). 「RFC 1035 - ドメイン名 - 実装と仕様」 . インターネット技術タスクフォース. 2019年3月16日閲覧。
  2. ^ 「RFC 2181: DNS仕様の明確化」 IETF 、 1997年7月。 2011年3月9日閲覧。
  3. ^ Mockapetris, P. (1987年11月). 「RFC 1034 - ドメイン名 - 概念と機能」 . インターネット技術タスクフォース. 2019年7月15日閲覧。
  4. ^ Mockapetris, P. (1987年11月). 「RFC 1034 section 4.2.1」 . 2019年7月15日閲覧。
  5. ^ Mockapetris, P. (1987年11月). 「RFC 1034 section 3.6.2」 . 2019年7月15日閲覧。
  6. ^ Braden, R. (1989年10月). 「RFC1123 - MAIL - SMTP & RFC-822」 . 2020年7月23日閲覧。
  7. ^ Bernstein, DJ 「メール内のCNAMEレコード」 。 2011年6月3日閲覧。
  8. ^ 「ALIAS Records」 . 2019年7月26日閲覧。
  9. ^ 「ANAME Records」 . 2022年9月24日閲覧。
  10. ^ a b「アドレス固有のDNSエイリアス（ANAME）」 . 2019年7月8日. 2019年7月26日閲覧。
  11. ^ Goldlust, Suzanne; Almond, Cathy. 「ゾーンの頂点におけるCNAME」 ISCのオープンソース・ナレッジベース. Internet Systems Consortium . 2023年4月8日閲覧。
  12. ^ Schwartz, B.; Bishop, M.; Nygren, E. (2023-03-11). 「DNSを介したサービスバインディングとパラメータ指定（DNS SVCBとHTTPS RR）」. 2023年4月8日閲覧。
  • RFC  2219 – ネットワークサービスにおけるDNSエイリアスの使用
「 https://en.wikipedia.org/w/index.php?title=CNAME_record&oldid=1301947313」から取得