RFC1536 日本語訳

Network Working Group                                           A. Kumar
Request for Comments: 1536                                     J. Postel
Category: Informational                                        C. Neuman
                                                                     ISI
                                                               P. Danzig
                                                               S. Miller
                                                                     USC
                                                            October 1993

コメントを求めるワーキンググループA.クマーの要求をネットワークでつないでください: 1536年のJ.ポステルカテゴリ: 情報のC.のP.ダンツィグS.ミラーUSCヌーマンISI1993年10月

          Common DNS Implementation Errors and Suggested Fixes

一般的なDNS実装誤りと提案されたフィックス

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。

Abstract

要約

   This memo describes common errors seen in DNS implementations and
   suggests some fixes. Where applicable, violations of recommendations
   from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo
   also describes, where relevant, the algorithms followed in BIND
   (versions 4.8.3 and 4.9 which the authors referred to) to serve as an
   example.

このメモは、DNS実装で見られた一般的な誤りについて説明して、いくつかのフィックスを示します。 適切であるところに、STD13とRFC1034とSTD13、RFC1035年からの推薦の違反は言及されます。 また、メモは関連しているところの例として機能するようにBIND(バージョン4.8 作者が言及した.3と4.9)で従われたアルゴリズムを説明します。

Introduction

序論

   The last few years have seen, virtually, an explosion of DNS traffic
   on the NSFnet backbone. Various DNS implementations and various
   versions of these implementations interact with each other, producing
   huge amounts of unnecessary traffic. Attempts are being made by
   researchers all over the internet, to document the nature of these
   interactions, the symptomatic traffic patterns and to devise remedies
   for the sick pieces of software.

ここ数年が実際にはDNSトラフィックのNSFnetバックボーンに関する爆発を見ました。 多量の不要なトラフィックを生産して、様々なDNS実装とこれらの実装の様々なバージョンは互いに対話します。 試みは、これらの相互作用の自然、徴候的なトラフィック・パターンを記録して、病気のソフトウェアのための療法を工夫するためにインターネット全体にわたる研究者によってされています。

   This draft is an attempt to document fixes for known DNS problems so
   people know what problems to watch out for and how to repair broken
   software.

この草稿が知られているDNS問題によってフィックスを記録する試みであるので、人々はどんな問題に注意するか、そして、どのように壊れているソフトウェアを修理するかを知っています。

1. Fast Retransmissions

1. 速いRetransmissions

   DNS implements the classic request-response scheme of client-server
   interaction. UDP is, therefore, the chosen protocol for communication
   though TCP is used for zone transfers. The onus of requerying in case
   no response is seen in a "reasonable" period of time, lies with the
   client. Although RFC 1034 and 1035 do not recommend any

DNSはクライアント/サーバ相互作用の古典的な要求応答体系を実装します。 TCPはゾーン転送に使用されますが、したがって、UDPはコミュニケーションのための選ばれたプロトコルです。 場合で応答について全く再質問しない重荷は「妥当な」期間、クライアントがいる偽りで見られます。 RFC1034と1035はいずれも推薦しませんが

Kumar, Postel, Neuman, Danzig & Miller                          [Page 1]

RFC 1536            Common DNS Implementation Errors        October 1993

クマー、ポステル、ヌーマン、ダンツィグ、およびDNS実装誤り1993年10月に一般的なミラー[1ページ]RFC1536

   retransmission policy, RFC 1035 does recommend that the resolvers
   should cycle through a list of servers. Both name servers and stub
   resolvers should, therefore, implement some kind of a retransmission
   policy based on round trip time estimates of the name servers. The
   client should back-off exponentially, probably to a maximum timeout
   value.

「再-トランスミッション」方針、RFC1035は、レゾルバがサーバのリストを通して自転車で行くはずであるのを推薦します。 したがって、ネームサーバとスタッブレゾルバの両方がネームサーバの周遊旅行時間見積りに基づく「再-トランスミッション」方針についてある種を実装するべきです。 クライアントはたぶん最大のタイムアウト値に指数関数的に引き返すべきです。

   However, clients might not implement either of the two. They might
   not wait a sufficient amount of time before retransmitting or they
   might not back-off their inter-query times sufficiently.

しかしながら、クライアントはどちらの2も実装しないかもしれません。 彼らが再送する前に、十分な時間を待たないかもしれませんか、または彼らは自分達の相互質問時代を十分戻さないかもしれません。

   Thus, what the server would see will be a series of queries from the
   same querying entity, spaced very close together. Of course, a
   correctly implemented server discards all duplicate queries but the
   queries contribute to wide-area traffic, nevertheless.

したがって、サーバが見るものは非常に近くで一緒に区切られた同じ質問実体から一連の質問になるでしょう。 もちろん、正しく実装しているサーバはすべての写し質問を捨てますが、それにもかかわらず、質問は広い領域トラフィックに貢献します。

   We classify a retransmission of a query as a pure Fast retry timeout
   problem when a series of query packets meet the following conditions.

一連の質問パケットが以下の条件を満たすと、私たちは純粋なFast再試行タイムアウト問題として質問の「再-トランスミッション」を分類します。

      a. Query packets are seen within a time less than a "reasonable
         waiting period" of each other.

a。 質問パケットは互いの「妥当な待ちの期間」より少ない時以内に見られます。

      b. No response to the original query was seen i.e., we see two or
         more queries, back to back.

b。 オリジナルの質問への応答は全く見られませんでした、すなわち、私たちが2つ以上の質問を後部に見て戻します。

      c. The query packets share the same query identifier.

c。 質問パケットは同じ質問識別子を共有します。

      d. The server eventually responds to the query.

d。 サーバは結局、質問に反応します。

