DNS/用語/wildcards/RFC4592について、ここに記述してください。

https://tools.ietf.org/html/rfc4592　　E. Lewis　July 2006

---

DNS/RFC/1034 DNS/RFC/4592　/example

Abstract
   This is an update to the wildcard definition of RFC 1034.  The
   interaction with wildcards and CNAME is changed, an error condition
   is removed, and the words defining some concepts central to wildcards
   are changed.  The overall goal is not to change wildcards, but to
   refine the definition of RFC 1034.

   In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
   synthesis of answers from special resource records (RRs) called
   wildcards.  The definition in RFC 1034 is incomplete and has proven
   to be confusing.  This document describes the wildcard synthesis by
   adding to the discussion and making limited modifications.
   Modifications are made to close inconsistencies that have led to
   interoperability issues.  This description does not expand the
   service intended by the original definition.

相互運用上の不一致を解消するための修正を施すだけに留める。

In this definition, wildcard refers to resource records.
   In other usage, wildcard has referred to domain names, and it has
   been used to describe the operational practice of relying on
   wildcards to generate answers.  It is clear from this that there is a
   need to define clear and unambiguous terminology in the process of
   discussing wildcards.

ここでのwildcardは資源レコードを指す。

• wildcardsを議論するには「明確で曖昧性のない用語」が必要なことは明らかである。

 The mention of the use of wildcards in the preparation of a response
   is contained in step 3, part 'c' of RFC 1034's section 4.3.2,
   entitled "Algorithm".  Note that "wildcard" does not appear in the
   algorithm, instead references are made to the "*" label.  The portion
   of the algorithm relating to wildcards is deconstructed in detail in
   section 3 of this document; this is the beginning of the relevant
   portion of the "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.

• wildcardの代わりに"*"ラベルが現れる。

"asterisk label" and "wildcard domain name"

複数の*が現れることも認める。

1. 2. Wildcard Syntax

The only significant feature is the owner name.

Wildcard Domain Name and Asterisk Label

• RFC 1034's definition of wildcard would be "a resource record owned by a wildcard domain name".

A wildcard domain name can be an empty non-terminal.

"wildcard domain name" がなにを指すか。

A "wildcard domain name" is defined by having its initial (i.e.,
   leftmost or least significant) label be, in binary format:

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

The first octet is the normal label type and length for a 1-octet-long label,
and the second octet is the ASCII representation [RFC20] for the '*' character.

2.1.3. Non-terminal Wildcard Domain Names

---

2. 2.2. Existence Rules

   The notion that a domain name 'exists' is mentioned in the definition
   of wildcards.  In section 4.3.3 of RFC 1034:

   # Wildcard RRs do not apply:
   #
   ...
   #   - When the query name or a name between the wildcard domain and
   #     the query name is know[n] to exist. . . .

"Existence" is therefore an important concept in the understanding of wildcards. Unfortunately, the definition of what exists, in RFC 1034, is unclear.

A node with no descendants is a leaf node. Empty leaf nodes do not exist.

3. 2.3. When Is a Wildcard Domain Name Not Special?

   When a wildcard domain name appears in a message's query section, no
   special processing occurs.  An asterisk label in a query name only
   matches a single, corresponding asterisk label in the existing zone
   tree when the 4.3.2 algorithm is being followed.

   When a wildcard domain name appears in the resource data of a record,
   no special processing occurs.  An asterisk label in that context
   literally means just an asterisk.

4. 3. Impact of a Wildcard Domain Name on a Response

/response

3.3.1. Closest Encloser and the Source of Synthesis

3.3.2. Closest Encloser and Source of Synthesis Examples