RFC 1034

6. 筋書き A SCENARIO

In our sample domain space, suppose we wanted separate administrative control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones. We might allocate name servers as follows:

サンプルのドメイン空間でルート、MIL、EDU、MIT.EDU、ISI.EDUゾーンを別々に管理したいとする。次のようにネームサーバを割り当てる。：


                                   |(C.ISI.EDU,SRI-NIC.ARPA
                                   | A.ISI.EDU)
             +---------------------+------------------+
             |                     |                  |
            MIL                   EDU                ARPA
             |(SRI-NIC.ARPA,       |(SRI-NIC.ARPA,    |
             | A.ISI.EDU           | C.ISI.EDU)       |
       +-----+-----+               |     +------+-----+-----+
       |     |     |               |     |      |           |
      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
                                   |
       +--------+------------------+---------------+--------+
       |        |                  |               |        |
      UCI      MIT                 |              UDEL     YALE
                |(XX.LCS.MIT.EDU, ISI
                |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
            +---+---+              | A.ISI.EDU)
            |       |              |
           LCS   ACHILLES +--+-----+-----+--------+
            |             |  |     |     |        |
            XX            A  C   VAXA  VENERA Mockapetris

In this example, the authoritative name server is shown in parentheses at the point in the domain tree at which is assumes control.

例ではドメイン木中の制御している筈場所に権威あるネームサーバをカッコでくくって示している。

Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and A.ISI.EDU. The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU. The EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU. Note that servers may have zones which are contiguous or disjoint. In this scenario, C.ISI.EDU has contiguous zones at the root and EDU domains. A.ISI.EDU has contiguous zones at the root and MIL domains, but also has a non- contiguous zone at ISI.EDU.

それで、ルートネームサーバはC.ISI.EDU、SRI-NIC.ARPA、A.ISI.EDU である。 MILドメインをサービスするのは SRI-NIC.ARPA と A.ISI.EDU である。 EDUドメインをサービスするのは SRI-NIC.ARPA.と C.ISI.EDU である。サーバは連続したものやばらばらの複数のゾーンをもっていることがある。この筋書きでは、 C.ISI.EDUはルートとEDUドメインという連続したゾーンを持つ。 A.ISI.EDUはルートとMILドメインという連続したゾーンを持つが、 ISI.EDUという離れたゾーンも持つ。

6.1. C.ISI.EDUネームサーバ

C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN class, and would have zones for these domains. The zone data for the root domain might be:

C.ISI.EDU は IN クラスのルート、MIL、EDUドメインのネームサーバであり、これらのドメインのゾーンを持つ。ルートドメインのゾーンデータは以下のようなものだ：

    .       IN      SOA     SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
                            870611          ;serial
                            1800            ;refresh every 30 min
                            300             ;retry every 5 min
                            604800          ;expire after a week
                            86400)          ;minimum of a day
                    NS      A.ISI.EDU.
                    NS      C.ISI.EDU.
                    NS      SRI-NIC.ARPA.

    MIL.    86400   NS      SRI-NIC.ARPA.
            86400   NS      A.ISI.EDU.

    EDU.    86400   NS      SRI-NIC.ARPA.
            86400   NS      C.ISI.EDU.

    SRI-NIC.ARPA.   A       26.0.0.73
                    A       10.0.0.51
                    MX      0 SRI-NIC.ARPA.
                    HINFO   DEC-2060 TOPS20

    ACC.ARPA.       A       26.6.0.65
                    HINFO   PDP-11/70 UNIX
                    MX      10 ACC.ARPA.

    USC-ISIC.ARPA.  CNAME   C.ISI.EDU.

    73.0.0.26.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
    65.0.6.26.IN-ADDR.ARPA.  PTR    ACC.ARPA.
    51.0.0.10.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
    52.0.0.10.IN-ADDR.ARPA.  PTR    C.ISI.EDU.
    103.0.3.26.IN-ADDR.ARPA. PTR    A.ISI.EDU.

    A.ISI.EDU. 86400 A      26.3.0.103
    C.ISI.EDU. 86400 A      10.0.0.52