A GOOD IMPLEMENTATION:

良い実装:

   BIND (we looked at versions 4.8.3 and 4.9) implements a good
   retransmission algorithm which solves or limits all of these
   problems.  The Berkeley stub-resolver queries servers at an interval
   that starts at the greater of 4 seconds and 5 seconds divided by the
   number of servers the resolver queries. The resolver cycles through
   servers and at the end of a cycle, backs off the time out
   exponentially.

BIND(私たちはバージョン4.8 .3と4.9を見た)はどれが. バークレースタッブレゾルバが4秒について、よりすばらしいところで始まる間隔を置いてサーバについて質問することにおけるこれらの問題のすべてを解決するか、または制限するか、そして、レゾルバが質問するサーバの数が割られた5秒を良い再送信アルゴリズムに実装します。 レゾルバはサーバを通して1サイクルの終わり、タイムアウトの後部で指数関数的に自転車で行きます。

   The Berkeley full-service resolver (built in with the program
   "named") starts with a time-out equal to the greater of 4 seconds and
   two times the round-trip time estimate of the server.  The time-out
   is backed off with each cycle, exponentially, to a ceiling value of
   45 seconds.

バークレーフルサービスレゾルバ(組立の「命名されている」プログラムで)はサーバの往復の時間見積りの4秒と2倍について、よりすばらしいのと等しいタイムアウトから始まります。タイムアウトはそれぞれのサイクルに45秒の天井値に指数関数的に戻されます。

Kumar, Postel, Neuman, Danzig & Miller                          [Page 2]

RFC 1536            Common DNS Implementation Errors        October 1993

クマー、ポステル、ヌーマン、ダンツィグ、およびDNS実装誤り1993年10月に一般的なミラー[2ページ]RFC1536

FIXES:

フィックス:

      a. Estimate round-trip times or set a reasonably high initial
         time-out.

a。 往復の回を見積もっているか、またはかなり高い初期のタイムアウトを設定してください。

      b. Back-off timeout periods exponentially.

b。 タイムアウト時間を指数関数的に戻してください。

      c. Yet another fundamental though difficult fix is to send the
         client an acknowledgement of a query, with a round-trip time
         estimate.

c。 難しいフィックスですが、さらに別の基本的は質問の承認をクライアントに送ることです、往復の時間見積りで。

   Since UDP is used, no response is expected by the client until the
   query is complete.  Thus, it is less likely to have information about
   previous packets on which to estimate its back-off time.  Unless, you
   maintain state across queries, so subsequent queries to the same
   server use information from previous queries.  Unfortunately, such
   estimates are likely to be inaccurate for chained requests since the
   variance is likely to be high.

UDPが使用されているので、質問が完全になるまで、応答は全くクライアントによって予想されません。 したがって、それは下に後部時間を見積もっている前のパケットの情報をより持っていそうにはありません。 あなたが、したがって、質問の向こう側に、同じサーバへのその後の質問が前の質問から情報を使用すると述べるように主張しない場合。 残念ながら、そのような見積りは変化が高い傾向があるのでチェーニングされた要求に不正確である傾向があります。

   The fix chosen in the ARDP library used by Prospero is that the
   server will send an initial acknowledgement to the client in those
   cases where the server expects the query to take a long time (as
   might be the case for chained queries).  This initial acknowledgement
   can include an expected time to wait before retrying.

プロスペローによって使用されたARDP図書館で選ばれたフィックスはサーバがサーバが質問が長くかかると予想する(チェーニングされた質問のためにそうであるかもしれないように)それらの場合におけるクライアントに初期の承認を送るということです。 この初期の承認は再試行する前に待つ予想された時間を含むことができます。

   This fix is more difficult since it requires that the client software
   also be trained to expect the acknowledgement packet. This, in an
   internet of millions of hosts is at best a hard problem.

また、クライアントソフトウェアが確認応答パケットを予想するよう訓練されるのが必要であるので、このフィックスは、より難しいです。 何百万人ものホストのインターネットにおけるこれはせいぜいそうです。難問。

2. Recursion Bugs

2. 再帰バグ

   When a server receives a client request, it first looks up its zone
   data and the cache to check if the query can be answered. If the
   answer is unavailable in either place, the server seeks names of
   servers that are more likely to have the information, in its cache or
   zone data. It then does one of two things. If the client desires the
   server to recurse and the server architecture allows recursion, the
   server chains this request to these known servers closest to the
   queried name. If the client doesn't seek recursion or if the server
   cannot handle recursion, it returns the list of name servers to the
   client assuming the client knows what to do with these records.

サーバがクライアント要求を受け取るとき、それは、最初に、質問に答えることができるかどうかチェックするためにゾーンデータとキャッシュを調べます。 答えがどちらかの場所で入手できないなら、サーバは情報をより持ちそうなサーバの名前を求めます、キャッシュかゾーンデータで。 そして、それは2つのものの1つをします。 クライアントが「再-呪い」にサーバを望んでいて、サーバー・アーキテクチャが再帰を許容するなら、サーバは質問された名前の最も近くでこれらの知られているサーバにこの要求を束縛します。 クライアントが再帰を求めないことができないか、サーバが再帰を扱うことができないなら、それはクライアントが、これらの記録で何をしたらよいかを知っていると仮定するクライアントにネームサーバのリストを返します。

   The client queries this new list of name servers to get either the
   answer, or names of another set of name servers to query. This
   process repeats until the client is satisfied. Servers might also go
   through this chaining process if the server returns a CNAME record
   for the queried name. Some servers reprocess this name to try and get
   the desired record type.

