RFC1183 日本語訳

Network Working Group                                        C. Everhart
Request for Comments: 1183                                      Transarc
Updates: RFCs 1034, 1035                                      L. Mamakos
                                                  University of Maryland
                                                              R. Ullmann
                                                          Prime Computer
                                                  P. Mockapetris, Editor
                                                                     ISI
                                                            October 1990

コメントを求めるワーキンググループC.エバーハートの要求をネットワークでつないでください: 1183のTransarcアップデート: RFCs1034、1035L.Mamakosメリーランド大学R.ウルマンプライムコンピュータP.Mockapetris、エディタISI1990年10月

                         New DNS RR Definitions

新しいDNS RR定義

Status of this Memo

このMemoの状態

   This memo defines five new DNS types for experimental purposes.  This
   RFC describes an Experimental Protocol for the Internet community,
   and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

このメモは実験目的のための5つの新しいDNSタイプを定義します。 このRFCは改良のためにインターネットコミュニティ、要求議論、および提案のためのExperimentalプロトコルについて説明します。 このメモの分配は無制限です。

Table of Contents

目次

   Introduction....................................................    1
   1. AFS Data Base location.......................................    2
   2. Responsible Person...........................................    3
   2.1. Identification of the guilty party.........................    3
   2.2. The Responsible Person RR..................................    4
   3. X.25 and ISDN addresses, Route Binding.......................    6
   3.1. The X25 RR.................................................    6
   3.2. The ISDN RR................................................    7
   3.3. The Route Through RR.......................................    8
   REFERENCES and BIBLIOGRAPHY.....................................    9
   Security Considerations.........................................   10
   Authors' Addresses..............................................   11

序論… 1 1. AFS Data基地の位置… 2 2. 責任がある人… 3 2.1. 犯人の識別… 3 2.2. 責任者RR… 4 3. X.25とISDNアドレス、Route Binding… 6 3.1. X25 RR… 6 3.2. ISDN RR… 7 3.3. RRを通したルート… 8つの参照箇所と図書目録… 9 セキュリティ問題… 10人の作者のアドレス… 11

Introduction

序論

   This RFC defines the format of new Resource Records (RRs) for the
   Domain Name System (DNS), and reserves corresponding DNS type
   mnemonics and numerical codes.  The definitions are in three
   independent sections: (1) location of AFS database servers, (2)
   location of responsible persons, and (3) representation of X.25 and
   ISDN addresses and route binding.  All are experimental.

このRFCはドメインネームシステム(DNS)のために新しいResource Records(RRs)の書式を定義します、そして、蓄えの対応するDNSはニーモニックと数字コードをタイプします。 定義が3つの独立しているセクションにあります: (1) AFSデータベースサーバー、責任者の(2)位置の位置、およびX.25、ISDNアドレス、およびルート結合の(3)表現。 すべてが実験的です。

   This RFC assumes that the reader is familiar with the DNS [3,4].  The
   data shown is for pedagogical use and does not necessarily reflect
   the real Internet.

このRFCは、読者がDNS[3、4]に詳しいと仮定します。 示されたデータは、教育学の使用のためにあって、必ず本当のインターネットを反映するというわけではありません。

Everhart, Mamakos, Ullmann & Mockapetris                        [Page 1]

RFC 1183                 New DNS RR Definitions             October 1990

エバーハート、Mamakos、ウルマン、およびDNS RR定義1990年10月に新しいMockapetris[1ページ]RFC1183

1. AFS Data Base location

1. AFS Data基地の位置

   This section defines an extension of the DNS to locate servers both
   for AFS (AFS is a registered trademark of Transarc Corporation) and
   for the Open Software Foundation's (OSF) Distributed Computing
   Environment (DCE) authenticated naming system using HP/Apollo's NCA,
   both to be components of the OSF DCE.  The discussion assumes that
   the reader is familiar with AFS [5] and NCA [6].

このセクションは、AFS(AFSはTransarc社の登録商標である)とHP/アポロのNCAを使用するとシステムを命名しながら認証されたオープン・ソフトウェア協議会(OSF)の分配されたComputing Environment(DCE)のためのサーバの場所を見つけて、ともにOSF DCEの部品になるようにDNSの拡大を定義します。 議論は、読者がAFS[5]とNCA[6]に詳しいと仮定します。

   The AFS (originally the Andrew File System) system uses the DNS to
   map from a domain name to the name of an AFS cell database server.
   The DCE Naming service uses the DNS for a similar function: mapping
   from the domain name of a cell to authenticated name servers for that
   cell.  The method uses a new RR type with mnemonic AFSDB and type
   code of 18 (decimal).

AFS(元々のアンドリューFile System)システムはドメイン名からAFSセルデータベースサーバーの名前まで地図にDNSを使用します。DCE Namingサービスは同様の機能にDNSを使用します: そのセルのためにセルのドメイン名から認証されたネームサーバまで写像します。 メソッドは18(10進)のニーモニックAFSDBとタイプコードと共に新しいRRタイプを使用します。

   AFSDB has the following format:

AFSDBには、以下の形式があります:

   <owner> <ttl> <class> AFSDB <subtype> <hostname>

<所有者><ttl><クラス>AFSDB<「副-タイプ」><ホスト名>。

   Both RDATA fields are required in all AFSDB RRs.  The <subtype> field
   is a 16 bit integer.  The <hostname> field is a domain name of a host
   that has a server for the cell named by the owner name of the RR.