This data is represented as it would be in a master file. Most RRs are single line entries; the sole exception here is the SOA RR, which uses "(" to start a multi-line RR and ")" to show the end of a multi-line RR. Since the class of all RRs in a zone must be the same, only the first RR in a zone need specify the class. When a name server loads a zone, it forces the TTL of all authoritative RRs to be at least the MINIMUM field of the SOA, here 86400 seconds, or one day. The NS RRs marking delegation of the MIL and EDU domains, together with the glue RRs for the servers host addresses, are not part of the authoritative data in the zone, and hence have explicit TTLs.

データはマスターファイルとしての表現になっている。ほとんどの資源レコード(RRs)は１行の項目からできている; 唯一の例外はSOA RRであり、"("で複数行 RR の始まりを示し、")"で終りを示す。ゾーン内の全ての RRs のクラスは同じでなければならないので、最初の RR でクラスを指定すればよい。ネームサーバがゾーンを読み込む時には SOA レコードのMINIMUM フィールド(ここでは 86400 秒つまり1日) 以上にすべての権威ある RRs のTTLを修正する。 MILとEDUドメインを委譲していることを示している NS RRs はそのネームサーバのホストアドレスであるグルー RRs とともにこのゾーンの権威あるデータには含まれない。そのため、TTL を明示的に書いてある。

Four RRs are attached to the root node: the SOA which describes the root zone and the 3 NS RRs which list the name servers for the root. The data in the SOA RR describes the management of the zone. The zone data is maintained on host SRI-NIC.ARPA, and the responsible party for the zone is HOSTMASTER@SRI-NIC.ARPA. A key item in the SOA is the 86400 second minimum TTL, which means that all authoritative data in the zone has at least that TTL, although higher values may be explicitly specified.

ルートノードには 4 つの RRs がついている；ルートゾーンを記述するSOAとネームサーバのための 3 つの NS RRs である。 SOA RR 中のデータはゾーンの管理方法を示している。ゾーンデータはホスト SRI - NIC.ARPA 上で管理され、ゾーンの責任者のメイルアドレスは HOSTMASTER@SRI-NIC.ARPAである。 SOAの重要な項目のひとつは 86400 秒となっている最小 TTLであり、これはゾーンのすべての権威あるデータはこの値以上の TTLを持つことを示す。もっと大きい TTL値を明示的に指定してもよい。

The NS RRs for the MIL and EDU domains mark the boundary between the root zone and the MIL and EDU zones. Note that in this example, the lower zones happen to be supported by name servers which also support the root zone.

MILとEDUドメインのための NS RRs はルートゾーンとMIL、EDUゾーンとの境界線を示している。この例ではたまたまであるが、ルートゾーンのためのネームサーバによって、下位のゾーンもサービスされている。

The master file for the EDU zone might be stated relative to the origin EDU. The zone data for the EDU domain might be:

EDUゾーンのマスターファイルはEDUを起点として記述されていて、 EDUドメインのゾーンデータは以下のようだとしよう：

    EDU.  IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
                            870729 ;serial
                            1800 ;refresh every 30 minutes
                            300 ;retry every 5 minutes
                            604800 ;expire after a week
                            86400 ;minimum of a day
                            )
                    NS SRI-NIC.ARPA.
                    NS C.ISI.EDU.

    UCI 172800 NS ICS.UCI
                    172800 NS ROME.UCI
    ICS.UCI 172800 A 192.5.19.1
    ROME.UCI 172800 A 192.5.19.31
    ISI 172800 NS VAXA.ISI
                    172800 NS A.ISI
                    172800 NS VENERA.ISI.EDU.
    VAXA.ISI 172800 A 10.2.0.27
                    172800 A 128.9.0.33
    VENERA.ISI.EDU. 172800 A 10.1.0.52
                    172800 A 128.9.0.32
    A.ISI 172800 A 26.3.0.103

    UDEL.EDU.  172800 NS LOUIE.UDEL.EDU.
                    172800 NS UMN-REI-UC.ARPA.
    LOUIE.UDEL.EDU. 172800 A 10.0.0.96
                    172800 A 192.5.39.3

    YALE.EDU.  172800 NS YALE.ARPA.
    YALE.EDU.  172800 NS YALE-BULLDOG.ARPA.

    MIT.EDU.  43200 NS XX.LCS.MIT.EDU.
                      43200 NS ACHILLES.MIT.EDU.
    XX.LCS.MIT.EDU.  43200 A 10.0.0.44
    ACHILLES.MIT.EDU. 43200 A 18.72.0.8

