RFC1794 日本語訳

Network Working Group                                          T. Brisco
Request for Comments: 1794                            Rutgers University
Category: Informational                                       April 1995

Briscoがコメントのために要求するワーキンググループT.をネットワークでつないでください: 1794年のラトガース大学カテゴリ: 情報の1995年4月

                     DNS Support for Load Balancing

ロードバランシングのDNSサポート

Status of this Memo

このMemoの状態

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

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

1. Introduction

1. 序論

   This RFC is meant to first chronicle a foray into the IETF DNS
   Working Group, discuss other possible alternatives to
   provide/simulate load balancing support for DNS, and to provide an
   ultimate, flexible solution for providing DNS support for balancing
   loads of many types.

このRFCは最初にIETF DNS作業部会に略奪を記録にとどめることになっていて、他の可能な代替手段について議論して、DNSのロードバランシングサポートを提供するか、またはシミュレートして、多くのタイプのバランスをとることの負荷のサポートをDNSに供給する究極の、そして、フレキシブルな解決法を提供してください。

2. History

2. 歴史

   The history of this probably dates back well before my own time - so
   undoubtedly some holes are here.  Hopefully they can be filled in by
   other authors.

この歴史は私自身の時のよく前にたぶんさかのぼられます--それほど確かにいくつかの穴がここにあります。 うまくいけば、他の作者はそれらに記入できます。

   Initially; "load balancing" was intended to permit the Domain Name
   System (DNS) [1] agents to support the concept of "clusters" (derived
   from the VMS usage) of machines - where all machines were
   functionally similar or the same, and it didn't particularly matter
   which machine was picked - as long as the load of the processing was
   reasonably well distributed across a series of actual different
   hosts.  Around 1986 a number of different schemes started surfacing
   as hacks to the Berkeley Internet Name Domain server (BIND)
   distribution.  Probably the most widely distributed of these were the
   "Shuffle Address" (SA) modifications by Bryan Beecher, or possibly
   Marshall Rose's "Round Robin" code.

初めは。 処理の負荷が一連の実際の異なったホストの向こう側に合理的によく分配された限り、「ロードバランシング」が、ドメインネームシステム(DNS)[1]エージェントがすべてのマシンが機能上同様であるか、または同じであり、どのマシンが選ばれたかが特に重要でなかったところのマシンの「クラスタ」(VMS用法から、派生する)の概念を支持することを許可することを意図しました。 1986年頃に、多くの異なった計画がハッキングとしてバークレーインターネットName Domainサーバ(BIND)分配に表面化し始めました。 たぶんこれらについて最も広く分配されているのは、ブライアンBeecherによる「シャッフルアドレス」(SA)変更、またはことによるとマーシャル・ローズの「連続」コードでした。

   The SA records, however, did a round-robin ordering of the Address
   resource records, and didn't do much with regard to the particular
   loads on the target machines.  Matt Madison (of TGV) implemented some
   changes that used VMS facilities to review the system loads, and
   return A RRs in the order of least-loaded to most loaded.

SA記録は、しかしながら、Addressリソース記録を注文する連続をして、ターゲットマシンで特定の負荷に関して多くのことはしませんでした。 マット・マディソン(TGVの)はシステム・ロードを見直すのにVMS施設を使用したいくつかの変化を実行しました、そして、大部分への最も満載でない注文におけるリターンA RRsはロードしました。

   The problem was with SAs was that load was not actually a factor, and
   TGV's relied on VMS specific facilities to order the records.  The SA
   RRs required changes to the DNS specification (in file syntax and in

問題はSAsと共に、それがいたということでした。負荷は実際に要素ではありませんでした、そして、TGVは記録を注文するためにVMSの特定の施設を当てにしました。 ファイル構文と中SA RRsがDNS仕様への変化を必要とした、(。

Brisco                                                          [Page 1]

RFC 1794             DNS Support for Load Balancing           April 1995

Brisco[1ページ]RFC1794DNSはロードバランシングのために1995年4月を支持します。

   record processing).  These were both viewed as drawbacks and not as
   general solutions.

記録的な処理) これらは一般解として見なされたのではなく、欠点としてともに見なされました。

   Most of the Internet waited in anticipation of an IETF approved
   method for simulating "clusters".

