DNS/RFC1034/5 DNS/RFC/1034

5. リゾルバ RESOLVERS

5.1. はじめに Introduction

Resolvers are programs that interface user programs to domain name servers. 
In the simplest case, a resolver receives a request from a user program (e.g., mail programs, TELNET, FTP)
in the form of a subroutine call, system call etc., and returns the desired information
in a form compatible with the local host's data formats.

リゾルバはユーザプログラムと DNS サーバをつなぐプログラムである。 最も単純な場合では、リゾルバはユーザプログラム（メールプログラム、TELNET、FTPなど）から サブルーチン呼びだし、システムコールなどの形で問合せを受け取り、 ローカルホストのデータ形式と互換性のある形式で目的の情報を返す。

The resolver is located on the same machine as the program that requests
the resolver's services, but it may need to consult name servers on other hosts. 
Because a resolver may need to consult several name ervers,
or may have the requested information in a local cache, the
amount of time that a resolver will take to complete can vary quite a
bit, from milliseconds to several seconds.

リゾルバはリゾルバサービスを使うプログラムと同じマシン上で動作するが、 他ホスト上のネームサーバに問い合わせる必要が生じることもある。 リゾルバは複数のネームサーバに問い合わせることもあり、 あるいは求める情報をローカルキャッシュに持っていることもあるため、 処理を完了するまでの所要時間はミリ秒から数秒までの大きな幅がある。

A very important goal of the resolver is to eliminate network delay and
name server load from most requests by answering them from its cache of
prior results.  It follows that caches which are shared by multiple
processes, users, machines, etc., are more efficient than non-shared
caches.

リゾルバの非常に重要な目的のひとつはキャッシュしてある以前の結果を使う事によって、 多くの問い合わせについて、ネットワークの遅延とネームサーバへの負荷をなくすことである。 このことにより、多数のプロセス、ユーザ、マシンなどで共有されるキャッシュは 共有されないキャッシュよりより効率的である。

5.2. クライアント－リゾルバインターフェース Client-resolver interface

5.2.1. 代表的な機能 Typical functions

The client interface to the resolver is influenced by the local host's
conventions, but the typical resolver-client interface has three
functions:

クライアントからみたリゾルバインタフェースは ローカルホストの便法の影響を受けるが、 典型的なリゾルバ－クライアント・インタフェースは以下の 3 つの機能を持つ：

1. ホスト名からホストアドレスへの変換 Host name to host address translation.

      This function is often defined to mimic a previous HOSTS.TXT
      based function.  Given a character string, the caller wants
      one or more 32 bit IP addresses.  Under the DNS, it
      translates into a request for type A RRs.  Since the DNS does
      not preserve the order of RRs, this function may choose to
      sort the returned addresses or select the 'best' address if
      the service returns only one choice to the client.  Note that
      a multiple address return is recommended, but a single
      address may be the only way to emulate prior HOSTS.TXT
      services.

• この機能はHOSTS.TXTの機能を再現するためによく定義される。 つまり、文字列に対して、32ビットIPアドレスを返すものである。 DNS ではタイプ A RRs 問い合わせとなる。 DNS は RRs の順序を保存しないので、 この機能は返事のアドレスを整列するかもしれないし、 サービスが答をひとつだけクライアントに返すときには 「最も良い」アドレスを選んだりするかもしれない。 複数のアドレスを返すことが推奨されるが、 以前のHOSTS.TXTサービスを模倣するには、 1つのアドレスが唯一の選択でありうることに注意せよ。

2. ホストアドレスからホスト名への変換 Host address to host name translation

      This function will often follow the form of previous
      functions.  Given a 32 bit IP address, the caller wants a
      character string.  The octets of the IP address are reversed,
      used as name components, and suffixed with 'IN-ADDR.ARPA'.  A
      type PTR query is used to get the RR with the primary name of
      the host.  For example, a request for the host name
      corresponding to IP address 1.2.3.4 looks for PTR RRs for
      domain name '4.3.2.1.IN-ADDR.ARPA'.

