2. Wildcard Syntax (ワイルドカード構文)

このセクションでは, レコードをワイルドカードとして解釈すること, およびワイルドカードからレコードを作成することを含む, ワイルドカードに関連する構文について説明します。セクション 2.1 と 2.2 は規範的であり, RFC 1034 のセクション 4.3.3 を更新します。

2.1 Identifying a Wildcard (ワイルドカードの識別)

RFC 1034 のセクション 4.3.3 の "wildcard" の定義は実際にはワイルドカードドメイン名の定義ですが, 用語とその使用法を混在させています。ワイルドカードドメイン名は, その初期 (すなわち最左または最下位) ラベルがバイナリ形式で次のようになることによって定義されます:

0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)

最初のオクテットは 1 オクテット長ラベルの通常のラベルタイプと長さであり, 2 番目のオクテットは '*' 文字の ASCII 表現 [RFC20] です。

この値に等しいラベルの説明的な名前は "asterisk label (アスタリスクラベル)" です。

このセクションは, ラベルとドメイン名を区別することによって定義を洗練します。

このセクションは RFC 1034 のセクション 4.3.3 を更新します。

2.1.1 Wildcard Domain Name and Asterisk Label (ワイルドカードドメイン名とアスタリスクラベル)

最初の定義は "asterisk label (アスタリスクラベル)" であり, これは次の値に等しいラベルです:

0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)

"wildcard domain name (ワイルドカードドメイン名)" は, アスタリスクラベルをその最下位ラベルとして持つことによって定義されます。

最下位ラベルにのみアスタリスクラベルを含むドメイン名の説明的な名前は "wildcard domain name (ワイルドカードドメイン名)" です。

これは, この別のセクションで繰り返されることによって顕著になった定義です。

2.1.2 Asterisks and Other Characters (アスタリスクと他の文字)

セクション 2.1.1 の値以外のラベル値はアスタリスクラベルではないため, 最左ラベル以外のラベルがその値に等しい名前はワイルドカードドメイン名ではありません。次の値に等しいラベル:

0000 0011 0111 1110 0010 1010 0010 1010 (binary)
= 0x03 0x7e 0x2a 0x2a (hexadecimal) = '~**'

その表現形式ではアスタリスクを含んでいるように見えるかもしれませんが, このラベルは * ではなく (** は 2 文字です), 最下位ラベルではないため, 特別な処理は行われません。

最下位ラベル位置以外にアスタリスクラベルを含む名前はワイルドカードドメイン名ではありません。たとえば, ドメイン名 '.example.com' がワイルドカードドメイン名である場合, 'a..example.com' はワイルドカードドメイン名ではなく, 4 つのラベルを持つ通常のドメイン名です。

2.1.3 Non-terminal Wildcard Domain Names (非終端ワイルドカードドメイン名)

ワイルドカードドメイン名はサブドメインを持つことができます。サブドメインを持つワイルドカードドメイン名と持たないものを区別する必要はありません。次の 2 つの例を考えてみましょう:

  *.example. 3600 IN MX 10 host1.example.
  host3.*.example. 3600 IN MX 10 host1.example.

ワイルドカードドメイン名の定義は a) 名前がアスタリスクラベルをその最下位ラベルとして持ち, b) 名前に少なくとも 1 つの RRSet が存在することです。"non-terminal wildcard domain name (非終端ワイルドカードドメイン名)" という用語は, データを明示的に設定されることによって存在するが, サブドメインも持つワイルドカードドメイン名を説明するために使用されます。上記の後者の例は, host3..example. がワイルドカードドメイン名 (.example.) のサブドメインを持つことを示しています。

2.2 Existence Rules (存在規則)

RFC 1034 では, ドメイン名の "存在" の概念は定義されていませんでした。すべてのドメイン名は明らかにラベルのシーケンスとしてどこかに "存在" しますが, RFC 1034 では, 存在の概念は狭い意味で意図されています。そこでは, "存在" はドメイン名が 1) 1 つ以上のリソースレコードの所有者 ("RR 所有者名") であるか, 2) 委任ポイント (delegation point) であることに基づいています。その後, "存在" の定義は [RFC2672] によって行われた変更を考慮に入れるために洗練されました。これは DNAME リソースレコードタイプを定義し, "non-terminal (非終端)" ドメイン名 (RRSet 所有者でも委任ポイントでもないドメイン名) の概念を導入しました。この改訂では RFC 2672 のセクション 8 で説明されている "non-terminal" という用語を使用しますが, 非終端が空の非終端である可能性を追加します。空の非終端のケースはセクション 2.2.2 で説明されます。

この文書では, ドメイン名の存在は次のように決定されます:

ドメイン名が 1 つ以上のリソースレコードの所有者名である場合, リソースレコードの内容またはタイプに関係なく, 存在すると言われます; そうでなければ,
ドメイン名が委任ポイントである場合, 存在します; そうでなければ,
ドメイン名が既存のドメイン名の "下" (すなわち, 既存のドメイン名のサブドメインである) にある場合, 存在します; そうでなければ,
ドメイン名は存在しません。