Note the use of relative names here. The owner name for the ISI.EDU. is stated using a relative name, as are two of the name server RR contents. Relative and absolute domain names may be freely intermixed in a master

ここでは相対名が使用されていることに注意せよ。 ISI.EDU. の所有者名は相対名を使って記述されており、ネームサーバ RR の中身も同様である。相対名と絶対ドメイン名はマスターファイル中で自由に混在させてよい。

6.2. 標準問合せ Example standard queries

The following queries and responses illustrate name server behavior. Unless otherwise noted, the queries do not have recursion desired (RD) in the header. Note that the answers to non-recursive queries do depend on the server being asked, but do not depend on the identity of the requester.

以下の問合せと返答はネームサーバ動作の説明である。特に断わりがなければ、問合せはそのヘッダーで再帰要請(RD)が設定されていないものとする。問い合わせたサーバによって再帰なし問合せの返答が異なるが問合せ側がなにものであるかには依存しないことに注意せよ。

6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
The query would look like:

問合せの例：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY                                     |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

The response from C.ISI.EDU would be:

C.ISI.EDUからの返答はこうだろう：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 86400 IN A 26.0.0.73                |
               |               86400 IN A 10.0.0.51                |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

The header of the response looks like the header of the query, except that the RESPONSE bit is set, indicating that this message is a response, not a query, and the Authoritative Answer (AA) bit is set indicating that the address RRs in the answer section are from authoritative data. The question section of the response matches the question section of the query.

返答のヘッダは問合せのヘッダに似ている。ただし、メッセージが応答であって、問合せではないことを示すために RESPONSEがセットされている。また、権威あり返答(AA)ビットは返答節内のアドレス RRs が権威あるデータからのものであることを示す。返答の質問節は問合せの質問節と一致している。

If the same query was sent to some other server which was not authoritative for SRI-NIC.ARPA, the response might be:

同じ問合せが SRI-NIC.ARPA の権威をもたないサーバに送られたときの返答：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY,RESPONSE                            |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 1777 IN A 10.0.0.51                 |
               |               1777 IN A 26.0.0.73                 |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

This response is different from the previous one in two ways: the header does not have AA set, and the TTLs are different. The inference is that the data did not come from a zone, but from a cache. The difference between the authoritative TTL and the TTL here is due to aging of the data in a cache. The difference in ordering of the RRs in the answer section is not significant.

この返答は前の返答と2箇所で異なる: ヘッダのAA は設定されておらず、TTLs は異なっている。データがゾーンからでなくキャッシュから来たことがわかる。権威のある TTLとここのTTLの差はキャッシュ内のデータの時間が経過したからである。解答節の中の RRs の順序の違いに意味はない。

6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*
A query similar to the previous one, but using a QTYPE of *, would receive the following response from C.ISI.EDU:

前の問合せに似てるが、QTYPE * を使うと、 C.ISI.EDUはこういう返答がくる：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 86400 IN  A     26.0.0.73           |
               |                         A     10.0.0.51           |
               |                         MX    0 SRI-NIC.ARPA.     |
               |                         HINFO DEC-2060 TOPS20     |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

If a similar query was directed to two name servers which are not authoritative for SRI-NIC.ARPA, the responses might be:

同様な問合せを SRI-NIC.ARPAの権威をもたないサーバでないネームサーバに送ったら、返答はこうなる：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE                           |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 12345 IN     A       26.0.0.73      |
               |                            A       10.0.0.51      |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

and

と

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE                           |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 1290 IN HINFO  DEC-2060 TOPS20      |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

Neither of these answers have AA set, so neither response comes from authoritative data. The different contents and different TTLs suggest that the two servers cached data at different times, and that the first server cached the response to a QTYPE=A query and the second cached the response to a HINFO query.

どちらの答も AA はセットされていなくて、権威あるデータでから来ていない。異なった内容と異なったTTLは二つのサーバが異なった時にデータをキャッシュしたこと、最初のサーバは QTYPE=A の問合せをキャッシュし、ふたつめは HINFO 問合せの結果をキャッシュしたことを示している。

6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX
This type of query might be result from a mailer trying to look up routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA. The response from C.ISI.EDU would be:

このタイプの問合せはメールの宛先 HOSTMASTER@SRI-NIC.ARPA のルーティング情報を検索しようとしているメイラからの問合せだろう。 C.ISI.EDUからの返答はこうだろう:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX          |
               +---------------------------------------------------+
    Answer     | SRI-NIC.ARPA. 86400 IN     MX      0 SRI-NIC.ARPA.|
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | SRI-NIC.ARPA. 86400 IN     A       26.0.0.73      |
               |                            A       10.0.0.51      |
               +---------------------------------------------------+

This response contains the MX RR in the answer section of the response. The additional section contains the address RRs because the name server at C.ISI.EDU guesses that the requester will need the addresses in order to properly use the information carried by the MX.

この返答の解答節はMX RR を含む。付加節にはアドレス RRsをある。その理由は C.ISI.EDUのネームサーバが MXの示す情報をまっとうに使うのに要求者にはアドレスが必要であろうと推測するからである。

6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS C.ISI.EDU would reply to this query with:

この問合せに対する C.ISI.EDU の返答：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS          |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

The only difference between the response and the query is the AA and RESPONSE bits in the header. The interpretation of this response is that the server is authoritative for the name, and the name exists, but no RRs of type NS are present there.

返答と問合せのとの間の違いはヘッダの AA と RESPONSE ビットだけである。この返答の解釈はサーバは名前に権威をもち、名前は存在するが、 NS タイプの RRs は存在しないというものだ。

6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A If a user mistyped a host name, we might see this type of query. C.ISI.EDU would answer it with:

ホスト名を間違えていたら、こういう問合せがあって、 C.ISI.EDU はこう答える：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE             |
               +---------------------------------------------------+
    Question   | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A           |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA.      |
               |       870611 1800 300 604800 86400                |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

This response states that the name does not exist. This condition is signalled in the response code (RCODE) section of the header.

この返答は名前が存在しないと述べている。ヘッダの返答コード（RCODE）節で状態が通知される。

The SOA RR in the authority section is the optional negative caching information which allows the resolver using this response to assume that the name will not exist for the SOA MINIMUM (86400) seconds.

権威節内のSOA RRs は実装任意であるネガティブキャッシュ情報であり、この返答を使うことで、リゾルバはその名前が SOA MINIMUM (86400)秒間は存在しないと判定できる。

6.2.6. QNAME=BRL.MIL, QTYPE=A If this query is sent to C.ISI.EDU, the reply would be:

この問合せがC.ISI.EDUに送られたら、返答はこうだ：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE                           |
               +---------------------------------------------------+
    Question   | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A                 |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | MIL.             86400 IN NS       SRI-NIC.ARPA.  |
               |                  86400    NS       A.ISI.EDU.     |
               +---------------------------------------------------+
    Additional | A.ISI.EDU.                A        26.3.0.103     |
               | SRI-NIC.ARPA.             A        26.0.0.73      |
               |                           A        10.0.0.51      |
               +---------------------------------------------------+