• この機能はしばしば既述の機能の形に従う。 32 ビット IP アドレスに対する(ホスト名)文字列を求める。 IPアドレスのオクテットを逆にならべて名前要素とし、 その後に'IN-ADDR.ARPA'をつける。 タイプ PTR の問合せを使って、ホストの基本名の RRを得る。 例えば、IP アドレス 1.2.3.4 に対するホスト名は ドメイン名 '4.3.2.1.IN-ADDR.ARPA'の PTR RRs を探す。

3. 一般的な検索機能 General lookup function

      This function retrieves arbitrary information from the DNS,
      and has no counterpart in previous systems.  The caller
      supplies a QNAME, QTYPE, and QCLASS, and wants all of the
      matching RRs.  This function will often use the DNS format
      for all RR data instead of the local host's, and returns all
      RR content (e.g., TTL) instead of a processed form with local
      quoting conventions.

• この機能はDNSから任意の情報を検索する。昔のシステムには対応する 機能はない。要求者は QNAME, QTYPE, QCLASSを指定し、 適合するすべての RRs を求める。 この機能はローカルホストの形式ではなく、 どの RR データに対しても DNS RRs データの形式を使って、 全ての RRs の内容（例えば TTL も）を返す。 ローカルな便法を使って処理された形は使わない。

When the resolver performs the indicated function, it usually has one of
the following results to pass back to the client:

リゾルバが指定された機能を実行する時、 クライアントへは次のどれかの結果が返される：

   - One or more RRs giving the requested data.

• - 要求されたデータである RRs

     In this case the resolver returns the answer in the
     appropriate format.

• この場合、リゾルバは適切な形式の答を返す。

   - A name error (NE).

• - 名前エラー(NE)

     This happens when the referenced name does not exist.  For
     example, a user may have mistyped a host name.

• 参照された名前が存在しない時におきる。 例えば、ユーザがホスト名を間違えたか。

   - A data not found error.

• - データなしエラー

     This happens when the referenced name exists, but data of the
     appropriate type does not.  For example, a host address
     function applied to a mailbox name would return this error
     since the name exists, but no address RR is present.

• 参照された名前は存在するが、該当するタイプのデータがない時におきる。 例えば、メールボックス名に対してホストアドレスを検索すると、 名前は存在するがアドレス RR は存在しないので、このエラーが返る。

It is important to note that the functions for translating between host
names and addresses may combine the 'name error' and 'data not found'
error conditions into a single type of error return, but the general
function should not.  One reason for this is that applications may ask
first for one type of information about a name followed by a second
request to the same name for some other type of information; if the two
errors are combined, then useless queries may slow the application.

ホスト名とアドレスの間の変換機能では「名前エラー」と「データなし」は ひとつのエラーにまとめてもいいように見えるが、 一般機能ではまとめるべきでない。このことは重要である。

その理由のひとつは アプリケーションがある名前についてのあるタイプの情報を求め、 つづいて、同じ名前についての別のタイプの情報を求めるかもしれない からである; もし二つのエラーが区別されていなければ、 無用な問合せが発生し、アプリケーションは遅くなるだろう。

5.2.2. 別名 Aliases

While attempting to resolve a particular request, the resolver may find
that the name in question is an alias.  For example, the resolver might
find that the name given for host name to address translation is an
alias when it finds the CNAME RR.  If possible, the alias condition
should be signalled back from the resolver to the client.

問合せを解決している際にリゾルバは質問されている名前が別名だと分るることがある。 例えば、ホスト名からアドレスへの変換時には CNAME RRs を見つけることで、名前が別名であると判明する。 可能なら別名だという事がリゾルバからクライアントへ伝えられるべきである。

In most cases a resolver simply restarts the query at the new name when
it encounters a CNAME.  However, when performing the general function,
the resolver should not pursue aliases when the CNAME RR matches the
query type.  This allows queries which ask whether an alias is present.
For example, if the query type is CNAME, the user is interested in the
CNAME RR itself, and not the RRs at the name it points to.