この状況を考慮する必要があるのは, ドメイン名がツリーから完全に削除されるケースをカバーするためです。過去には, そのような状況は考慮されませんでした。なぜなら, 結果が重要であると理解されていなかったためです。ほとんどの場合, "exist" という用語の定義の欠如は問題ではありませんでした。なぜなら, ネームサーバーはドメイン名がかつて存在したがその後削除されたことを記憶するように設計されていないためです。名前に関する情報が何もないことは, それが存在するかどうかを伝えません; それは単に無知を反映しているだけです。一般的に, かつて存在したが今は存在しないドメイン名と, 決して存在しなかったドメイン名を区別できることは意味がありません。

DNSSEC が使用される場合, ドメイン名の存在または非存在が主張される可能性があります。DNSSEC は認証された否定 (authenticated denial) のメカニズムを提供します。これは, この文書の目的のためにドメイン名の非存在の証明として定義されます。認証された否定は, "closest encloser (最近接エンクローザ)" の存在の証明を提供することによって確立されます。これはセクション 3.3.1 で説明されます。この証明のために, 存在の定義が必要であり, 上記で与えられました。

2.2.1 An Example (例)

次の RR を持つゾーンでは:

  example. 3600 IN SOA &lt;SOA RDATA>
  example. 3600 IN NS ns.example.
  *.example. 3600 IN TXT "this is a wildcard"
  host.example. 3600 IN A 192.0.2.1
  _telnet._tcp.host.example. 3600 IN SRV &lt;SRV RDATA>

ドメイン名 "example.", ".example.", "host.example.", "_telnet._tcp.host.example." は存在します。"_smtp._tcp.host.example." に対するクエリは ".example." ワイルドカードにマッチし, これは "_smtp._tcp.host.example." が存在しないことを示します (セクション 2.2 の最初の 3 つのルールに従って)。"host..example." に対するクエリは, これらの同じ 3 つのルールに従って "host..example." が存在しないことを証明するために使用できます。"_telnet._tcp..example." に対するクエリは, "_telnet._tcp..example." が既存のドメイン名の下にあり, したがって確かに存在することを示します。

2.2.2 Empty Non-terminals (空の非終端)

空の非終端 (Empty non-terminals) は, リソースレコードを所有していないが, 所有しているサブドメインを持つドメイン名です。セクション 2.2.1 では, host.example. と _telnet._tcp.host.example. は存在します。ドメイン名 _tcp.host.example. は存在しますが, RR はありません。_tcp.host.example. の存在は _telnet._tcp.host.example. の存在から推論できます; したがって, _tcp.host.example. は "empty non-terminal (空の非終端)" です。

この用語の目的は, ドメイン名自体が権威データではなく, 委任ポイントでもない状況を説明することです。空の非終端は別のドメイン名の存在の結果として存在する可能性があり, したがって暗黙的に存在すると推論されます。ドメイン名の存在が他のデータによって暗示される場合, それを列挙する理由はありません。しかし, DNSSEC では, 空の非終端の存在を明示的に列挙する必要がある場合があります。

セクション 3.3.1 から, ワイルドカードがドメイン名にマッチできる唯一の方法は, ドメイン名が存在しない場合です。存在には空の非終端が含まれます。

2.2.3 Yet Another Definition of Existence (存在のもう一つの定義)

同じ概念のさらに別の説明として: DNS では, 1) 権威データに名前を持つレコードが存在する場合, または 2) 名前が存在することが知られている別の名前の下にある場合 (カットポイントの下または RRSet 所有者名の下), ドメイン名は存在します。

DNSSEC [RFC4033] では, 存在の定義が関連します。たとえば, ワイルドカードの名前ではないがワイルドカードにマッチする名前に対するクエリへの応答は, レコードを合成する構築された応答です。この合成応答により, レコードのセットが新しい所有者名と関連付けられますが, 新しい所有者名が存在することにはなりません。これは重要です。なぜなら, DNSSEC では, 名前が "存在しない" と言われるのは, 名前の非存在の認証された証明が存在する場合のみだからです。ただし, ワイルドカード合成によって構築された名前は存在するか存在しないかが証明されていないため, リゾルバーはワイルドカードマッチに基づいて名前が存在するか存在しないかを主張してはなりません。

2.3 When Is a Wildcard Domain Name Not Special? (ワイルドカードドメイン名が特別でないとき)

この文書でのワイルドカードに関する議論は, クエリ内のドメイン名のマッチングと, 応答合成のためのワイルドカードドメイン名の使用に関連しています。"wildcard domain name" という用語は, RFC 1034 のセクション 3.4.2.2 の更新のコンテキストでは使用されません。そこでは "RRs with wildcard names" というテキストが現れます。"do not check for conflicts with wildcard domain names" という文は, "アスタリスクラベルを含むドメイン名" を意味します。名前がワイルドカードドメイン名であるかどうかは重要ではありません。言い換えれば, 更新が既存のワイルドカードと競合するかどうかを考慮する際には, 更新の内容は無視されるべきです。動的更新 (dynamic updates) とゾーン転送 (zone transfers) についても同様です。

ワイルドカードドメイン名は, レコードを合成するために使用されている場合にのみ特別です; 他のすべてのケースでは特別ではありません。ワイルドカードドメイン名は, RFC 1034 のセクション 4.3.2 で指定された解決アルゴリズムのステップ 3.c でのみ特別です。ゾーンファイルの転送を含む他のすべての状況では, ワイルドカードドメイン名は特別ではありません。