1. Introduction (はじめに)

RFC 1034 [RFC1034] のセクション 4.3.2 と 4.3.3 では, ワイルドカード (wildcards) と呼ばれる特殊なリソースレコード (Resource Records, RRs) から応答を合成することについて説明しています。RFC 1034 の定義は不完全であり, 混乱を招くことが証明されています。この文書は, 議論を追加し, 限定的な変更を加えることでワイルドカード合成を説明します。変更は, 相互運用性の問題を引き起こした不整合を解消するために行われます。この説明は, 元の定義が意図したサービスを拡張するものではありません。

元の文書の精神とスタイルを保ちながら, この文書は DNS 実装に関するワイルドカードのルールを規定することを避けています。意図は, 実装の選択を制限するのではなく, 相互運用性に必要なものだけを説明することです。さらに, RFC 1034 の定義に準拠する実装との後方互換性の問題を最小限に抑えることを考慮しています。

この文書は RFC 1034 で定義されたワイルドカードの概念に焦点を当てています。リソースレコードセット (Resource Record Sets, RRSets) を合成する代替手段については何も示唆されず, 代替案も議論されません。

1.1 Motivation (動機)

多くの DNS 実装は, 様々な方法でワイルドカードの元の定義から逸脱しています。これだけでも元の文書を明確化する必要があることは明らかですが, この文書の原動力は DNS セキュリティ拡張 (DNS Security Extensions) [RFC4033] のエンジニアリングにありました。ワイルドカードの定義が不明確であるため, 認証された否定 (authenticated denial) の設計が絡み合うようになりました。

この文書は, 実装経験に基づいて必要と判断されたもののみを文書化し, 変更を制限し, 元の文書にできるだけ近いままにすることを意図しています。この文書がワイルドカードを再定義するのではなく明確化と調整を意図していることを強化するために, RFC 1034 の関連セクションが逐語的に繰り返され, 新旧のテキストの比較を容易にします。

1.2 The Original Definition (元の定義)

ワイルドカード概念の定義は, ネームサーバーが応答を準備するアルゴリズムの文書 (RFC 1034 のセクション 4.3.2) と, リソースレコード (セット) が合成データのソースとして識別される方法 (セクション 4.3.3) から構成されます。

これは RFC 1034 のセクション 4.3.3 に現れる "wildcard" という用語の定義です。

# In the previous algorithm, special treatment was given to RRs with
# owner names starting with the label "*".  Such RRs are called
# wildcards. Wildcard RRs can be thought of as instructions for
# synthesizing RRs.  When the appropriate conditions are met, the
# name server creates RRs with an owner name equal to the query name
# and contents taken from the wildcard RRs.

この一節は, wildcard という用語が最初に使用されるアルゴリズムに続きます。この定義では, wildcard はリソースレコードを指します。他の用法では, wildcard はドメイン名を指し, 応答を生成するためにワイルドカードに依存する運用慣行を説明するために使用されてきました。このことから, ワイルドカードの議論において明確で曖昧さのない用語を定義する必要があることは明らかです。

応答の準備においてワイルドカードを使用することについての言及は, RFC 1034 のセクション 4.3.2 の "Algorithm" と題されたステップ 3 のパート 'c' に含まれています。"wildcard" はアルゴリズムには現れず, 代わりに "*" ラベルへの参照が行われることに注意してください。ワイルドカードに関連するアルゴリズムの部分は, この文書のセクション 3 で詳しく分解されます; これは "Algorithm" の関連部分の冒頭です。

#    c. If at some label, a match is impossible (i.e., the
#       corresponding label does not exist), look to see if [...]
#       the "*" label exists.

この文書の範囲は, RFC 1034 のワイルドカード定義と, DNS セキュリティ (DNS Security, DNSSEC) などのこれらの文書への更新の影響です。応答を合成する代替スキームは考慮されません。(参照は記載されていないことに注意してください。代替スキームを説明する文書は知られていませんが, メーリングリストでいくつか言及されています。)

1.3 Roadmap to This Document (この文書のロードマップ)

この文書は以下の 3 つのタスクを達成します。

新しい用語を定義する
矛盾する概念を避けるために小さな変更を加える
特定のリソースレコードのワイルドカードとしての動作を説明する

1.3.1 New Terms (新しい用語)

どのリソースレコードがワイルドカードであるかを議論するのを助けるために, 2 つの用語が定義されます: "asterisk label (アスタリスクラベル)" と "wildcard domain name (ワイルドカードドメイン名)"。これらはセクション 2.1.1 で定義されます。

RFC 1034 のセクション 4.3.2 のネームサーバーアルゴリズムにおけるワイルドカードの役割を明確化するのを支援するため, "source of synthesis (合成ソース)" と "closest encloser (最近接エンクローザ)" が定義されます。これらの用語はセクション 3.3.1 で定義されます。

1.3.2 Changed Text (変更されたテキスト)

"wildcards" の定義は, RFC 1034 のセクション 4.3.3 のテキストをこの文書のセクション 2.1 のテキストに置き換えることで変更されました。置き換えテキストは "wildcard domain name" と "asterisk label" を用語として定義します。これによって意味を変更する意図はなく, より明確にすることを望むだけです。

この変更は, RFC 1034 で wildcard という用語が 2 つの方法で定義されているために行われました。セクション 4.3.3 では, "wildcard" はリソースレコードを命名するために使用されます。セクション 4.3.2 のアルゴリズムでは, "wildcards" はドメイン名とラベルであり, リソースレコードではありません。後者の場合, wildcard という用語が 1 つの使用法か 2 つの使用法 (1 つはラベル用, もう 1 つは名前用) かが不明確だったため, 新しい用語が発明されました。

RFC 1034 のセクション 4.3.2 のステップ 3 アルゴリズムの一部が変更され, この文書のセクション 3.3.3 で規定されています。これは特殊なタイプの合成を許可し, SIG (RRSIG の旧名称) などの一部のタイプが合成ソースになることを禁止するためです。

1.3.3 Considerations with Special Types (特殊なタイプに関する考慮事項)

セクション 4 では, 様々なタイプのリソースレコードを考慮し, それらがどのように処理されるべきか, またはされるべきでないかを説明します。

CNAME が他のデータと共存できないタイプとしての定義は RFC 1034 で提示されました。しかし, "wildcard" テキストの改訂を考慮すると, 合成ソースに CNAME RRSet が存在する場合の合成の禁止を議論することは有用です。

ワイルドカードとの他のタイプのリソースレコードの相互作用は, そのステータスの順序で議論されます: 標準 (standards), 実験的 (experimental), 廃止 (obsolete), 非推奨 (deprecated)。

1.4 Standards Terminology (標準用語)

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は RFC 2119 [RFC2119] で説明されているように解釈されるものとします。

これらのキーワードはプロトコルを議論する際にのみ使用されるため, 唯一の関連コンテンツはセクション 4 であり, セクション 3 が前者から参照されます。この文書の残りの部分は情報提供目的であり, 概念を詳しく説明し明確化するために役立ちます。

RFC 1034 は, "ゾーンの完全な情報" を持つネームサーバーを説明するために "authoritative" という用語を使用しています。混乱を避けるため, この文書では "authoritative name server (権威ネームサーバー)" と "zone (ゾーン)" という用語を使用して, RFC 1034 と同じ関係を説明します。特に, ネームサーバーが特定のゾーンのコンテンツに対して権威を持つことによってです。この区別が行われるのは, ネームサーバーは一般的に複数のゾーンに対して権威を持ちますが, DNS ツリー全体に対しては権威を持たないためです。