クライアントは答えを得るネームサーバのこの新しいリスト、または質問するもう1セットのネームサーバの名前について質問します。 クライアントが満足するまで、このプロセスは繰り返されます。 また、サーバが質問された名前のためのCNAME記録を返すなら、サーバはこの推論プロセスを通るかもしれません。 これが必要なレコード種類を得てみるために命名するいくらかのサーバ「再-プロセス」。

Kumar, Postel, Neuman, Danzig & Miller                          [Page 3]

RFC 1536            Common DNS Implementation Errors        October 1993

クマー、ポステル、ヌーマン、ダンツィグ、およびDNS実装誤り1993年10月に一般的なミラー[3ページ]RFC1536

   However, in certain cases, this chain of events may not be good. For
   example, a broken or malicious name server might list itself as one
   of the name servers to query again. The unsuspecting client resends
   the same query to the same server.

しかしながら、ある場合には、この一連の出来事は良くないかもしれません。 例えば、壊れているか悪意があるネームサーバは再び質問するネームサーバの1つにそれ自体について記載するかもしれません。 疑わないクライアントは同じサーバに同じ質問を再送します。

   In another situation, more difficult to detect, a set of servers
   might form a loop wherein A refers to B and B refers to A. This loop
   might involve more than two servers.

1セットのサーバが形成するかもしれない別の検出するより難しい状況に、AがBについて言及して、BがA.This輪を呼ぶ輪は2つ以上のサーバにかかわるかもしれません。

   Yet another error is where the client does not know how to process
   the list of name servers returned, and requeries the same server
   since that is one (of the few) servers it knows.

さらに別の誤りはクライアントがそれ以来の同じサーバがどのように返されたネームサーバ、および再質問のリストを処理するためには、それが知っている1つ(わずかの)のサーバであるかを知らないところです。

   We, therefore, classify recursion bugs into three distinct
   categories:

したがって、私たちは再帰バグを3つの異なったカテゴリに分類します:

      a. Ignored referral: Client did not know how to handle NS records
         in the AUTHORITY section.

a。 無視された紹介: クライアントはAUTHORITY部でNS記録を扱う方法を知りませんでした。

      b. Too many referrals: Client called on a server too many times,
         beyond a "reasonable" number, with same query. This is
         different from a Fast retransmission problem and a Server
         Failure detection problem in that a response is seen for every
         query.  Also, the identifiers are always different. It implies
         client is in a loop and should have detected that and broken
         it.  (RFC 1035 mentions that client should not recurse beyond
         a certain depth.)

b。 あまりに多くの紹介: クライアントはあまりに何回も同じ質問がある「妥当な」数を超えてサーバを訪問しました。 これはFast retransmission問題とServer Failure検出問題と応答があらゆる質問に関して見られるという点において異なっています。 また、識別子もいつも異なっています。 それは、クライアントが輪にいるのを含意して、それを検出して、それを壊すべきでした。 (ある深さを超えた「再-呪い」ではなく、クライアントがそうするべきであるRFC1035言及。)

      c. Malicious Server: a server refers to itself in the authority
         section. If a server does not have an answer now, it is very
         unlikely it will be any better the next time you query it,
         specially when it claims to be authoritative over a domain.

c。 悪意があるサーバ: 権威部でサーバはそれ自体について言及します。 ドメインの上で正式であると主張するとき、サーバに答えが現在ないなら、特に、あなたがそれについて質問する次の時に少しもより良くなるのは非常にありそうもないです。

      RFC 1034 warns against such situations, on page 35.

RFC1034は35ページのそのような状況に対して警告します。

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

「要求が他の実装EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED SOME DATAで無限ループに入ることができませんし、要求か質問の連鎖反応を始めることができないように、仕事量を縛ります(パケットは発信して、平行なプロセスは始まりました)。」だった

A GOOD IMPLEMENTATION:

良い実装:

   BIND fixes at least one of these problems. It places an upper limit
   on the number of recursive queries it will make, to answer a
   question.  It chases a maximum of 20 referral links and 8 canonical
   name translations.

BINDは少なくともこれらの問題の1つを固定します。それは、それがする反復クエリーの数に関して質問に答えるために上限を課します。 それは最大20個の紹介リンクと8つの正準な名前翻訳を追いかけます。

Kumar, Postel, Neuman, Danzig & Miller                          [Page 4]

RFC 1536            Common DNS Implementation Errors        October 1993

クマー、ポステル、ヌーマン、ダンツィグ、およびDNS実装誤り1993年10月に一般的なミラー[4ページ]RFC1536

FIXES:

フィックス:

      a. Set an upper limit on the number of referral links and CNAME
         links you are willing to chase.

a。 あなたが追いかけても構わないと思っている紹介リンクとCNAMEリンクの数に上限を設定してください。

         Note that this is not guaranteed to break only recursion loops.
         It could, in a rare case, prune off a very long search path,
         prematurely.  We know, however, with high probability, that if
         the number of links cross a certain metric (two times the depth
         of the DNS tree), it is a recursion problem.

これが再帰輪だけを壊すために保証されないことに注意してください。 まれなケースでは、それは早まって、非常に長い検索で経路を剪定するかもしれません。 私たちは知っていて、高い確率で、しかしながら、それはリンクの数であるならメートル法であり(DNS木の深さの2倍)、それが再帰問題であることを確信しているaに交差しています。

      b. Watch out for self-referring servers. Avoid them whenever
         possible.

b。 自己を参照するサーバに注意してください。 可能であるときはいつも、それらを避けてください。

      c. Make sure you never pass off an authority NS record with your
         own name on it!

c。 あなた自身の名前がそれにある状態で、権威NS記録を必ず決してそらさないでください!

      d. Fix clients to accept iterative answers from servers not built
         to provide recursion. Such clients should either be happy with
         the non-authoritative answer or be willing to chase the
         referral links themselves.