IETFを予測して待たれたインターネットの大部分は「クラスタ」をシミュレートするための方法を承認しました。

   Through a few IETF DNS Working Group sessions (Chaired by Rob Austein
   of Epilogue), it was collectively agreed upon that a number of
   criteria must be met:

いくつかのIETF DNS作業部会のセッション(EpilogueのロブAusteinによってまとめられる)で、それで多くの評価基準を満たさなければならないのにまとめて同意されました:

       A) Backwards compatibility with the existing DNS RFC.

a) 既存のDNS RFCとの遅れている互換性。

       B) Information changes frequently.

B) 情報は頻繁に変化します。

       C) Multiple addresses should be sent out.

C) 複数のアドレスを出すべきです。

       D) Must interact with other RRs appropriately.

D) 適切に他のRRsと対話しなければなりません。

       E) Must be able to represent many types of "loads"

E) 多くのタイプの「負荷」を表すことができなければなりません。

       F) Must be fast.

F) 断食はそうであるに違いありませんか?

   (A) would ensure that the installed base of BIND and other DNS
   implementations would continue to operate and interoperate properly.

(A) BINDと他のDNS実現のインストールされたベースが適切に作動して、共同利用し続けているのを確実にするでしょう。

   (B) would permit very fast update times - to enable modeling of
   real-time data.  Five minutes was thought as a normal interval,
   though changes as fast as every sixty seconds could be imagined.

(B) 非常に速いアップデート時間を可能にするでしょう--リアルタイムデータのモデルを可能にするために。 60秒毎としての速い同じくらい変化を想像できましたが、5分は正常な間隔として考えられました。

   (C) would cover the possibility of a host's address being advertised
   as optimal, yet the machine crashed during the period within the TTL
   of the RR.  The second-most preferable address would be advertised
   second, the third-most preferable third, and so on.  This would allow
   a reasonable stab at recovery during machine failures.

(C) 最適であるとして広告に掲載されているホストのアドレスの可能性をカバーして、しかし、マシンは期間、RRのTTLの中でクラッシュしました。 2番目に、最も2番目の望ましいアドレスの広告を出すだろう、最も第3望ましい3番目、とてもオンです。 マシンの故障の間、これは回復で妥当な一刺しを許容するでしょう。

   (D) would ensure correct handling of all ancillary information - such
   as MX, RP, and TXT information, as well as reverse lookup
   information.  It needed to be ensured that such processes as mail
   handling continued to work in an unsurprising and predictable manner.

(D) MXや、RPや、TXT情報などのすべての補助的情報の正しい取り扱いを確実にして、ルックアップ情報を逆にするでしょう。 それは、メール取り扱いとしての過程が驚くほどでなくて予測できる方法で働き続けていたそのそのようなものが確実にされる必要がありました。

   (E) would ensure the flexibility that everyone wished.  A breadth of
   "loads" were wished to be represented by various members of the DNS
   Working Group.  Some "loads" were fairly eclectic - such as the
   address ordering by the RTT to the host, some were pragmatic - such
   as balancing the CPU load evenly across a series of hosts.  All
   represented valid concerns within their own context, and the idea of
   having separate RR types for each was unthinkable (primarily; it
   would violate goal A).

(E) 皆が願っていた柔軟性を確実にするでしょう。 「負荷」の幅はDNS作業部会の様々なメンバーによって表されることが願われていました。 いくつかの「負荷」がRTTによってホストに注文されるアドレスなどのようにかなり折衷主義者であった、或るものは一連のホストの向こう側に均等にCPU荷重のバランスをとるのなどように実践的でした。 すべてがそれら自身の文脈の中に有効な関心を表しました、そして、それぞれのための別々のRRタイプがあるという考えは思いもよりませんでした(主として、それは目標Aに違反するでしょう)。