両方のRDATA分野がすべてのAFSDB RRsで必要です。 <「副-タイプ」>分野は16ビットの整数です。 <ホスト名>分野は所有者名(RR)でセルのためのサーバを命名させるホストのドメイン名です。

   The format of the AFSDB RR is class insensitive.  AFSDB records cause
   type A additional section processing for <hostname>.  This, in fact,
   is the rationale for using a new type code, rather than trying to
   build the same functionality with TXT RRs.

AFSDB RRの形式はクラス神経が鈍いです。 AFSDB記録原因は<ホスト名>のためにA追加セクション処理をタイプします。 事実上、これは、TXT RRsと共に同じ機能性を築き上げようとするよりむしろ新しいタイプコードを使用するための原理です。

   Note that the format of AFSDB in a master file is identical to MX.
   For purposes of the DNS itself, the subtype is merely an integer.
   The present subtype semantics are discussed below, but changes are
   possible and will be announced in subsequent RFCs.

基本ファイルのAFSDBの形式がMXと同じであることに注意してください。 DNS自身の目的のために、「副-タイプ」は単に整数です。 以下で現在の「副-タイプ」意味論について議論しますが、変更は、可能であり、その後のRFCsで発表されるでしょう。

   In the case of subtype 1, the host has an AFS version 3.0 Volume
   Location Server for the named AFS cell.  In the case of subtype 2,
   the host has an authenticated name server holding the cell-root
   directory node for the named DCE/NCA cell.

「副-タイプ」1の場合では、ホストは命名されたAFSセルのためのAFSバージョン3.0Volume Location Serverを持っています。 「副-タイプ」2の場合では、ホストは命名されたDCE/NCAセルのためのセルルートディレクトリノードを保持する認証されたネームサーバを持っています。

   The use of subtypes is motivated by two considerations.  First, the
   space of DNS RR types is limited.  Second, the services provided are
   sufficiently distinct that it would continue to be confusing for a
   client to attempt to connect to a cell's servers using the protocol
   for one service, if the cell offered only the other service.

血液型亜型の使用は2つの問題によって動機づけられています。 まず最初に、DNS RRタイプのスペースは限られます。 2番目に、提供されたサービスは十分異なっています。クライアントが、試みるように混乱させ続けているだろうというのが1つのサービスにプロトコルを使用することでセルのサーバに接続します、セルがもう片方のサービスだけを提供したなら。

   As an example of the use of this RR, suppose that the Toaster
   Corporation has deployed AFS 3.0 but not (yet) the OSF's DCE.  Their
   cell, named toaster.com, has three "AFS 3.0 cell database server"

このRRの使用に関する例として、Toaster社が(まだ、)OSFのDCEではなく、AFS3.0を配布したと仮定してください。 toaster.comという彼らの細胞が3を持っている、「AFS3.0セルデータベースサーバー」

Everhart, Mamakos, Ullmann & Mockapetris                        [Page 2]

RFC 1183                 New DNS RR Definitions             October 1990

エバーハート、Mamakos、ウルマン、およびDNS RR定義1990年10月に新しいMockapetris[2ページ]RFC1183

   machines: bigbird.toaster.com, ernie.toaster.com, and
   henson.toaster.com.  These three machines would be listed in three
   AFSDB RRs.  These might appear in a master file as:

マシン: bigbird.toaster.com、ernie.toaster.com、およびhenson.toaster.com。 これらの3台のマシンが3AFSDB RRsに記載されているでしょう。 これらは以下として基本ファイルに現れるかもしれません。

   toaster.com.   AFSDB   1 bigbird.toaster.com.
   toaster.com.   AFSDB   1 ernie.toaster.com.
   toaster.com.   AFSDB   1 henson.toaster.com.

toaster.com。 AFSDB1bigbird.toaster.com toaster.com。 AFSDB1ernie.toaster.com toaster.com。 AFSDB1henson.toaster.com。

   As another example use of this RR, suppose that Femto College (domain
   name femto.edu) has deployed DCE, and that their DCE cell root
   directory is served by processes running on green.femto.edu and
   turquoise.femto.edu.  Furthermore, their DCE file servers also run
   AFS 3.0-compatible volume location servers, on the hosts
   turquoise.femto.edu and orange.femto.edu.  These machines would be
   listed in four AFSDB RRs, which might appear in a master file as:

このRRの別の例の使用として、Femto大学(ドメイン名femto.edu)がDCEを配布して、それらのDCEセルルートディレクトリがgreen.femto.eduとturquoise.femto.eduの上で作業するプロセスによって役立たれていると仮定してください。 その上、また、それらのDCEファイルサーバーはAFSの3.0コンパチブルボリューム位置のサーバをホストのturquoise.femto.eduとorange.femto.eduに実行します。 これらのマシンは4AFSDB RRsに記載されているでしょう。(AFSDB RRsは以下として基本ファイルに現れるかもしれません)。

   femto.edu.   AFSDB   2 green.femto.edu.
   femto.edu.   AFSDB   2 turquoise.femto.edu.
   femto.edu.   AFSDB   1 turquoise.femto.edu.
   femto.edu.   AFSDB   1 orange.femto.edu.

femto.edu。 AFSDB2green.femto.edu femto.edu。 AFSDB2turquoise.femto.edu femto.edu。 AFSDB1turquoise.femto.edu femto.edu。 AFSDB1orange.femto.edu。

2. Responsible Person

2. 責任者

   The purpose of this section is to provide a standard method for
   associating responsible person identification to any name in the DNS.