d。 クライアントを修理して、再帰を提供するために組立てられなかったサーバから繰り返しの答えを受け入れてください。 そのようなクライアントは、非正式の答えにうれしいか、または紹介リンク自体を追いかけても構わないと思うべきです。

3. Zero Answer Bugs:

3. ゼロはバグに答えます:

   Name servers sometimes return an authoritative NOERROR with no
   ANSWER, AUTHORITY or ADDITIONAL records. This happens when the
   queried name is valid but it does not have a record of the desired
   type. Of course, the server has authority over the domain.

ネームサーバはANSWERも、AUTHORITYもまたはADDITIONAL記録なしで正式のNOERRORを時々返します。 質問された名前が妥当ですが、それでは必要なタイプに関する記録がないとき、これは起こります。 もちろん、サーバはドメインの上で権限があります。

   However, once again, some implementations of resolvers do not
   interpret this kind of a response reasonably. They always expect an
   answer record when they see an authoritative NOERROR. These entities
   continue to resend their queries, possibly endlessly.

しかしながら、もう一度、レゾルバのいくつかの実装は合理的に応答のこの種類を解釈しません。 正式のNOERRORを見るとき、彼らはいつも答え記録を予想します。 これらの実体は、彼らの質問をことによると際限なく再送し続けています。

A GOOD IMPLEMENTATION

良い実装

   BIND resolver code does not query a server more than 3 times. If it
   is unable to get an answer from 4 servers, querying them three times
   each, it returns error.

BINDレゾルバコードは3回以上のサーバについて質問しません。 それぞれそれらについて3回質問して、4つのサーバから答を出すことができないなら、それは誤りを返します。

   Of course, it treats a zero-answer response the way it should be
   treated; with respect!

もちろん、扱われるべきである方法で無答え応答を扱います。 敬意をもって!

FIXES:

フィックス:

      a. Set an upper limit on the number of retransmissions for a given
         query, at the very least.

a。 「再-トランスミッション」の数に少なくとも与えられた質問に上限を設定してください。

Kumar, Postel, Neuman, Danzig & Miller                          [Page 5]

RFC 1536            Common DNS Implementation Errors        October 1993

クマー、ポステル、ヌーマン、ダンツィグ、およびDNS実装誤り1993年10月に一般的なミラー[5ページ]RFC1536

      b. Fix resolvers to interpret such a response as an authoritative
         statement of non-existence of the record type for the given
         name.

b。 レゾルバを修理して、名のためのレコード種類の非存在の権威ある声明のような応答を解釈してください。

4. Inability to detect server failure:

4. サーバ失敗を検出できないこと:

   Servers in the internet are not very reliable (they go down every
   once in a while) and resolvers are expected to adapt to the changed
   scenario by not querying the server for a while. Thus, when a server
   does not respond to a query, resolvers should try another server.
   Also, non-stub resolvers should update their round trip time estimate
   for the server to a large value so that server is not tried again
   before other, faster servers.