Brisco                                                          [Page 2]

RFC 1794             DNS Support for Load Balancing           April 1995

Brisco[2ページ]RFC1794DNSはロードバランシングのために1995年4月を支持します。

   (F) needed to ensure a few things.  Primarily that the time to
   calculate the information to order the addressing information did not
   exceed the TTL of the information distributed - i.e., that elements
   with a TTL of five minutes didn't take six minutes to calculate.
   Similarly; it seems a fairly clear goal in the DNS RFC that clients
   should not be kept waiting - that request processing should continue
   regardless of the state of any other processing occurring.

いくつかのものを確実にするのに必要である(F)。 主として、アドレス指定情報を注文するために情報について計算する時間はすなわち、5分のTTLがある要素が計算するには6分かからなかったという分配された情報のTTLを超えていませんでした。 同様に。 クライアントを待ち続けるべきではありません--要求処理がいかなる他の処理発生の状態にかかわらず続くべきであるのはDNS RFCでかなり明確な目標に見えます。

3. Possible Alternatives

3. 可能な代替手段

   During various discussions with the DNS Working Group and with the
   Load Balancing Committee, it was noted that no existing solution
   dealt with all wishes appropriately.  One of the major successes of
   the DNS is its flexibility - and it was felt that this needed to be
   retained in all aspects.  It was conceived that perhaps not only
   address information would need to be changed rapidly, but other
   records may also need to change rapidly (at least this could not be
   ruled out - who knows what technologies lurk in the future).

DNS作業部会とLoad Balancing Committeeとの様々な議論の間、どんな既存の解決策も適切にすべての願望に対処したというわけではないことに注意されました。 DNSの大成功の1つは柔軟性です、そして、これが、全面で保有される必要だったと感じられました。 また、恐らく、情報が急速に変えるために必要とするアドレスだけではなく、他の記録も、急速に変化する必要であるかもしれないのが(少なくともこれを除外できませんでした--何か技術は将来、潜みます)発想されました。

   Of primary concern to many was the ability to interact with older
   implementations of DNS.  The DNS is implemented widely now, and
   changes to critical portions of the protocol could cause havoc for
   years.  It became rapidly apparent through conversations with Jon
   Postel and Dave Crocker (Area Director) that modifications to the
   protocol would be viewed dimly.

予備選挙では、多くへの関心はDNSの、より古い実現と対話する能力でした。 DNSは現在広く実行されました、そして、プロトコルの批判的な部分への変化は長年大破壊を引き起こす場合がありました。 プロトコルへの変更が薄暗く見られるだろうというのはジョン・ポステルとデーヴ・クロッカー(領域のディレクター)との会話で急速に明らかになりました。

4. A Flexible Model

4. フレキシブルなモデル

   During many hours of discussions, it arose upon suggestion from Rob
   Austein that the changes could be implemented without changes to the
   protocol; if zone transfer behavior could be subtly changed, then the
   zone transfer process could accommodate the changing of various RR
   information.  What was needed was a smarter program to do the zone
   transfers.  Pursuant to this, changes were made to BIND that would
   permit the specification of the program to do the zone transfers for
   particular zones.

何時間も議論の間、提案のときに、ロブAusteinから、プロトコルへの変化なしで変化を実行できたのは起こりました。 ゾーン転送の振舞いをかすかに変えることができるなら、ゾーン転送の過程は様々なRR情報の変化を収容するかもしれないでしょうに。 必要であったものはゾーン転送をするよりきびきびしたプログラムでした。 これに従って、変更をプログラムの仕様が特定のゾーンのためのゾーン転送をするのを可能にするBINDにしました。

   There is no specification that a secondary has to receive updates
   from its primary server in any specific manner - only that it needs
   to check periodically, and obtain new zone copies when changes have
   been made.  Conceivably the zone transfer agent could obtain the
   information from any number of sources (e.g., a load average daemon,
   a round-robin sorter) and present the information back to the
   nameserver for distribution.

