10. Naming issues (命名問題)
DNS仕様 [RFC1034, RFC1035] のいくつかのセクションから、ホスト、またはおそらくホストのインターフェイスが、正規名 (canonical name) と呼ばれる正確に1つの権威的または公式な名前を許可されていると推測されることがあります。DNSにはそのような要件はありません。
10.1. CNAME resource records (CNAMEリソースレコード)
DNS CNAME(「正規名」、canonical name)レコードは、エイリアス名に関連付けられた正規名を提供するために存在します。任意の1つのエイリアスに対して、このような正規名は1つだけ存在する可能性があります (may)。その名前は一般的にDNSの他の場所に存在する名前であるべきです (should)が、伴う正規名がDNSで未定義のエイリアスに対するいくつかのまれなアプリケーションがあります。エイリアス名(CNAMEレコードのラベル)は、DNSSECが使用されている場合、SIG、NXT、およびKEY RRを持つことができます (may) が、他のデータを持つことはできません (may have no other data)。つまり、DNS内の任意のラベル(任意のドメイン名)に対して、以下のいずれか1つが真です:
- 1つのCNAMEレコードが存在し、オプションでSIG、NXT、およびKEY RRが伴う
- 1つまたは複数のレコードが存在し、そのいずれもCNAMEレコードではない
- 名前は存在するが、関連するいかなるタイプのRRもない
- 名前はまったく存在しない
10.1.1. CNAME terminology (CNAME用語)
CNAMEレコードのラベルを「a CNAME」と呼ぶことは伝統的です。これは不幸なことです。なぜなら、「CNAME」は「canonical name」(正規名)の略であり、CNAMEレコードのラベルは確かに正規名ではないからです。しかし、これは定着した用法です。したがって、CNAMEリソースレコードのラベルを意味しているのか、値(正規名)を意味しているのかを非常に明確にするために注意を払う必要があります。本文書では、CNAMEリソースレコードのラベルは常にエイリアス (alias) と呼ばれます。
10.2. PTR records (PTRレコード)
正規名に関する混乱は、PTRレコードがそのRRSet内に正確に1つのRRを持つべきであるという信念につながりました。これは正しくありません。RFC1034の関連セクション(セクション3.6.2)は、PTRレコードの値が正規名であるべきであることを示しています。つまり、それはエイリアスであるべきではありません (should not)。そのセクションには、名前に対して1つのPTRレコードのみが許可されることを暗示するものはありません。そのような制限を推測すべきではありません (should not)。
PTRレコードの値はエイリアスであってはなりませんが (must not)、PTRレコードを解決するプロセスがいかなるエイリアスにも遭遇しないという要件はないことに注意してください。PTR値を検索しているラベルはCNAMEレコードを持つ可能性があります (might)。つまり、それはエイリアスである可能性があります。そのCNAME RRの値(別のエイリアスでない場合、そうであるべきではありません)は、PTRレコードが見つかる場所を示します。そのレコードがPTRタイプ検索の結果を与えます。この最終結果、PTR RRの値は、エイリアスであってはならないラベルです (must not)。
10.3. MX and NS records (MXおよびNSレコード)
NSリソースレコードの値として使用されるドメイン名、またはMXリソースレコードの値の一部として使用されるドメイン名は、エイリアスであってはなりません (must not)。仕様がこの点で明確であるだけでなく、これらの位置のいずれかでエイリアスを使用することは、期待どおりに機能せず、このアプローチにつながった可能性のある目標をうまく達成しません。このドメイン名は、その値として1つまたは複数のアドレスレコードを持たなければなりません (must)。現在、これらはAレコードになりますが、将来的にはアドレス情報を提供する他のレコードタイプが受け入れられる可能性があります (may)。他のRRを持つこともできます (can) が、CNAME RRであってはなりません (never)。
NSまたはMXレコードの検索は「追加セクション処理」(additional section processing) を引き起こし、検索されたレコードの値に関連付けられたアドレスレコードが応答に追加されます。これは、最初のクエリが行われたときに簡単に予想される不必要な追加クエリを回避するのに役立ちます。
追加セクション処理にはCNAMEレコードは含まれず、ましてやエイリアスから派生した正規名に関連付けられている可能性のあるアドレスレコードも含まれません。したがって、エイリアスがNSまたはMXレコードの値として使用される場合、NSまたはMX値とともにアドレスは返されません。これにより、すべてのクエリで追加のクエリと追加のネットワーク負担が発生する可能性があります。DNS管理者は、エイリアスを解決し、影響を受けるレコードが更新またはインストールされるときに正規名を直接配置することで、これを一度だけ簡単に回避できます。一部の特定の困難なケースでは、NS検索の結果に追加セクションのアドレスレコードがないことにより、リクエストが失敗する可能性があります。