メインコンテンツまでスキップ

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

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

これは様々なタイプに対するアクションの要約です。これらの規定のほとんどは, あるタイプの RR が共存できるかどうかによるものです。一部は単なる観察です。

4.1 SOA RRSet at a Wildcard Domain Name (ワイルドカードドメイン名での SOA RRSet)​

SOA RRSet を所有するワイルドカードドメイン名は, ドメインがゾーンの頂点にあり, ワイルドカードドメイン名であることを意味します。これは RFC 1035 の SOA 定義の洗練であり, そこでは SOA RR がゾーンの頂点に存在します。これは明確化のみです; 仕様の変更を示す意図はありません。

ワイルドカードドメイン名による SOA レコードの所有は定義されていない効果を持ちます。ワイルドカードを使用して SOA レコードを合成する状況を避けるために, SOA レコードはワイルドカードドメイン名の唯一のレコードであってはなりません。

この禁止は AXFR と IXFR に影響を与えますが, ここでは議論しません。

4.2 NS RRSet at a Wildcard Domain Name (ワイルドカードドメイン名での NS RRSet)​

RFC 1034 はセクション 4.2.2 で NS レコードの所有権に制限を設けています:

# If a CNAME RR is present at a node, no other data should be
# present; this ensures that the data for a canonical name and its
# aliases cannot be different.  This rule also insures that a
# cached CNAME can be used without checking with an authoritative
# server for other RR types.

委任ポイント名と委任の RDATA に現れるドメイン名の間には重要な区別があります。前者は NS RRSet を持つ名前です; 後者は A または AAAA RRSet を持つ可能性のある名前です。たとえば, 委任の場合:

  foo.example. NS ns1.example.
  ns1.example. A 192.0.2.1

名前 "foo.example." は委任ポイント名であり, "ns1.example." は RDATA に現れる名前です。名前 "foo.example." は NS RRSet を持ちます。名前 "ns1.example." は A RRSet を持ちます。これは非常に重要な区別です。なぜなら, ワイルドカード合成は後者には適用できますが, 前者には適用できないからです。

ワイルドカードドメイン名は委任ポイントではありません。NS RRSet の合成は定義されていません。以前のいくつかの DNS 作業は委任ポイントの合成を許可することを検討しましたが, この可能性は拒否されました。RFC 1034 は次のように述べています:

# A particular subzone and the associated NS RRs are added to the
# zone when the domain administrator decides to delegate the
# subzone, by adding the subzone's NS RRs to the parent zone.

委任の決定は NS RR がゾーンに追加されるときに行われます。"adding NS RRs to a zone" というフレーズは, 委任ポイントが明示的な構成によって追加されることを意味すると解釈されてきました。"wildcard" という用語は RFC 1034 の委任部分 (セクション 4.2.2) には現れません。したがって, ワイルドカードは意図的に NS RR には使用されません。

NS の合成が許可されていないため, 合成を実行するサーバーに追加の作業はありません。

4.2.1 Discarded Notions (廃棄された概念)​

かつて, 委任ポイントの合成, ゾーン内データの合成, ネームサーバー名の合成の間に区別が設けられていました。この文書が委任ポイントの合成が許可されないことを規定しているため, この区別をさらに探求する必要はありません。同様に, ゾーン内ワイルドカードマッチとネームサーバー名のマッチを区別する必要もありません。

4.3 CNAME RRSet at a Wildcard Domain Name (ワイルドカードドメイン名での CNAME RRSet)​

CNAME とワイルドカードの相互作用は, この文書のセクション 3.3.3 で更新されています。ワイルドカードドメイン名での CNAME RRSet は CNAME RR を合成するためにのみ使用できます。CNAME RRSet を所有するワイルドカードドメイン名は, 他のリソースレコードを所有できません。

4.4 DNAME RRSet at a Wildcard Domain Name (ワイルドカードドメイン名での DNAME RRSet)​

ワイルドカードドメイン名による DNAME [RFC2672] RRSet の所有は, DNS の一貫性に対する脅威を表し, 回避または完全に拒否されるべきです。このような DNAME RRSet は, 異なるキャッシュに供給されるルールの非決定論的合成を表します。キャッシュが異なるルール (予測不可能な方法で) を供給されると, キャッシュは一貫性を失います。("キャッシュが供給される" とは, 再帰または反復サーバーによって応答で取得されたレコードをキャッシュに保存することを指します。)

