3. Impact of a Wildcard Domain Name on a Response (レスポンスに対するワイルドカードドメイン名の影響)

RFC 1034 のセクション 4.3.2 のアルゴリズムは, この文書のセクション 3.3.3 で指定されている内容を除き, 変更されていません。問題は, RFC 1034 のセクション 4.3.3 でワイルドカードを定義するように, RFC 1034 のセクション 4.3.2 のステップ 3 のパート 'c' のアルゴリズムの解釈にあります。

以下の説明では, RFC 1034 が言及される場合, そのテキストは RFC 1034 への任意の更新 (DNAME を定義する [RFC2672] など) が適用される場合にも適用されます。

3.1 Step 2 (ステップ2)

検索アルゴリズムのステップ 2 は "可能な限り最長のマッチを見つける" ことです。キャッシュされた参照が "最長マッチ" の問題に答え, 後続のステップを続ける必要性を排除すると主張されてきました。これは正しくありません。ステップ 2 を完了するには, DNS 階層のさらに先にさらに長いマッチが利用可能かどうかを判断することが含まれます。

3.2 Step 3 (ステップ3)

RFC 1034 のセクション 4.3.2 の検索アルゴリズムのステップ 3 は, ワイルドカードが呼び出される場所ですが, ドメイン名でクエリのタイプにマッチするリソースレコードセットが見つからない場合のみです。これはステップ 3 のパート 'c' です。この文は次のとおりです:

# c. If at some label, a match is impossible (i.e., the
#    corresponding label does not exist), look to see if [...]
#    the "*" label exists.
#
#    If the "*" label does not exist, check whether the name
#    we are looking for is the original QNAME in the query
#    or a name we have followed due to a CNAME.  If the name
#    is original, set an authoritative name error in the
#    response and exit.  Otherwise just exit.
#
#    If the "*" label does exist, match RRs at that node
#    against QTYPE.  If any match, copy them into the answer
#    section, but set the owner of the RR to be QNAME, and
#    not the node with the "*" label. [...]

3.3 Part 'c' (パート 'c')

これは, RFC 1034 のセクション 4.3.2 のステップ 3 のパート 'c' から引用された "look to see" テキストに関する議論です。

3.3.1 Closest Encloser and the Source of Synthesis (最近接エンクローザと合成ソース)

"closest encloser (最近接エンクローザ)" は, クエリ名に (ルートラベルから下に連続してカウントして) 最も多くのラベルがマッチするゾーンの既存のドメイン名のツリー内のノードです。各マッチは "label match (ラベルマッチ)" であり, マッチするラベルの数のカウントは "closest encloser proof (最近接エンクローザ証明)" です。ある意味で, 最近接エンクローザは, クエリ名の祖先であるゾーン内の最も深い既存のドメイン名です。

"source of synthesis (合成ソース)" は, 最近接エンクローザから即座に下降するワイルドカードドメイン名であり, そのロケーションのゾーンにワイルドカードドメイン名が表示される場合に限ります。合成ソースは, アスタリスクラベル ("*") を最近接エンクローザに前置することによって決定されます。

ワイルドカード合成に関与するワイルドカードドメイン名を説明するために "source of synthesis" というフレーズを使用することは, 有用な用語を提供し, 最左ラベル位置にアスタリスクラベルを持たない名前の使用を説明する際に問題を引き起こしません。なぜなら, それらはワイルドカードドメイン名ではないためです。

3.3.2 Closest Encloser and Source of Synthesis Examples (最近接エンクローザと合成ソースの例)

セクション 2.2.1 の例のゾーンを使用して説明します:

クエリ名 "host.example." の場合, 最近接エンクローザは "example." であり, 合成ソースは "*.example." です。

クエリ名 "a.host.example." の場合, 最近接エンクローザは "host.example." であり, 合成ソースは "*.host.example." になりますが, このワイルドカードドメイン名はゾーンの一部ではなく, 存在しません。

クエリ名 "_telnet._tcp.host.example." の場合, 完全一致が存在し, 合成ソースはありません。これは, 完全一致がワイルドカードマッチングよりも優先されるためです。

