RFC1033 日本語訳
1033 Domain administrators operations guide. M. Lottor. November 1987. (Format: TXT=37263 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Lottor
Request For Comments: 1033 SRI International
November 1987
Lottorがコメントのために要求するワーキンググループM.をネットワークでつないでください: 1033 SRIインターナショナル1987年11月
DOMAIN ADMINISTRATORS OPERATIONS GUIDE
操作が誘導するドメイン管理者
STATUS OF THIS MEMO
このメモの状態
This RFC provides guidelines for domain administrators in operating a domain server and maintaining their portion of the hierarchical database. Familiarity with the domain system is assumed. Distribution of this memo is unlimited.
このRFCはドメインサーバを操作して、彼らの階層型データベースの部分を維持する際にドメイン管理者にガイドラインを提供します。 ドメインシステムへの親しみは想定されます。 このメモの分配は無制限です。
ACKNOWLEDGMENTS
承認
This memo is a formatted collection of notes and excerpts from the references listed at the end of this document. Of particular mention are Paul Mockapetris and Kevin Dunlap.
このメモはこのドキュメントの端にリストアップされた参照からの注意と抜粋のフォーマットされた収集です。 特定の言及において、ポールMockapetrisとケビン・ダンラップはそうですか?
INTRODUCTION
序論
A domain server requires a few files to get started. It will normally have some number of boot/startup files (also known as the "safety belt" files). One section will contain a list of possible root servers that the server will use to find the up-to-date list of root servers. Another section will list the zone files to be loaded into the server for your local domain information. A zone file typically contains all the data for a particular domain. This guide describes the data formats that can be used in zone files and suggested parameters to use for certain fields. If you are attempting to do anything advanced or tricky, consult the appropriate domain RFC's for more details.
ドメインサーバは、開始するためにいくつかのファイルを必要とします。 それには、通常、何らかの数のブーツ/始動ファイル(また、「シートベルト」がファイルされるので、知っている)があるでしょう。 1つのセクションがサーバがルートサーバーの最新のリストを見つけるのに使用する可能なルートサーバーのリストを含むでしょう。 もう1つのセクションが、あなたの局所領域情報のためにサーバにロードされるためにゾーンファイルをリストアップするでしょう。 ゾーンファイルは特定のドメインのためのすべてのデータを通常含んでいます。 このガイドはゾーンファイルで使用できるデータ形式とある一定の分野に使用する提案されたパラメタについて説明します。 高度であるか、または何か扱いにくいことをするのを試みているなら、その他の詳細のために適切なドメインRFCのものに相談してください。
Note: Each implementation of domain software may require different files. Zone files are standardized but some servers may require other startup files. See the appropriate documentation that comes with your software. See the appendix for some specific examples.
以下に注意してください。 ドメインソフトウェアの各実装は異なったファイルを必要とするかもしれません。 ゾーンファイルは標準化されますが、いくつかのサーバが他の始動ファイルを必要とするかもしれません。 あなたのソフトウェアと共に来る適切なドキュメンテーションを見てください。 いくつかの特定の例に関して付録を見てください。
ZONES
ゾーン
A zone defines the contents of a contiguous section of the domain space, usually bounded by administrative boundaries. There will typically be a separate data file for each zone. The data contained in a zone file is composed of entries called Resource Records (RRs).
ゾーンはスペースの、そして、通常、管理境界のそばで境界があるドメインの隣接のセクションのコンテンツを定義します。 各ゾーンのための別々のデータファイルが通常あるでしょう。 ゾーンファイルに含まれたデータはResource Records(RRs)と呼ばれるエントリーで構成されます。
Lottor [Page 1] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[1ページ]RFC1033ドメイン
You may only put data in your domain server that you are authoritative for. You must not add entries for domains other than your own (except for the special case of "glue records").
あなたは正式であるドメインサーバにデータを入れることができるだけです。 あなたはあなた自身の(「接着剤記録」の特別なケースを除いた)を除いたドメインのためのエントリーを加えてはいけません。
A domain server will probably read a file on start-up that lists the zones it should load into its database. The format of this file is not standardized and is different for most domain server implementations. For each zone it will normally contain the domain name of the zone and the file name that contains the data to load for the zone.
ドメインサーバはたぶんそれがデータベースにロードするべきであるゾーンを記載する上にから始まるファイルを読むでしょう。 このファイルの形式は、標準化されないで、ほとんどのドメインサーバ実装において、異なっています。 各ゾーンに、通常、それはゾーンにロードするデータを含むゾーンとファイル名のドメイン名を含むでしょう。
ROOT SERVERS
ルートサーバー
A resolver will need to find the root servers when it first starts. When the resolver boots, it will typically read a list of possible root servers from a file.
レゾルバは、最初に始まるとき、ルートサーバーを見つける必要があるでしょう。 レゾルバブーツであるときに、それはファイルから可能なルートサーバーのリストを通常読むでしょう。
The resolver will cycle through the list trying to contact each one. When it finds a root server, it will ask it for the current list of root servers. It will then discard the list of root servers it read from the data file and replace it with the current list it received.
レゾルバは、それぞれに連絡しようとしながら、リストを通して自転車で行くでしょう。 ルートサーバーを見つけるとき、それはルートサーバーの現在のリストのためにそれを尋ねるでしょう。 それは、次に、それがデータファイルから読んだルートサーバーのリストを捨てて、それを受け取った現在のリストに取り替えるでしょう。
Root servers will not change very often. You can get the names of current root servers from the NIC.
ルートサーバーは頻繁に変化しないでしょう。 あなたはNICから現在のルートサーバーの名前を得ることができます。
FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to NIC@SRI-NIC.ARPA.
FTP、NETINFO: ROOT-SERVERS.TXTをファイルするか、またはメール要求を NIC@SRI-NIC.ARPA に送ってください。
As of this date (June 1987) they are:
現在の時点では、(1987年6月)のときに、それらは以下の通りです。
SRI-NIC.ARPA 10.0.0.51 26.0.0.73
C.ISI.EDU 10.0.0.52
BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2
A.ISI.EDU 26.3.0.103
様-NIC.ARPA10.0.0.51 26.0.0.73C.ISI.EDU10.0.0.52BRL-AOS.ARPA192.5.25.82 192.5.22.82 128.20.1.2A.ISI.EDU26.3.0、.103
RESOURCE RECORDS
リソース記録
Records in the zone data files are called resource records (RRs). They are specified in RFC-883 and RFC-973. An RR has a standard format as shown:
ゾーンデータファイルでの記録はリソース記録(RRs)と呼ばれます。 それらはRFC-883とRFC-973で指定されます。 RRには、標準書式が示されるようにあります:
<name> [<ttl>] [<class>] <type> <data>
<名前>[<ttl>][<のクラス>]<タイプ><データ>。
The record is divided into fields which are separated by white space.
記録は余白によって切り離される野原に分割されます。
<name>
<名前>。
The name field defines what domain name applies to the given
名前欄は、どんなドメイン名が付与に適用されるかを定義します。
Lottor [Page 2] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[2ページ]RFC1033ドメイン
RR. In some cases the name field can be left blank and it will
default to the name field of the previous RR.
RR。 いくつかの場合、名前欄を空白のままにできます、そして、それは前のRRの名前欄をデフォルトとするでしょう。
<ttl>
<ttl>。
TTL stands for Time To Live. It specifies how long a domain
resolver should cache the RR before it throws it out and asks a
domain server again. See the section on TTL's. If you leave
the TTL field blank it will default to the minimum time
specified in the SOA record (described later).
TTLはTime To Liveを表します。 それは、それを放り出して、再びドメインサーバを尋ねる前にどれくらい長いドメインレゾルバがRRをキャッシュするはずであるかを指定します。 TTLのところのセクションを見てください。 あなたが空白の状態でTTL野原を出ると、SOA記録(後で説明される)で指定された最小の時間をデフォルトとするでしょう。
<class>
<のクラス>。
The class field specifies the protocol group. If left blank it
will default to the last class specified.
類体はプロトコルグループを指定します。 空白のままにされると、それは指定された最後のクラスをデフォルトとするでしょう。
<type>
<タイプ>。
The type field specifies what type of data is in the RR. See
the section on types.
タイプ分野は、どんなタイプに関するデータがRRにあるかを指定します。 タイプの上のセクションを見てください。
<data>
<データ>。
The data field is defined differently for each type and class
of data. Popular RR data formats are described later.
データ・フィールドはそれぞれのタイプとクラスに関するデータのために異なって定義されます。 ポピュラーなRRデータ形式は後で説明されます。
The domain system does not guarantee to preserve the order of resource records. Listing RRs (such as multiple address records) in a certain order does not guarantee they will be used in that order.
ドメインシステムは、リソース記録の注文を保存するのを保証しません。 あるオーダーにRRs(複数のアドレス記録などの)を記載するのは、それらがそのオーダーで使用されるのを保証しません。
Case is preserved in names and data fields when loaded into the name server. All comparisons and lookups in the name server are case insensitive.
ネームサーバにロードされると、ケースは名前とデータ・フィールドに保存されます。ネームサーバにおけるすべての比較とルックアップは大文字と小文字を区別しないです。
Parenthesis ("(",")") are used to group data that crosses a line
boundary.
挿入句、(「(「」、)、」、)、系列境界に交差するデータを分類するために、使用されます。
A semicolon (";") starts a comment; the remainder of the line is
ignored.
セミコロン、(「」、)、コメントを始めます。 系列の残りは無視されます。
The asterisk ("*") is used for wildcarding.
アスタリスク(「*」)は、wildcardingするのに使用されます。
The at-sign ("@") denotes the current default domain name.
サインの("@")は現在のデフォルトドメイン名を指示します。
Lottor [Page 3] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[3ページ]RFC1033ドメイン
NAMES
名前
A domain name is a sequence of labels separated by dots.
ドメイン名はドットによって分離されたラベルの系列です。
Domain names in the zone files can be one of two types, either absolute or relative. An absolute name is the fully qualified domain name and is terminated with a period. A relative name does not terminate with a period, and the current default domain is appended to it. The default domain is usually the name of the domain that was specified in the boot file that loads each zone.
ゾーンファイルのドメイン名は絶対の、または、相対的な2つのタイプのひとりであることができます。 絶対名は、完全修飾ドメイン名であり、期間で終えられます。 相対的な名前は期間で終わりません、そして、現在のデフォルトドメインをそれに追加します。 通常、デフォルトドメインは各ゾーンをロードするブート・ファイルで指定されたドメインの名前です。
The domain system allows a label to contain any 8-bit character. Although the domain system has no restrictions, other protocols such as SMTP do have name restrictions. Because of other protocol restrictions, only the following characters are recommended for use in a host name (besides the dot separator):
ドメインシステムで、ラベルはどんな8ビットのキャラクタも含むことができます。 ドメインシステムには、制限が全くありませんが、SMTPなどの他のプロトコルでは、名前制限があります。 他のプロトコル制限のために、以下のキャラクタだけがホスト名(ドット分離符以外に)における使用のために推薦されます:
"A-Z", "a-z", "0-9", dash and underscore
「A-Z」、「a-z」、「09インチ、ダッシュと強調、」
TTL's (Time To Live)
TTLのもの(生きる時間)
It is important that TTLs are set to appropriate values. The TTL is the time (in seconds) that a resolver will use the data it got from your server before it asks your server again. If you set the value too low, your server will get loaded down with lots of repeat requests. If you set it too high, then information you change will not get distributed in a reasonable amount of time. If you leave the TTL field blank, it will default to what is specified in the SOA record for the zone.
TTLsが値を当てるように用意ができているのは、重要です。 TTLは再びあなたのサーバを尋ねる前にレゾルバがそれがあなたのサーバから得たデータを使用する時間(秒の)です。 あなたがあまりに低く値を設定すると、あなたのサーバは多くの反復要求でどっさり積まれるでしょう。 あなたがそれをあまり高く設定すると、あなたが変える情報は妥当な時間で分配されないでしょう。 あなたが空白の状態でTTL野原を出ると、それはゾーンのためのSOA記録で指定されることをデフォルトとするでしょう。
Most host information does not change much over long time periods. A good way to set up your TTLs would be to set them at a high value, and then lower the value if you know a change will be coming soon. You might set most TTLs to anywhere between a day (86400) and a week (604800). Then, if you know some data will be changing in the near future, set the TTL for that RR down to a lower value (an hour to a day) until the change takes place, and then put it back up to its previous value.
ほとんどのホスト情報は長い期間にわたってあまり変化しません。 あなたのTTLsをセットアップする早道は、あなたが、変化がすぐ来るのを知っているなら、高い値で彼らを設定して、次に、値を下げるだろうことです。 あなたはほとんどのTTLsをどこでも1日(86400)と1週間(604800)の間設定するかもしれません。 次に、いくつかのデータが近い将来変化するのを知っているなら、変化が起こるまで、そのRRにTTLを(1時間から1日)あたり1つの下側の値まで設定してください、そして、次に、それを前の値まで置いてください。
Also, all RRs with the same name, class, and type should have the same TTL value.
また、同じ名前、クラス、およびタイプがあるすべてのRRsには、同じTTL値があるはずです。
CLASSES
クラス
The domain system was designed to be protocol independent. The class field is used to identify the protocol group that each RR is in.
ドメインシステムは、プロトコル独立者になるように設計されました。 類体は、各RRがいるプロトコルグループを特定するのに使用されます。
The class of interest to people using TCP/IP software is the class
TCP/IPソフトウェアを使用している人々にとって、興味深いクラスはクラスです。
Lottor [Page 4] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[4ページ]RFC1033ドメイン
"Internet". Its standard designation is "IN".
「インターネット。」 標準の名称は「IN」です。
A zone file should only contain RRs of the same class.
ゾーンファイルは同じクラスのRRsを入れてあるだけであるはずです。
TYPES
タイプ
There are many defined RR types. For a complete list, see the domain specification RFCs. Here is a list of current commonly used types. The data for each type is described in the data section.
多くの定義されたRRタイプがあります。 全リストに関しては、ドメイン仕様RFCsを見てください。 ここに、現在の一般的に使用されたタイプのリストがあります。 データは資料課で各タイプに説明されます。
Designation Description
==========================================
SOA Start Of Authority
NS Name Server
名称記述========================================== 権威ナノ秒のSOA始まり、ネームサーバ
A Internet Address
CNAME Canonical Name (nickname pointer)
HINFO Host Information
WKS Well Known Services
インターネットAddress CNAME Canonical Name(あだ名指針)HINFO Host情報WKS Well Known Services
MX Mail Exchanger
MXは交換器を郵送します。
PTR Pointer
PTR指針
SOA (Start Of Authority)
SOA(権威の始まり)
<name> [<ttl>] [<class>] SOA <origin> <person> (
<serial>
<refresh>
<retry>
<expire>
<minimum> )
<名前>[<ttl>][<のクラス>]SOA<発生源><人の>。(<の連続の><が><最小の状態で<が吐き出す><再試行>をリフレッシュする、>)
The Start Of Authority record designates the start of a zone. The zone ends at the next SOA record.
Start Of Authority記録はゾーンの始まりを指定します。 ゾーンは次のSOA記録で終わります。
<name> is the name of the zone.
<名前>はゾーンの名前です。
<origin> is the name of the host on which the master zone file resides.
<発生源>はマスターゾーンファイルがあるホストの名前です。
<person> is a mailbox for the person responsible for the zone. It is formatted like a mailing address but the at-sign that normally separates the user from the host name is replaced with a dot.
<人の>はゾーンに責任がある人のためのメールボックスです。 郵送先住所のようにそれをフォーマットしますが、通常、ホスト名とユーザを切り離すサインをドットに取り替えます。
<serial> is the version number of the zone file. It should be incremented anytime a change is made to data in the zone.
<の連続の>はゾーンファイルのバージョン番号です。 いつでも増加されて、ゾーンで変更をデータにするということであるべきです。
Lottor [Page 5] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[5ページ]RFC1033ドメイン
<refresh> is how long, in seconds, a secondary name server is to check with the primary name server to see if an update is needed. A good value here would be one hour (3600).
<は>をリフレッシュします。セカンダリネームサーバは、どのようにが秒が長いかとアップデートが必要であるかどうかを見るプライマリネームサーバに問い合わせることになっています。 ここの値打ち品は1時間(3600)でしょう。
<retry> is how long, in seconds, a secondary name server is to retry after a failure to check for a refresh. A good value here would be 10 minutes (600).
<再試行>は秒のセカンダリネームサーバがaがないかどうかチェックしないことの後に再試行するのでどれくらい長いかがリフレッシュするということです。 ここの値打ち品は10分(600)でしょう。
<expire> is the upper limit, in seconds, that a secondary name server is to use the data before it expires for lack of getting a refresh. You want this to be rather large, and a nice value is 3600000, about 42 days.
<は期限が切れます。>は秒のセカンダリネームサーバが使用することになっているそれの前のデータがaがリフレッシュする得ることの不足によって吐き出す上限です。 あなたは、これにかなり大きくあって欲しいです、そして、良い値は3600000、およそ42日間です。
<minimum> is the minimum number of seconds to be used for TTL values in RRs. A minimum of at least a day is a good value here (86400).
<の最小の>はRRsのTTL値に使用されるべき最小の秒数です。 最低少なくとも1日は利益がここで(86400)を評価するということです。
There should only be one SOA record per zone. A sample SOA record would look something like:
1ゾーンあたり1つのSOA記録しかあるべきではありません。 サンプルSOA記録は何かに似ているでしょう:
@ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
45 ;serial
3600 ;refresh
600 ;retry
3600000 ;expire
86400 ) ;minimum
@SOA様-NIC.ARPAで。 HOSTMASTER.SRI-NIC.ARPA。 (45; 連続の3600;は600をリフレッシュします; 3600000を再試行してください; 86400を吐き出してください) ; 最小限
NS (Name Server)
ナノ秒(ネームサーバ)
<domain> [<ttl>] [<class>] NS <server>
<ドメイン>[<ttl>][<のクラス>]ナノ秒<サーバ>。
The NS record lists the name of a machine that provides domain service for a particular domain. The name associated with the RR is the domain name and the data portion is the name of a host that provides the service. If machines SRI-NIC.ARPA and C.ISI.EDU provide name lookup service for the domain COM then the following entries would be used:
NS記録は特定のドメインのためのドメインサービスを提供するマシンの名前を記載します。 RRに関連している名前はドメイン名です、そして、データ部はサービスを提供するホストの名前です。 マシンのSRI-NIC.ARPAとC. ISI.EDUが名前ルックアップサービスをドメインCOMに供給するなら、以下のエントリーは使用されるでしょう:
COM. NS SRI-NIC.ARPA.
NS C.ISI.EDU.
COM。 ナノ秒様-NIC.ARPA。 ナノ秒C.ISI.EDU。
Note that the machines providing name service do not have to live in the named domain. There should be one NS record for each server for a domain. Also note that the name "COM" defaults for the second NS record.
名前サービスを提供するマシンが命名されたドメインに住む必要はないことに注意してください。 ドメインへの各サーバあたり1つのNS記録があるべきです。 また、"COM"という名前が第2ナノ秒記録のためにデフォルトとすることに注意してください。
NS records for a domain exist in both the zone that delegates the domain, and in the domain itself.
ドメインのためのNS記録はドメインを代表として派遣する両方のゾーン、およびドメイン自体に存在しています。
Lottor [Page 6] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[6ページ]RFC1033ドメイン
GLUE RECORDS
接着剤記録
If the name server host for a particular domain is itself inside the domain, then a 'glue' record will be needed. A glue record is an A (address) RR that specifies the address of the server. Glue records are only needed in the server delegating the domain, not in the domain itself. If for example the name server for domain SRI.COM was KL.SRI.COM, then the NS record would look like this, but you will also need to have the following A record.
特定のドメインへのネームサーバホストがドメインの中にそれ自体でいると、'接着剤'記録が必要でしょう。 接着剤レコードはサーバのアドレスを指定するA(アドレス)RRです。接着剤記録がそのドメイン自体で必要であるのではなく、ドメインを代表として派遣するサーバで必要であるだけです。 例えば、ドメインSRI.COMへのネームサーバがKL.SRI.COMであるなら、NS記録はこれに似ているでしょうにが、また、あなたは、以下のAが記録させる必要があるでしょう。
SRI.COM. NS
KL.SRI.COM. KL.SRI.COM. A 10.1.0.2.
SRI.COM。 ナノ秒KL.SRI.COM。 KL.SRI.COM。 10.1 .0 .2。
A (Address)
A(アドレス)
<host> [<ttl>] [<class>] A <address>
<が>を扱う<ホスト>[<ttl>][<のクラス>]
The data for an A record is an internet address in dotted decimal form. A sample A record might look like:
データは、A記録がドット付き10進法でインターネットアドレスであるので、形成されます。 サンプルA記録に似るかもしれません:
SRI-NIC.ARPA. A 10.0.0.51
様-NIC.ARPA。 A10.0.0、.51
There should be one A record for each address of a host.
ホストの各アドレスに、記録的な1つAがあるべきです。
CNAME ( Canonical Name)
CNAME(正準な名前)
<nickname> [<ttl>] [<class>] CNAME <host>
<あだ名>[<ttl>][<のクラス>]CNAME<ホスト>。
The CNAME record is used for nicknames. The name associated with the RR is the nickname. The data portion is the official name. For example, a machine named SRI-NIC.ARPA may want to have the nickname NIC.ARPA. In that case, the following RR would be used:
CNAME記録はあだ名に使用されます。 RRに関連している名前はあだ名です。 データ部は正式名称です。 例えば、SRI-NIC.ARPAというマシンはあだ名NIC.ARPAを必要とするかもしれません。 その場合、以下のRRは使用されるでしょう:
NIC.ARPA. CNAME SRI-NIC.ARPA.
NIC.ARPA。 CNAME様-NIC.ARPA。
There must not be any other RRs associated with a nickname of the same class.
同じクラスに関するあだ名に関連しているいかなる他のRRsもあるはずがありません。
Nicknames are also useful when a host changes it's name. In that case, it is usually a good idea to have a CNAME pointer so that people still using the old name will get to the right place.
あだ名はまた、ホストがそれを変えると役に立つのが、名前であるということです。 その場合、通常、CNAME指針を持つのは、まだ旧名を使用している人々が適当な場所に着くための名案です。
Lottor [Page 7] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[7ページ]RFC1033ドメイン
HINFO (Host Info)
HINFO(ホストインフォメーション)
<host> [<ttl>] [<class>] HINFO <hardware> <software>
<ホスト>[<ttl>][<のクラス>]HINFO<ハードウェア><ソフトウェア>。
The HINFO record gives information about a particular host. The data is two strings separated by whitespace. The first string is a hardware description and the second is software. The hardware is usually a manufacturer name followed by a dash and model designation. The software string is usually the name of the operating system.
HINFO記録は特定のホストに関して知らせます。 データは空白によって分離された2個のストリングです。 最初のストリングはハードウェア記述です、そして、2番目はソフトウェアです。 通常、ハードウェアはダッシュと型式番号がいうことになったメーカー名です。 通常、ソフトウェアストリングはオペレーティングシステムの名前です。
Official HINFO types can be found in the latest Assigned Numbers RFC, the latest of which is RFC-1010. The Hardware type is called the Machine name and the Software type is called the System name.
最新のAssigned民数記RFCで公式のHINFOタイプを見つけることができます。その最新のものはRFC-1010です。 HardwareタイプはMachine名と呼ばれます、そして、SoftwareタイプはSystem名と呼ばれます。
Some sample HINFO records:
いくらかのサンプルHINFOが記録します:
SRI-NIC.ARPA. HINFO DEC-2060 TOPS20
UCBARPA.Berkeley.EDU. HINFO VAX-11/780 UNIX
様-NIC.ARPA。 HINFO12月-2060TOPS20 UCBARPA.Berkeley.EDU。 HINFOバックス-11/780UNIX
WKS (Well Known Services)
WKS(よく知られているサービス)
<host> [<ttl>] [<class>] WKS <address> <protocol> <services>
<ホスト>[<ttl>][<のクラス>]WKS<アドレス><プロトコル><サービス>。
The WKS record is used to list Well Known Services a host provides. WKS's are defined to be services on port numbers below 256. The WKS record lists what services are available at a certain address using a certain protocol. The common protocols are TCP or UDP. A sample WKS record for a host offering the same services on all address would look like:
WKS記録は、ホストが提供するWell Known Servicesを記載するのに使用されます。 WKSのものは、ポートNo.256におけるサービスになるように定義されます。 WKS記録は、サービスがものであるとあるアドレスで利用可能な状態であるプロトコルを使用することで記載します。 一般的なプロトコルは、TCPかUDPです。 すべてのアドレスに対しては同じサービスを提供するホストへのサンプルWKS記録に似ているでしょう:
Official protocol names can be found in the latest Assigned Numbers RFC, the latest of which is RFC-1010.
最新のAssigned民数記RFCで公式のプロトコル名を見つけることができます。その最新のものはRFC-1010です。
SRI-NIC.ARPA. WKS 10.0.0.51 TCP TELNET FTP SMTP
WKS 10.0.0.51 UDP TIME
WKS 26.0.0.73 TCP TELNET FTP SMTP
WKS 26.0.0.73 UDP TIME
様-NIC.ARPA。 WKS10.0.0.51TCP telnet FTP SMTP WKS10.0.0.51UDP時間WKS26.0.0.73TCP telnet FTP SMTP WKS26.0.0.73UDP時間
MX (Mail Exchanger) (See RFC-974 for more details.)
MX(交換器を郵送します)(その他の詳細に関してRFC-974を見てください。)
<name> [<ttl>] [<class>] MX <preference> <host>
<名前>[<ttl>][<のクラス>]MX<好みの><ホスト>。
MX records specify where mail for a domain name should be delivered. There may be multiple MX records for a particular name. The preference value specifies the order a mailer should try multiple MX records when delivering mail. Zero is the highest preference. Multiple records for the same name may have the same preference.
MX記録は、ドメイン名のためのメールがどこに提供されるべきであるかを指定します。 特定の名前のための複数のMX記録があるかもしれません。 好みの値はオーダーを指定します。配送メールであるときに、郵送者は複数のMX記録を試みるはずです。 ゼロは最も高い好みです。 同じ名前のための複数の記録には、同じ好みがあるかもしれません。
Lottor [Page 8] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[8ページ]RFC1033ドメイン
A host BAR.FOO.COM may want its mail to be delivered to the host PO.FOO.COM and would then use the MX record:
ホストBAR.FOO.COMはホストPO.FOO.COMにメールを提供して欲しいかもしれません、そして、次に、MX記録を使用するでしょう:
BAR.FOO.COM. MX 10 PO.FOO.COM.
BAR.FOO.COM。 Mx10PO.FOO.COM。
A host BAZ.FOO.COM may want its mail to be delivered to one of three different machines, in the following order:
ホストBAZ.FOO.COMは以下のオーダーにおける3台の異なったマシンの1つにメールを提供して欲しいかもしれません:
BAZ.FOO.COM. MX 10 PO1.FOO.COM.
MX 20 PO2.FOO.COM.
MX 30 PO3.FOO.COM.
BAZ.FOO.COM。 Mx10PO1.FOO.COM。 Mx20PO2.FOO.COM。 Mx30PO3.FOO.COM。
An entire domain of hosts not connected to the Internet may want their mail to go through a mail gateway that knows how to deliver mail to them. If they would like mail addressed to any host in the domain FOO.COM to go through the mail gateway they might use:
インターネットに接続されなかったホストの全体のドメインは、彼らの郵便配達人がそれが、どのようにがメールを彼らに提供するかを知っているメール・ゲートウェイを通る必要があるかもしれません。 メール・ゲートウェイを通るためにドメインFOO.COMのあらゆるホストにメールを扱って欲しいなら、彼らは以下を使用するかもしれません。
FOO.COM. MX 10 RELAY.CS.NET.
*.FOO.COM. MX 20 RELAY.CS.NET.
FOO.COM。 Mx10RELAY.CS.NET。 *.FOO.COM。 Mx20RELAY.CS.NET。
Note that you can specify a wildcard in the MX record to match on anything in FOO.COM, but that it won't match a plain FOO.COM.
FOO.COMで何でも合うようにMX記録でワイルドカードを指定できますが、明瞭なFOO.COMを合わせないことに注意してください。
IN-ADDR.ARPA
ADDR.ARPA
The structure of names in the domain system is set up in a hierarchical way such that the address of a name can be found by tracing down the domain tree contacting a server for each label of the name. Because of this 'indexing' based on name, there is no easy way to translate a host address back into its host name.
ドメインシステムの名前の構造は、名前の各ラベルのためにサーバに連絡する突き止めるのによるドメイン木を名前のアドレスに見つけることができるように階層的な方法で設立されます。 名前に基づくこの'インデックス'のために、ホスト・アドレスをホスト名に翻訳して戻すどんな簡単な方法もありません。
In order to do the reverse translation easily, a domain was created that uses hosts' addresses as part of a name that then points to the data for that host. In this way, there is now an 'index' to hosts' RRs based on their address. This address mapping domain is called IN-ADDR.ARPA. Within that domain are subdomains for each network, based on network number. Also, for consistency and natural groupings, the 4 octets of a host number are reversed.
容易に逆の翻訳をするために、次にそのホストのためにデータを示す名前の一部としてホストのアドレスを使用するドメインは作成されました。 このように、現在、彼らのアドレスに基づくホストのRRsへの'インデックス'があります。 このアドレス・マッピングドメインはIN-ADDR.ARPAと呼ばれます。 そのドメインの中に、ネットワーク・ナンバーに基づいた各ネットワークのためのサブドメインがあります。 また、一貫性と自然な組分けにおいて、ホスト番号の4つの八重奏が逆にされます。
For example, the ARPANET is net 10. That means there is a domain called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR at 51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA (who's address is 10.0.0.51). Since the NIC is also on the MILNET (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN- ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA. The format of these special pointers is defined below along with the examples for the NIC.
例えば、アルパネットはネットの10です。 それは、10.IN-ADDR.ARPAと呼ばれるドメインがあることを意味します。 だれがアドレスであるかがあります。そこのこのドメインがホストSRI-NIC.ARPAのためにRRsを示す51.0.0.10.IN-ADDRの中では、PTR RRである、(10.0 .0 .51)。 以来、NICがMILNETにもある、(ネット26、アドレス、26.0、.0、.73、)、また、PTR RRがSRI-NIC.ARPAのためにRRの同じものを示す73.0.0.26.IN ADDR.ARPAにあります。 これらの特別な指針の書式はNICのための例と共に以下で定義されます。
Lottor [Page 9] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[9ページ]RFC1033ドメイン
PTR
PTR
<special-name> [<ttl>] [<class>] PTR <name>
<の特別な名前の>[<ttl>][<のクラス>]PTR<名前>。
The PTR record is used to let special names point to some other location in the domain tree. They are mainly used in the IN- ADDR.ARPA records for translation of addresses to names. PTR's should use official names and not aliases.
特別な名前にドメイン木にある他の位置を示させるのにPTR記録は使用されます。 それらはアドレスに関する翻訳にIN ADDR.ARPA記録で名前に主に使用されます。 PTRのものは別名ではなく、正式名称を使用するはずです。
For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73 would have the following records in the respective zone files for net 10 and net 26:
そして、例えば、アドレス10.0.0でSRI-NIC.ARPAを接待してください、.51、26.0 .0 .73には、ネットの10とネットの26のためのそれぞれのゾーンファイルでの以下の記録があるでしょう:
51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
ADDR.ARPAの51.0.0.10.。 PTR様-NIC.ARPA。 ADDR.ARPAの73.0.0.26.。 PTR様-NIC.ARPA。
GATEWAY PTR's
ゲートウェイPTRのもの
The IN-ADDR tree is also used to locate gateways on a particular network. Gateways have the same kind of PTR RRs as hosts (as above) but in addition they have other PTRs used to locate them by network number alone. These records have only 1, 2, or 3 octets as part of the name depending on whether they are class A, B, or C networks, respectively.
また、IN-ADDR木は、特定のネットワークにゲートウェイの場所を見つけるのに使用されます。 ゲートウェイには、(as above)を接待するとき、PTR RRsの同じ種類がありますが、さらに、彼らは、ネットワーク・ナンバーに従って彼らの単独で居場所を見つけるのに他のPTRsを使用させます。 これらの記録には、それらがクラスA、B、またはCであるかどうかに依存するのがそれぞれネットワークでつなぐ名前の一部として1だけ、2、または3つの八重奏があります。
Lets take the SRI-CSL gateway for example. It connects 3 different networks, one class A, one class B and one class C. It will have the standard RR's for a host in the CSL.SRI.COM zone:
例えばSRI-CSLゲートウェイを取らせます。 それは3つの異なったネットワークを接続します、1つのクラスA、1つのクラスB、1つのクラスのC.ItはCSL.SRI.COMゾーンにホストのための標準のRRのものを持つでしょう:
GW.CSL.SRI.COM. A 10.2.0.2
A 128.18.1.1
A 192.12.33.2
GW.CSL.SRI.COM。 A10.2.0、.2、A128.18.1、.1、A192.12.33、.2
Also, in 3 different zones (one for each network), it will have one of the following number to name translation pointers:
また、3つの異なったゾーン(各ネットワークあたり1つ)では、翻訳を指針と命名する以下の数の1つを持つでしょう:
2.0.2.10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
ADDR.ARPAの2.0.2.10.。 PTR GW.CSL.SRI.COM。 ADDR.ARPAの1.1.18.128.。 PTR GW.CSL.SRI.COM。 ADDR.ARPAの1.33.12.192.。 PTR GW.CSL.SRI.COM。
In addition, in each of the same 3 zones will be one of the following gateway location pointers:
さらに、それぞれの同じ3では、ゾーンは以下のゲートウェイ位置の指針の1つになるでしょう:
10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
ADDR.ARPAの10.。 PTR GW.CSL.SRI.COM。 ADDR.ARPAの18.128.。 PTR GW.CSL.SRI.COM。 ADDR.ARPAの33.12.192.。 PTR GW.CSL.SRI.COM。
Lottor [Page 10] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[10ページ]RFC1033ドメイン
INSTRUCTIONS
指示
Adding a subdomain.
サブドメインを加えます。
To add a new subdomain to your domain:
あなたのドメインに新しいサブドメインを加えるために:
Setup the other domain server and/or the new zone file.
他のドメインサーバ、そして/または、新しいゾーンファイルをセットアップしてください。
Add an NS record for each server of the new domain to the zone
file of the parent domain.
NSが新しいドメインの各サーバのために親ドメインのゾーンファイルに記録すると言い足してください。
Add any necessary glue RRs.
あらゆる必要な接着剤RRsを加えてください。
Adding a host.
ホストを加えます。
To add a new host to your zone files:
新しいホストをあなたのゾーンに追加するのはファイルされます:
Edit the appropriate zone file for the domain the host is in.
ホストがいるドメインのための適切なゾーンファイルを編集してください。
Add an entry for each address of the host.
ホストの各アドレスのためのエントリーを加えてください。
Optionally add CNAME, HINFO, WKS, and MX records.
任意にCNAME、HINFO、WKS、およびMX記録を加えてください。
Add the reverse IN-ADDR entry for each host address in the
appropriate zone files for each network the host in on.
それぞれのための逆のIN-ADDRエントリーがそれぞれのためのファイルがホストをネットワークでつなぐ適切なゾーンのアドレスをホスティングすると言い足してください。
Deleting a host.
ホストを削除します。
To delete a host from the zone files:
ゾーンからホストを削除するのはファイルされます:
Remove all the hosts' resource records from the zone file of
the domain the host is in.
ホストがいるドメインのゾーンファイルからすべてのホストのリソース記録を取り除いてください。
Remove all the hosts' PTR records from the IN-ADDR zone files
for each network the host was on.
ホストがいた各ネットワークのためのIN-ADDRゾーンファイルからすべてのホストのPTR記録を取り除いてください。
Adding gateways.
ゲートウェイを加えます。
Follow instructions for adding a host.
ホストを加えるには、指示に従ってください。
Add the gateway location PTR records for each network the
gateway is on.
ゲートウェイがある各ネットワークのためのゲートウェイ位置のPTR記録を加えてください。
Deleting gateways.
ゲートウェイを削除します。
Follow instructions for deleting a host.
ホストを削除するには、指示に従ってください。
Also delete the gateway location PTR records for each network
また、各ネットワークのためのゲートウェイ位置のPTR記録を削除してください。
Lottor [Page 11] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[11ページ]RFC1033ドメイン
the gateway was on.
ゲートウェイはオンでした。
COMPLAINTS
苦情
These are the suggested steps you should take if you are having problems that you believe are caused by someone else's name server:
引き起こされるあなたが他の誰かのネームサーバで信じている問題がありましていたらこれらはあなたが採るべきである提案された方法です:
1. Complain privately to the responsible person for the domain. You can find their mailing address in the SOA record for the domain.
1. ドメインのために責任者に個人的に不平を言ってください。 あなたはドメインへのSOA記録のそれらの郵送先住所を見つけることができます。
2. Complain publicly to the responsible person for the domain.
2. ドメインのために公的に責任者に不平を言ってください。
3. Ask the NIC for the administrative person responsible for the domain. Complain. You can also find domain contacts on the NIC in the file NETINFO:DOMAIN-CONTACTS.TXT
3. ドメインに責任がある管理人をNICに求めてください。 不平を言ってください。 また、あなたはNETINFO: ファイルDOMAIN-CONTACTS.TXTのNICでドメイン接触を見つけることができます。
4. Complain to the parent domain authorities.
4. 親ドメイン当局に不平を言ってください。
5. Ask the parent authorities to excommunicate the domain.
5. ドメインを破門するように親当局に頼んでください。
Lottor [Page 12] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[12ページ]RFC1033ドメイン
EXAMPLE DOMAIN SERVER DATABASE FILES
例のドメインサーバデータベース・ファイル
The following examples show how zone files are set up for a typical organization. SRI will be used as the example organization. SRI has decided to divided their domain SRI.COM into a few subdomains, one for each group that wants one. The subdomains are CSL and ISTC.
以下の例はゾーンファイルがどう典型的な組織に設定されるかを示しています。 SRIは例の組織として使用されるでしょう。 SRIは、決めました。1つを必要とする各グループのためにそれらのドメインSRI.COMをいくつかのサブドメイン、1つに分割しました。 サブドメインは、CSLとISTCです。
Note the following interesting items:
以下の興味深い項目に注意してください:
There are both hosts and domains under SRI.COM.
SRI.COMの下にホストとドメインの両方があります。
CSL.SRI.COM is both a domain name and a host name.
CSL.SRI.COMはドメイン名とホスト名の両方です。
All the domains are serviced by the same pair of domain servers.
すべてのドメインがドメインサーバの同じ組によって修理されます。
All hosts at SRI are on net 128.18 except hosts in the CSL domain
which are on net 192.12.33. Note that a domain does not have to
correspond to a physical network.
SRIのすべてのホストがCSLドメインのホスト以外のネットにあるネットの128.18にいる、192.12、.33 ドメインが物理ネットワークと食い違わなければならないことに注意してください。
The examples do not necessarily correspond to actual data in use
by the SRI domain.
例は必ずSRIドメインのそばで使用中の実際のデータと食い違っています。
SRI Domain Organization
様のドメイン構成
+-------+
| COM |
+-------+
|
+-------+
| SRI |
+-------+
|
+----------++-----------+
| | |
+-------+ +------+ +-------+
| CSL | | ISTC | | Hosts |
+-------+ +------+ +-------+
| |
+-------+ +-------+
| Hosts | | Hosts |
+-------+ +-------+
+-------+ | COM| +-------+ | +-------+ | 様| +-------+ | +----------++-----------+ | | | +-------+ +------+ +-------+ | CSL| | ISTC| | ホスト| +-------+ +------+ +-------+ | | +-------+ +-------+ | ホスト| | ホスト| +-------+ +-------+
Lottor [Page 13] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[13ページ]RFC1033ドメイン
[File "CONFIG.CMD". Since bootstrap files are not standardized, this file is presented using a pseudo configuration file syntax.]
"CONFIG.CMD"をファイルしてください。以来、独力で進んでください。[ファイルが標準化されないで、このファイルが疑似構成ファイル構文を使用することで提示される、]
load root server list from file ROOT.SERVERS load zone SRI.COM. from file SRI.ZONE load zone CSL.SRI.COM. from file CSL.ZONE load zone ISTC.SRI.COM. from file ISTC.ZONE load zone 18.128.IN-ADDR.ARPA. from file SRINET.ZONE load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE
ファイルROOT.SERVERS負荷ゾーンSRI.COMからのルートサーバーリストをロードしてください。ファイルSRI.ZONEから、ゾーンCSL.SRI.COMを積み込んでください。ファイルCSL.ZONEから、ゾーンISTC.SRI.COMを積み込んでください。ファイルISTC.ZONEから、ゾーン18.128.IN-ADDR.ARPAを積み込んでください。ファイルSRINET.ZONEからゾーン33.12.192.IN-ADDR.ARPAを積み込んでください、ファイルSRI-CSL-NET.ZONE
Lottor [Page 14] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[14ページ]RFC1033ドメイン
[File "ROOT.SERVERS". Again, the format of this file is not standardized.]
「ROOT.SERVERS」をファイルしてください。[一方、このファイルの形式は標準化されません。]
;list of possible root servers SRI-NIC.ARPA 10.0.0.51 26.0.0.73 C.ISI.EDU 10.0.0.52 BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 A.ISI.EDU 26.3.0.103
; 可能なルートサーバーSRI-NIC.ARPA10.0.0.51 26.0.0.73C. ISI.EDU10.0.0.52BRL-AOS.ARPA192.5.25.82 192.5.22.82 128.20.1.2A. ISI.EDU26.3.0.103のリスト
Lottor [Page 15] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[15ページ]RFC1033ドメイン
[File "SRI.ZONE"]
[ファイル"SRI.ZONE"]
SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (
870407 ;serial
1800 ;refresh every 30 minutes
600 ;retry every 10 minutes
604800 ;expire after a week
86400 ;default of an hour
)
SRI.COM。 SOA KL.SRI.COMで。 DLE.STRIPE.SRI.COM。 (870407; 連続の1800;は、30分600毎; 10分604800毎; 1週間86400後に期限が切れるのを再試行するのをリフレッシュします; 1時間のデフォルト)
SRI.COM. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
MX 10 KL.SRI.COM.
SRI.COM。 ナノ秒KL.SRI.COM。 ナノ秒STRIPE.SRI.COM。 Mx10KL.SRI.COM。
;SRI.COM hosts
; SRI.COMホスト
KL A 10.1.0.2
A 128.18.10.6
MX 10 KL.SRI.COM.
キロリットルA10.1.0.2A128.18.10.6Mx10KL.SRI.COM。
STRIPE A 10.4.0.2
STRIPE A 128.18.10.4
MX 10 STRIPE.SRI.COM.
128.18に10.4.0.2しまにしまをつけてください。.10 .4 Mx10STRIPE.SRI.COM。
NIC CNAME SRI-NIC.ARPA.
NIC CNAME様-NIC.ARPA。
Blackjack A 128.18.2.1
HINFO VAX-11/780 UNIX
WKS 128.18.2.1 TCP TELNET FTP
こん棒は128.18.2.1HINFOバックス-11/780UNIX WKS128.18.2.1TCP telnet FTPです。
CSL A 192.12.33.2
HINFO FOONLY-F4 TOPS20
WKS 192.12.33.2 TCP TELNET FTP SMTP FINGER
MX 10 CSL.SRI.COM.
CSL A192.12.33.2HINFO FOONLY-F4 TOPS20 WKS192.12.33.2TCP telnet FTP SMTPはMx10CSL.SRI.COMを弄ります。
Lottor [Page 16] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[16ページ]RFC1033ドメイン
[File "CSL.ZONE"]
[ファイル"CSL.ZONE"]
CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (
870330 ;serial
1800 ;refresh every 30 minutes
600 ;retry every 10 minutes
604800 ;expire after a week
86400 ;default of a day
)
CSL.SRI.COM。 SOA KL.SRI.COMで。 DLE.STRIPE.SRI.COM。 (870330; 連続の1800;は、30分600毎; 10分604800毎; 1週間86400後に期限が切れるのを再試行するのをリフレッシュします; 1日のデフォルト)
CSL.SRI.COM. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
A 192.12.33.2
CSL.SRI.COM。 ナノ秒KL.SRI.COM。 ナノ秒STRIPE.SRI.COM。 A192.12.33、.2
;CSL.SRI.COM hosts
; CSL.SRI.COMホスト
A CNAME CSL.SRI.COM.
B A 192.12.33.3
HINFO FOONLY-F4 TOPS20
WKS 192.12.33.3 TCP TELNET FTP SMTP
GW A 10.2.0.2
A 192.12.33.1
A 128.18.1.1
HINFO PDP-11/23 MOS
SMELLY A 192.12.33.4
HINFO IMAGEN IMAGEN
SQUIRREL A 192.12.33.5
HINFO XEROX-1100 INTERLISP
VENUS A 192.12.33.7
HINFO SYMBOLICS-3600 LISPM
HELIUM A 192.12.33.30
HINFO SUN-3/160 UNIX
ARGON A 192.12.33.31
HINFO SUN-3/75 UNIX
RADON A 192.12.33.32
HINFO SUN-3/75 UNIX
CNAME CSL.SRI.COM。 B A192.12.33.3HINFO FOONLY-F4 TOPS20 WKS192.12.33.3TCP telnet FTP SMTP GW A10.2.0.2A192.12.33.1A128.18.1.1HINFO PDP-11/23のモスの臭いの悪いA192.12.33.4HINFO IMAGEN IMAGENリスのA192.12.33.5HINFOゼロックス-1100INTERLISPビーナスA192.12.33.7HINFO信条学-3600LISPMヘリウムA192.12.33.30HINFO Sun-3/160UNIXアルゴンA192.12.33.31HINFO Sun-3/75UNIXラドンA192.12.33.32HINFO Sun-3/75UNIX
Lottor [Page 17] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[17ページ]RFC1033ドメイン
[File "ISTC.ZONE"]
[ファイル"ISTC.ZONE"]
ISTC.SRI.COM. IN SOA KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. (
870406 ;serial
1800 ;refresh every 30 minutes
600 ;retry every 10 minutes
604800 ;expire after a week
86400 ;default of a day
)
ISTC.SRI.COM。 SOA KL.SRI.COM roemers.JOYCE.ISTC.SRI.COMで。 (870406; 連続の1800;は、30分600毎; 10分604800毎; 1週間86400後に期限が切れるのを再試行するのをリフレッシュします; 1日のデフォルト)
ISTC.SRI.COM. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
MX 10 SPAM.ISTC.SRI.COM.
ISTC.SRI.COM。 ナノ秒KL.SRI.COM。 ナノ秒STRIPE.SRI.COM。 Mx10SPAM.ISTC.SRI.COM。
; ISTC hosts
; ISTCホスト
joyce A 128.18.4.2
HINFO VAX-11/750 UNIX
bozo A 128.18.0.6
HINFO SUN UNIX
sundae A 128.18.0.11
HINFO SUN UNIX
tsca A 128.18.0.201
A 10.3.0.2
HINFO VAX-11/750 UNIX
MX 10 TSCA.ISTC.SRI.COM.
tsc CNAME tsca
prmh A 128.18.0.203
A 10.2.0.51
HINFO PDP-11/44 UNIX
spam A 128.18.4.3
A 10.2.0.107
HINFO VAX-11/780 UNIX
MX 10 SPAM.ISTC.SRI.COM.
joyce A128.18.4.2HINFO VAX-11/750UNIXアホA128.18.0.6HINFO SUN UNIXサンデーA128.18.0.11HINFO SUN UNIX tsca A128.18.0.201A10.3.0.2HINFO VAX-11/750UNIX Mx10TSCA.ISTC.SRI.COM. tsc CNAME tsca prmh A128.18.0.203A10.2.0.51HINFO PDP-11/44 UNIXスパムA128.18.4.3A10.2.0.107HINFO VAX-11/780UNIX Mx10SPAM.ISTC.SRI.COM。
Lottor [Page 18] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[18ページ]RFC1033ドメイン
[File "SRINET.ZONE"]
[ファイル"SRINET.ZONE"]
18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. (
870406 ;serial
1800 ;refresh every 30 minutes
600 ;retry every 10 minutes
604800 ;expire after a week
86400 ;default of a day
)
ADDR.ARPAの18.128.。 SOA KL.SRI.COM DLE.STRIPE.SRI.COMで。 (870406; 連続の1800;は、30分600毎; 10分604800毎; 1週間86400後に期限が切れるのを再試行するのをリフレッシュします; 1日のデフォルト)
18.128.IN-ADDR.ARPA. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
PTR GW.CSL.SRI.COM.
ADDR.ARPAの18.128.。 ナノ秒KL.SRI.COM。 ナノ秒STRIPE.SRI.COM。 PTR GW.CSL.SRI.COM。
; SRINET [128.18.0.0] Address Translations
; SRINET、[128.18の.0.0]アドレス変換
; SRI.COM Hosts 1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM.
; SRI.COMは1.2.18.128.IN-ADDR.ARPAを接待します。 PTR Blackjack.SRI.COM。
; ISTC.SRI.COM Hosts 2.4.18.128.IN-ADDR.ARPA. PTR joyce.ISTC.SRI.COM. 6.0.18.128.IN-ADDR.ARPA. PTR bozo.ISTC.SRI.COM. 11.0.18.128.IN-ADDR.ARPA. PTR sundae.ISTC.SRI.COM. 201.0.18.128.IN-ADDR.ARPA. PTR tsca.ISTC.SRI.COM. 203.0.18.128.IN-ADDR.ARPA. PTR prmh.ISTC.SRI.COM. 3.4.18.128.IN-ADDR.ARPA. PTR spam.ISTC.SRI.COM.
; ISTC.SRI.COMは2.4.18.128.IN-ADDR.ARPAを接待します。 PTR joyce.ISTC.SRI.COM。 ADDR.ARPAの6.0.18.128.。 PTR bozo.ISTC.SRI.COM。 ADDR.ARPAの11.0.18.128.。 PTR sundae.ISTC.SRI.COM。 ADDR.ARPAの201.0.18.128.。 PTR tsca.ISTC.SRI.COM。 ADDR.ARPAの203.0.18.128.。 PTR prmh.ISTC.SRI.COM。 ADDR.ARPAの3.4.18.128.。 PTR spam.ISTC.SRI.COM。
; CSL.SRI.COM Hosts 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
; CSL.SRI.COMは1.1.18.128.IN-ADDR.ARPAを接待します。 PTR GW.CSL.SRI.COM。
Lottor [Page 19] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[19ページ]RFC1033ドメイン
[File "SRI-CSL-NET.ZONE"]
[ファイル「様-CSL-NET.ZONE」]
33.12.192.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. (
870404 ;serial
1800 ;refresh every 30 minutes
600 ;retry every 10 minutes
604800 ;expire after a week
86400 ;default of a day
)
ADDR.ARPAの33.12.192.。 SOA KL.SRI.COM DLE.STRIPE.SRI.COMで。 (870404; 連続の1800;は、30分600毎; 10分604800毎; 1週間86400後に期限が切れるのを再試行するのをリフレッシュします; 1日のデフォルト)
33.12.192.IN-ADDR.ARPA. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
PTR GW.CSL.SRI.COM.
ADDR.ARPAの33.12.192.。 ナノ秒KL.SRI.COM。 ナノ秒STRIPE.SRI.COM。 PTR GW.CSL.SRI.COM。
; SRI-CSL-NET [192.12.33.0] Address Translations
; 様のCSLネット、[192.12の.33.0]アドレス変換
; SRI.COM Hosts 2.33.12.192.IN-ADDR.ARPA. PTR CSL.SRI.COM.
; SRI.COMは2.33.12.192.IN-ADDR.ARPAを接待します。 PTR CSL.SRI.COM。
; CSL.SRI.COM Hosts 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 3.33.12.192.IN-ADDR.ARPA. PTR B.CSL.SRI.COM. 4.33.12.192.IN-ADDR.ARPA. PTR SMELLY.CSL.SRI.COM. 5.33.12.192.IN-ADDR.ARPA. PTR SQUIRREL.CSL.SRI.COM. 7.33.12.192.IN-ADDR.ARPA. PTR VENUS.CSL.SRI.COM. 30.33.12.192.IN-ADDR.ARPA. PTR HELIUM.CSL.SRI.COM. 31.33.12.192.IN-ADDR.ARPA. PTR ARGON.CSL.SRI.COM. 32.33.12.192.IN-ADDR.ARPA. PTR RADON.CSL.SRI.COM.
; CSL.SRI.COMは1.33.12.192.IN-ADDR.ARPAを接待します。 PTR GW.CSL.SRI.COM。 ADDR.ARPAの3.33.12.192.。 PTR B.CSL.SRI.COM。 ADDR.ARPAの4.33.12.192.。 PTR SMELLY.CSL.SRI.COM。 ADDR.ARPAの5.33.12.192.。 PTR SQUIRREL.CSL.SRI.COM。 ADDR.ARPAの7.33.12.192.。 PTR VENUS.CSL.SRI.COM。 ADDR.ARPAの30.33.12.192.。 PTR HELIUM.CSL.SRI.COM。 ADDR.ARPAの31.33.12.192.。 PTR ARGON.CSL.SRI.COM。 ADDR.ARPAの32.33.12.192.。 PTR RADON.CSL.SRI.COM。
Lottor [Page 20] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[20ページ]RFC1033ドメイン
APPENDIX
付録
BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD UNIX
4.3BSD UNIXと共に分配されたBIND(バークレーインターネットName Domainサーバ)
This section describes two BIND implementation specific files; the boot file and the cache file. BIND has other options, files, and specifications that are not described here. See the Name Server Operations Guide for BIND for details.
このセクションは2個のBINDの実装の特定のファイルについて説明します。 ブート・ファイルとキャッシュはファイルされます。 BINDには、ここで説明されない別の選択肢、ファイル、および仕様があります。 BINDに関して詳細に関してName Server Operationsガイドを見てください。
The boot file for BIND is usually called "named.boot". This corresponds to file "CONFIG.CMD" in the example section.
通常、BINDのためのブート・ファイルは"named.boot"と呼ばれます。 これは、例の部に"CONFIG.CMD"をファイルするために対応しています。
--------------------------------------------------------
cache . named.ca
primary SRI.COM SRI.ZONE
primary CSL.SRI.COM CSL.ZONE
primary ISTC.SRI.COM ISTC.ZONE
primary 18.128.IN-ADDR.ARPA SRINET.ZONE
primary 33.12.192.IN-ADDR.ARPA SRI-CSL-NET.ZONE
--------------------------------------------------------
-------------------------------------------------------- キャッシュプライマリプライマリnamed.caのプライマリISTC.SRI.COM ISTC.ZONEプライマリ18.128.IN-ADDR.ARPA SRINET.ZONEプライマリSRI.COM SRI.ZONE CSL.SRI.COM CSL.ZONE33.12.192.IN-ADDR.ARPA SRI-CSL-NET.ZONE--------------------------------------------------------
The cache file for BIND is usually called "named.ca". This corresponds to file "ROOT.SERVERS" in the example section.
通常、BINDのためのキャッシュファイルは"named.ca"と呼ばれます。 これは、例の部に「ROOT.SERVERS」をファイルするために対応しています。
-------------------------------------------------
;list of possible root servers
. 1 IN NS SRI-NIC.ARPA.
NS C.ISI.EDU.
NS BRL-AOS.ARPA.
NS C.ISI.EDU.
;and their addresses
SRI-NIC.ARPA. A 10.0.0.51
A 26.0.0.73
C.ISI.EDU. A 10.0.0.52
BRL-AOS.ARPA. A 192.5.25.82
A 192.5.22.82
A 128.20.1.2
A.ISI.EDU. A 26.3.0.103
-------------------------------------------------
------------------------------------------------- ; 可能なルートサーバー. 1IN NS SRI-NIC.ARPAのリスト。 ナノ秒C.ISI.EDU。 ナノ秒BRL-AOS.ARPA。 ナノ秒C.ISI.EDU。 ; それらのアドレスSRI-NIC.ARPA。 A10.0.0.51A26.0.0.73C.ISI.EDU。 10.0 .0 .52 BRL-AOS.ARPA。 A192.5.25.82A192.5.22.82A128.20.1.2A.ISI.EDU。 A26.3.0、.103-------------------------------------------------
Lottor [Page 21] RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
操作が1987年11月に誘導するLottor[21ページ]RFC1033ドメイン
REFERENCES
参照
[1] Dunlap, K., "Name Server Operations Guide for BIND", CSRG,
Department of Electrical Engineering and Computer Sciences,
University of California, Berkeley, California.
[1] ダンラップとK.と「操作がひものために誘導するネームサーバ」とCSRGと電気工学の部とカリフォルニア大学バークレイ校コンピューターサイエンシズ(カリフォルニア)。
[2] Partridge, C., "Mail Routing and the Domain System", RFC-974,
CSNET CIC BBN Laboratories, January 1986.
[2] ヤマウズラ、C.が「ルート設定とドメインシステムを郵送する」、RFC-974、CSNET CIC BBN研究所、1月1986
[3] Mockapetris, P., "Domains Names - Concepts and Facilities",
RFC-1034, USC/Information Sciences Institute, November 1987.
[3]Mockapetris、P.、「ドメイン名--、概念と施設、」、RFC-1034、科学が設けるUSC/情報、11月1987日
[4] Mockapetris, P., "Domain Names - Implementations Specification",
RFC-1035, USC/Information Sciences Institute, November 1987.
[4]Mockapetris、P.、「ドメイン名--実装、仕様、」、RFC-1035、科学が設けるUSC/情報、11月1987日
Lottor [Page 22]
Lottor[22ページ]
一覧
スポンサーリンク