たとえば, 1 つのキャッシュが再帰リクエストに応答して次のレコードを取得すると仮定します:

  "a.b.example. DNAME foo.bar.example.net."

別のキャッシュは次を取得します:

  "b.example.  DNAME foo.bar.example.net."

両方とも権威サーバーによってレコードから生成されます:

  "*.example. DNAME foo.bar.example.net."

DNAME 仕様は, キャッシュ内の DNAME レコードがクエリを書き換えるために使用されるかどうかについて明確ではありません。いくつかの解釈では書き換えが発生します; 他の解釈では発生しません。書き換えの発生を許可すると, "sub.a.b.example. A" のクエリは前者のキャッシュサーバーによって "sub.foo.bar.tld. A" に書き換えられる可能性があり, 後者によって "sub.a.foo.bar.tld. A" に書き換えられる可能性があります。一貫性が失われ, 運用上の悪夢が続きます。

ワイルドカード DNAME レコードの使用を避けることを推奨するもう 1 つの正当化は, そのようなレコードが "sub.foo.bar.example." と "foo.bar.example." によって所有される DNAME を合成できるという観察です。DNAME 定義には, DNAME を所有するドメインの下にドメインが存在してはならないという制限があります; したがって, ワイルドカード DNAME は避けるべきです。

4.5 SRV RRSet at a Wildcard Domain Name (ワイルドカードドメイン名での SRV RRSet)​

SRV RRset の定義は RFC 2782 [RFC2782] です。レコードの定義では, "Name" という用語についていくつかの混乱があります。定義は次のように読まれます:

# The format of the SRV RR
...
#    _Service._Proto.Name TTL Class SRV Priority Weight Port Target
...
#  Name
#   The domain this RR refers to.  The SRV RR is unique in that the
#   name one searches for is not this name; the example near the end
#   shows this clearly.

定義 "Name" を所有者名と混同しないでください。つまり, SRV RRSet の所有者名から _Service と _Proto ラベルを削除すると, 残りがワイルドカードドメイン名である可能性がありますが, これは SRV RRSet には重要ではありません。

たとえば, SRV レコードが次のようである場合:

  _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.

.example はワイルドカードドメイン名であり, SRV RR の Name ですが, 所有者 (ドメイン名) ではありません。所有者ドメイン名は "_foo._udp..example." であり, これはワイルドカードドメイン名ではありません。

"_foo._udp.bar.example." (class IN) の SRV RRSet のクエリは, (bar.example. が存在しないと仮定して) 名前 ".example." のマッチになり, 示されている SRV レコードのマッチにはなりません。".example." に SRV RRSet がない場合, 応答セクションはそれを反映します (空または CNAME RRset)。

混乱は, SRV RR の仕様と "ユースケース" の説明の混在に基づいている可能性があります。

4.6 DS RRSet at a Wildcard Domain Name (ワイルドカードドメイン名での DS RRSet)​

ワイルドカードドメイン名によって所有される DS RRSet は無意味で無害です。この声明は, ワイルドカードドメイン名での NS RRSet が定義されていないというコンテキストで行われます。非委任ポイントでは, DS RRSet には価値がありません (DNSSEC 検証で使用される対応する DNSKEY RRSet はありません)。合成された DS RRSet が存在する場合, それだけでは非常に有用ではありません。なぜなら, それは委任ポイントのコンテキストに存在するからです。

4.7 NSEC RRSet at a Wildcard Domain Name (ワイルドカードドメイン名での NSEC RRSet)​

DNSSEC 署名ゾーン内のワイルドカードドメイン名は NSEC RRSet を持ちます。これらのレコードの合成は, クエリがレコードと完全に一致する場合にのみ発生します。合成された NSEC RR は有害ではありません。なぜなら, それらはネガティブキャッシュや否定応答の生成に使用されることは決してないからです [RFC2308]。

4.8 RRSIG at a Wildcard Domain Name (ワイルドカードドメイン名での RRSIG)​

RRSIG レコードは署名ゾーン内のワイルドカードドメイン名に存在し, クエリで求められるデータとともに合成されます。所有者名が合成されるという事実は問題ではありません。なぜなら, RRSIG 内のラベルカウントが検証コードにそれを無視するように指示するからです。

4.9 Empty Non-terminal Wildcard Domain Name (空の非終端ワイルドカードドメイン名)​

合成ソースが空の非終端である場合, 応答は戻りコードにエラーがなく, 応答セクションに RRSet がないものになります。