ほとんどの場合、CNAMEに出会うとリゾルバは新しい名前を使って問合せをやり直す。 しかしながら、一般機能を実行している時には CNAME RRs が質問タイプ と適合するなら、リゾルバは別名を続行すべきではない。 これにより、別名の存在を尋ねる質問が許される。 例えば、質問タイプがCNAMEなら、 ユーザはCNAME RRs 自身に興味があるのであって、 CNAMEが示す名前の RRs にではない。

Several special conditions can occur with aliases.  Multiple levels of
aliases should be avoided due to their lack of efficiency, but should
not be signalled as an error.  Alias loops and aliases which point to
non-existent names should be caught and an error condition passed back
to the client.

別名にはいくつかの特別な条件がある。 別名を多段で使うのは効率が悪いので避けるべきである。 しかし、エラーとすべきではない。 別名のループや存在しない名前を指す別名は検出すべきであり、 エラーはクライアントに通知されるべきである。

5.2.3. 一時的障害 Temporary failures

In a less than perfect world, all resolvers will occasionally be unable
to resolve a particular request.  This condition can be caused by a
resolver which becomes separated from the rest of the network due to a
link failure or gateway problem, or less often by coincident failure or
unavailability of all servers for a particular domain.

完全ではない世界では、リゾルバが解決ができない問合せもあるだろう。 リンクの故障やゲートウェーの問題で外部のネットワークから 切り離されたリゾルバとか、 あまり起きないはずのことであるが、 あるドメインの全てのサーバが同時に使えなくなるとかで発生する。

It is essential that this sort of condition should not be signalled as a
name or data not present error to applications.  This sort of behavior
is annoying to humans, and can wreak havoc when mail systems use the
DNS.

この種の条件はアプリケーションに名前エラーとかデータなしエラーとして 通知されることがあってはならないということが肝心である。 この様な行動をするなら、人を不安にさせ、 メールシステムで DNS を使うときに破滅を引き起こしうる。

While in some cases it is possible to deal with such a temporary problem
by blocking the request indefinitely, this is usually not a good choice,
particularly when the client is a server process that could move on to
other tasks.  The recommended solution is to always have temporary
failure as one of the possible results of a resolver function, even
though this may make emulation of existing HOSTS.TXT functions more
difficult.

無期限に要求を止めることで、この種の一時的問題を扱うことができる 場合もあるが、普通にはよい選択ではない。 クライアントがサーバープロセスであって、他の仕事を進行できるような ときには特にそうである。 推奨される解決策はリゾルバ機能の取りうる結果として一時的故障を 常に認めることである。 既存のHOSTS.TXT機能のまねはより難しくなるが。

5.3. リゾルバの内部動作 Resolver internals

Every resolver implementation uses slightly different algorithms, and
typically spends much more logic dealing with errors of various sorts
than typical occurances.  This section outlines a recommended basic
strategy for resolver operation, but leaves details to [RFC-1035].

各リゾルバの実装はわずかずつ異なったアルゴリズムを使っている。 そして、通常、普通に発生することに対するよりも 各種のエラーを処理するためにずっと多くの「論理」を費している。 この節ではリゾルバ動作として推奨される基本戦略の概略を述べる。 ただし、詳細は[RFC1035]に任せている。

5.3.1. つなぎリゾルバ Stub resolvers

One option for implementing a resolver is to move the resolution
function out of the local machine and into a name server which supports
recursive queries.  This can provide an easy method of providing domain
service in a PC which lacks the resources to perform the resolver
function, or can centralize the cache for a whole local network or
organization.

リゾルバを実装するひとつの方法は 解決機能をローカルマシンから取りはずして、 再帰問合せをサポートするネームサーバに移すことである。 こうすれば、リゾルバを動かすには資源が足りない PC にもドメインサービスを 簡単に提供することができるようになる。 また、ローカルネットーワークや組織全体のための キャッシュを集中することもできる。

