RFC1637 日本語訳
1637 DNS NSAP Resource Records. B. Manning, R. Colella. June 1994. (Format: TXT=21768 bytes) (Obsoletes RFC1348) (Obsoleted by RFC1706) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group B. Manning
Request for Comments: 1637 Rice University
Obsoletes: 1348 R. Colella
Category: Experimental NIST
June 1994
コメントを求めるワーキンググループB.マニングの要求をネットワークでつないでください: 1637 ライス大学は以下を時代遅れにします。 1348年のR.Colellaカテゴリ: 実験的なNIST1994年6月
DNS NSAP Resource Records
DNS NSAPリソース記録
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
The Internet is moving towards the deployment of an OSI lower layers infrastructure. This infrastructure comprises the connectionless network protocol (CLNP) and supporting routing protocols. Also required as part of this infrastructure is support in the Domain Name System (DNS) for mapping between names and NSAP addresses.
インターネットはOSI下層インフラストラクチャの展開に近づいています。 このインフラストラクチャは、コネクションレスなネットワーク・プロトコル(CLNP)とルーティング・プロトコルをサポートするのを包括します。 また、このインフラストラクチャの一部として必要であるのは、ドメインネームシステム(DNS)で、名前とNSAPの間でアドレスを写像するサポートです。
This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with any NSAP address format. This document supercedes RFC 1348.
このドキュメントはドメイン名からNSAPへのマッピングのためのDNSのために1新しいResource Record(RR)の書式を定義します。 RRはどんなNSAPアドレス形式と共にも使用されるかもしれません。 このドキュメントsupercedes RFC1348。
NSAP-to-name translation is accomplished through use of the PTR RR (see STD 13, RFC 1035 for a description of the PTR RR). This paper describes how PTR RRs are used to support this translation.
NSAPから名前への翻訳はPTR RRの使用で実行されます(STD13を見てください、PTR RRの記述のためのRFC1035)。 この論文はPTR RRsがこの翻訳をサポートするのにどう使用されるかを説明します。
Manning & Colella [Page 1] RFC 1637 DNS NSAP RRs June 1994
マニングとColella[1ページ]RFC1637DNS NSAP RRs1994年6月
1. Introduction
1. 序論
The Internet is moving towards the deployment of an OSI lower layers infrastructure. This infrastructure comprises the connectionless network protocol (CLNP) [6] and supporting routing protocols. Also required as part of this infrastructure is support in the Domain Name System (DNS) [8] [9] for mapping between domain names and OSI Network Service Access Point (NSAP) addresses [7] [Note: NSAP and NSAP address are used interchangeably throughout this memo].
インターネットはOSI下層インフラストラクチャの展開に近づいています。 このインフラストラクチャは、コネクションレスなネットワーク・プロトコル(CLNP)[6]とルーティング・プロトコルをサポートするのを包括します。 また、このインフラストラクチャの一部として必要であるのは、ドメインネームシステム(DNS)[8][9]でのドメイン名とOSI Network Service Access Point(NSAP)の間でアドレス[7]を写像するサポート[注意: NSAPとNSAPアドレスはこのメモ中で互換性を持って使用される]です。
This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with any NSAP address format.
このドキュメントはドメイン名からNSAPへのマッピングのためのDNSのために1新しいResource Record(RR)の書式を定義します。 RRはどんなNSAPアドレス形式と共にも使用されるかもしれません。
NSAP-to-name translation is accomplished through use of the PTR RR (see RFC 1035 for a description of the PTR RR). This paper describes how PTR RRs are used to support this translation.
NSAPから名前への翻訳はPTR RRの使用で実行されます(PTR RRの記述に関してRFC1035を見てください)。 この論文はPTR RRsがこの翻訳をサポートするのにどう使用されるかを説明します。
This memo assumes that the reader is familiar with the DNS. Some familiarity with NSAPs is useful; see [2] or [7] for additional information.
このメモは、読者がDNSに詳しいと仮定します。 NSAPsへの何らかの親しみが役に立ちます。 追加情報のための[2]か[7]を見てください。
2. Background
2. バックグラウンド
The reason for defining DNS mappings for NSAPs is to support CLNP in the Internet. Debugging with CLNP ping and traceroute is becoming more difficult with only numeric NSAPs as the scale of deployment increases. Current debugging is supported by maintaining and exchanging a configuration file with name/NSAP mappings similar in function to hosts.txt. This suffers from the lack of a central coordinator for this file and also from the perspective of scaling. The former is the most serious short-term problem. Scaling of a hosts.txt-like solution has well-known long-term scaling difficiencies.
NSAPsのためのDNSマッピングを定義する理由はインターネットでCLNPをサポートすることです。 展開のスケールが増加するのに従って、CLNPと共にピングとトレースルートをデバッグするのは数値NSAPsだけによって、より難しくなっています。 現在のデバッグは、機能においてhosts.txtと同様の名前/NSAPマッピングで構成ファイルを維持して、交換することによって、サポートされます。 これはこのファイルとスケーリングの見解からも主要なコーディネータの不足に苦しみます。 前者は最も重大な短期的な問題です。 hosts.txtのようなソリューションのスケーリングには、よく知られる長期のスケーリングdifficienciesがあります。
A second reason for this work is the proposal to use CLNP as an alternative to IP: "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" [1]. For this to be practical, the DNS must be capable of supporting CLNP addresses.
この仕事の2番目の理由はIPに代わる手段としてCLNPを使用するという提案です: 「より大きいアドレス(tuba)、インターネットアドレシングとルート設定のための簡単な提案があるTCPとUDP」[1]。 これが実用的であるように、DNSはCLNPにアドレスをサポートできなければなりません。
3. Scope
3. 範囲
The methods defined in this paper are applicable to all NSAP formats. This includes support for the notion of a custom-defined NSAP format based on an AFI obtained by the IAB for use in the Internet.
この紙で定義されたメソッドはすべてのNSAP形式に適切です。 これはIABによってインターネットでの使用に入手されたAFIに基づく習慣で定義されたNSAP形式の概念のサポートを含んでいます。
As a point of reference, there is a distinction between registration and publication of addresses. For IP addresses, the IANA is the root
参照のポイントとして、アドレスの登録と公表の間には、区別があります。 IPアドレスのために、IANAは根です。
Manning & Colella [Page 2] RFC 1637 DNS NSAP RRs June 1994
マニングとColella[2ページ]RFC1637DNS NSAP RRs1994年6月
registration authority and the DNS a publication method. For NSAPs, addendum two of the network service definition, ISO8348/Ad2 [7] is the root registration authority and this memo defines how the DNS is used as a publication method.
登録局とDNS a公表メソッド。 NSAPs、ネットワーク・サービス定義の付加物twoのために、ISO8348/Ad2[7]は根の登録局です、そして、このメモはDNSが公表メソッドとしてどう使用されるかを定義します。
4. Structure of NSAPs
4. NSAPsの構造
NSAPs are hierarchically structured to allow distributed administration and efficient routing. Distributed administration permits subdelegated addressing authorities to, as allowed by the delegator, further structure the portion of the NSAP space under their delegated control. Accomodating this distributed authority requires that there be little or no a priori knowledge of the structure of NSAPs built into DNS resolvers and servers.
NSAPsは、分散型管理と効率的なルーティングを許すために階層的で構造化されます。 分散型管理許可証は、「反-遺贈者」によって許されているようにさらに彼らの代表として派遣されたコントロールの下のNSAPスペースの部分を構造化するために当局に演説しながら、副代表として派遣されました。 この分配された権威をAccomodatingするのはほとんどDNSが組み込まれたNSAPsの構造に関するどんな先験的な知識もレゾルバとサーバでなかったならそこでそれを必要とします。
For the purposes of this memo, NSAPs can be thought of as a tree of identifiers. The root of the tree is ISO8348/Ad2 [7], and has as its immediately registered subordinates the one-octet Authority and Format Identifiers (AFIs) defined there. The size of subsequently- defined fields depends on which branch of the tree is taken. The depth of the tree varies according to the authority responsible for defining subsequent fields.
このメモの目的のために、識別子の木としてNSAPsを考えることができます。 木の根は、ISO8348/Ad2[7]であり、すぐに登録された部下としてAuthorityとFormat Identifiers(AFIs)がそこで定義した1八重奏を持っています。 次に定義された分野のサイズは木のどの枝を取るかに依存します。 その後の分野を定義するのに原因となる権威に従って、木の深さは異なります。
An example is the authority under which U.S. GOSIP defines NSAPs [3]. Under the AFI of 47, NIST (National Institute of Standards and Technology) obtained a value of 0005 (the AFI of 47 defines the next field as being two octets consisting of four BCD digits from the International Code Designator space [4]). NIST defined the subsequent fields in [3], as shown in Figure 1. The field immediately following 0005 is a format identifier for the rest of the U.S. GOSIP NSAP structure, with a hex value of 80. Following this is the three-octet field, values for which are allocated to network operators; the registration authority for this field is delegated to GSA (General Services Administration).
例はU.S. GOSIPがNSAPs[3]を定義する権威です。 47のAFIの下では、NIST(米国商務省標準技術局)は0005年の値を得ました。(47のAFIは国際旗信号Designatorスペース[4])から次の分野を4BCDケタから成る2つの八重奏であると定義します。 NISTは図1に示されるように[3]でその後の分野を定義しました。 すぐに0005に続く分野はU.S. GOSIP NSAP構造の残りのための形式IDです、80の十六進法値で。 これに続いて、3八重奏の分野、値はどれをネットワーク・オペレータに割り当てるかものです。 GSA(共通役務庁)へこの分野への登録局を代表として派遣します。
The last octet of the NSAP is the NSelector (NSel). In practice, the NSAP minus the NSel identifies the CLNP protocol machine on a given system, and the NSel identifies the CLNP user. Since there can be more than one CLNP user (meaning multiple NSel values for a given "base" NSAP), the representation of the NSAP should be CLNP-user independent. To achieve this, an NSel value of zero shall be used with all NSAP values stored in the DNS. An NSAP with NSel=0 identifies the network layer itself. It is left to the application retrieving the NSAP to determine the appropriate value to use in that instance of communication.
NSAPの最後の八重奏はNSelector(NSel)です。 実際には、NSelを引いたNSAPは与えられたシステムの上でCLNPプロトコルマシンを特定します、そして、NSelはCLNPユーザを特定します。 1人以上のCLNPユーザがいることができるので(複数の意味NSelが与えられた「ベース」にNSAPを評価します)、NSAPの表現はCLNP-ユーザ独立者であるべきです。 これを達成するために、ゼロのNSel値はDNSに保存されるすべてのNSAP値と共に使用されるものとします。 NSel=0とNSAPはネットワーク層自体を特定します。 それが、適切な値がコミュニケーションのそのインスタンスに使用することを決定するのがNSAPを検索するアプリケーションに残されます。
Manning & Colella [Page 3] RFC 1637 DNS NSAP RRs June 1994
マニングとColella[3ページ]RFC1637DNS NSAP RRs1994年6月
|--------------|
| <-- IDP --> |
|--------------|-------------------------------------|
| AFI | IDI | <-- DSP --> |
|-----|--------|-------------------------------------|
| 47 | 0005 | DFI | AA |Rsvd | RD |Area | ID |Sel |
|-----|--------|-----|----|-----|----|-----|----|----|
octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 |
|-----|--------|-----|----|-----|----|-----|----|----|
|--------------| | <-- IDP-->。| |--------------|-------------------------------------| | AFI| イディ| <-- DSP-->。| |-----|--------|-------------------------------------| | 47 | 0005 | DFI| AA|Rsvd| rd|領域| ID|Sel| |-----|--------|-----|----|-----|----|-----|----|----| 八重奏| 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 | |-----|--------|-----|----|-----|----|-----|----|----|
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
DFI DSP Format Identifier
AA Administrative Authority
Rsvd Reserved
RD Routing Domain Identifier
Area Area Identifier
ID System Identifier
SEL NSAP Selector
IDPの初期のドメイン部分AFI権威と初期の形式IDの特定の部分DFI DSP形式ID AA IDIドメイン識別子DSPドメイン職務権限Rsvdは経路ドメイン識別子領域領域識別子IDシステム識別子SEL NSAP第セレクタを予約しました。
Figure 1: GOSIP Version 2 NSAP structure.
図1: GOSIPバージョン2NSAP構造。
When CLNP is used to support TCP and UDP services, the NSel value used is the appropriate IP PROTO value as registered with the IANA. For "standard" OSI, the selection of NSel values is left as a matter of local administration. Administrators of systems that support the OSI transport protocol [5] in addition to TCP/UDP must select NSels for use by OSI Transport that do not conflict with the IP PROTO values.
CLNPがTCPとUDPがサービスであるとサポートするのに使用されるとき、値が使用したNSelは登録されるとしてIANAがある適切なIPプロト価値です。 「標準」のOSIにおいて、NSel値の品揃えは地方行政の問題として残されます。 TCP/UDPに加えてOSIトランスポート・プロトコルが[5]であるとサポートするシステムの管理者はIPプロト値と衝突しないOSI Transportによる使用のためにNSelsを選択しなければなりません。
In the NSAP RRs in Master Files and in the printed text in this memo, NSAPs are often represented as a string of "."-separated hex values. The values correspond to convenient divisions of the NSAP to make it more readable. For example, the "."-separated fields might correspond to the NSAP fields as defined by the appropriate authority (ISOC, RARE, U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for readability. The "."s do not appear in DNS packets and DNS servers can ignore them when reading Master Files. For example, a printable representation of the first four fields of a U.S. GOSIP NSAP might look like
「Master FilesのNSAP RRsとこのメモによる印刷されたテキストでは、NSAPsは」 . 」 切り離された十六進法値のストリングとしてしばしば表されます。 値は、それをより読み込み可能にするようにNSAPの便利な部門に対応しています。 「例えば、」 . 」 切り離された分野は適切な権威(ISOC、まれで、米国のGOSIP、ANSIなど)によって定義されるようにNSAP分野に対応するかもしれません。 この記法の使用は厳密に読み易さのためのものです。 . 「sはDNSパケットに現れません、そして、基本ファイルを読むとき、DNSサーバはそれらを無視できます」。 例えば、U.S. GOSIP NSAPの最初の4つの分野の印刷可能な表現に似るかもしれません。
47.0005.80.005a00
47.0005.80.005 a00
Manning & Colella [Page 4] RFC 1637 DNS NSAP RRs June 1994
マニングとColella[4ページ]RFC1637DNS NSAP RRs1994年6月
and a full U.S. GOSIP NSAP might appear as
そして、U.S. GOSIP NSAPが現れるかもしれない満
47.0005.80.005a00.0000.1000.0020.00800a123456.00.
47.0005.80.005 a00.0000.1000.0020.00800a123456.00。
Other NSAP formats have different lengths and different administratively defined field widths to accomodate different requirements. For more information on NSAP formats in use see RFC 1629 [2].
他のNSAP形式は異なった長さと異なった行政上定義された欄の幅をaccomodateの異なった要件に持っています。 NSAPの詳しい情報に関しては、使用中の形式はRFC1629[2]を見ます。
5. The NSAP RR
5. NSAP RR
The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22 (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP mapping in the DNS using the NSAP RR operates analogously to IP address lookup. A query is generated by the resolver requesting an NSAP RR for a provided domain name.
NSAP RRはニーモニック"NSAP"とタイプコード22(小数)で定義されて、ドメイン名からNSAPsまで写像するのにおいて使用されています。 NSAP RRを使用するDNSの名前からNSAPへのマッピングは類似してIPアドレスルックアップに作動します。 質問は提供されたドメイン名のためにNSAP RRを要求するレゾルバによって生成されます。
NSAP RRs conform to the top level RR format and semantics as defined in Section 3.2.1 of RFC 1035.
NSAP RRsは.1セクション3.2RFC1035で定義されるように最高平らなRR形式と意味論に従います。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE = NSAP |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS = IN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | ///名/| | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | =NSAPをタイプしてください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 中のクラス=| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL| | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / RDATA / / /+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
どこ:
* NAME: an owner name, i.e., the name of the node to which this
resource record pertains.
* 以下を命名してください。 すなわち、所有者名、このリソース記録が関係するノードの名前。
* TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
* 以下をタイプしてください。 22(10進)のNSAP RR TYPEコードを含む2つの八重奏。
Manning & Colella [Page 5] RFC 1637 DNS NSAP RRs June 1994
マニングとColella[5ページ]RFC1637DNS NSAP RRs1994年6月
* CLASS: two octets containing the RR IN CLASS code of 1.
* クラス: 1のRR IN CLASSコードを含む2つの八重奏。
* TTL: a 32 bit signed integer that specifies the time interval in
seconds that the resource record may be cached before the source
of the information should again be consulted. Zero values are
interpreted to mean that the RR can only be used for the
transaction in progress, and should not be cached. For example,
SOA records are always distributed with a zero TTL to prohibit
caching. Zero values can also be used for extremely volatile data.
* TTL: 情報の源が再び参照されるべきリソース記録がキャッシュされるかもしれない秒前に32ビットは時間間隔を指定する整数をサインインしました。 値は、全くRRが進行中のトランザクションに使用できるだけであって、キャッシュされるべきでないことを意味するために解釈されません。 例えば、SOA記録は、キャッシュするのを禁止するためにどんなTTLと共にもいつも分配されるというわけではありません。 また、非常に揮発性のデータに値を全く使用できません。
* RDLENGTH: an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
* RDLENGTH: 16ビットの未署名の整数に、それはRDATA分野の八重奏における長さを指定します。
* RDATA: a variable length string of octets containing the NSAP.
The value is the binary encoding of the NSAP as it would appear in
the CLNP source or destination address field. A typical example of
such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
20 (decimal); "."s have been omitted to emphasize that they don't
appear in the DNS packets.
* RDATA: NSAPを含む八重奏の可変長ストリング。 値はCLNPソースか目的地アドレス・フィールドに載っているようにNSAPの2進のコード化です。 そのようなNSAP(十六進法における)の典型的な例は以下に示されます。 このNSAPに関しては、RDLENGTHは20歳(10進)です。 「. 」 sは、彼らがDNSパケットに現れないと強調するために省略されました。
39840f80005a0000000001e13708002010726e00
39840f80005a0000000001e13708002010726e00
5.1 Additional Section Processing
5.1 追加セクション処理
[The specification in this section is necessary for completeness in describing name server support for TUBA. For the time being, name servers participating in TUBA demonstrations MAY ELECT to implement this behavior; it SHOULD NOT be the default behavior of name servers because the IPng sweepstakes are still outstanding and further consideration is required for truncation and other issues.]
[このセクションの仕様がTUBAのネームサーバサポートについて説明するのにおいて完全性に必要です。 当分の間、この振舞いを実装するためにTUBAデモンストレーションMAY ELECTに参加するネームサーバ。 SHOULD NOTはIPng賞金レースがまだ傑出しているのでネームサーバのデフォルトの振舞いであり、考慮を促進します。それ、トランケーションと他の問題のために、必要です。]
RFC 1035 describes the additional section processing (ASP) required when servers encounter NS records during query processing. From Section 3.3.11, "NS RDATA format":
RFC1035はサーバが問い合わせ処理の間NS記録に遭遇するとき必要である追加セクション処理(ASP)について説明します。 セクション3.3.11、「NS RDATA形式」から:
NS records cause both the usual additional section processing to
locate a type A record, and, when used in a referral, a special
search of the zone in which they reside for glue information.
NS記録はタイプA記録の場所を見つけるように処理される普通の追加セクション、および紹介に使用されるときのそれらが接着剤情報のために住んでいるゾーンの特別な検索を両方に引き起こします。
For TUBA, identical ASP is required on type NSAP records to support servers and resolvers that use CLNP, either because of preference or because it is the only internetworking protocol available (i.e., in the absense of IPv4). Thus, NS records cause ASP which locates a type NSAP record in addition to a type A record. Both type A and NSAP records should be returned, if available.
TUBAに関しては、同じASPはタイプNSAP記録でCLNPを使用するサーバとレゾルバをサポートしなければなりません、好みのためのどちらか、またはそれが利用可能な(すなわち、IPv4のabsenseの)唯一のインターネットワーキングプロトコルであるので。 したがって、NS記録はタイプA記録に加えたタイプNSAP記録の場所を見つけるASPを引き起こします。 NSAP記録は、両方がAをタイプして、返して、利用可能であるべきです。
Manning & Colella [Page 6] RFC 1637 DNS NSAP RRs June 1994
マニングとColella[6ページ]RFC1637DNS NSAP RRs1994年6月
6. NSAP-to-name Mapping Using the PTR RR
6. NSAPから名前へのPTR RRを使用するマッピング
The PTR RR is defined in RFC 1035. This RR is typically used under the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.
PTR RRはRFC1035で定義されます。 このRRは「ADDR.ARPA」のIPv4アドレスからドメイン名まで写像するドメインの下に通常使用されます。
Similarly, the PTR RR is used to map from NSAPs to domain names under the "NSAP.INT" domain. A domain name is generated from the NSAP according to the rules described below. A query is sent by the resolver requesting a PTR RR for the provided domain name.
同様に、PTR RRは"NSAP.INT"ドメインの下でNSAPsからドメイン名まで写像するのにおいて使用されています。 以下で説明された規則に従って、ドメイン名はNSAPから生成されます。 質問は提供されたドメイン名のためにPTR RRを要求するレゾルバによって送られます。
A domain name is generated from an NSAP by reversing the hex nibbles of the NSAP, treating each nibble as a separate subdomain, and appending the top-level subdomain name "NSAP.INT" to it. For example, the domain name used in the reverse lookup for the NSAP
ドメイン名はNSAPからNSAPの十六進法少量を逆にすることによって、生成されます、別々のサブドメインとして各少量を扱って、"NSAP.INT"というトップレベルサブドメイン名をそれに追加して。 例えばNSAPに逆のルックアップに使用されるドメイン名
47.0005.80.005a00.0000.0001.e133.ffffff000162.00
47.0005.80.005 a00.0000.0001.e133.ffffff000162.00
would appear as
現れるでしょう。
0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
0.8.5.0.0.0.7.4.NSAP.INT.
0.0.2.6.1.0.0.0.f. f. f. f. f. f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0。 %%BODY%%.8.5.0.0.0.7.4.NSAP.INT。
[Implementation note: For sanity's sake user interfaces should be designed to allow users to enter NSAPs using their natural order, i.e., as they are typically written on paper. Also, arbitrary "."s should be allowed (and ignored) on input.]
[実現注意: 正気の目的において、ユーザインタフェースはユーザがNSAPsに入るのを彼らの自然界の秩序を使用することで許可するように設計されるべきです、すなわち、彼らが紙上で通常書かれているとき。 「」 . また「sは入力のときにまた許容(そして、無視されます)にされるべきである」任意の。]
7. Master File Format
7. 基本ファイル形式
The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files conforms to Section 5, "Master Files," of RFC 1035. Below are examples of the use of these RRs in Master Files to support name-to- NSAP and NSAP-to-name mapping.
Master FilesのNSAP RRs(そして、NSAP関連のPTR RRs)の形式はセクション5、RFC1035の「基本ファイル」に従います。 以下に、サポートの名前からNSAPとNSAPから名前へのマッピングにはMaster FilesにおけるこれらのRRsの使用に関する例があります。
The NSAP RR introduces a new hex string format for the RDATA field. The format is "0x" (i.e., a zero followed by an 'x' character) followed by a variable length string of hex characters (0 to 9, a to f). The hex string is case-insensitive. "."s (i.e., periods) may be inserted in the hex string anywhere after the "0x" for readability. The "."s have no significance other than for readability and are not propagated in the protocol (e.g., queries or zone transfers).
NSAP RRは新しい十六進法記号列の書式をRDATA分野に取り入れます。 形式は十六進法キャラクタ(0〜9、aからf)の可変長ストリングがいうことになった"0x"(すなわち、aゼロは'x'キャラクタで続いた)です。 16進数列は大文字と小文字を区別しないです。 「. 」 s(すなわち、期間)は"0x"の後に読み易さのためにどこでも16進数列に挿入されるかもしれません。 . 「sは、読み易さ以外に、意味を全く持たないで、またプロトコル(例えば、質問かゾーン転送)で伝播されません」。
Manning & Colella [Page 7] RFC 1637 DNS NSAP RRs June 1994
マニングとColella[7ページ]RFC1637DNS NSAP RRs1994年6月
;;;;;; ;;;;;; Master File for domain nsap.nist.gov. ;;;;;;
;;;;;; ;;;;;; ドメインnsap.nist.govにFileを習得してください。 ;;;;;;
@ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. (
1994041800 ; Serial - date
1800 ; Refresh - 30 minutes
300 ; Retry - 5 minutes
604800 ; Expire - 7 days
3600 ) ; Minimum - 1 hour
IN NS emu.ncsl.nist.gov.
IN NS tuba.nsap.lanl.gov.
;
;
$ORIGIN nsap.nist.gov.
;
; hosts
;
bsdi1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
IN A 129.6.224.161
IN HINFO PC_486 BSDi1.1(TUBA)
;
bsdi2 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
IN A 129.6.224.162
IN HINFO PC_486 BSDi1.1(TUBA)
;
cursive IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
IN A 129.6.224.171
IN HINFO PC_386 DOS_5.0/NCSA_Telnet(TUBA)
;
infidel IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
IN A 129.6.55.164
IN HINFO PC/486 BSDi1.0(TUBA)
;
; routers
;
cisco1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
IN A 129.6.224.151
IN A 129.6.225.151
IN A 129.6.229.151
;
3com1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
IN A 129.6.224.111
IN A 129.6.225.111
IN A 129.6.228.111
@IN SOA emu.ncsl.nist.gov root.emu.ncsl.nist.gov。 3600 7日間リフレッシュしてください--30分300、再試行してください--5分604800、(1994041800; 連続しています--は1800の日付を入れます; 期限が切れてください) ; 最小限--1時間のIN NS emu.ncsl.nist.gov。 IN NS tuba.nsap.lanl.gov。 ; ; $ORIGIN nsap.nist.gov。 ; ; ホスト。 bsdi1IN NSAP0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00IN A129.6.224.161IN HINFO PC_486BSDi1.1(TUBA)。 bsdi2IN NSAP0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00IN A129.6.224.162IN HINFO PC_486BSDi1.1(TUBA)。 草書IN NSAP0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00IN A129.6.224.171IN HINFO PC_386DOS_5.0/NCSA_Telnet(TUBA)。 不信心者IN NSAP0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00IN A129.6.55.164IN HINFO PC/486BSDi1.0(TUBA)。 ; ルータ。 cisco1IN NSAP0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00IN A129.6.224.151IN A129.6.225.151IN A129.6.229.151。 A129.6.224.111IN A129.6.225.111IN A129.6.228におけるNSAP0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00の3com1、.111
Manning & Colella [Page 8] RFC 1637 DNS NSAP RRs June 1994
マニングとColella[8ページ]RFC1637DNS NSAP RRs1994年6月
;;;;;; ;;;;;; Master File for reverse mapping of NSAPs under the ;;;;;; NSAP prefix: ;;;;;; ;;;;;; 47.0005.80.005a00.0000.0001.e133 ;;;;;;
;;;;;; ;;;;;; NSAPs下の逆のマッピングのためにFileを習得してください、。 NSAPは以下を前に置きます。 ;;;;;; ;;;;;; 47.0005.80.005 a00.0000.0001.e133。
@ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. (
1994041800 ; Serial - date
1800 ; Refresh - 30 minutes
300 ; Retry - 5 minutes
604800 ; Expire - 7 days
3600 ) ; Minimum - 1 hour
IN NS emu.ncsl.nist.gov.
IN NS tuba.nsap.lanl.gov.
;
;
$ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
;
0.0.1.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi1.nsap.nist.gov.
;
0.0.2.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi2.nsap.nist.gov.
;
0.0.1.7.1.0.0.0.f.f.f.f.f.f IN PTR cursive.nsap.nist.gov.
;
0.0.4.6.1.0.0.0.f.f.f.f.f.f IN PTR infidel.nsap.nist.gov.
;
0.0.1.5.1.0.0.0.a.a.a.a.a.a IN PTR cisco1.nsap.nist.gov.
;
0.0.1.1.1.0.0.0.a.a.a.a.a.a IN PTR 3com1.nsap.nist.gov.
@IN SOA emu.ncsl.nist.gov root.emu.ncsl.nist.gov。 3600 7日間リフレッシュしてください--30分300、再試行してください--5分604800、(1994041800; 連続しています--は1800の日付を入れます; 期限が切れてください) ; 最小限--1時間のIN NS emu.ncsl.nist.gov。 IN NS tuba.nsap.lanl.gov。 ; ; $起源3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT。 ; 0.0.1.6.1.0.0.0.f. f. f. f. f. f IN PTR bsdi1.nsap.nist.gov。 ; 0.0.2.6.1.0.0.0.f. f. f. f. f. f IN PTR bsdi2.nsap.nist.gov。 ; 0.0.1.7.1.0.0.0.f. f. f. f. f. f IN PTR cursive.nsap.nist.gov。 ; 0.0.4.6.1.0.0.0.f. f. f. f. f. f IN PTR infidel.nsap.nist.gov。 ; 0.0.1.5.1.0.0.0.a. a. a. a. a. IN PTR cisco1.nsap.nist.gov。 ; 0.0.1.1.1.0.0.0.a. a. a. a. a. IN PTR 3com1.nsap.nist.gov。
8. Security Considerations
8. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Manning & Colella [Page 9] RFC 1637 DNS NSAP RRs June 1994
マニングとColella[9ページ]RFC1637DNS NSAP RRs1994年6月
9. Authors' Addresses
9. 作者のアドレス
Bill Manning Rice University -- ONCS P.O. Box 1892 6100 South Main Houston, Texas 77251-1892 USA
ビルマニングライス大学--ONCSの私書箱1892 6100の南主なテキサス77251-1892ヒューストン(米国)
Phone: +1.713.285.5415 EMail: bmanning@rice.edu
以下に電話をしてください。 +1.713 .285 .5415 メール: bmanning@rice.edu
Richard Colella National Institute of Standards and Technology Technology/B217 Gaithersburg, MD 20899 USA
リチャードColella米国商務省標準技術局技術/B217MD20899ゲイザースバーグ(米国)
Phone: +1 301-975-3627 Fax: +1 301 590-0932 EMail: colella@nist.gov
以下に電話をしてください。 +1 301-975-3627Fax: +1 301 590-0932 メールしてください: colella@nist.gov
10. References
10. 参照
[1] Callon R., "TCP and UDP with Bigger Addresses (TUBA), A Simple
Proposal for Internet Addressing and Routing", RFC 1347, DEC,
June 1992.
[1] Callon R.、「より大きいのがあるTCPとUDPは(tuba)、インターネットアドレシングとルート設定のための簡単な提案を記述します」、RFC1347、1992年12月、6月。
[2] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
1994.
[2]ColellaとR.とガードナーとE.とCallon、R.とY.Rekhter、「オウシNSAP Allocation inhインターネットのためのガイドライン」RFC1629、NIST、Wellfleet、Mitre、T.J.ワトソン研究所、IBM社(1994年5月)。
[3] GOSIP Advanced Requirements Group. Government Open Systems
Interconnection Profile (GOSIP) Version 2. Federal Information
Processing Standard 146-1, U.S. Department of Commerce, National
Institute of Standards and Technology, Gaithersburg, MD, April
1991.
[3] GOSIPの高度な要件は分類されます。 政府オープンシステムインタコネクトは(GOSIP)バージョン2の輪郭を描きます。 連邦情報処理基準146-1、米国商務省、米国商務省標準技術局、ゲイザースバーグ(MD)1991年4月。
[4] ISO/IEC. Data interchange - structures for the identification of
organization. International Standard 6523, ISO/IEC JTC 1,
Switzerland, 1984.
[4] ISO/IEC。 データは交換されます--組織の識別のための構造。 国際規格6523、ISO/IEC JTC1、スイス1984。
[5] ISO/IEC. Connection oriented transport protocol specification.
International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
[5] ISO/IEC。 接続は輸送プロトコル仕様を適応させました。 国際規格8073、ISO/IEC JTC1、スイス1986。
Manning & Colella [Page 10] RFC 1637 DNS NSAP RRs June 1994
マニングとColella[10ページ]RFC1637DNS NSAP RRs1994年6月
[6] ISO/IEC. Protocol for Providing the Connectionless-mode Network
Service. International Standard 8473, ISO/IEC JTC 1,
Switzerland, 1986.
[6] ISO/IEC。 コネクションレスなモードネットワーク・サービスを提供するには、議定書を作ってください。 国際規格8473、ISO/IEC JTC1、スイス1986。
[7] ISO/IEC. Information Processing Systems -- Data Communications --
Network Service Definition Addendum 2: Network Layer Addressing.
International Standard 8348/Addendum 2, ISO/IEC JTC 1,
Switzerland, 1988.
[7] ISO/IEC。 情報処理システム(データ通信)はサービス定義付加物2をネットワークでつなぎます: ネットワーク層アドレシング。 国際規格8348/付加物2、ISO/IEC JTC1、スイス1988。
[8] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[8]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日
[9] Mockapetris, P., "Domain Names -- Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[9]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、科学が設けるUSC/情報、11月1987日
Manning & Colella [Page 11]
マニングとColella[11ページ]
一覧
スポンサーリンク