このセクションの目的はDNSのどんな名前にも責任者識別を関連づけるための標準方法を提供することです。

   The domain name system functions as a distributed database which
   contains many different form of information.  For a particular name
   or host, you can discover it's Internet address, mail forwarding
   information, hardware type and operating system among others.

ドメイン名システムは多くの異なったフォームの情報を含む分散データベースとして機能します。 特定の名前かホストに関しては、あなたは、それがインターネット・アドレスと、メール転送情報と、ハードウェアタイプと特にオペレーティングシステムであると発見できます。

   A key aspect of the DNS is that the tree-structured namespace can be
   divided into pieces, called zones, for purposes of distributing
   control and responsibility.  The responsible person for zone database
   purposes is named in the SOA RR for that zone.  This section
   describes an extension which allows different responsible persons to
   be specified for different names in a zone.

DNSの特徴はばらばらに木で構造化された名前空間を分割できるということです、呼ばれたゾーン、コントロールと責任を広げる目的のために。 ゾーンデータベース目的のための責任者はSOA RRでそのゾーンにちなんで命名されます。 このセクションは異なった責任者がゾーンの異なった名前に指定されるのを許容する拡大について説明します。

2.1. Identification of the guilty party

2.1. 犯人の識別

   Often it is desirable to be able to identify the responsible entity
   for a particular host.  When that host is down or malfunctioning, it
   is difficult to contact those parties which might resolve or repair
   the host.  Mail sent to POSTMASTER may not reach the person in a
   timely fashion.  If the host is one of a multitude of workstations,
   there may be no responsible person which can be contacted on that
   host.

しばしば、特定のホストのために原因となる実体を特定できるのは望ましいです。 そのホストが下がるか誤動作しているとき、ホストを決議するか、または修理するかもしれないそれらのパーティーに連絡するのは難しいです。 POSTMASTERに送られたメールは直ちに人に届かないかもしれません。 ホストがワークステーションの多数のひとりであるなら、そのホストで連絡できる責任者は全くいないかもしれません。

Everhart, Mamakos, Ullmann & Mockapetris                        [Page 3]

RFC 1183                 New DNS RR Definitions             October 1990

エバーハート、Mamakos、ウルマン、およびDNS RR定義1990年10月に新しいMockapetris[3ページ]RFC1183

   The POSTMASTER mailbox on that host continues to be a good contact
   point for mail problems, and the zone contact in the SOA record for
   database problem, but the RP record allows us to associate a mailbox
   to entities that don't receive mail or are not directly connected
   (namespace-wise) to the problem (e.g., GATEWAY.ISI.EDU might want to
   point at HOTLINE@BBN.COM, and GATEWAY doesn't get mail, nor does the
   ISI zone administrator have a clue about fixing gateways).

そのホストの上のPOSTMASTERメールボックスはずっとメール問題のための良い接点です、そして、SOAでのゾーン接触はデータベース問題によって記録しますが、RP記録は私たちがメールを受け取らないか、または直接問題に関連づけられない(名前空間的な)実体にメールボックスを関連づけるのを許容します。(例えば、GATEWAY.ISI.EDUが HOTLINE@BBN.COM を指し示したがっているかもしれなくて、ゲートウェイがメールを受け取らない、または、ISIゾーンの管理者にはゲートウェイを修理することに関する手がかりがない、)

2.2. The Responsible Person RR

2.2. 責任者RR

   The method uses a new RR type with mnemonic RP and type code of 17
   (decimal).

メソッドは17(10進)のニーモニックRPとタイプコードと共に新しいRRタイプを使用します。

   RP has the following format:

RPには、以下の形式があります:

   <owner> <ttl> <class> RP <mbox-dname> <txt-dname>

<所有者><ttl><のクラス>RP<mbox-dname><txt-dname>。

   Both RDATA fields are required in all RP RRs.

両方のRDATA分野がすべてのRP RRsで必要です。

   The first field, <mbox-dname>, is a domain name that specifies the
   mailbox for the responsible person.  Its format in master files uses
   the DNS convention for mailbox encoding, identical to that used for
   the RNAME mailbox field in the SOA RR.  The root domain name (just
   ".") may be specified for <mbox-dname> to indicate that no mailbox is
   available.

最初の分野(<mbox-dname>)は責任者にメールボックスを指定するドメイン名です。 基本ファイルの形式はメールボックスコード化にDNSコンベンションを使用します、SOA RRのRNAMEメールボックス分野に使用されるそれと同じです。 「根のドメイン名、(まさしく」、」、)、<mbox-dname>が、どんなメールボックスも利用可能でないことを示すように、指定されるかもしれません。

   The second field, <txt-dname>, is a domain name for which TXT RR's
   exist.  A subsequent query can be performed to retrieve the
   associated TXT resource records at <txt-dname>.  This provides a
   level of indirection so that the entity can be referred to from
   multiple places in the DNS.  The root domain name (just ".") may be
   specified for <txt-dname> to indicate that the TXT_DNAME is absent,
   and no associated TXT RR exists.

2番目の分野(<txt-dname>)はTXT RRのものが存在するドメイン名です。 <txt-dname>で関連TXTリソース記録を検索するためにその後の質問を実行できます。 これは、DNSの複数の場所から実体について言及できるように間接指定のレベルを提供します。 「根のドメイン名、(まさしく」、」、)、<txt-dname>が、TXT_DNAMEが欠けていて、どんな関連TXT RRも存在しないのを示すように、指定されるかもしれません。

   The format of the RP RR is class insensitive.  RP records cause no
   additional section processing.  (TXT additional section processing
   for <txt-dname> is allowed as an option, but only if it is disabled
   for the root, i.e., ".").