All that the remaining stub needs is a list of name server addresses
that will perform the recursive requests.  This type of resolver
presumably needs the information in a configuration file, since it
probably lacks the sophistication to locate it in the domain database.
The user also needs to verify that the listed servers will perform the
recursive service; a name server is free to refuse to perform recursive
services for any or all clients.  The user should consult the local
system administrator to find name servers willing to perform the
service.

残ったスタブが必要とするものは 再帰問合せを実行してくれるネームサーバのアドレス一覧だけである。 おそらく、この種のリゾルバは ドメインデータベースから必要な情報を取り出すこともできないだろうから、 設定ファイル中に情報があることが必要であろう。 ユーザはリストにあるサーバが再帰サービスを提供することを確かめる必要があろう; ネームサーバにはクライアントからの再帰サービス要請を拒否する自由がある。 ユーザはサービスをしてくれるネームサーバを探すときには、 ローカルシステム管理者に相談すべきである。

This type of service suffers from some drawbacks.  Since the recursive
requests may take an arbitrary amount of time to perform, the stub may
have difficulty optimizing retransmission intervals to deal with both
lost UDP packets and dead servers; the name server can be easily
overloaded by too zealous a stub if it interprets retransmissions as new
requests.  Use of TCP may be an answer, but TCP may well place burdens
on the host's capabilities which are similar to those of a real
resolver.

この種のサービスにはいくつか欠点がある。 再帰問合せにかかる時間が不明なため、 スタブリゾルバでは UDP パケットが失われた場合と死んだサーバとの両方に 対処するような最適な再送間隔をきめるのに困るだろう; リゾルバにより 再送信された問い合わせを新規の要求として受け取るネームサーバは 過度に熱心なスタブ により過負荷になりやすい。 TCP を使うのが答かもしれないが、 TCP は real リゾルバと同程度にホストの機能に負荷となるかもしれない。

5.3.2. 資源 Resources

In addition to its own resources, the resolver may also have shared
access to zones maintained by a local name server.  This gives the
resolver the advantage of more rapid access, but the resolver must be
careful to never let cached information override zone data.  In this
discussion the term 'local information' is meant to mean the union of
the cache and such shared zones, with the understanding that
authoritative data is always used in preference to cached data when both
are present.

リゾルバは自身の資源の他にローカルネームサーバが保守するゾーンを 共用資源としてアクセスできることがある。 これはより速いアクセスという利点をリゾルバに与えるが、 リゾルバはキャッシュ情報をゾーンデータより決して優先することがないよう 注意をはらわなくてはならない。 この議論中では、用語「ローカル情報」とは キャッシュと共有ゾーンを合わせたものを意味する。 権威あるデータとキャッシュデータの両方があるときには、 権威あるデータが採用されるという理解のもとに。

The following resolver algorithm assumes that all functions have been
converted to a general lookup function, and uses the following data
structures to represent the state of a request in progress in the
resolver:

以降のリゾルバアルゴリズムでは すべての機能は一般的な検索機能に変換されるという仮定をしている。 さらに、進行中の問合せの状態を表すための以下のデータ構造を使う：

SNAME           the domain name we are searching for.

• 探してるドメイン名

STYPE           the QTYPE of the search request.

• 問合せの問合せタイプ

SCLASS          the QCLASS of the search request.

• 問合せの問合せクラス

SLIST           a structure which describes the name servers and the
                zone which the resolver is currently trying to query.
                This structure keeps track of the resolver's current
                best guess about which name servers hold the desired
                information; it is updated when arriving information
                changes the guess.  This structure includes the
                equivalent of a zone name, the known name servers for
                the zone, the known addresses for the name servers, and
                history information which can be used to suggest which
                server is likely to be the best one to try next.  The
                zone name equivalent is a match count of the number of
                labels from the root down which SNAME has in common with
                the zone being queried; this is used as a measure of how
                'close' the resolver is to SNAME.