This response has an empty answer section, but is not authoritative, so it is a referral. The name server on C.ISI.EDU, realizing that it is not authoritative for the MIL domain, has referred the requester to servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative for the MIL domain.

この返答は空の解答節を持つが、権威はないので参照である。 C.ISI.EDU のネームサーバは自分がMILドメインの権威はもたないので、 A.ISI.EDU と SRI-NIC.ARPAのサーバを要求者に参照した。これらが MIL ドメインの権威もつことを知っている。

6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A The response to this query from A.ISI.EDU would be:

この問合せに対するA.ISI.EDUからの答え：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
               +---------------------------------------------------+
    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
               | C.ISI.EDU.     86400 IN A          10.0.0.52      |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

Note that the AA bit in the header guarantees that the data matching QNAME is authoritative, but does not say anything about whether the data for C.ISI.EDU is authoritative. This complete reply is possible because A.ISI.EDU happens to be authoritative for both the ARPA domain where USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is found.

ヘッダのAAビットは QNAME とマッチする名前は権威あることを保証するが、 C.ISI.EDUのデータが権威あるかどうかは何も言っていないことに注意せよ。この完全な答が可能なのは A.ISI.EDU がたまたま USC-ISIC.ARPA のある ARPA ドメインと C.ISI.EDU のある ISI.EDU ドメインの両方の権威であるためである。

If the same query was sent to C.ISI.EDU, its response might be the same as shown above if it had its own address in its cache, but might also be:

同じ質問が C.ISI.EDU に送られたら、自身のアドレスをそのキャッシュに持っていれば、上記と同じになるが、そうでなければ、こうだ:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
               +---------------------------------------------------+
    Answer     | USC-ISIC.ARPA.   86400 IN CNAME   C.ISI.EDU.      |
               +---------------------------------------------------+
    Authority  | ISI.EDU.        172800 IN NS      VAXA.ISI.EDU.   |
               |                           NS      A.ISI.EDU.      |
               |                           NS      VENERA.ISI.EDU. |
               +---------------------------------------------------+
    Additional | VAXA.ISI.EDU.   172800    A       10.2.0.27       |
               |                 172800    A       128.9.0.33      |
               | VENERA.ISI.EDU. 172800    A       10.1.0.52       |
               |                 172800    A       128.9.0.32      |
               | A.ISI.EDU.      172800    A       26.3.0.103      |
               +---------------------------------------------------+

This reply contains an authoritative reply for the alias USC-ISIC.ARPA, plus a referral to the name servers for ISI.EDU. This sort of reply isn't very likely given that the query is for the host name of the name server being asked, but would be common for other aliases.

この答はUSC-ISIC.ARPAの別名の権威ある返答と、ISI.EDUのネームサーバの参照を含んでいる。ネームサーバのホスト名を問合せたものに対する答としてはあまりないことだが、別名の場合には普通のことだ。

6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would be:

この質問をA.ISI.EDUかC.ISI.EDUに送ったら、答は：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
               +---------------------------------------------------+
    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name server doesn't attempt to look up anything for C.ISI.EDU. (Except possibly for the additional section.)

QTYPE=CNAME なので、CNAME RRs 自身が問合せの答である。そして、ネームサーバは C.ISI.EDU については何も調べようとしない。（付加節については除外）。

6.3. 6.3. 解決の例 Example resolution The following examples illustrate the operations a resolver must perform for its client. We assume that the resolver is starting without a cache, as might be the case after system boot. We further assume that the system is not one of the hosts in the data and that the host is located somewhere on net 26, and that its safety belt (SBELT) data structure has the following information:

以下の例はクライアントのためにリゾルバが行うべき動作を示す。リゾルバはシステムブート直後ではそうであるように、キャッシュ無しで開始したものと想定する。さらに、システムはデータ中のどのホストでもなく、ネット 26 上にあって、安全ベルト(SBELT) データ構造体は次の情報を持つとする:

    Match count = -1
    SRI-NIC.ARPA.   26.0.0.73       10.0.0.51
    A.ISI.EDU.      26.3.0.103