RP RRの形式はクラス神経が鈍いです。 RP記録はどんな追加セクション処理も引き起こしません。 「(すなわち、それが根のために無効にされる場合にだけ<txt-dname>のためのTXTの追加セクション処理がオプションとして許されている、」、」、)

   The Responsible Person RR can be associated with any node in the
   Domain Name System hierarchy, not just at the leaves of the tree.

木の葉だけで関連づけられるのではなく、ドメインネームシステム階層構造でどんなノードにもResponsible Person RRを関連づけることができます。

   The TXT RR associated with the TXT_DNAME contain free format text
   suitable for humans.  Refer to [4] for more details on the TXT RR.

TXT_DNAMEに関連しているTXT RRは人間に適当なフリー・フォーマットテキストを含んでいます。 TXT RRに関するその他の詳細のための[4]を参照してください。

   Multiple RP records at a single name may be present in the database.
   They should have identical TTLs.

ただ一つの名前における複数のRP記録がデータベースに存在しているかもしれません。 彼らは同じTTLsを持つべきです。

Everhart, Mamakos, Ullmann & Mockapetris                        [Page 4]

RFC 1183                 New DNS RR Definitions             October 1990

エバーハート、Mamakos、ウルマン、およびDNS RR定義1990年10月に新しいMockapetris[4ページ]RFC1183

   EXAMPLES

例

   Some examples of how the RP record might be used.

RPがどう記録するかに関するいくつかの例が使用されるかもしれません。

   sayshell.umd.edu. A     128.8.1.14
                     MX    10 sayshell.umd.edu.
                     HINFO NeXT UNIX
                     WKS   128.8.1.14 tcp ftp telnet smtp
                     RP    louie.trantor.umd.edu.  LAM1.people.umd.edu.

sayshell.umd.edu。 128.8.1.14MX10sayshell.umd.edu。 HINFO NeXT UNIX WKS128.8.1.14tcp ftp telnet smtp RP louie.trantor.umd.edu。 LAM1.people.umd.edu。

   LAM1.people.umd.edu. TXT (
         "Louis A. Mamakos, (301) 454-2946, don't call me at home!" )

LAM1.people.umd.edu。 TXT( 「ルイスA.Mamakos((301)454-2946)は、ホームで私に電話をしません!」 )

   In this example, the responsible person's mailbox for the host
   SAYSHELL.UMD.EDU is louie@trantor.umd.edu.  The TXT RR at
   LAM1.people.umd.edu provides additional information and advice.

この例では、ホストSAYSHELL.UMD.EDUのための責任者のメールボックスは louie@trantor.umd.edu です。 LAM1.people.umd.eduのTXT RRは追加情報とアドバイスを提供します。

   TERP.UMD.EDU.    A     128.8.10.90
                    MX    10 128.8.10.90
                    HINFO MICROVAX-II UNIX
                    WKS   128.8.10.90 udp domain
                    WKS   128.8.10.90 tcp ftp telnet smtp domain
                    RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
                    RP    root.terp.umd.edu. ops.CS.UMD.EDU.

TERP.UMD.EDU。 128.8.10.90Mx10 128.8.10.90HINFO MICROVAX-II UNIX WKS128.8.10.90udpドメインWKS128.8.10.90tcp ftp telnet smtpドメインRP louie.trantor.umd.edu。 LAM1.people.umd.edu。 RP root.terp.umd.edu ops.CS.UMD.EDU。

   TRANTOR.UMD.EDU. A     128.8.10.14
                    MX    10 trantor.umd.edu.
                    HINFO MICROVAX-II UNIX
                    WKS   128.8.10.14 udp domain
                    WKS   128.8.10.14 tcp ftp telnet smtp domain
                    RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
                    RP    petry.netwolf.umd.edu. petry.people.UMD.EDU.
                    RP    root.trantor.umd.edu. ops.CS.UMD.EDU.
                    RP    gregh.sunset.umd.edu.  .

TRANTOR.UMD.EDU。 128.8.10.14MX10trantor.umd.edu。 HINFO MICROVAX-II UNIX WKS128.8.10.14udpドメインWKS128.8.10.14tcp ftp telnet smtpドメインRP louie.trantor.umd.edu。 LAM1.people.umd.edu。 RP petry.netwolf.umd.edu. petry.people.UMD.EDU。 RP root.trantor.umd.edu ops.CS.UMD.EDU。 RP gregh.sunset.umd.edu。 .

   LAM1.people.umd.edu.  TXT   "Louis A. Mamakos (301) 454-2946"
   petry.people.umd.edu. TXT   "Michael G. Petry (301) 454-2946"
   ops.CS.UMD.EDU.       TXT   "CS Operations Staff (301) 454-2943"

LAM1.people.umd.edu。 TXT「ルイスA.Mamakos(301)454-2946」petry.people.umd.edu。 TXT「マイケルG.Petry(301)454-2946」ops.CS.UMD.EDU。 TXT「Cs操作スタッフ(301)454-2943」

   This set of resource records has two hosts, TRANTOR.UMD.EDU and
   TERP.UMD.EDU, as well as a number of TXT RRs.  Note that TERP.UMD.EDU
   and TRANTOR.UMD.EDU both reference the same pair of TXT resource
   records, although the mail box names (root.terp.umd.edu and
   root.trantor.umd.edu) differ.