• リゾルバが現在問い合わせようとしているネームサーバとゾーンを記 述する構造体。 この構造体はどのネームサーバが望ましい情報を持つかについて、 現在のベストな推測を保持している; 受信した情報によって推測が変更されたら更新される。 この構造体はゾーン名に等価なもの、ゾーンの既知のネームサーバー、 ネームサーバの既知のアドレス、次に試すときにベストなネームサーバを 選ぶのに使える履歴情報などを持つ。 ゾーン名等価なものとはルートからたどっていったときに 問合せ対象のゾーンと SNAMEが共通にもつラベルの数である; これはリゾルバがどれくらい SNAMEに近いか計るのに使われる。

SBELT           a 'safety belt' structure of the same form as SLIST,
                which is initialized from a configuration file, and
                lists servers which should be used when the resolver
                doesn't have any local information to guide name server
                selection.  The match count will be -1 to indicate that
                no labels are known to match.

• SLISTと同じ形をした「安全ベルト」構造体、 これは設定ファイルを使って初期化される。 ネームサーバ選択の助けとなるローカル情報を リゾルバが持たないときに使うべきサーバの一覧である。 一致するラベルがないことを示すときのマッチ数は -1 であろう。

CACHE           A structure which stores the results from previous
                responses.  Since resolvers are responsible for
                discarding old RRs whose TTL has expired, most
                implementations convert the interval specified in
                arriving RRs to some sort of absolute time when the RR
                is stored in the cache.  Instead of counting the TTLs
                down individually, the resolver just ignores or discards
                old RRs when it runs across them in the course of a
                search, or discards them during periodic sweeps to
                reclaim the memory consumed by old RRs.

• 返答を記録しておく構造体。 TTLの期限がきた古い RRs は捨てる責任があるので、 たいていの実装では受信した RRs にあった期間を キャッシュに記録するときになんらかの絶対時間に変えておく。 TTLを個々にカウントダウンするのではなく、 検索中に古い RRs を見つけたら、無視するか捨てるかする。 そのほか、 古い RRs のためのメモリを回収するために周期的清掃を行う。

5.3.3. アルゴリズム Algorithm

The top level algorithm has four steps:

アルゴリズム全体は 4 ステップからなる：

   1. See if the answer is in local information, and if so return
      it to the client.

• ローカル情報にあればそれを返す。

   2. Find the best servers to ask.

• 尋ねるためのサーバ群をさがす。

   3. Send them queries until one returns a response.

• どれかが返事を返してくるまで、問合せを送る。

   4. Analyze the response, either:

• 返事を分析する：

         a. if the response answers the question or contains a name
            error, cache the data as well as returning it back to
            the client.

• 問合せに対する答か名前エラーなら、クライアントに送るとともに データをキャッシュする。

         b. if the response contains a better delegation to other
            servers, cache the delegation information, and go to
            step 2.

• 他のサーバへの委譲なら、委譲情報をキャッシュしてステップ 2 に行く。

         c. if the response shows a CNAME and that is not the
            answer itself, cache the CNAME, change the SNAME to the
            canonical name in the CNAME RR and go to step 1.

• 返事がCNAMEであり、CNAMEが答そのものではないなら、 CNAMEをキャッシュする。 SNAMEを CNAME RRs の正規名で置き換えて、ステップ 1に行く。

         d. if the response shows a servers failure or other
            bizarre contents, delete the server from the SLIST and
            go back to step 3.

• サーバの故障か他の奇異な内容なら、SLISTからサーバを削除し、 ステップ 3に行く。

Step 1 searches the cache for the desired data. If the data is in the
cache, it is assumed to be good enough for normal use.  Some resolvers
have an option at the user interface which will force the resolver to
ignore the cached data and consult with an authoritative server.  This
is not recommended as the default.  If the resolver has direct access to
a name server's zones, it should check to see if the desired data is
present in authoritative form, and if so, use the authoritative data in
preference to cached data.