クエリ名 "_dns._udp.host.example." の場合, 最近接エンクローザは "host.example." であり, 合成ソースは "*.host.example." ですが, このワイルドカードドメイン名はゾーンに存在せず, 合成ソースはありません。

クエリ名 "*.example." の場合, 完全一致が存在し, 合成ソースはありません。

クエリ名 "a..example." の場合, 最近接エンクローザは ".example." であり, 合成ソースは "..example." ですが, これはゾーンに存在しないため, 合成ソースはありません。

クエリ名 "_telnet._tcp..example." の場合, 最近接エンクローザは ".example." であり, 合成ソースは "..example." ですが, これはゾーンに存在しないため, 合成ソースはありません。

クエリ名 "host3..example." の場合, 最近接エンクローザは ".example." であり, 合成ソースは "..example." ですが, これはゾーンに存在しません。合成ソースはありません。このケースで教訓的なのは, "host3.*.example." は存在しますが, 自身または他の名前の合成ソースではないということです。

これらの例の要点は, ネームサーバーが権威として何を答えるか (応答, 参照, NXDOMAIN, NOERROR/NODATA のいずれか) ではなく, 最近接エンクローザと合成ソースの識別です。

3.3.3 Type Matching (タイプマッチング)

RFC 1034 のセクション 4.3.3 は次のように述べています:

# 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.

および

# If the "*" label does exist, match RRs at that node against QTYPE.
# If any match, copy them into the answer section, but set the owner
# of the RR to be QNAME, and not the node with the "*" label.

最初に引用されたセクションは, RR の所有者名を変更することによってワイルドカード RRSet からレコードを合成することを説明しています。2 番目に引用されたセクションは, "match RRs ... against QTYPE" と述べ, マッチングする場合にのみコピーします。明らかに, すべての名前マッチの場合と同様に, タイプ QTYPE の RR のみをコピーできます。QTYPE が CNAME でない場合 (または QTYPE が ANY の場合), CNAME マッチはありません。CNAME の存在は他のタイプの存在を妨げます。

ワイルドカード CNAME の場合, CNAME RRSet は非 CNAME クエリにマッチせず, 合成には使用されません。これは, 求められるタイプが CNAME または ANY でない場合に, 終端ノードに存在する CNAME RRSet が無視されるのと似ています。

ワイルドカード CNAME RRSet の場合, 合成を説明する文が変更されました。RFC 1034 から:

# If the "*" label does exist, match RRs at that node against QTYPE.
# If any match, copy them into the answer section, but set the owner
# of the RR to be QNAME, and not the node with the "*" label.  Go
# to step 6.

次のように変更されました:

# If the "*" label does exist, match RRs at that node against QTYPE.
# If any match, copy them into the answer section, but set the owner
# of the RR to be QNAME, and not the node with the "*" label.
# If QTYPE is CNAME, continue with step 3.d.
# If QTYPE is not CNAME and a CNAME RRSet exists at the node,
# copy the CNAME RRSet into the answer section,
# but set the owner of the RRSet to be QNAME,
# and not the node with the "*" label.
# Go to step 6.

混乱は RFC 1034 のこの段落によって引き起こされます:

# To illustrate the use of wildcard RRs, suppose a large company with
# a large IT staff wanted to provide a TELNET gateway

混乱は, ワイルドカードから合成された CNAME RR がその後 A クエリに応答するためのアドレスを取得するために使用されるように見える例によって引き起こされます。1 つの解釈は, ワイルドカードは一種の "マクロ展開" であり, この例はワイルドカード CNAME が存在する場合に A クエリに応答する方法であるということです。別の解釈は, これは特殊なケースであるということです。3 番目の解釈は, ゾーンデータがサーバーにロードされるときにワイルドカードを展開し, その後特別な展開ルールなしで適用すべきだということです。

ワーキンググループが採用した立場は, この例は異常であり, 教育するよりも混乱を引き起こすということです。アルゴリズムの文言を変更することにより, この例はワイルドカードの誤った使用であることが明らかにされます。