このセットのリソース記録には、多くのTXT RRsと同様に2人のホスト(TRANTOR.UMD.EDUとTERP.UMD.EDU)がいます。 TERP.UMD.EDUとTRANTOR.UMD.EDUがともにTXTリソース記録の同じ組に参照をつけることに注意してください、メールボックス名(root.terp.umd.eduとroot.trantor.umd.edu)は異なりますが。

   Here, we obviously care much more if the machine flakes out, as we've
   specified four persons which might want to be notified of problems or
   other events involving TRANTOR.UMD.EDU.  In this example, the last RP

ここで、私たちは、マシンが寝入るかどうかはるかに明らかに気にかけます、私たちが4人の人々を指定したとき(問題か他のイベントがTRANTOR.UMD.EDUにかかわるのについて通知されたいかもしれません)。 この例、最後のRPで

Everhart, Mamakos, Ullmann & Mockapetris                        [Page 5]

RFC 1183                 New DNS RR Definitions             October 1990

エバーハート、Mamakos、ウルマン、およびDNS RR定義1990年10月に新しいMockapetris[5ページ]RFC1183

   RR for TRANTOR.UMD.EDU specifies a mailbox (gregh.sunset.umd.edu),
   but no associated TXT RR.

メールボックス(gregh.sunset.umd.edu)を指定しますが、TRANTOR.UMD.EDUのためのRRはどんな関連TXT RRも指定しません。

3. X.25 and ISDN addresses, Route Binding

3. X.25とISDNアドレス、Route Binding

   This section describes an experimental representation of X.25 and
   ISDN addresses in the DNS, as well as a route binding method,
   analogous to the MX for mail routing, for very large scale networks.

このセクションはDNSのX.25とISDNアドレスの実験的な表現について説明します、メソッドを縛るルートと同様に、メールルーティングにおいてMXに類似しています、非常に大きいスケールネットワークのために。

   There are several possible uses, all experimental at this time.
   First, the RRs provide simple documentation of the correct addresses
   to use in static configurations of IP/X.25 [11] and SMTP/X.25 [12].

このときすべて実験的ないくつかの可能な用途があります。 まず最初に、RRsはIP/X.25[11]とSMTP/X.25[12]の静的な構成に使用する正しいアドレスの簡単なドキュメンテーションを提供します。

   The RRs could also be used automatically by an internet network-layer
   router, typically IP.  The procedure would be to map IP address to
   domain name, then name to canonical name if needed, then following RT
   records, and finally attempting an IP/X.25 call to the address found.
   Alternately, configured domain names could be resolved to identify IP
   to X.25/ISDN bindings for a static but periodically refreshed routing
   table.

また、インターネットネットワーク層ルータ、通常IPは自動的にRRsを使用できました。 手順は、IPアドレスをドメイン名に写像して、次に、次の必要であるならRT記録、および最終的にアドレスへのIP/X.25呼び出しが当たった試みるのを正準な名前と命名するだろうことです。 交互に、静的な、しかし、定期的に壮快な経路指定テーブルのためのX.25/ISDN結合にIPを特定するために構成されたドメイン名を決議できました。

   This provides a function similar to ARP for wide area non-broadcast
   networks that will scale well to a network with hundreds of millions
   of hosts.

これは何億人ものホストと共にネットワークによく比例する広い領域非放送網に、ARPと同様の機能を提供します。

   Also, a standard address binding reference will facilitate other
   experiments in the use of X.25 and ISDN, especially in serious
   inter-operability testing.  The majority of work in such a test is
   establishing the n-squared entries in static tables.

また、標準のアドレス結合参照はX.25とISDNの使用における他の実験を容易にするでしょう、特に重大な相互運用性テストで。 そのようなテストにおける、仕事の大多数はnで二乗されたエントリーを静的なテーブルに設置しています。

   Finally, the RRs are intended for use in a proposal [13] by one of
   the authors for a possible next-generation internet.

最終的に、RRsは作者のひとりによる提案[13]における、可能な次世代インターネットの使用のために意図します。

3.1. The X25 RR

3.1. X25 RR

   The X25 RR is defined with mnemonic X25 and type code 19 (decimal).

X25 RRは簡略記憶X25とタイプコード19(小数)で定義されます。

   X25 has the following format:

X25には、以下の形式があります:

   <owner> <ttl> <class> X25 <PSDN-address>

<所有者><ttl><クラス>X25<PSDN-アドレス>。

   <PSDN-address> is required in all X25 RRs.

<PSDN-アドレス>がすべてのX25 RRsで必要です。

   <PSDN-address> identifies the PSDN (Public Switched Data Network)
   address in the X.121 [10] numbering plan associated with <owner>.
   Its format in master files is a <character-string> syntactically
   identical to that used in TXT and HINFO.

<PSDN-アドレス>は<所有者>に関連しているX.121[10]付番プランにおけるPSDN(公共のSwitched Data Network)アドレスを特定します。 基本ファイルの形式はシンタクス上TXTとHINFOで使用されるそれと同じ<文字列>です。

Everhart, Mamakos, Ullmann & Mockapetris                        [Page 6]

RFC 1183                 New DNS RR Definitions             October 1990

エバーハート、Mamakos、ウルマン、およびDNS RR定義1990年10月に新しいMockapetris[6ページ]RFC1183

   The format of X25 is class insensitive.  X25 RRs cause no additional
   section processing.

X25の形式はクラス神経が鈍いです。 X25 RRsはどんな追加セクション処理も引き起こしません。

   The <PSDN-address> is a string of decimal digits, beginning with the
   4 digit DNIC (Data Network Identification Code), as specified in
   X.121. National prefixes (such as a 0) MUST NOT be used.