ステップ 1 ではキャッシュを検索する。 データがキャッシュにあれば、通常の利用には十分使えるものとされる。

レゾルバによっては、 キャッシュされたデータは無視して、 強制的に権威あるサーバに問合せさせるというオプションをユーザインタフェースに もつものもある。 これはデフォルトでは勧められない。 リゾルバがどれかのネームサーバのゾーンに直接アクセスできるのなら、 望むデータが権威を持つものかどうかを検査し、そうであれば、 キャッシュされたデータではなく権威あるデータを使うべきである。

Step 2 looks for a name server to ask for the required data.  The
general strategy is to look for locally-available name server RRs,
starting at SNAME, then the parent domain name of SNAME, the
grandparent, and so on toward the root.  Thus if SNAME were
Mockapetris.ISI.EDU, this step would look for NS RRs for
Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).
These NS RRs list the names of hosts for a zone at or above SNAME.  Copy
the names into SLIST.  Set up their addresses using local data.  It may
be the case that the addresses are not available.  The resolver has many
choices here; the best is to start parallel resolver processes looking
for the addresses while continuing onward with the addresses which are
available.  Obviously, the design choices and options are complicated
and a function of the local host's capabilities.  The recommended
priorities for the resolver designer are:

ステップ2 では必要なデータを問い合わせるためのネームサーバを探す。 一般戦略はローカルに利用可能なネームサーバ RRs を以下の順に探すことだ。 SNAMEから始めて、ルートに向かって順番に SNAME の親ドメイン名、 そのまた親という順に。 例えば、SNAME が Mockapetris.ISI.EDUであったとして、 このステップは Mockapetris.ISI.EDUのネームサーバ RRs、 次に ISI.EDUのネームサーバ RRs、 次にEDUのネームサーバ RRs、 次にルートのネームサーバ RRs を探すことになる。

これらの NS RRs は SNAMEとその祖先のゾーンのためのホストの一覧である。 それらの名前をSLISTにコピーする。ローカルデータを使って、そのアドレスを設定する。 アドレスはないかもしれない。 ここでリゾルバにはいくつか選択枝がある; 最もよいのは分っているアドレスを使って進行するのと並行して、 アドレス解決を始めることだ。 デザインの決定と選択は複雑であり、ローカルホストの能力によります。 リゾルバ設計者へのお勧めの優先順位は：

   1. Bound the amount of work (packets sent, parallel processes
      started) so that a request can't get into an infinite loop or
      start off a chain reaction of requests or queries with other
      implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
      SOME DATA.

1. 仕事の量 (送信パケット数、平行プロセス数)を制限せよ。
   • これは 『誰かがなにかのデータを間違って設定した場合』でも 問合せが無限ループに入ることがないように、 また、他の実装と合わせて 問合せの連鎖反応をひき起すことがないようにするためである。

   2. Get back an answer if at all possible.

• 可能なら答を戻す。

   3. Avoid unnecessary transmissions.

• 不必要な転送を避けよ。

   4. Get the answer as quickly as possible.

• できるだけ速く答を求めよ。

If the search for NS RRs fails, then the resolver initializes SLIST from
the safety belt SBELT.  The basic idea is that when the resolver has no
idea what servers to ask, it should use information from a configuration
file that lists several servers which are expected to be helpful.
Although there are special situations, the usual choice is two of the
root servers and two of the servers for the host's domain.  The reason
for two of each is for redundancy.  The root servers will provide
eventual access to all of the domain space.  The two local servers will
allow the resolver to continue to resolve local names if the local
network becomes isolated from the internet due to gateway or link
failure.

NS RRs の探索に失敗したら、リゾルバは安全ベルト SBELT でSLISTを初期化する。