2番目が第一のサーバからどんな特定の方法でもアップデートを受けるために持っている仕様が全くありません--変更が行われたときだけ、それは、定期的にチェックして、新しいゾーンコピーを入手する必要があります。 多分、ゾーンの証券代行は、いろいろなソース(例えば、負荷の平均したデーモン、連続選別機)から情報を得て、分配のためにネームサーバに情報を提示であって戻しできました。

   A number of questions arose from this concept, and all seem to have
   been dealt with accordingly.  Primarily, the DNS protocol doesn't
   guarantee ordering.  While the DNS protocol doesn't guarantee

多くの質問がこの概念から起こりました、そして、すべてがそれに従って、対処されたように思えます。 主として、DNSプロトコルは注文を保証しません。 プロトコルが保証しないDNSをゆったり過ごしてください。

Brisco                                                          [Page 3]

RFC 1794             DNS Support for Load Balancing           April 1995

Brisco[3ページ]RFC1794DNSはロードバランシングのために1995年4月を支持します。

   ordering, it is clear that the ordering is predictive - that
   information read in twice in the same order will be presented twice
   in the same order to clients.  Clients, of course, may reorder this
   information, but that is deemed as a "local issue" as it is
   configurable by the remote systems administrators (e.g., sortlists,
   etc).  The zone transfer agent would have to account for any "mis-
   ordering" that may occur locally, but remote reordering (e.g., client
   side sortlists) of RRs is is impossible to predict.  Since local
   mis-ordering is consistent, the zone transfer agents could easily
   account for this.

注文、注文が予言的であることは、明確です--二度同次で読まれた情報は同次でクライアントに二度提示されるでしょう。 クライアント、もちろん、追加注文、それがリモート上級システムアドミニストレータ(例えば、sortlistsなど)が構成可能であるので、しかし、この情報、それは「ローカルの問題」として考えられるかもしれません。 局所的に起こるかもしれませんが、RRsのリモート再命令(例えば、クライアントサイドsortlists)が起こるどんな「誤注文」も予測するのが不可能であるので、ゾーンの証券代行は説明しなければならないでしょう。 地方の誤注文が一貫しているので、ゾーンの証券代行は容易にこれを説明できました。

   Secondarily, but perhaps more subtly, the problem arises that zone
   transfers aren't used by primary nameservers, only by secondary
   nameservers.  To clarify this, the idea of "fast" or "volatile"
   subzones must be dealt with.  In a volatile environment (where
   address or other RR ordering changes rapidly), the refresh rate of a
   zone must be set very low, and the TTL of the RRs handed out must
   similarly be very low.  There is no use in handing out information
   with TTLs of an hour, when the conditions for ordering the RRs
   changes minutely.  There must be a relatively close relationship
   between the refresh rates and TTLs of the information.  Of course,
   with very low refresh rates, zone transfers between the primary and
   secondary would have to occur frequently.  Given that primary and
   secondary nameservers should be topologically and geographically far
   apart, moving that much data that frequently is seen as prohibitive.
   Also; the longer the propagation time between the primary and
   secondary, the larger the window in which circumstances can change -
   thus invalidating the secondary's information.  It is generally
   thought that passing volatile information on to a secondary is fairly
   useless - if secondaries want accurate information, then they should
   calculate it themselves and not obtain it via zone transfers.  This
   avoids the problem with secondaries losing contact with the primaries
   (but access to the targets of the volatile domain are still
   reachable), but the secondary has information that is growing stale.