<PSDN-アドレス>は一連の10進数字です、4ケタDNIC(データNetwork Identification Code)と共に始まって、X.121で指定されるように。 国家の接頭語(0などの)を使用してはいけません。

   For example:

例えば:

   Relay.Prime.COM.  X25       311061700956

Relay.Prime.COM。 X25 311061700956

3.2. The ISDN RR

3.2. ISDN RR

   The ISDN RR is defined with mnemonic ISDN and type code 20 (decimal).

ISDN RRは簡略記憶ISDNとタイプコード20(小数)で定義されます。

   An ISDN (Integrated Service Digital Network) number is simply a
   telephone number.  The intent of the members of the CCITT is to
   upgrade all telephone and data network service to a common service.

ISDN(統合Service Digital Network)番号は単に電話番号です。 CCITTのメンバーの意図は電話とデータ網が共益サービスに修理するすべてをアップグレードさせることです。

   The numbering plan (E.163/E.164) is the same as the familiar
   international plan for POTS (an un-official acronym, meaning Plain
   Old Telephone Service).  In E.166, CCITT says "An E.163/E.164
   telephony subscriber may become an ISDN subscriber without a number
   change."

付番プラン(E.163/E.164)はPOTS(非公式の頭文字語、意味Plain Old Telephone Service)に、身近な国際的なプランと同じです。 E.166では、「E.163/E.164電話加入者は数の変化なしでISDN加入者になるかもしれません。」と、CCITTは言います。

   ISDN has the following format:

ISDNには、以下の形式があります:

   <owner> <ttl> <class> ISDN <ISDN-address> <sa>

<所有者><ttl><クラス>ISDN<ISDNアドレス><sa>。

   The <ISDN-address> field is required; <sa> is optional.

>がさばく<ISDNアドレスが必要です。 <sa>は任意です。

   <ISDN-address> identifies the ISDN number of <owner> and DDI (Direct
   Dial In) if any, as defined by E.164 [8] and E.163 [7], the ISDN and
   PSTN (Public Switched Telephone Network) numbering plan.  E.163
   defines the country codes, and E.164 the form of the addresses.  Its
   format in master files is a <character-string> syntactically
   identical to that used in TXT and HINFO.

<ISDNアドレス>はもしあれば<所有者>とDDI(ダイレクトDial In)のISDN番号を特定します、E.164[8]とE.163[7]によって定義されるように、ISDNとPSTN(公共のSwitched Telephone Network)付番プラン。 E.163は国名略号を定義します、そして、E.164はアドレスのフォームを定義します。 基本ファイルの形式はシンタクス上TXTとHINFOで使用されるそれと同じ<文字列>です。

   <sa> specifies the subaddress (SA).  The format of <sa> in master
   files is a <character-string> syntactically identical to that used in
   TXT and HINFO.

<sa>は「副-アドレス」(SA)を指定します。 基本ファイルの<sa>の形式はシンタクス上TXTとHINFOで使用されるそれと同じ<文字列>です。

   The format of ISDN is class insensitive.  ISDN RRs cause no
   additional section processing.

ISDNの形式はクラス神経が鈍いです。 ISDN RRsはどんな追加セクション処理も引き起こしません。

   The <ISDN-address> is a string of characters, normally decimal
   digits, beginning with the E.163 country code and ending with the DDI
   if any.  Note that ISDN, in Q.931, permits any IA5 character in the

<ISDNアドレス>は一連のキャラクタと、通常10進数字と、E.163国名略号で始まって、DDIと共にもしあれば終わることです。 ISDNがQ.931でどんなIA5キャラクタも入るのを許すことに注意してください。

Everhart, Mamakos, Ullmann & Mockapetris                        [Page 7]

RFC 1183                 New DNS RR Definitions             October 1990

エバーハート、Mamakos、ウルマン、およびDNS RR定義1990年10月に新しいMockapetris[7ページ]RFC1183

   general case.

一般的なケース。

   The <sa> is a string of hexadecimal digits.  For digits 0-9, the
   concrete encoding in the Q.931 call setup information element is
   identical to BCD.

<sa>は一連の16進数字です。 ケタ0-9において、Q.931呼び出しセットアップ情報要素における具体的なコード化はBCDと同じです。

   For example:

例えば:

   Relay.Prime.COM.   IN   ISDN      150862028003217
   sh.Prime.COM.      IN   ISDN      150862028003217 004

Relay.Prime.COM。 ISDN150862028003217sh.Prime.COMで。 ISDN150862028003217 004で

   (Note: "1" is the country code for the North American Integrated
   Numbering Area, i.e., the system of "area codes" familiar to people
   in those countries.)

(以下に注意してください、「1インチが北米の統合付番領域(すなわち、それらの国の人々にとって、なじみ深い「市外局番」のシステム)への国名略号である、)、」

   The RR data is the ASCII representation of the digits.  It is encoded
   as one or two <character-string>s, i.e., count followed by
   characters.

RRデータはケタのASCII表現です。 それは1か2<文字列>sとしてコード化されました、すなわち、カウントがキャラクタで続きました。

   CCITT recommendation E.166 [9] defines prefix escape codes for the
   representation of ISDN (E.163/E.164) addresses in X.121, and PSDN
   (X.121) addresses in E.164.  It specifies that the exact codes are a
   "national matter", i.e., different on different networks.  A host
   connected to the ISDN may be able to use both the X25 and ISDN
   addresses, with the local prefix added.