尋ねるべきサーバがかわからない時には 設定ファイルある助けが期待できるサーバの一覧を使うというのが 基本的な考えです。 そうでないこともあるが、 通常はルートサーバのうちの二つとホストのドメインのサーバから二つを選ぶ。 二つ選ぶ理由は冗長正のためである。 ルートサーバは全ドメイン空間のいかなる部分へのアクセスも可能とする。 ローカルサーバはゲートウェイやリンクの故障でローカルネットワークが インターネットから切り離されてもローカルな名前の解決は続けられるためである。

In addition to the names and addresses of the servers, the SLIST data
structure can be sorted to use the best servers first, and to insure
that all addresses of all servers are used in a round-robin manner.  The
sorting can be a simple function of preferring addresses on the local
network over others, or may involve statistics from past events, such as
previous response times and batting averages.

サーバの名前とアドレス以外に SLIST データ構造体は 使用するのによいサーバが最初にきて、 全サーバのゼンアドレスがラウンドロビンで使われるように 順に並べておいてよい。

並べ替えはローカルネットワークを優先する単純なものであったり、 以前の応答時間や打率などの過去のイベントの統計を利用するものであったりしてよい。

Step 3 sends out queries until a response is received.  The strategy is
to cycle around all of the addresses for all of the servers with a
timeout between each transmission.  In practice it is important to use
all addresses of a multihomed host, and too aggressive a retransmission
policy actually slows response when used by multiple resolvers
contending for the same name server and even occasionally for a single
resolver.  SLIST typically contains data values to control the timeouts
and keep track of previous transmissions.

ステップ 3では返事があるまで、問合せを送る。 戦略は問合せ毎にタイムアウトを待ちながら、 全てのサーバの全アドレスをまわって順番に問合せることだ。 特にマルチホームホストにはその全アドレスを使うことが重要である。 あまり攻撃的な再送方針をもちいると、 同じサーバに対して複数のリゾルバが競合したりして 返答が遅くなる。ひとつのリゾルバでもおきることがある。

一般にSLISTはタイムアウトを制御し、過去の更新を記録するデータ値をもつ。

Step 4 involves analyzing responses.  The resolver should be highly
paranoid in its parsing of responses.  It should also check that the
response matches the query it sent using the ID field in the response.
The ideal answer is one from a server authoritative for the query which
either gives the required data or a name error.  The data is passed back
to the user and entered in the cache for future use if its TTL is
greater than zero.

ステップ4 では返事を分析する。 リゾルバは返事を解析するときには高度に神経を使うべきだ。 返事の ID フィールドを使って、返事と質問が対応しているかを検査すべきだ。 理想的な答とは問合せに対する権威をもつサーバからのものであって、 求めるデータまたは名前エラーがであるものである。 データはユーザに渡されるとともに、 TTL が 0 より大きいものは将来の利用に備えてキャッシュされる。

If the response shows a delegation, the resolver should check to see
that the delegation is 'closer' to the answer than the servers in SLIST
are.  This can be done by comparing the match count in SLIST with that
computed from SNAME and the NS RRs in the delegation.  If not, the reply
is bogus and should be ignored.  If the delegation is valid the NS
delegation RRs and any address RRs for the servers should be cached.
The name servers are entered in the SLIST, and the search is restarted.

返事が委譲を示しているとき、 リゾルバは委譲が SLIST 中のサーバーよりも答に「近い」か確認すべきだ。 これは SLIST と SNAMEの一致数と、委任とSNAMEの一致数を比較することで可能だ。 近くなければ答はゴミで無視される。 委譲が正当であれば、NS 委譲 RRs とサーバーのすべてのアドレス RRs とを キャッシュする。 これらのネームサーバは SLISTに含められ、探索を再開する。

If the response contains a CNAME, the search is restarted at the CNAME
unless the response has the data for the canonical name or if the CNAME
is the answer itself.

返事がCNAMEを含んでいる場合、 返事に正規名のデータがあるとか、CNAME自身が答であるとかいうのでなければ、 CNAMEから探索が再開される。

Details and implementation hints can be found in [RFC-1035].

詳細と実装の助言は[RFC-1035]にある。

---

2002-12-31 訳 前野年紀