二次的に、しかし、恐らくよりかすかに、ゾーン転送が第一のネームサーバと、二次ネームサーバだけによって使用されないという問題は起こります。 これをはっきりさせるために、「速い」か「揮発性」の「副-ゾーン」の考えに対処しなければなりません。 揮発性の環境(アドレスか他のRR注文が急速に変化するところ)で、非常に低くゾーンのリフレッシュレートを設定しなければなりません、そして、与えられたRRsのTTLは同様に非常に低くなければなりません。 1時間のTTLsがある情報を与えるのにおいて無駄があります、RRs変化を綿密に注文するための状態であるときに。 情報のリフレッシュレートとTTLsとの比較的親密な関係があるに違いありません。 もちろん、非常に低いリフレッシュレートで、第一と二次の間のゾーン転送は頻出しなければならないでしょう。 それを考えて、第一の、そして、二次のネームサーバは位相的に地理的にかけ離れるべきです、頻繁に禁止とみなされる感動的なそれだけのデータ。 また。 第一と二次の間の伝播時間が長ければ長いほど、事情が変化する、その結果、2番目の情報を無効にすることができる窓は、より大きいです。 一般に、揮発性の情報を2番目に渡すのがかなり役に立たないと思われます--代理人が的確な情報が欲しいなら、彼らは、自分たちでそれについて計算して、ゾーン転送を通してそれを得るべきではありません。 これは予備選挙から連絡が絶える代理人に関する問題を避けますが(揮発性のドメインの目標へのアクセスはまだ届いています)、二次には、聞き古したであるなっている情報があります。

   What is essentially necessary is a secondary (with no primary) which
   can calculate the necessary ordering of the RR data for itself (which
   also avoids the problem of different versions of domain servers
   predictively ordering RR information in different predictive
   fashions).  For a volatile zone, there is no primary DNS agent, but
   rather a series of autonomous secondary agents.  Each autonomous
   secondary agent is, of course, capable of calculating the ordering or
   content of the volatile RRs itself.

本質的には必要なことはそれの缶がそれ自体(また、ドメインサーバの異なった見解が異なった予言のファッションによる情報をRRに予言したように注文するという問題を避ける)のためのRRデータの必要な注文について計算する2番目(予備選挙のない)です。 揮発性のゾーンには、いいえ、第一のDNSエージェント、しかし、むしろ一連の自治の二次エージェントがいます。 それぞれの自治の二次エージェントはもちろん揮発性のRRs自身の注文か内容について計算できます。

Brisco                                                          [Page 4]

RFC 1794             DNS Support for Load Balancing           April 1995

Brisco[4ページ]RFC1794DNSはロードバランシングのために1995年4月を支持します。

5. Implementation

5. 実現

   With some help from Masataka Ohta (Tokyo Institute of Technology), I
   implemented modifications to BIND to permit the specification of the
   zone transfer program (zone transfer agent) for particular domains:

Masataka太田(東京工業大学)からの何らかの助けで、私は特定のドメインのためのゾーン転送プログラム(ゾーンの証券代行)の仕様を可能にするためにBINDへの変更を実行しました:

           transfer        <domain-name>       <program-name>

転送<ドメイン名><プログラム名>。

   Currently I define a separate subdomain that has a few hosts defined
   in it - all volatile information.  The zone has a refresh rate of
   300, and a minimum TTL of 300 indicated.  The configuration file is
   indicated as "volatile.hosts".  Every 300 seconds a program "doAxfer"
   is run to do the zone transfer.  The program "doAxfer" reads the file
   "volatile.hosts.template" and the file "volatile.hosts.list".  The
   addresses specified in volatile.hosts.list are rotated a random
   number of times, and then substituted (in order) into
   volatile.hosts.template to generate the file volatile.hosts.  The
   program "doAxfer" then exits with a value of 1 - to indicate to the
   nameserver that the zone transfer was successful, and that the file
   should be read in, and the information distributed.  This results in
   a host having multiple addresses, and the addresses are randomized
   every five minutes (300 seconds).