CCITT推薦E.166[9]はX.121のISDN(E.163/E.164)アドレスの表現、およびE.164のPSDN(X.121)アドレスのために接頭語エスケープコードを定義します。 正確なコードがすなわち、異なったネットワークで異なった「国家の件」であることは指定します。 ISDNに接続されたホストは両方のX25とISDNアドレスを使用できるかもしれません、ローカルの接頭語が加えられている状態で。

3.3. The Route Through RR

3.3. RRを通したルート

   The Route Through RR is defined with mnemonic RT and type code 21
   (decimal).

Route Through RRは簡略記憶RTとタイプコード21(小数)で定義されます。

   The RT resource record provides a route-through binding for hosts
   that do not have their own direct wide area network addresses.  It is
   used in much the same way as the MX RR.

RTリソース記録はそれら自身のダイレクト広域ネットワーク住所を知っていないホストのためのルート終えた結合を提供します。 それは大体同じようなやり方でMX RRとして使用されます。

   RT has the following format:

RTには、以下の形式があります:

   <owner> <ttl> <class> RT <preference> <intermediate-host>

<の<の好みの>の<の中間的所有者><ttl><クラス>RTホスト>。

   Both RDATA fields are required in all RT RRs.

両方のRDATA分野がすべてのRT RRsで必要です。

   The first field, <preference>, is a 16 bit integer, representing the
   preference of the route.  Smaller numbers indicate more preferred
   routes.

ルートの好みを表して、最初の分野(<好みの>)は16ビットの整数です。 より少ない数は、より都合のよいルートを示します。

   <intermediate-host> is the domain name of a host which will serve as
   an intermediate in reaching the host specified by <owner>.  The DNS
   RRs associated with <intermediate-host> are expected to include at

<の中間的ホスト>はホストに届くことにおける中間介在物が<所有者>で指定したように役立つホストのドメイン名です。 DNS RRsは含んでいる中間的ホストの>が予想される<と交際しました。

Everhart, Mamakos, Ullmann & Mockapetris                        [Page 8]

RFC 1183                 New DNS RR Definitions             October 1990

エバーハート、Mamakos、ウルマン、およびDNS RR定義1990年10月に新しいMockapetris[8ページ]RFC1183

   least one A, X25, or ISDN record.

最少のものA、X25、またはISDN記録。

   The format of the RT RR is class insensitive.  RT records cause type
   X25, ISDN, and A additional section processing for <intermediate-
   host>.

RT RRの形式はクラス神経が鈍いです。 RT記録は<の中間的ホスト>のための追加セクション処理をタイプX25、ISDN、およびAに引き起こします。

   For example,

例えば

   sh.prime.com.      IN   RT   2    Relay.Prime.COM.
                      IN   RT   10   NET.Prime.COM.
   *.prime.com.       IN   RT   90   Relay.Prime.COM.

sh.prime.com。 RT2Relay.Prime.COMで。 RT10NET.Prime.COMで。 *.prime.com。 RT90Relay.Prime.COMで。

   When a host is looking up DNS records to attempt to route a datagram,
   it first looks for RT records for the destination host, which point
   to hosts with address records (A, X25, ISDN) compatible with the wide
   area networks available to the host.  If it is itself in the set of
   RT records, it discards any RTs with preferences higher or equal to
   its own.  If there are no (remaining) RTs, it can then use address
   records of the destination itself.

ホストがデータグラムを発送するのを試みるためにDNS記録を調べているとき、それは最初に、あて先ホストへのRT記録を探します。(記録は利用可能な広域ネットワークをもっているアドレスが記録(A、X25、ISDN)互換性があるホストをホストに示します)。 RT記録のセットにそれ自体であるなら、それはそれ自身のものと、より高いか等しい好みでどんなRTsも捨てます。 (残っていること)のRTsが全くなければ、それは目的地自体に関するアドレス記録を使用できます。

   Wild-card RTs are used exactly as are wild-card MXs.  RT's do not
   "chain"; that is, it is not valid to use the RT RRs found for a host
   referred to by an RT.

ワイルドカードRTsはちょうどワイルドカードMXsのように使用されます。 RTのものは「鎖を作りません」。 すなわち、RTによって言及されたホストのために見つけられたRT RRsを使用するのは有効ではありません。

   The concrete encoding is identical to the MX RR.

具体的なコード化はMX RRと同じです。

REFERENCES and BIBLIOGRAPHY