This information specifies servers to try, their addresses, and a match count of -1, which says that the servers aren't very close to the target. Note that the -1 isn't supposed to be an accurate closeness measure, just a value so that later stages of the algorithm will work.

この情報では問合せるサーバ、そのアドレス、そして一致カウントが -1 であることを指定している。サーバは目標に近くはない事を示している。 "-1" はアルゴリズムの後の方の段階が働くための値であって、近さを表わす正確な値のつもりではないことに注意せよ。

The following examples illustrate the use of a cache, so each example assumes that previous requests have completed.

キャッシュの使用例を示す。そのため、各例では以前の問合せは完了しているものとする。

6.3.1. ISI.EDU の MX の解決 Resolve MX for ISI.EDU.
Suppose the first request to the resolver comes from the local mailer, which has mail for PVM@ISI.EDU. The mailer might then ask for type MX RRs for the domain name ISI.EDU.

リゾルバへの最初の問合せはローカルメイラから来るとする。それは PVM@ISI.EDU へのメールを持っている。メイラはドメイン名 ISI.EDU のタイプMX RRs を求める。

The resolver would look in its cache for MX RRs at ISI.EDU, but the empty cache wouldn't be helpful. The resolver would recognize that it needed to query foreign servers and try to determine the best servers to query. This search would look for NS RRs for the domains ISI.EDU, EDU, and the root. These searches of the cache would also fail. As a last resort, the resolver would use the information from the SBELT, copying it into its SLIST structure.

リゾルバはキャッシュ内に ISI.EDU のMX RRsを探すが、キャッシュは空で役にたたない。外部のサーバに問合せが必要だと分り、質問に最も良いサーバを決めようとする。このために、ISI.EDU、EDU、ルートのネームサーバ RRsを検索する。これらもキャッシュにない。最後のたよりどころとして、SBELT を SLIST構造にコピーして、 SBELTにある情報を使う。

At this point the resolver would need to pick one of the three available addresses to try. Given that the resolver is on net 26, it should choose either 26.0.0.73 or 26.3.0.103 as its first choice. It would then send off a query of the form:

この時点でリゾルバは 3つあるアドレスからひとつを選ぶ。リゾルバがネットワーク 26にいるので、最初の選択としては 26.0.0.73 か 26.3.0.103を選択すべきだ。そして、以下の形式の質問を送る：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY                                     |
               +---------------------------------------------------+
    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

The resolver would then wait for a response to its query or a timeout. If the timeout occurs, it would try different servers, then different addresses of the same servers, lastly retrying addresses already tried. It might eventually receive a reply from SRI-NIC.ARPA:

リゾルバは問合せの返答かタイムアウトを待つ。もしタイムアウトが起きれば、他のサーバを試し、それから、それらのサーバの別のアドレスを試す。最後に、すでに試したアドレスを再度試します。いずれ、SRI-NIC.ARPAから答を受け取るかもしれない：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE                           |
               +---------------------------------------------------+
    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
               +---------------------------------------------------+
    Answer     | <empty>                                           |
               +---------------------------------------------------+
    Authority  | ISI.EDU.        172800 IN NS       VAXA.ISI.EDU.  |
               |                           NS       A.ISI.EDU.     |
               |                           NS       VENERA.ISI.EDU.|
               +---------------------------------------------------+
    Additional | VAXA.ISI.EDU.   172800    A        10.2.0.27      |
               |                 172800    A        128.9.0.33     |
               | VENERA.ISI.EDU. 172800    A        10.1.0.52      |
               |                 172800    A        128.9.0.32     |
               | A.ISI.EDU.      172800    A        26.3.0.103     |
               +---------------------------------------------------+

The resolver would notice that the information in the response gave a closer delegation to ISI.EDU than its existing SLIST (since it matches three labels). The resolver would then cache the information in this response and use it to set up a new SLIST:

返答中の情報がISI.EDUに対して既存の SLISTよりも近い委任を与えたことにリゾルバは気付く。（3つのラベルに一致するので）リゾルバはこの返答の情報をキャッシュし、それを新しくSLISTに設定する：

    Match count = 3
    A.ISI.EDU.      26.3.0.103
    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
    VENERA.ISI.EDU. 10.1.0.52       128.9.0.32

A.ISI.EDU appears on this list as well as the previous one, but that is purely coincidental. The resolver would again start transmitting and waiting for responses. Eventually it would get an answer:

A.ISI.EDUは前のと同じくこのリストにも現われるが、それは偶然の一致です。リゾルバは再び問合せを送って、返事を待つ。いずれ答を得る:

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
               +---------------------------------------------------+
    Answer     | ISI.EDU.                MX 10 VENERA.ISI.EDU.     |
               |                         MX 20 VAXA.ISI.EDU.       |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | VAXA.ISI.EDU.   172800  A  10.2.0.27              |
               |                 172800  A  128.9.0.33             |
               | VENERA.ISI.EDU. 172800  A  10.1.0.52              |
               |                 172800  A  128.9.0.32             |
               +---------------------------------------------------+

The resolver would add this information to its cache, and return the MX RRs to its client.

リゾルバはキャッシュにこの情報を加えて、クライアントにMX RRsを返す。

6.3.2. 6.3.2. アドレス 26.6.0.65 のホスト名を得る Get the host name for address 26.6.0.65
The resolver would translate this into a request for PTR RRs for 65.0.6.26.IN-ADDR.ARPA. This information is not in the cache, so the resolver would look for foreign servers to ask. No servers would match, so it would use SBELT again. (Note that the servers for the ISI.EDU domain are in the cache, but ISI.EDU is not an ancestor of 65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.)

リゾルバは問合せを 65.0.6.26.IN-ADDR.ARPA の PTR RRs の要求に変換する。情報はキャッシュにないので、問合わせるべき外部のサーバを探す。適当なものがないので、再びSBELTを使う。（ISI.EDUドメインのサーバはキャッシュにあるが、しかしISI.EDUは 65.0.6.26.IN-ADDR.ARPAの祖先ではない。そこで、SBELTが使われる。このことに注意せよ。）

Since this request is within the authoritative data of both servers in SBELT, eventually one would return:

この問い合わせは SBELT内の両方のサーバの権威あるデータにあるので、結局は以下の返事が返ってくる：

               +---------------------------------------------------+
    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
               +---------------------------------------------------+
    Question   | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
               +---------------------------------------------------+
    Answer     | 65.0.6.26.IN-ADDR.ARPA.    PTR     ACC.ARPA.      |
               +---------------------------------------------------+
    Authority  | <empty>                                           |
               +---------------------------------------------------+
    Additional | <empty>                                           |
               +---------------------------------------------------+

6.3.3. poneria.ISI.EDUのホストアドレスを得る Get the host address of poneria.ISI.EDU
This request would translate into a type A request for poneria.ISI.EDU. The resolver would not find any cached data for this name, but would find the NS RRs in the cache for ISI.EDU when it looks for foreign servers to ask. Using this data, it would construct a SLIST of the form:

この問合せは poneria.ISI.EDUのタイプAの問合せに変換される。キャッシュされたデータ中にはないが、問合せ先の外部サーバを探す時に、ISI.EDUの NS RRs をキャッシュに見つける。このデータを使って次の形の SLISTを作る：

    Match count = 3

    A.ISI.EDU.      26.3.0.103
    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
    VENERA.ISI.EDU. 10.1.0.52

A.ISI.EDU is listed first on the assumption that the resolver orders its choices by preference, and A.ISI.EDU is on the same network.

リゾルバの選択は優先順位にもとづくという仮定のもと、 A.ISI.EDU はリストの最初に置かれる。そして、A.ISI.EDUは同じネットワークにいる。

One of these servers would answer the query.

これらのサーバのどれかが答えるだろう。

2008-09-19 訳前野年紀 qmail.jp djbdns.org