現在の、私はそれで数人のホストを定義する別々のサブドメインを定義します--すべての揮発性の情報。 ゾーンには、300のリフレッシュレート、および300のTTLが示した最小限があります。 構成ファイルは"volatile.hosts"として示されます。 300秒プログラム"doAxfer"毎は、ゾーン転送をするために走ります。 プログラム"doAxfer"はファイル"volatile.hosts.template"とファイル"volatile.hosts.list"を読みます。 volatile.hosts.listで指定されたアドレスは、ファイルvolatile.hostsを発生させるようにvolatile.hosts.templateに回の乱数が回転して、次に、代入された(in order)が回転します。 次に、プログラム"doAxfer"は1の値と共に出ます--ファイルがゾーン転送がうまくいって、中の読書と、広げられた情報であるべきであることをネームサーバに示すために。 これは複数のアドレスを持っているホストをもたらします、そして、アドレスは5分(300秒)毎にランダマイズされます。

   Two bugs continue to plague us in this endeavor.  BIND currently
   considers any TTL under 300 seconds as "irrational", and substitutes
   in the value of 300 instead.  This greatly hampers the functionality
   of volatile zones.  In the fastest of all cases - a 0 TTL -
   information would be used once, and then thrown away.  Presumably the
   new RR information could be calculated every 5 seconds, and the RRs
   handed out with a TTL of 0.  It must be considered that one
   limitation of the speed of a zone is going to be the ability of a
   machine to calculate new information fast enough.

2つのバグが、この努力で私たちを苦しめ続けています。 BINDは現在、代わりに「不合理である」としての300秒未満のどんなTTL、および300の値における代用品も考えます。 これは揮発性のゾーンの機能性を大いに妨げます。 最も速い場合(0TTL)では、情報は、一度使用されて、次に、無駄にされるでしょう。 おそらく、新しいRR情報は、計算された5秒毎と、0のTTLと共に与えられたRRsであるかもしれません。 マシンが十分速く新情報について計算するためにゾーンの速度の1つの制限が能力になると考えなければなりません。

   The other bug that also effects this is that, as with TTLs, BIND
   considers any zone refresh rate under 15 minutes to be similarly
   irrational.  Obviously zone refresh rates of 15 minutes is
   unacceptable for this sort of applications.

また、これに作用するもう片方のバグはそれです、BINDが、TTLsと共に15分未満のどんなゾーンリフレッシュレートも同様に不合理であると考えるとき。 明らかに、この種類のアプリケーションには、15のゾーンリフレッシュレートは分間容認できません。

   For a work-around, the current code sets these same hard-coded values
   to 60 seconds.  Sixty seconds is still large enough to avoid any
   residual bugs associated with small timer values, but is also short
   enough to allow fast subzones to be of use.

次善策のために、現在のコードはこれらの同じ困難なコード化された値を60秒に設定します。 60秒も、まだ三流の人の値に関連しているどんな残りのバグも避けることができるくらい大きいのですが、また、「副-ゾーン」が役に立つのを速く許容できるくらい短いです。

   This version of BIND is currently in release within Rutgers
   University, operating in both "fast" and normal zones.

ともに「速く」て正常なゾーンで作動して、ラトガース大学の中にBINDのこのバージョンは現在、リリースにあります。

Brisco                                                          [Page 5]

RFC 1794             DNS Support for Load Balancing           April 1995

Brisco[5ページ]RFC1794DNSはロードバランシングのために1995年4月を支持します。

6. Performance