参照と図書目録

   [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
       Information Center, SRI International, November 1987.

[1] スタール、M.、「ドメイン管理者のガイド」(RFC1032)が1987年11月にインフォメーション・センター、SRIインターナショナルをネットワークでつなぎます。

   [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
       Network Information Center, SRI International, November, 1987.

[2] Lottor(M.、「操作が誘導するドメイン管理者」、RFC1033)は1987年11月にインフォメーション・センター、SRIインターナショナルをネットワークでつなぎます。

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

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

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

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

   [5] Spector A., and M. Kazar, "Uniting File Systems", UNIX Review,
       7(3), pp. 61-69, March 1989.

[5] スペクターA.、およびM.Kazar、「ファイルシステムを結合させます」、UNIX Review、7(3)、ページ 61-69と、1989年3月。

   [6] Zahn, et al., "Network Computing Architecture", Prentice-Hall,
       1989.

[6] ザーン、他、「ネットワークコンピューティングアーキテクチャ」、Prentice-ホール、1989。

   [7] International Telegraph and Telephone Consultative Committee,

[7] 国際電信電話諮問委員会

Everhart, Mamakos, Ullmann & Mockapetris                        [Page 9]

RFC 1183                 New DNS RR Definitions             October 1990

エバーハート、Mamakos、ウルマン、およびDNS RR定義1990年10月に新しいMockapetris[9ページ]RFC1183

       "Numbering Plan for the International Telephone Service", CCITT
       Recommendations E.163., IXth Plenary Assembly, Melbourne, 1988,
       Fascicle II.2 ("Blue Book").

「国際電話サービスのための付番プラン」、CCITT推薦E.163、IXth総会、メルボルン、1988、分冊II.2(「紳士録」。)

   [8] International Telegraph and Telephone Consultative Committee,
       "Numbering Plan for the ISDN Era", CCITT Recommendations E.164.,
       IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue
       Book").

[8] 国際電信電話諮問委員会、議会、メルボルン、1988、「付番はISDN時代の計画を立ててい」て(CCITT推薦E.164)、IXth絶対的な分冊II.2(「紳士録」)

   [9] International Telegraph and Telephone Consultative Committee.
       "Numbering Plan Interworking in the ISDN Era", CCITT
       Recommendations E.166., IXth Plenary Assembly, Melbourne, 1988,
       Fascicle II.2 ("Blue Book").

[9] 国際電信電話諮問委員会。 「ISDN時代の付番プランの織り込む」CCITT推薦E.166、IXth総会、メルボルン、1988、分冊II.2(「紳士録」。)

  [10] International Telegraph and Telephone Consultative Committee,
       "International Numbering Plan for the Public Data Networks",
       CCITT Recommendations X.121., IXth Plenary Assembly, Melbourne,
       1988, Fascicle VIII.3 ("Blue Book"); provisional, Geneva, 1978;
       amended, Geneva, 1980, Malaga-Torremolinos, 1984 and Melborne,
       1988.

[10] 国際電信電話諮問委員会、議会、メルボルン、1988、「国際付番は公衆データネットワークの計画を立ててい」て(CCITT推薦X.121)、IXth絶対的な分冊VIII.3(「紳士録」)、。 臨時郵便切手、ジュネーブ、1978。 修正、ジュネーブと1980とマラガ-トレモリノスと1984とMelborne、1988

  [11] Korb, J., "Standard for the Transmission of IP datagrams Over
       Public Data Networks", RFC 877, Purdue University, September
       1983.

[11]コルプ、J.、「IPデータグラムOver Public Data NetworksのTransmissionの規格」、RFC877、パデュー大学、1983年9月。

  [12] Ullmann, R., "SMTP on X.25", RFC 1090, Prime Computer, February
       1989.

[12] ウルマン、R.、「X.25"の上のSMTP、RFC1090、プライムコンピュータ、1989年2月。」

  [13] Ullmann, R., "TP/IX: The Next Internet", Prime Computer
       (unpublished), July 1990.

[13] ウルマン、R.、「TP/IX:」 「次のインターネット」、プライムコンピュータ(未発表の)、1990年7月。

  [14] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
       RFC 1101, USC/Information Sciences Institute, April 1989.

[14]Mockapetris、P.、「ネットワーク名と他のタイプのDNSコード化」、RFC1101、科学が1989年4月に設けるUSC/情報。

Security Considerations

セキュリティ問題

   Security issues are not addressed in this memo.

安全保障問題はこのメモで扱われません。

Everhart, Mamakos, Ullmann & Mockapetris                       [Page 10]

RFC 1183                 New DNS RR Definitions             October 1990

エバーハート、Mamakos、ウルマン、およびDNS RR定義1990年10月に新しいMockapetris[10ページ]RFC1183

Authors' Addresses

作者のアドレス

   Craig F. Everhart
   Transarc Corporation
   The Gulf Tower
   707 Grant Street
   Pittsburgh, PA  15219

湾の塔707が通りピッツバーグ、PA 15219を与えるクレイグF.エバーハートTransarc社

   Phone: +1 412 338 4467

以下に電話をしてください。 +1 412 338 4467

   EMail: Craig_Everhart@transarc.com

メール: Craig_Everhart@transarc.com

   Louis A. Mamakos
   Network Infrastructure Group
   Computer Science Center
   University of Maryland
   College Park, MD 20742-2411

ルイス・A.Mamakosネットワークインフラグループコンピュータサイエンスセンターメリーランド大学カレッジパーク、MD20742-2411

   Phone: +1-301-405-7836

以下に電話をしてください。 +1-301-405-7836

   Email: louie@Sayshell.UMD.EDU

メール: louie@Sayshell.UMD.EDU

   Robert Ullmann 10-30
   Prime Computer, Inc.
   500 Old Connecticut Path
   Framingham, MA 01701

ロバート・ウルマン10-30プライムコンピュータInc.500の古いコネチカットPathフレイミングハム、MA 01701

   Phone: +1 508 620 2800 ext 1736

以下に電話をしてください。 +1 508 620 2800ext1736

   Email: Ariel@Relay.Prime.COM

メール: Ariel@Relay.Prime.COM

   Paul Mockapetris
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

ポールMockapetris USC情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292

   Phone: 213-822-1511

以下に電話をしてください。 213-822-1511

   EMail: pvm@isi.edu

メール: pvm@isi.edu

Everhart, Mamakos, Ullmann & Mockapetris                       [Page 11]

エバーハート、Mamakos、ウルマン、およびMockapetris[11ページ]