インターネットにおけるサーバはそれほど高信頼ではありません、そして、(それらは時々、落ちます)レゾルバがしばらくサーバについて質問しないことによって変えられたシナリオに順応すると予想されます。 したがって、サーバが質問に反応しないと、レゾルバは別のサーバを試みるはずです。また、非スタッブレゾルバがサーバのための彼らの周遊旅行時間見積りを大きい値にアップデートするはずであるので、サーバは他の、そして、より速いサーバの前に再び試みられません。

   Stub resolvers, however, cycle through a fixed set of servers and if,
   unfortunately, a server is down while others do not respond for other
   reasons (high load, recursive resolution of query is taking more time
   than the resolver's time-out, ....), the resolver queries the dead
   server again! In fact, some resolvers might not set an upper limit on
   the number of query retransmissions they will send and continue to
   query dead servers indefinitely.

しかしながら、スタッブレゾルバは固定セットのサーバを通して自転車で行きます、そして、他のものが他の理由で応じませんが(高い負荷、質問の再帰的な決議はリゾルバのタイムアウトより多くの時間がかかっています)、サーバが残念ながら下がっているなら、レゾルバは再び死んでいるサーバについて質問します! 事実上、何人かのレゾルバは、彼らが送る質問「再-トランスミッション」の数に上限を設定して、死んでいるサーバについて無期限に質問し続けないかもしれません。

   Name servers running system or chained queries might also suffer from
   the same problem. They store names of servers they should query for a
   given domain. They cycle through these names and in case none of them
   answers, hit each one more than one. It is, once again, important
   that there be an upper limit on the number of retransmissions, to
   prevent network overload.

また、システムを動かすネームサーバかチェーニングされた質問が同じ問題に苦しむかもしれません。 彼らはそれらが与えられたドメインに質問するべきであるサーバの名前を保存します。 彼らはこれらの名前、およびそれらのいずれが答えでない場合におけるヒットそれぞれ1以上を通して循環します。 それがもう一度重要である、それ、そこ、ネットワークオーバーロードを防ぐためには「再-トランスミッション」の数に関する上限になってください。

   This behavior is clearly in violation of the dictum in RFC 1035 (page
   46)

この振舞いは明確にRFC1035の断言を違反しています。(46ページ)

      "If a resolver gets a server error or other bizarre response
       from a name server, it should remove it from SLIST, and may
       wish to schedule an immediate transmission to the next
       candidate server address."

「レゾルバがネームサーバからサーバ誤りか他の奇妙な応答を得るなら、SLISTからそれを取り除くべきであり、次の候補サーバアドレスに即座のトランスミッションの計画をしたがっているかもしれません。」

   Removal from SLIST implies that the server is not queried again for
   some time.

SLISTからの取り外しは、サーバが再びしばらく質問されないのを含意します。

   Correctly implemented full-service resolvers should, as pointed out
   before, update round trip time values for servers that do not respond
   and query them only after other, good servers. Full-service resolvers
   might, however, not follow any of these common sense directives. They
   query dead servers, and they query them endlessly.

正しく実装しているフルサービスレゾルバは単にそれらについて反応して、次々と質問しない他の、そして、良いサーバのために、以前指摘されるように周遊旅行時間的価値をアップデートするはずです。 しかしながら、フルサービスレゾルバはこれらの常識の指示のいずれにも続かないかもしれません。 彼らは死んでいるサーバについて質問します、そして、それらはそれらについて際限なく質問します。

Kumar, Postel, Neuman, Danzig & Miller                          [Page 6]

RFC 1536            Common DNS Implementation Errors        October 1993

クマー、ポステル、ヌーマン、ダンツィグ、およびDNS実装誤り1993年10月に一般的なミラー[6ページ]RFC1536

A GOOD IMPLEMENTATION:

良い実装:

   BIND places an upper limit on the number of times it queries a
   server.  Both the stub-resolver and the full-service resolver code do
   this.  Also, since the full-service resolver estimates round-trip
   times and sorts name server addresses by these estimates, it does not
   query a dead server again, until and unless all the other servers in
   the list are dead too!  Further, BIND implements exponential back-off
   too.

BINDはサーバについて質問するという回の数に関して上限を課します。スタッブレゾルバとフルサービスレゾルバコードの両方がこれをします。 そして、また、フルサービスレゾルバが、往復の回と種類がネームサーバアドレスであるとこれらの見積りで見積もっているので再び死んでいるサーバについて質問しない、リストの他のすべてのサーバもまた、死んでいるというわけではないなら! さらに、BINDは下に指数の後部も実装します。

FIXES:

フィックス:

      a. Set an upper limit on number of retransmissions.

a。 「再-トランスミッション」の数に上限を設定してください。

      b. Measure round-trip time from servers (some estimate is better
         than none). Treat no response as a "very large" round-trip
         time.

b。 サーバからの往復の時間を測定してください(何らかの見積りがなにもより良いです)。 往復の「非常に大きい」時間として応答を全く扱わないでください。

      c. Maintain a weighted rtt estimate and decay the "large" value
         slowly, with time, so that the server is eventually tested
         again, but not after an indefinitely long period.

c。 時間でゆっくり「大きい」値を荷重しているrtt見積りに維持して、腐食してください、サーバが結局再びテストされますが、無期限に長い期間の後にテストされるというわけではないように。

      d. Follow an exponential back-off scheme so that even if you do
         not restrict the number of queries, you do not overload the
         net excessively.

d。 質問の数を制限しないでも、ネットを過度に積みすぎないように指数の下に後部体系に続いてください。

5. Cache Leaks:

5. 漏出をキャッシュしてください:

   Every resource record returned by a server is cached for TTL seconds,
   where the TTL value is returned with the RR. Full-service (or stub)
   resolvers cache the RR and answer any queries based on this cached
   information, in the future, until the TTL expires. After that, one
   more query to the wide-area network gets the RR in cache again.

サーバによって返されたあらゆるリソース記録がTTL秒の間、キャッシュされます、RRと共にTTL値を返すところで。 フルサービス(または、スタッブ)レゾルバはどんな質問もこのキャッシュされた情報に基礎づけたRRと答えをキャッシュします、将来、TTLが期限が切れるまで。 その後に、広域ネットワークへのもうひとつの質問が再びキャッシュでRRを手に入れます。

   Full-service resolvers might not implement this caching mechanism
   well. They might impose a limit on the cache size or might not
   interpret the TTL value correctly. In either case, queries repeated
   within a TTL period of a RR constitute a cache leak.

フルサービスレゾルバは、メカニズムをよくキャッシュしながら、これを実装しないかもしれません。 彼らは、キャッシュサイズで指し値しないか、正しくTTL値を解釈しないかもしれません。 どちらの場合ではも、RRのTTLの期間以内に繰り返された質問はキャッシュ漏出を構成します。

A GOOD/BAD IMPLEMENTATION:

良いか悪い実装:

   BIND has no restriction on the cache size and the size is governed by
   the limits on the virtual address space of the machine it is running
   on. BIND caches RRs for the duration of the TTL returned with each
   record.

BINDはキャッシュサイズに制限を全く持っていません、そして、サイズはそれが動いているマシンの仮想アドレス空間における限界で決定されます。 TTLの持続時間のためのBINDキャッシュRRsは各記録とともに帰りました。

   It does, however, not follow the RFCs with respect to interpretation
   of a 0 TTL value. If a record has a TTL value of 0 seconds, BIND uses

しかしながら、RFCsは、0TTL価値の解釈に関してそれがそうするのに続きません。 記録に0秒、BIND用途のTTL値があるなら

Kumar, Postel, Neuman, Danzig & Miller                          [Page 7]

RFC 1536            Common DNS Implementation Errors        October 1993

クマー、ポステル、ヌーマン、ダンツィグ、およびDNS実装誤り1993年10月に一般的なミラー[7ページ]RFC1536

   the minimum TTL value, for that zone, from the SOA record and caches
   it for that duration. This, though it saves some traffic on the
   wide-area network, is not correct behavior.

最小のTTLはその持続時間のためにSOA記録とキャッシュからそのゾーンにそれを評価します。 広域ネットワークに関する何らかのトラフィックを保存しますが、これは正しい振舞いではありません。

FIXES:

フィックス:

      a. Look over your caching mechanism to ensure TTLs are interpreted
         correctly.

a。 TTLsが正しく解釈されるのを保証するためにメカニズムをキャッシュするのに目を通してください。

      b. Do not restrict cache sizes (come on, memory is cheap!).
         Expired entries are reclaimed periodically, anyway. Of course,
         the cache size is bound to have some physical limit. But, when
         possible, this limit should be large (run your name server on
         a machine with a large amount of physical memory).

b。 キャッシュサイズを制限しないでください(来てください、そして、メモリは安いです!)。 満期のエントリーは定期的、とにかく開墾されます。 もちろん、キャッシュサイズには、何らかの物理的な限界が必ずあるでしょう。 しかし、可能であるときに、この限界は大きいはずです(多量の物理的なメモリでネームサーバをマシンに実行してください)。

      c. Possibly, a mechanism is needed to flush the cache, when it is
         known or even suspected that the information has changed.

c。 ことによると、メカニズムがキャッシュを洗い流すのに必要です、情報が変化したと知られているか、または疑われるときさえ。

6. Name Error Bugs:

6. 誤りをバグと命名してください:

   This bug is very similar to the Zero Answer bug. A server returns an
   authoritative NXDOMAIN when the queried name is known to be bad, by
   the server authoritative for the domain, in the absence of negative
   caching. This authoritative NXDOMAIN response is usually accompanied
   by the SOA record for the domain, in the authority section.

このバグはZero Answerバグと非常に同様です。 質問された名前が悪いのが知られていると、サーバは正式のNXDOMAINを返します、ドメインに、正式のサーバで、否定的キャッシュが不在のとき。 通常、この正式のNXDOMAIN応答は権威部のドメインのためのSOA記録によって伴われます。

   Resolvers should recognize that the name they queried for was a bad
   name and should stop querying further.

レゾルバが認識するはずである、名義の彼らが質問した、悪名であり、さらに質問するのを止めるべきです。

   Some resolvers might, however, not interpret this correctly and
   continue to query servers, expecting an answer record.

答え記録を予想して、しかしながら、何人かのレゾルバは、正しくこれを解釈して、サーバについて質問し続けないかもしれません。

   Some applications, in fact, prompt NXDOMAIN answers! When given a
   perfectly good name to resolve, they append the local domain to it
   e.g., an application in the domain "foo.bar.com", when trying to
   resolve the name "usc.edu" first tries "usc.edu.foo.bar.com", then
   "usc.edu.bar.com" and finally the good name "usc.edu". This causes at
   least two queries that return NXDOMAIN, for every good query. The
   problem is aggravated since the negative answers from the previous
   queries are not cached.  When the same name is sought again, the
   process repeats.

事実上、いくつかのアプリケーションがNXDOMAIN答えをうながします! 決議する完全に良い名前を与えるとき、彼らは局所領域をそれに追加します、例えば、"usc.edu"という名前を決議しようとするときのドメイン"foo.bar.com"のアプリケーションは最初に、"usc.edu.foo.bar.com"、当時の"usc.edu.bar.com"、および最終的に良い名前"usc.edu"を試みます。 これはあらゆる良い質問のために少なくとも2つの質問にそのリターンNXDOMAINを引き起こします。 問題は以来いらいらさせられて、前の質問からの否定的な返答がキャッシュされないということです。 同じ名前が再び求められるとき、プロセスは繰り返されます。

   Some DNS resolver implementations suffer from this problem, too. They
   append successive sub-parts of the local domain using an implicit
   searchlist mechanism, when certain conditions are satisfied and try
   the original name, only when this first set of iterations fails. This
   behavior recently caused pandemonium in the Internet when the domain
   "edu.com" was registered and a wildcard "CNAME" record placed at the

いくつかのDNSレゾルバ実装がこの問題にも苦しみます。 彼らは局所領域が内在しているsearchlistメカニズムを使用する連続したサブの部品を追加します、ある状態が満たされていて、オリジナルの名前を試みるとき、繰り返しのこの第一セットが失敗する場合にだけ。 ドメイン"edu.com"が最近登録されたとき大混乱がインターネットで引き起こされたこの振舞いと入賞したワイルドカード"CNAME"記録

Kumar, Postel, Neuman, Danzig & Miller                          [Page 8]

RFC 1536            Common DNS Implementation Errors        October 1993

クマー、ポステル、ヌーマン、ダンツィグ、およびDNS実装誤り1993年10月に一般的なミラー[8ページ]RFC1536

   top level. All machines from "com" domains trying to connect to hosts
   in the "edu" domain ended up with connections to the local machine in
   the "edu.com" domain!

トップレベル。 "edu"ドメインのすべての接続しようとする"com"ドメインからホストまでのマシンが"edu.com"ドメインの地方のマシンとの接続で終わりました!

GOOD/BAD IMPLEMENTATIONS:

良いか悪い実装:

   Some local versions of BIND already implement negative caching. They
   typically cache negative answers with a very small TTL, sufficient to
   answer a burst of queries spaced close together, as is typically
   seen.

BINDのいくつかのローカルのバージョンが既に否定的キャッシュを実装します。 彼らは非常に小さいTTLとの否定的な返答を通常キャッシュします、近くで一緒に、そのままで通常見られた状態で区切られた質問の炸裂に答えるために、十分です。

   The next official public release of BIND (4.9.2) will have negative
   caching as an ifdef'd feature.

BINDの次の公式の公共のリリース、(4.9、.2、)、ifdefがキャッシュするようにキャッシュされるネガに特集させるでしょう。

   The BIND resolver appends local domain to the given name, when one of
   two conditions is met:

2つの状態の1つが会われるとき、BINDレゾルバは局所領域を名に追加します:

      i.  The name has no periods and the flag RES_DEFNAME is set.
      ii. There is no trailing period and the flag RES_DNSRCH is set.

i。 名前には、期間が全くありません、そして、旗のRES_DEFNAMEは. iiを設定することです。 引きずっている期間が全くありません、そして、旗のRES_DNSRCHは用意ができています。

   The flags RES_DEFNAME and RES_DNSRCH are default resolver options, in
   BIND, but can be changed at compile time.

旗のRES_DEFNAMEとRES_DNSRCHをBINDのデフォルトレゾルバオプションですが、コンパイル時に変えることができます。

   Only if the name, so generated, returns an NXDOMAIN is the original
   name tried as a Fully Qualified Domain Name. And only if it contains
   at least one period.

そのように生成している名前が戻る場合にだけ、NXDOMAINはFully Qualified Domain Nameとして試みられたオリジナルの名前です。 そして、少なくとも1回の期間を含んでいる場合にだけ。

FIXES:

フィックス:

      a. Fix the resolver code.

a。 レゾルバコードを修理してください。

      b. Negative Caching. Negative caching servers will restrict the
         traffic seen on the wide-area network, even if not curb it
         altogether.

b。 否定的キャッシュ。 否定的キャッシュサーバが広域ネットワークで見られたトラフィックを制限する、それを全体で制限してください。

      c. Applications and resolvers should not append the local domain to
         names they seek to resolve, as far as possible. Names
         interspersed with periods should be treated as Fully Qualified
         Domain Names.

c。 アプリケーションとレゾルバは彼らができるだけ決議しようとする名前に局所領域を追加するはずがありません。 期間で点在する名前はFully Qualified Domain Namesとして扱われるべきです。

         In other words, Use searchlists only when explicitly specified.
         No implicit searchlists should be used. A name that contains
         any dots should first be tried as a FQDN and if that fails, with
         the local domain name (or searchlist if specified) appended. A
         name containing no dots can be appended with the searchlist right
         away, but once again, no implicit searchlists should be used.

言い換えれば、明らかであるときにだけ、Use searchlistsは指定しました。 どんな内在しているsearchlistsも使用するべきではありません。 FQDNとそれが失敗するかどうかとしてどんなドットも含む名前は最初に試みられるべきです、局所領域名で(searchlist、指定される、)、追加しています。 すぐ、searchlistでドットを全く含まない名前は追加できますが、もう一度、どんな内在しているsearchlistsも使用するべきではありません。

Kumar, Postel, Neuman, Danzig & Miller                          [Page 9]

RFC 1536            Common DNS Implementation Errors        October 1993

クマー、ポステル、ヌーマン、ダンツィグ、およびDNS実装誤り1993年10月に一般的なミラー[9ページ]RFC1536

   Associated with the name error bug is another problem where a server
   might return an authoritative NXDOMAIN, although the name is valid. A
   secondary server, on start-up, reads the zone information from the
   primary, through a zone transfer. While it is in the process of
   loading the zones, it does not have information about them, although
   it is authoritative for them.  Thus, any query for a name in that
   domain is answered with an NXDOMAIN response code. This problem might
   not be disastrous were it not for negative caching servers that cache
   this answer and so propagate incorrect information over the internet.

名前誤りバグに関連づけられているのは、サーバが正式のNXDOMAINを返すかもしれない別の問題です、名前が妥当ですが。 上にから始まるところでは、セカンダリサーバは予備選挙からゾーン転送でゾーン情報を読みます。 ゾーンをロードすることの途中にある間、それには、それらの情報がありません、それらに、それは正式ですが。 したがって、そのドメインの名前のためのどんな質問もNXDOMAIN応答コードで答えられます。 この答えをキャッシュするのでインターネットの上で不正確な情報を伝播する否定的キャッシュサーバがなければ、この問題は悲惨でないかもしれません。

BAD IMPLEMENTATION:

悪い実装:

   BIND apparently suffers from this problem.

BINDは明らかにこの問題が欠点です。

   Also, a new name added to the primary database will take a while to
   propagate to the secondaries. Until that time, they will return
   NXDOMAIN answers for a good name. Negative caching servers store this
   answer, too and aggravate this problem further. This is probably a
   more general DNS problem but is apparently more harmful in this
   situation.

また、プライマリデータベースに追加された新しい名前は、代理人に伝播するにはしばらくかかるでしょう。 その時まで、彼らは良い名前のための答えをNXDOMAINに返すでしょう。 否定的キャッシュサーバは、また、この答えを保存して、さらにこの問題をいらいらさせます。 これは、たぶんより一般的なDNS問題ですが、この状況で明らかにより有害です。

FIX:

以下を修理してください。

      a. Servers should start answering only after loading all the zone
         data. A failed server is better than a server handing out
         incorrect information.

a。 サーバは、すべてのゾーンデータをロードした後にだけ答え始めるべきです。 失敗したサーバは不正確な情報を与えるサーバより良いです。

      b. Negative cache records for a very small time, sufficient only
         to ward off a burst of requests for the same bad name. This
         could be related to the round-trip time of the server from
         which the negative answer was received. Alternatively, a
         statistical measure of the amount of time for which queries
         for such names are received could be used. Minimum TTL value
         from the SOA record is not advisable since they tend to be
         pretty large.

b。 同じ悪名を求める要求の炸裂を避けることができるくらいのだけ非常に小さい時間の否定的キャッシュ記録。 これは否定的な返答が受けられたサーバの往復の時間に関連できました。 あるいはまた、そのような名前のための質問が受け取られている時間の統計的な基準を使用できました。 かなり大きい傾向があって、SOA記録からの最小のTTL値は賢明ではありません。

      c. A "PUSH" (or, at least, a "NOTIFY") mechanism should be allowed
         and implemented, to allow the primary server to inform
         secondaries that the database has been modified since it last
         transferred zone data.  To alleviate the problem of "too many
         zone transfers" that this might cause, Incremental Zone
         Transfers should also be part of DNS.  Also, the primary should
         not NOTIFY/PUSH with every update but bunch a good number
         together.

c。 「プッシュ」(少なくとも「通知」)メカニズムは、プライマリサーバが、最後にゾーンデータを移して以来データベースが変更されていることを代理人に知らせるのを許容するために許容されていて、実装されるべきです。 また、これが引き起こすかもしれない「あまりに多くのゾーン転送」の問題を軽減するために、Incremental Zone TransfersはDNSの一部であるべきです。 また、予備選挙はあらゆるアップデートがあるNOTIFY/PUSHではなく、一緒に房のa良い番号がそうするべきです。

Kumar, Postel, Neuman, Danzig & Miller                         [Page 10]

RFC 1536            Common DNS Implementation Errors        October 1993

クマー、ポステル、ヌーマン、ダンツィグ、およびDNS実装誤り1993年10月に一般的なミラー[10ページ]RFC1536

7. Format Errors:

7. 誤りをフォーマットしてください:

   Some resolvers issue query packets that do not necessarily conform to
   standards as laid out in the relevant RFCs. This unnecessarily
   increases net traffic and wastes server time.

何らかのレゾルバ問題が必ず関連RFCsで広げられるように規格に従うというわけではないパケットについて質問します。 これは不必要にネットのトラフィックと廃棄物サーバ時間を増強します。

FIXES:

フィックス:

      a. Fix resolvers.

a。 レゾルバを修理してください。

      b. Each resolver verify format of packets before sending them out,
         using a mechanism outside of the resolver. This is, obviously,
         needed only if step 1 cannot be followed.

b。 それらを出す前に各レゾルバはパケットの形式について確かめます、レゾルバの外でメカニズムを使用して。方法1に従うことができない場合にだけ、これが明らかに必要です。

References

参照

   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
       RFC 1034, USC/Information Sciences Institute, November 1987.

[1]Mockapetrisと、P.と、「ドメイン名概念と施設」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日

   [2] Mockapetris, P., "Domain Names Implementation and Specification",
       STD 13, RFC 1035, USC/Information Sciences Institute, November
       1987.

[2]Mockapetrisと、P.と、「ドメイン名実装と仕様」、STD13、RFC1035、科学が設けるUSC/情報、11月1987日

   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
       974, CSNET CIC BBN, January 1986.

[3] ヤマウズラと、C.と、「メールルート設定とドメインシステム」、STD14、RFC974、CSNET CIC BBN、1月1986日

   [4] Gavron, E., "A Security Problem and Proposed Correction With
       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
       October 1993.

[4] Gavronと、E.と、「広く配布しているDNSソフトウェアとの警備上の問題と提案された修正」(RFC1535)は研究株式会社(1993年10月)を負かします。

   [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
       1537, CWI, October 1993.

[5]Beertema、P.、「一般的なDNSデータファイル構成誤り」、RFC1537、CWI、1993年10月。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Kumar, Postel, Neuman, Danzig & Miller                         [Page 11]

RFC 1536            Common DNS Implementation Errors        October 1993

クマー、ポステル、ヌーマン、ダンツィグ、およびDNS実装誤り1993年10月に一般的なミラー[11ページ]RFC1536

Authors' Addresses

作者のアドレス

   Anant Kumar
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina Del Rey CA 90292-6695

AnantクマーUSC情報科学は4676の海軍省方法でマリーナデル・レイカリフォルニア90292-6695を設けます。

   Phone:(310) 822-1511
   FAX:  (310) 823-6741
   EMail: anant@isi.edu

電話: (310) 822-1511 ファックスで以下を送ってください。 (310) 823-6741 メールしてください: anant@isi.edu

   Jon Postel
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina Del Rey CA 90292-6695

ジョンポステルUSC情報科学は4676の海軍省方法でマリーナデル・レイカリフォルニア90292-6695を設けます。

   Phone:(310) 822-1511
   FAX:  (310) 823-6714
   EMail: postel@isi.edu

電話: (310) 822-1511 ファックスで以下を送ってください。 (310) 823-6714 メールしてください: postel@isi.edu

   Cliff Neuman
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina Del Rey CA 90292-6695

クリフヌーマンUSC情報科学は4676の海軍省方法でマリーナデル・レイカリフォルニア90292-6695を設けます。

   Phone:(310) 822-1511
   FAX:  (310) 823-6714
   EMail: bcn@isi.edu

電話: (310) 822-1511 ファックスで以下を送ってください。 (310) 823-6714 メールしてください: bcn@isi.edu

   Peter Danzig
   Computer Science Department
   University of Southern California
   University Park

ピーターダンツィグコンピュータサイエンス部の南カリフォルニア大学大学公園

   EMail: danzig@caldera.usc.edu

メール: danzig@caldera.usc.edu

   Steve Miller
   Computer Science Department
   University of Southern California
   University Park
   Los Angeles CA 90089

南カリフォルニアユニヴァーシティー・パークロサンゼルスカリフォルニア 90089人のスティーブ・ミラーコンピュータサイエンス部の大学

   EMail: smiller@caldera.usc.edu

メール: smiller@caldera.usc.edu

Kumar, Postel, Neuman, Danzig & Miller                         [Page 12]

クマー、ポステル、ヌーマン、ダンツィグ、およびミラー[12ページ]