6. パフォーマンス

   While the performance of fast zones isn't exactly stellar, it is not
   much more than the normal CPU loads induced by BIND.  Testing was
   performed on a Sun Sparc-2 being used as a normal workstation, but no
   resolvers were using the name server - essentially the nameserver was
   idle.  For a configuration with no fast subzones, BIND accrued 11 CPU
   seconds in 24 hours.  For a configuration with one fast zone, six
   address records, and being refreshed every 300 seconds (5 minutes),
   BIND accrued 1 minute 4 seconds CPU time.  For the same previous
   configuration, but being refreshed every sixty seconds, BIND accrued
   5 minutes and 38 seconds of CPU time.

速いゾーンの性能がまさに星ではありませんが、それはBINDによって引き起こされた正常なCPU荷重よりあまり多くはありません。 テストは正常なワークステーションが使用しますが、どんなレゾルバもネームサーバを使用していなかったので使用されることでSun Sparc-2に実行されました--本質的にはネームサーバは活動していませんでした。 速い「副-ゾーン」のない構成のために、BINDは24時間で11CPU秒生じました。 1つの速いゾーンと、6つのアドレス記録と、リフレッシュされる300秒(5分)毎の構成のために、BINDは1分4秒CPU時間に生じました。 しかし、同じ前の構成、60秒毎に壮快な存在のために、BINDは5分と38秒のCPU時間を生じさせました。

   As is no great surprise, the CPU load on the serving machine was
   linear to the frequency of the refresh time.  The sixty second
   refresh configuration used approximately five times as much CPU time
   as did the 300 second refresh configuration.  One can easily
   extrapolate that the overall CPU utilization would be linear to the
   number of zones and the frequency of the refresh period.  All of this
   is based on a shell script that always indicated that a zone update
   was necessary, a more intelligent program should realize when the
   reordering of the RRs was unnecessary and avoid such periodic zone
   reloads.

どんな寝耳に水の出来事のようにも、給仕マシンにおけるCPU荷重が頻度に直線的でなかった、時間をリフレッシュしてください。 62番目は300のように、2番目が構成をリフレッシュする多くのCPU時間としておよそ5回使用される構成をリフレッシュします。 1つが容易に推定できる、総合的なCPU使用率がゾーンの数と頻度に直線的であるだろう、期間をリフレッシュしてください。 このすべてがいつもゾーンアップデートが必要であることを示したシェルスクリプトに基づいていて、より知的なプログラムは、RRsの再命令がいつ不要であったかをわかって、そのような周期的なゾーン再ロードを避けるはずです。

7. Acknowledgments

7. 承認

   Most of the ideas in this document are the results of conversations
   and proposals from many, many people - including, but not limited to,
   Robert Austein, Stuart Vance, Masataka Ohta, Marshall Rose, and the
   members of the IETF DNS Working Group.

考えの大部分は本書では多くの人々からの会話と提案の結果です--包含、他、ロバートAustein、スチュアート・ヴァンス、Masataka太田、ローズ、およびIETF DNSのメンバーのマーシャルの作業部会。

8. References

8. 参照

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

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

Brisco                                                          [Page 6]

RFC 1794             DNS Support for Load Balancing           April 1995

Brisco[6ページ]RFC1794DNSはロードバランシングのために1995年4月を支持します。

9.  Security Considerations

9. セキュリティ問題

   Security issues are not discussed in this memo.

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

10. Author's Address

10. 作者のアドレス

   Thomas P. Brisco
   Associate Director for Network Operations
   Rutgers University
   Computing Services, Telecommunications Division
   Hill Center for the Mathematical Sciences
   Busch Campus
   Piscataway, New Jersey 08855-0879
   USA

ネットワークオペレーションラトガース大学コンピューターサービスのためのトーマスP.Brisco次長、数学の科学ブッシュキャンパスニュージャージー08855-0879ピスキャタウェイ(米国)への電信課ヒルセンター

   Phone: +1-908-445-2351
   EMail: brisco@rutgers.edu

以下に電話をしてください。 +1-908-445-2351 メールしてください: brisco@rutgers.edu

Brisco                                                          [Page 7]

Brisco[7ページ]