RFC1480 日本語訳
1480 The US Domain. A. Cooper, J. Postel. June 1993. (Format: TXT=100556 bytes) (Obsoletes RFC1386) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Cooper Request for Comments: 1480 J. Postel Obsoletes: 1386 June 1993
コメントを求めるワーキンググループA.桶屋要求をネットワークでつないでください: 1480 J.ポステルは以下を時代遅れにします。 1386 1993年6月
The US Domain
米国ドメイン
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction ................................................ 2
1.1 The Internet Domain Name System......................... 2
1.2 Top-Level Domains....................................... 3
1.3 The US Domain .......................................... 4
2. Naming Structure ............................................ 4
2.1 State Codes ............................................ 8
2.2 Locality Names.......................................... 8
2.3 Schools ................................................ 10
2.4 State Agencies.......................................... 15
2.5 Federal Agencies ....................................... 15
2.6 Distributed National Institutes......................... 15
2.7 General Independent Entities............................ 16
2.8 Examples of Names....................................... 17
3. Registration ................................................ 20
3.1 Requirements ........................................... 20
3.2 Direct Entries ......................................... 21
3.2.1 IP-Hosts............................................. 21
3.2.2 Non-IP Hosts ........................................ 21
3.3 Delegated Subdomains ................................... 24
3.3.1 Delegation Requirement............................... 26
3.3.2 Delegation Procedures ............................... 28
3.3.3 Subdomain Contacts................................... 29
4. Database Information......................................... 30
4.1 Name Servers ........................................... 30
4.2 Zone files ............................................. 30
4.3 Resource Records ....................................... 31
4.3.1 "A" Records ......................................... 32
4.3.2 CNAME Records ....................................... 32
4.3.3 MX Records .......................................... 33
4.3.4 HINFO Records ....................................... 33
4.3.5 PTR Records ......................................... 33
4.4 Wildcards .............................................. 34
5. References .................................................. 35
1. 序論… 2 1.1 インターネットドメインネームシステム… 2 1.2の最上位のドメイン… 3 1.3 米国ドメイン… 4 2. 構造を命名します… 4 2.1 コードを述べてください… 8 2.2 場所名… 8 2.3 群がります… 10 2.4の州機関… 15 2.5の連邦機関… 15 2.6 国家の研究所を分配します… 15 2.7 一般独立実体… 16 名前に関する2.8の例… 17 3. 登録… 20 3.1の要件… 20 3.2 エントリーを指示してください… 21 3.2 .1 IP-ホスト… 21 3.2 .2 非IPホスト… 21 3.3はサブドメインを代表として派遣しました… 24 3.3 .1代表団要件… 26 3.3 .2 代表団手順… 28 3.3 .3 サブドメイン接触… 29 4. データベース情報… 30 4.1のネームサーバ… 30 4.2ゾーンはファイルされます… 30 4.3 リソース記録… 31 4.3 .1 記録… 32 4.3 .2 CNAMEは記録します… 32 4.3 .3 MXは記録します… 33 4.3 .4 HINFOは記録します… 33 4.3 .5 PTRは記録します… 33 4.4個のワイルドカード… 34 5. 参照… 35
Cooper & Postel [Page 1] RFC 1480 The US Domain June 1993
クーパーとポステル[1ページ]RFC1480米国ドメイン1993年6月
6. Security Considerations ..................................... 35 7. Authors' Addresses .......................................... 36 Appendix-I: US Domain Names BNF................................. 37 Appendix-II: US Domain Questionnaire ............................ 42
6. セキュリティ問題… 35 7. 作者のアドレス… 36、付録I: 米国ドメイン名BNF… 37、付録II: 米国のドメインアンケート… 42
1. INTRODUCTION
1. 序論
1.1 The Internet Domain Name System
1.1 インターネットドメインネームシステム
The Domain Name System (DNS) provides for the translation between hostnames and addresses. Within the Internet, this means translating from a name such as "venera.isi.edu", to an IP address such as "128.9.0.32". The DNS is a set of protocols and databases. The protocols define the syntax and semantics for a query language to ask questions about information located by DNS-style names. The databases are distributed and replicated. There is no dependence on a single central server, and each part of the database is provided in at least two servers.
ドメインネームシステム(DNS)はホスト名とアドレスの間の翻訳に備えます。 インターネットの中では、これが、"venera.isi.edu"などの名前からIPアドレスまで翻訳することを意味する、「128.9 .0 0.32インチ」 DNSは1セットのプロトコルとデータベースです。 照会言語がDNS-スタイル名によって見つけられた情報に関して質問するように、プロトコルは構文と意味論を定義します。 データベースは、分配されて、模写されます。 ただ一つのセントラルサーバーへの依存が全くありません、そして、データベースの各部分を少なくとも2つのサーバに提供します。
The assignment of the 32-bit IP addresses is a separate activity. IP addresses are delegated by the central Internet Registry to regional authorities (such as the RIPE NCC for Europe) and the network providers.
32ビットのIPアドレスの課題は別々の活動です。 IPアドレスは中央のインターネットRegistryによって地方分権(ヨーロッパへのRIPE NCCなどの)とネットワーク内の提供者へ代表として派遣されます。
To have a network number assigned please contact your network service provider or regional registration authority. To determine who this is (or as a last resort), you can contact the central Internet Registry at Hostmaster@INTERNIC.NET.
ネットワーク・ナンバーを割り当てさせるには、ネットワークサービスプロバイダーか地方の登録局に連絡してください。 これがだれ(最後の手段として)であるかを決定するために、あなたは中央のインターネットRegistryに Hostmaster@INTERNIC.NET へ連絡できます。
In addition to translating names to addresses for hosts that are on the Internet, the DNS provides for registering DNS-style names for other hosts reachable (via electronic mail) through gateways or mail relays. The records for such name registrations point to an Internet host (one with an IP address) that acts as a mail forwarder for the registered host. For example, the host "bah.rochester.ny.us" is registered in the DNS with a pointer to the mail relay "relay1.uu.net". This type of pointer is called an MX record.
インターネットにいるホストのために名前をアドレスに翻訳することに加えて、DNSはゲートウェイを通して他のホストにとって、届いているDNS-スタイル名(電子メールを通した)を登録するか、メール中継に備えます。 そのような名前登録証明書のための記録は登録されたホストのためのメール混載業者として務めるインターネット・ホスト(IPアドレスがある1)を示します。 例えば、ホスト"bah.rochester.ny.us"はDNSにメール中継への"relay1.uu.net"というポインタに登録されます。 このタイプのポインタはMX記録と呼ばれます。
This gives electronic mail users a uniform mail addressing syntax and avoids making users aware of the underlying network boundaries.
これは、一定のメールアドレシング構文を電子メールユーザに与えて、ユーザを基本的なネットワーク限界を意識するようにするのを避けます。
The reason for the development of the domain system was growth in the Internet. The hostname to address mappings were maintained by the InterNIC in a single file, called HOSTS.TXT, which was FTP'd by all the hosts on the Internet. The network population was changing in character. The time-share hosts that made up the original ARPANET were being replaced with local networks of workstations. Local organizations were administering their own names and addresses, but
ドメインシステムの開発の理由はインターネットでの成長でした。 HOSTS.TXTは、アドレス・マッピングへのホスト名が一列でInterNICによって維持されたと呼んで、どれがFTPであったかはインターネットのすべてのホストでそうするでしょう。 ネットワーク人口はぴったりした変化しました。 それが存在をワークステーションの企業内情報通信網に取り替えたならオリジナルのアルパネットにしたホストを時分割してください。 しかし、地方の組織はそれら自身の名前とアドレスを管理していました。
Cooper & Postel [Page 2] RFC 1480 The US Domain June 1993
クーパーとポステル[2ページ]RFC1480米国ドメイン1993年6月
had to wait for the NIC to make changes in HOSTS.TXT to make the changes visible to the Internet at large. Organizations also wanted some local structure on the name space. The applications on the Internet were getting more sophisticated and creating a need for general purpose name service. The idea of a hierarchical name space, with the hierarchy roughly corresponding to organizational structure, and names using "." as the character to mark the boundary between hierarchy levels was developed. A design using a distributed database and generalized resources was implemented.
NICが変更を全体のインターネットに目に見えるようにするようにHOSTS.TXTの変更を行うのを待たなければなりませんでした。 また、組織はスペースという名前の何らかのローカルの構造が欲しかったです。 インターネットにおけるアプリケーションは、より洗練されるようになって、汎用の名前サービスの必要性を作成しています。 「階層構造がおよそ組織体制に対応している、名前が使用されている階層的な名前スペースの考え」、」 マークするキャラクタとして、階層構造レベルの間の境界は開発されました。 分散データベースと一般化されたリソースを使用するデザインは実行されました。
The DNS provides standard formats for resource data, standard methods for querying the database, and standard methods for name servers to refresh local data from other name servers.
DNSはリソースデータのための標準書式、データベースについて質問するための標準方法、およびネームサーバが他のネームサーバからのローカルのデータをリフレッシュする標準方法を提供します。
1.2 Top-Level Domains
1.2 最上位のドメイン
The top-level domains in the DNS are EDU, COM, GOV, MIL, ORG, INT, and NET, and all the 2-letter country codes from the list of countries in ISO-3166. The establishment of new top-level domains is managed by the Internet Assigned Numbers Authority (IANA). The IANA may be contacted at IANA@ISI.EDU.
DNSの最上位のドメインは、EDUと、COMと、GOVと、MILと、ORGと、INTと、NETと、すべて、ISO-3166の国のリストからの2文字の国名略号です。 新しい最上位のドメインの確立はインターネットAssigned民数記Authority(IANA)によって管理されます。 IANAは IANA@ISI.EDU へ連絡されるかもしれません。
Even though the original intention was that any educational institution anywhere in the world could be registered under the EDU domain, in practice, it has turned out with few exceptions, only those in the United States have registered under EDU, similarly with COM (for commercial). In other countries, everything is registered under the 2-letter country code, often with some subdivision. For example, in Korea (KR) the second level names are AC for academic community, CO for commercial, GO for government, and RE for research. However, each country may go its own way about organizing its domain, and many have.
オリジナルの意志はEDUドメインの下で世界でどこでもどんな学園も登録できたということでしたが、実際には、合衆国のものだけにEDUの下に同様にCOM(コマーシャルのための)に登録されたと判明しました。 他国では、すべてが2文字の国名略号の下でしばしば何らかの下位区分に登録されます。 例えば、韓国(KR)では、2番目の平らな名前が学界、コマーシャルのためのCO、政府のためのGO、および調査のためのREのための西暦です。 しかしながら、各国はドメインを組織化しながら、それ自身の道に取り組むかもしれません、そして、多くは取り組みました。
There are no current plans of putting all of the organizational domains EDU, GOV, COM, etc., under US. These name tokens are not used in the US Domain to avoid confusion.
組織的なドメインEDU、GOV、COMなどのすべてを米国の下に置くどんな現在のプランもありません。 これらの名前象徴は、混乱を避けるのに米国Domainで使用されません。
Currently, only four year colleges and universities are being registered in the EDU domain. All other schools are being registered in the US Domain.
現在、ほんの4年間の大学と大学はEDUドメインに登録されています。 他のすべての学校が米国Domainに登録されています。
There are also concerns about the size of the other top-level domains (especially COM) and ideas are being considered for restructuring.
再構築する他の最上位のドメイン(特にCOM)とおよそ考えのサイズが考えることにされるのである関心もあります。
Other names sometimes appear as top-level domain names. Some people have made up names in the DNS-style without coordinating or registering with the DNS management. Some names that typically appear are BITNET, UUCP, and two-letter codes for continents, such as
他の名前は最上位のドメイン名として時々現れます。 人々の中にはDNS管理と調整するか、またはともに記名しないでDNS-スタイルで名前を作った人もいました。 通常現れるいくつかの名前がUUCPと、大陸のための2レター・コードの、そして、そのようなBitnetです。
Cooper & Postel [Page 3] RFC 1480 The US Domain June 1993
クーパーとポステル[3ページ]RFC1480米国ドメイン1993年6月
"NA" for North America (this conflicts with the official Internet code for Namibia).
北アメリカ(これは公式のインターネットコードとナミビアに衝突する)への"NA"。
For example, the DNS-style name "KA7EEJ.CO.USA.NA" is used in the amateur radio network. These addresses are never supposed to show up on the Internet but they do occasionally. The amateur radio network people created their own naming scheme, and it interferes sometimes with Internet addresses.
例えば、"KA7EEJ.CO. USA.NA"というDNS-スタイル名はアマチュア無線ネットワークに使用されます。 これらのアドレスはインターネットに決して現れるべきではありませんが、それらは時折します。 アマチュア無線ネットワークの人々はそれら自身の命名計画を作成しました、そして、それは時々インターネット・アドレスを妨げます。
1.3 The US Domain
1.3 米国ドメイン
The US Domain is an official top-level domain in the DNS of the Internet community. The domain administrators are Jon Postel and Ann Westine Cooper at the Information Sciences Institute of the University of Southern California (USC-ISI).
米国DomainはインターネットコミュニティのDNSの公式の最上位のドメインです。 ドメイン管理者は、南カリフォルニア(USC-ISI)大学の情報Sciences Instituteのジョン・ポステルとアン・Westineクーパーです。
US is the ISO-3166 2-letter country code for the United States and thus the US Domain is established as a top-level domain and registered with the InterNIC the same way other country domains are.
米国が合衆国へのISO-3166の2文字の国名略号であり、その結果、米国Domainは他の国のドメインがある同じように最上位のドメインとして設立されて、InterNICに登録されます。
Because organizations in the United States have registered primarily in the EDU and COM domains, little use was initially made of the US domain. In the past, the computers registered in the US Domain were primarily owned by small companies or individuals with computers at home. However, the US Domain has grown and currently registers hosts in federal government agencies, state government agencies, K12 schools, community colleges, technical/vocational schools, private schools, libraries, city and county government agencies, to name a few.
合衆国での組織が主としてEDUとCOMドメインに登録されたので、初めは、米国ドメインで使用をほとんどしませんでした。 過去に、コンピュータが家にある状態で、米国Domainに登録されたコンピュータは小会社か個人によって主として所有されていました。 しかしながら、米国Domainは、成長して、現在、いくつかを命名するために連邦政府代理店、州の政府機関、K12学校、コミュニティカレッジ、技術的であるか職業上の学校、私立学校、ライブラリ、都市、およびカウンティーの政府機関でホストを登録します。
Initially, the administration of the US Domain was managed solely by the Domain Registrar. However, due to the increase in registrations, administration of subdomains is being delegated to others.
初めは、米国Domainの管理は唯一Domain Registrarによって経営されました。 しかしながら、登録証明書の増加のため、サブドメインの管理を他のものへ代表として派遣しています。
Any computer in the United States may be registered in the US Domain.
合衆国のどんなコンピュータも米国Domainに登録されるかもしれません。
2. NAMING STRUCTURE
2. 構造を命名します。
The US Domain hierarchy is based on political geography. The basic name space under US is the state name space, then the "locality" name space, (like a city, or county) then organization or computer name and so on.
米国Domain階層構造は政治地理学に基づいています。 米国の下の基本的な名前スペースがスペースという州の名であり、次に、「場所」名は、(都市、またはカウンティーのような)のスペースか次に、組織かコンピュータ名などです。
For example:
例えば:
BERKELEY.CA.US
PORTLAND.WA.US
BERKELEY.CA.US PORTLAND.WA.US
Cooper & Postel [Page 4] RFC 1480 The US Domain June 1993
クーパーとポステル[4ページ]RFC1480米国ドメイン1993年6月
There is of course no problem with running out of names.
もちろん、名前を使い果たすことに関する問題が全くありません。
The things that are named are individual computers.
命名されることは個々のコンピュータです。
If you register now in one city and then move, the database can be updated with a new name in your new city, and a pointer can be set up from your old name to your new name. This type of pointer is called a CNAME record.
あなたが今、1つの都市に登録して、次に、移るなら、新しい名前があなたの新しい都市にある状態で、データベースをアップデートできます、そして、あなたの旧名から新しいあなたの名前までポインタをセットアップできます。 このタイプのポインタはCNAME記録と呼ばれます。
The use of unregistered names is not effective and causes problems for other users. Inventing your own name and using it without registering is not a good idea.
登録されていない名前の使用は、有効でなく、他のユーザのために問題を起こします。 あなた自身の名前を発明して、登録しないでそれを使用するのは、名案ではありません。
In addition to strictly geographically names, some special names are used, such as FED, STATE, AGENCY, DISTRICT, K12, LIB, CC, CITY, and COUNTY. Several new name spaces have been created, DNI, GEN, and TEC, and a minor change under the "locality" name space was made to the existing CITY and COUNTY subdomains by abbreviating them to CI and CO. A detailed description follows.
に加えて名前であり厳密に、地理的に、いくつかの特別な名前が使用されています、連邦政府や、州や、AGENCYや、DISTRICTや、K12や、LIBや、CCや、市や、カウンティーなどのように。 いくつかの新しい名前空間を作成してあります、とそれらをCIに簡略化することによって、スペースという「場所」名の下におけるDNI、GEN、TEC、およびマイナーチェンジを既存の市とカウンティーのサブドメインにして、CO詳述は続きます。
Below US, Parallel to States: -----------------------------
米国の下では、州に以下に沿ってください。 -----------------------------
"FED" - This branch may be used for agencies of the federal government. For example: <org-name>.<city>.FED.US
"FED"--このブランチは連邦政府の政府機関に使用されるかもしれません。 例えば: <組織名><都市の>.FED.US
"DNI" - DISTRIBUTED NATIONAL INSTITUTES - The "DNI" branch was created directly under the top-level US. This branch is to be used for distributed national institutes; organizations that span state, regional, and other organizational boundaries; that are national in scope, and have distributed facilities. For example: <org-name>.DNI.US.
"DNI"--DISTRIBUTED NATIONAL INSTITUTES--"DNI"ブランチはトップレベルの米国の直接下に創設されました。 このブランチは分配された国家の研究所に使用されることになっています。 状態にかかる組織、地方の、そして、他の組織境界。 それは、範囲で国家であり、施設を分配しました。 例えば: <組織名>.DNI.US。
Name Space Within States: ------------------------
州の中でスペースを命名してください: ------------------------
"locality" - cities, counties, parishes, and townships. Subdomains under the "locality" would be like CI.<city>.<state>.US, CO.<county>.<state>.US, or businesses. For example: Petville.Marvista.CA.US.
「場所」--都市、カウンティー、教区、および郡区。 「場所」の下におけるサブドメインは>CI<都市の<州の>.US、COに似ているでしょう。><カウンティーの<は>.US、またはビジネスを述べます。 例えば: Petville.Marvista.CA.US。
"CI" - This branch is used for city government agencies and is a subdomain under the "locality" name (like Los Angeles). For example: Fire-Dept.CI.Los-Angeles.CA.US.
"CI"--このブランチは、都市の政府機関に使用されて、「場所」名の下でサブドメイン(ロサンゼルスのように)です。 例えば: 炎部のCI.Los-Angeles.CA.US。
"CO" - This branch is used for county government agencies and is a subdomain under the "locality" name (like Los Angeles). For example: Fire-Dept.CO.San-Diego.CA.US.
「CO」--このブランチは、カウンティーの政府機関に使用されて、「場所」名の下でサブドメイン(ロサンゼルスのように)です。 例えば: 炎部のCO.San-Diego.CA.US。
Cooper & Postel [Page 5] RFC 1480 The US Domain June 1993
クーパーとポステル[5ページ]RFC1480米国ドメイン1993年6月
"K12" - This branch may be used for public school districts. A special name "PVT" can be used in the place of a school district name for private schools. For example: <school-name>.K12.<state>.US and <school-name>.PVT.K12.<state>.US.
「K12"--このブランチは公立の学校地区に使用されるかもしれません。」 私立学校に学区名の場所で特別な名前"PVT"を使用できます。 例えば: <学校名の>.K12.<州の>.USと<学校名の>.PVT.K12.<は>.USを述べます。
"CC" - COMMUNITY COLLEGES - This branch was established for all state wide community colleges. For example: <school-name>.CC.<state>.US.
「CC」--COMMUNITY COLLEGES--この支店はすべての州の広いコミュニティカレッジのために開設されました。 例えば: <学校名の>.CC.<州の>.US。
"TEC" - TECHNICAL AND VOCATIONAL SCHOOLS - The branch "TEC" was established for technical and vocational schools and colleges. For example: <school-name>.TEC.<state>.US.
「テック」--TECHNICALとVOCATIONAL学校--ブランチ「テック」は技術的で職業上の学校と大学に設立されました。 例えば: <学校名の>.TEC.<州の>.US。
"LIB" - LIBRARIES (STATE, REGIONAL, CITY, COUNTY) - This branch may be used for libraries only. For example: <lib-name>.LIB.<state>.US.
"LIB"--図書館(州、REGIONAL、市、カウンティー)--このブランチはライブラリだけに使用されるかもしれません。 例えば: <リブ名の>.LIB.<州の>.US。
"STATE" - This branch may be used for state government agencies. For example: <org-name>.STATE.<state>.US.
「州」--このブランチは州の政府機関に使用されるかもしれません。 例えば: <組織名>.STATE.<州の>.US。
"GEN" - GENERAL INDEPENDENT ENTITY - This branch is for the things that don't fit easily into any other structure listed -- things that might fit in to something like ORG at the top-level. It is best not to use the same keywords (ORG, EDU, COM, etc.) that are used at the top-level to avoid confusion. GEN would be used for such things as, state-wide organizations, clubs, or domain parks. For example: <org-name>.GEN.<state-code>.US.
"GEN"--GENERAL INDEPENDENT ENTITY--このブランチは容易に記載されたいかなる他の構造にも収まらないもののためのものです--何かトップレベルにおけるORGのようなものに適合するかもしれないもの。 混乱を避けるのにトップレベルに使用されるのと同じキーワード(ORG、EDU、COMなど)を使用しないのは最も良いです。 州全体の組織、クラブ、またはドメインが駐車するので、GENはそのようなものに使用されるでしょう。 例えば: <組織名>.GEN.<州コード>.US。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
VIEW OF SECOND LEVEL DOMAINS UNDER US
米国の下のセカンドレベルドメインの視点
+-------+
| US |
+-------+
|
+----------------------------------+
| | | | |
+-----+ +-----+ +-----+ +-----+ +-----+
| FED | | DNI | | TX | | SD | | CA |
+-----+ +-----+ +-----+ +-----+ +-----+
+-------+ | 米国| +-------+ | +----------------------------------+ | | | | | +-----+ +-----+ +-----+ +-----+ +-----+ | 食べます。| | DNI| | テキサス| | サウスダコタ| | カリフォルニア| +-----+ +-----+ +-----+ +-----+ +-----+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Cooper & Postel [Page 6] RFC 1480 The US Domain June 1993
クーパーとポステル[6ページ]RFC1480米国ドメイン1993年6月
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
SCHOOL AND LIBRARY VIEW
+-----+
| CA |
+-----+
|
+------------------------------------------------+
| | | | |
+-----+ +-----+ +-----+ +-------------+ +-----+
| K12 | | CC | | TEC | | LOS ANGELES | | LIB |
+-----+ +-----+ +-----+ +-------------+ +-----+
/ \ /|\ /|\ /|\ /|\
+--------+ +---+ +---+ +--------+ +----------+ +------+
|sch dist| |PVT| |SJC| |WM TRADE| |pvt school| |MALIBU|
+--------+ +---+ +---+ +--------+ +----------+ +------+
/|\ /|\
+--------+ +--------+
|sch name| |sch name|
+--------+ +--------+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ SCHOOL AND LIBRARY VIEW +-----+ | カリフォルニア| +-----+ | +------------------------------------------------+ | | | | | +-----+ +-----+ +-----+ +-------------+ +-----+ | K12| | CC| | テック| | ロサンジェルス| | リブ| +-----+ +-----+ +-----+ +-------------+ +-----+ / \ /|\ /|\ /|\ /|\ +--------+ +---+ +---+ +--------+ +----------+ +------+ |sch dist| |PVT| |SJC| |WM貿易| |pvt学校| |マリブ| +--------+ +---+ +---+ +--------+ +----------+ +------+ /|\ /|\ +--------+ +--------+ |sch名| |sch名| +--------+ +--------+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
VIEW OF STATE, REGIONAL, and GENERAL AGENCIES
状態の視点、地方的、そして、一般的な政府機関
+-----+
| CA |
+-----+
|
+-------------------------+
| | |
+-------+ +--------+ +-----+
| STATE | |DISTRICT| | GEN |
+-------+ +--------+ +-----+
/|\ /|\ /|\
+--------+ +------+ +---------+
|CALTRANS| |SCAQMD| |domain pk|
---------+ +------+ +---------+
|
+--------+
|TCEW100E|
+--------+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+-----+ | カリフォルニア| +-----+ | +-------------------------+ | | | +-------+ +--------+ +-----+ | 状態| |地区| | 情報を得てください。| +-------+ +--------+ +-----+ /|\ /|\ /|\ +--------+ +------+ +---------+ |CALTRANS| |SCAQMD| |ドメインpk| ---------+ +------+ +---------+ | +--------+ |TCEW100E| +--------+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Cooper & Postel [Page 7] RFC 1480 The US Domain June 1993
クーパーとポステル[7ページ]RFC1480米国ドメイン1993年6月
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
VIEW OF LOCALITY
+-----+
| CA |
+-----+
|
+-----------------------------------+
| |
+-------------------------+ +----------------+
| LOS ANGELES | | SANTA MONICA |
+-------------------------+ +----------------+
/ | | /|\ | /|\
/ | | | | |
+---+ +--+ +--+ +-----------+ +--+ +---+
|bus| |CI| |CO| | pvt school| |CI| |bus|
+---+ +--+ +--+ +-----------+ +--+ +---+
/\ | |
/ \ | +------------+
/ \ | |HARBOR GUARD|
/ \ | +------------+
+-----+ +-----+ +-----+ +----+
|FIRE | |ADMIN| |PARKS| |FIRE|
+-----+ +-----+ +-----+ +----+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
場所+の視点-----+ | カリフォルニア| +-----+ | +-----------------------------------+ | | +-------------------------+ +----------------+ | ロサンジェルス| | サンタモニカ| +-------------------------+ +----------------+ / | | /|\ | /|\ / | | | | | +---+ +--+ +--+ +-----------+ +--+ +---+ |バス| |CI| |CO| | pvt学校| |CI| |バス| +---+ +--+ +--+ +-----------+ +--+ +---+ /\ | | / \ | +------------+ / \ | |港の警備| / \ | +------------+ +-----+ +-----+ +-----+ +----+ |炎| |アドミン| |公園| |炎| +-----+ +-----+ +-----+ +----+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2.1 State Codes
2.1 州のコード
The state codes are the two letter US Postal abbreviations. For example: "CA" California.
州のコードは2つの手紙米国Postal略語です。 例えば: 「カリフォルニア」カリフォルニア。
2.2 Locality Names
2.2 場所名
Within the state name space there are "locality" names, some may be cities, some may be counties, some may be local names, but not incorporated entities.
何かが都市であるかもしれない、何かがカウンティーであるかもしれない、スペースという州の名の中に、「場所」名があって、何かが法人組織の実体ではなく、地方名であるかもしれません。
Registered names under "locality" could be like:
「場所」の下における登録名は以下に似るかもしれません。
<hostname>.CI.<locality>.<state>.US ==> city gov't agency
<hostname>.CO.<locality>.<state>.US, ==> county gov't agency
<hostname>.<locality>.<state>.US ==> businesses
>>>>都市の政府政府機関<ホスト名>.CO.<><ホスト名>.CI.<場所<州の>.US=場所<州の>.US、=>カウンティー政府政府機関<ホスト名><場所<州の>.US=ビジネス
In the cases where the locality name is a county, there is a branch under the locality name, called "county" or "CO", that is used by the county government. Businesses are registered directly under the locality name.
「CO」、「カウンティー」が、場所名がカウンティーである場合には、ブランチが場所名の下にあると呼んだか、またはそれは郡政府によって使用されます。 ビジネスは場所名の直接下で登録されます。
Cooper & Postel [Page 8] RFC 1480 The US Domain June 1993
クーパーとポステル[8ページ]RFC1480米国ドメイン1993年6月
Under the city locality name space there is a "city" or "CI" branch for city government agencies. As usual, businesses and private schools may register directly under the city name.
スペースという都市の場所名の下では、「都市」があるか、または"CI"は都市の政府機関のために分岐します。 いつものように、ビジネスと私立学校は都市の名の直接下で登録されるかもしれません。
In the case where there is both a county and a city with the same locality name there is no problem, since the names will be unique with the "CO" or "CI" keyword. In our area the county has a fire department and the city has its own fire department. They could have names like:
同じ場所名があるカウンティーと都市の両方がある場合には、問題が全くありません、名前が「CO」か"CI"キーワードにユニークになるので。 私たちの領域では、カウンティーが消防署を持っています、そして、都市には、それ自身の消防署があります。 彼らには、名前が以下のようにあるかもしれません。
Fire-Dept.CI.Los-Angeles.CA.US
Fire-Dept.CO.Los-Angeles.CA.US
炎部のCI.Los-Angeles.CA.US炎部のCO.Los-Angeles.CA.US
Cities may be named (designated) by their full name (spelled out with hyphens replacing spaces (e.g., Los-Angeles or Fort-Collins), or by a city code. The first choice is the full city name. In some cases it may be appropriate to use the well-known city abbreviation known throughout a locality. However, it is very desirable that all users in the same city use the same designator for the city. That is, any particular locality should have just one DNS name.
都市はそれらのフルネームによって命名されるかもしれません(指定されます)。ハイフンがコード空間(例えば、ロサンゼルスかフォートコリンズ)、または都市のそばでの最初の選択を置き換えていて詳しく説明されているのは、完全な都市の名です。いくつかの場合、場所の間中知られていた周知の都市の略語を使用するのは適切であるかもしれません。(しかしながら、すなわち、どんな特定の場所にもちょうど1つのDNS名があるのは、非常に望ましいです。同じ都市のすべてのユーザが都市に同じ指示子を使用します。
Some users would like names associated with a greater metropolitan area or region like the "Bay Area" or "Tri-Cities". One problem with this is that these names are not necessarily unique within a state. The best thing to do in this case is to use the larger metropolitan city in your hostname. Cities and counties are used.
名前が「湾岸地区」や「3都市」のように大首都圏か領域に関連しているのが好きであるユーザもいるでしょう。 これに関する1つの問題はこれらの名前が必ず州の中でユニークであるというわけではないということです。 この場合する最も良いことはあなたのホスト名で、より大きい首都の都市を使用することです。 都市とカウンティーは使用されています。
Should all the names be obvious? Trying to do this is desirable and also impossible. There will come a point when the obviously right name for an organization is already taken. As the system grows this will happen with increasing frequency. While ease of use to the end user is desirable, a higher priority must be placed on having a system that operates. This means that the manageability of the system must have high consideration.
すべての名前が明白であるべきですか? これをしようとするのも望ましくて、また、不可能です。 組織のための明らかに正しい名前が既にかかるとき、ポイントは来るでしょう。 システムが成長するのに従って、これは増加する頻度で起こるでしょう。 エンドユーザへの使いやすさが望ましい間、作動するシステムを持っているのにより高い優先度を置かなければなりません。 これは、高い考慮がシステムの管理可能性になければならないことを意味します。
The reason the DNS was created was to subdivide the problem of maintaining a list of hosts in the Internet into manageable portions.
DNSが作成された理由はインターネットで処理しやすい部分にホストのリストを維持するという問題を細分することでした。
The happy result is that this subdivision makes name uniqueness easier and promotes logical grouping. What is a "logical grouping" though, always depends on the viewer.
満足な結果はこの下位区分が名前のユニークさをより簡単にして、論理的な組分けを促進するということです。 「論理的な組分け」であることはもっとも、そして、いつもビューアーに頼っています。
Many levels of delegation are needed to keep the zone files manageable. Many sections of the name space are needed to allow unique names to be easily added.
代表団の多くのレベルが、ゾーンファイルを処理しやすく保つのに必要です。 スペースという名前の多くのセクションが、ユニークな名前が容易に加えられるのを許容するのに必要です。
Cooper & Postel [Page 9] RFC 1480 The US Domain June 1993
クーパーとポステル[9ページ]RFC1480米国ドメイン1993年6月
Way back in the olden days, when the Internet was invented, some thought that an 8-bit network number would be more than enough to number all the networks that would ever exist. Today, there are over 10,000 networks operating in the Internet, and arguments are made about the doubling time being 2 years versus 4 years.
ずっとインターネットが発明されたときの或るものが8ビットのネットワーク・ナンバーが数に十二分であると思った昔の日に、かつてそうするすべてのネットワークが存在します。 今日、インターネットで作動する1万以上のネットワークがあります、そして、倍増時頃に2年である対4年によって議論をします。
One concern is that things will continue to grow dramatically, and this will require more subdivision of the domain name management. Maybe the plan for the US Domain is overkill on growth planning, but there has never been overplanning for growth yet.
1回の関心はいろいろなことが、劇的に成長し続けるということです、そして、これはドメイン名管理の、より多くの下位区分を必要とするでしょう。 多分、米国Domainのためのプランは成長計画での過剰殺傷ですが、成長のためにまだ過剰計画しているのが一度もありませんでした。
When things are bigger, names have to be longer. There is an argument that with only 8-character names, and in each position allow a-z, 0-9, and -, you get 37**8 = 3,512,479,453,921 or 3.5 trillion possible names. It is a great argument, but how many of us want names like "xs4gp-7q". It is like license plate numbers, sure some people get the name they want on a vanity plate, but a lot more people who want something specific on a vanity plate can't get it because someone else got it first. Structure and longer names also let more people get their "obviously right" name.
いろいろなことが、より大きいときに、名前は、より長くなければなりません。 -8キャラクタだけの名前、およびコネによる各位置がa-zを許容するという主張があります、0-9、あなたは37**8 = 3,512,479,453,921か3兆5000億の可能な名前を得ます。 それはかなりの議論ですが、私たちのいくつが"xs4gp-7q"のような名前を必要としますか? プレートナンバー、確実に何人かの人々が自分達が欲しい名前をバニティー・プレートに乗せますが、他の誰かが最初にそれを得たのでバニティー・プレートで特定のものが欲しいずっと多くの人々がそれを得ることができないようです。 また、構造と、より長い名前で、より多くの人々が彼らの「明らかに正しい」名前を得ることができます。
2.3 Schools
2.3 学校
K12 schools are connecting to the Internet and registering in the Internet DNS. A decision has been made by the IANA (after consultation with the new InterNIC Internet Registry and the Federal Networking Council (FNC)) to direct these school registrations to the US domain using the naming structure described here.
K12学校は、インターネットに接続して、インターネットDNSに登録することです。 決定がここで説明された命名構造を使用することでこれらの学校登録証明書を米国ドメインに向けるのがIANA(新しいInterNICインターネットRegistryと連邦ネットワーキング協議会(FNC)との相談の後の)によってされました。
There is a need for competent, experienced, volunteers to come forward to act as third and perhaps fourth level registries and to operate delegated portions of the DNS.
有能で、経験豊富なボランティアが3番目として機能して、恐らく4番目に登録を平らにして、DNSの代表として派遣された部分を操作するために進み出る必要があります。
There are two reasons for registering schools in the US Domain. (1) uniqueness of names, and (2) management of the database.
米国Domainに学校を登録する2つの理由があります。 (1) 名前のユニークさ、およびデータベースの(2)管理。
1. Name Uniqueness:
1. ユニークさを命名してください:
There are many "Washington" high schools, only one can be
"Washington.EDU" (actually none can be, since that name is used
by a University. There will be many name conflicts if all
schools attempt to register directly under EDU.
実際になにもはそうであることができます、その名前が大学によって使用されるので。多くが高くそこでは、「ワシントン」であるという学校、唯一の1つが"Washington.EDU"であることができます。(すべての学校が、EDUの直接下に登録するのを試みると、多くの名前闘争があるでしょう。
In addition, in some districts, the same school name is used at
different levels, for example, Washington Elementary School and
Washington High School. We suggest that when necessary, the
keywords "Elementary", "Middle", and "High" be used to
distinguish these schools. These keywords would only be used
さらに、同じ学校名は異なったレベル、例えば、ワシントンElementary学校、およびワシントン高校でいくつかの地区では、使用されます。 必要であるときに、私たちがそれを勧める、キーワード「基本」、そして、「中央」、および「高値」、使用されて、これらの学校を区別してください。 これらのキーワードは使用されるだけでしょう。
Cooper & Postel [Page 10] RFC 1480 The US Domain June 1993
クーパーとポステル[10ページ]RFC1480米国ドメイン1993年6月
when they are needed, if the school's name is unique without
such keywords, don't use them.
学校の名前がそのようなキーワードなしでユニークであるならそれらが必要であったら、それらを使用しないでください。
2. Database Management:
2. データベース管理:
One goal of the DNS is to divide up the management of the name
database in to small pieces. Each piece (or "zone" in DNS
terminology) could be managed by a distinct administrator.
Adding all the high schools to the EDU domain will make the
already large zone file for EDU even larger, possibly to the
point of being unmanageable.
DNSのある目標は小さい断片への中の名前データベースの管理に分割することです。 異なった管理者は各断片(または、DNS用語の「ゾーン」)に対処できました。 EDUドメインにすべての高校を加えるのにEDUのための既に大きいゾーンファイルはさらに大きくなるでしょう、ことによると「非-処理しやす」でなるまで。
For both these reasons it is necessary to introduce structure into names. Structure provides a basis for making common names unique in context, and for dividing the management responsibility.
これらの理由の両方に、名前に構造を取り入れるのが必要です。 構造は状況内において一般名をユニークにして、経営者の責任を分割する基礎を提供します。
The US Domain has a framework established and has registered many
schools already in this structured scheme. The general form is:
米国Domainは枠組みを確立させて、既にこの構造化された計画で多くの授業を登録しました。 一般的なフォームは以下の通りです。
<school>.<district>.K12.<state>.US.
<学校><地区>.K12.<州の>.US。
For example: Hamilton.LA-Unified.K12.CA.US
例えば: Hamilton.LA-Unified.K12.CA.US
Public schools are usually organized by districts which can be larger or smaller than a city or county. For example, the Portland school district in Oregon, is in three or four counties. Each of those counties also has non-Portland districts.
通常、公立の学校は都市かカウンティーよりさらに大きいか、または小さい場合がある地区によって組織化されます。 例えばオレゴンのポートランド学区が3か4つのカウンティーにあります。 また、それぞれのそれらのカウンティーには、非ポートランド地区があります。
It makes sense to name schools within districts. However districts often have the same name as a city or county so there has to be a way to distinguish a public school district name from some other type of locality name. The keyword "K12" is used for this.
それは地区の中の名前学校に理解できます。 しかしながら、地区で、同じくらいはしたがって、なければならない都市かカウンティーとしてしばしばある他のタイプの場所名と公立の学校地区名を区別する方法を命名します。 キーワード、「K12"はこれに使用されます」。
For example, typical K12 school names currently used are:
例えば、現在使用されている典型的なK12学校名は以下の通りです。
IVY.PRS.K12.NJ.US
DMHS.JCPS.K12.KY.US
OHS.EUNION.K12.CA.US
BOHS.BREA.K12.CA.US
IVY.PRS.K12.NJ.US DMHS.JCPS.K12.KY.米国OHS.EUNION.K12.CA.US BOHS.BREA.K12.CA.US
These names are generally longer than the old alternative of shorter names in the EDU domain, but that would not have lasted long without a significant number of schools finding that their "obviously correct" name has already been used by some other school.
これらの名前はEDUドメインにおける、より短い名前の古い代替手段より一般に長いのですが、多くの学校が、それらの「明らかに正しい」名前がある他の学校によって既に使用されたのがわからない、それは長い間続いていないでしょう。
Cooper & Postel [Page 11] RFC 1480 The US Domain June 1993
クーパーとポステル[11ページ]RFC1480米国ドメイン1993年6月
When there are many things to name some of the names will be long. In some cases there may be appropriate abbreviations that can be used. For example Hamilton High School in Los Angeles could be:
多くのものがあるとき、名前のいくつかを挙げるのは長いでしょう。 いくつかの場合、使用できる適切な略語があるかもしれません。 例えば、ロサンゼルスのハミルトン高校は以下の通りであるかもしれません。
Hami.Hi.LA.K12.CA.US
Hami.Hi.LA.K12.CA.US
If a school has a number of PCs, then each PC should have a name. Suppose they are named "alpha", "beta", ... then if they belong to a school named "Lincoln.High.Lakewood.K12.CA.US" their names would be:
学校に多くのPCがあるなら、各PCには、名前があるはずです。 それらが「アルファ」、「ベータ」と命名されると仮定してください… そして、彼らが「Lincoln.High.Lakewood.K12.CA.US」という学校のものなら、彼らの名前は以下の通りでしょう。
alpha.Lincoln.High.Lakewood.K12.CA.US.
beta.Lincoln.High.Lakewood.K12.CA.US
...
alpha.Lincoln.High.Lakewood.K12.CA.US beta.Lincoln.High.Lakewood.K12.CA.US…
The K12 subdomain provides two points at which to delegate a branch of the database to distinct administrators -- the K12 Administrator for each state, and the district administrator for each district within a state.
K12サブドメインはどれについてブランチを代表として派遣するかで異なった管理者にデータベースを2ポイント提供します--各状態へのK12 Administrator、および州の中の各地区への地区の管理者。
The US Domain Administrator will delegate a branch of the US domain to an appropriate party. In some cases, this may be a particular school, a school district, or ever all of K12 for a state.
米国Domain Administratorは米国ドメインのブランチを適切なパーティーへ代表として派遣するでしょう。 いくつかの場合、これは、状態へのK12の特定の学校、学区、またはかつて、すべてであるかもしれません。
The responsibility for managing a K12 branch or sub-branch may be delegated to an appropriate volunteer. We envision that such delegations of the schools' DNS service may eventually migrate to someone else "more appropriate" from an administrative organizational point of view. The "obvious" state agency to manage the schools' DNS branch may take some time to get up to speed on Internetting. In the meantime, we can have the more advanced schools up and running.
K12ブランチかサブブランチを経営することへの責任を適切なボランティアへ代表として派遣するかもしれません。 私たちはそれを思い描きます。学校のDNSサービスのそのような代表団は結局、管理組織的な観点から他の誰か「より適切な」ものにわたるかもしれません。 学校のDNSブランチを経営する「明白な」州機関は、Internettingを疾走するために起きるにはいくらかの時間がかかるかもしれません。 差し当たり、私たちは、より高度な授業を活動するようにすることができます。
Special Schools and Service Units
専修学校とサービスユニット
In many states, there are special schools that are not in districts that are run directly by the state or by consortiums. There are also service units that provide "educational services" ranging from books and computers to janitorial supplies and building maintenance. Often these service units do not have a one-to-one relationship with districts.
多くの州に、直接州か共同体が走らせる地区にない専修学校があります。また、本とコンピュータから用務の供給とビル管理まで及びながら「教育的なサービス」を提供するサービスユニットがあります。 しばしばこれらのサービスユニットには、地区との1〜1つの関係がありません。
There is some concern about naming these schools and service units within the naming structure for schools established in this memo. There are several possibilities. For a state with many service units creating a "pseudo district" ESU (or whatever, the common terminology is in that state) is a possibility. For example, the Johnson service unit could be JOHNSON.ESU.K12.CA.US. For a state with a few such service units (and avoiding conflicts with district names) the service units could be directly under K12. For example,
このメモに設置された学校にちなんで命名の中のこれらの学校とサービスユニットを構造と命名することに関する何らかの心配があります。 いくつかの可能性があります。 多くのサービスユニットが「疑似地区」を作成している状態において、ESU(何でもに、一般的な用語がその状態にある)は可能性です。 例えば、ジョンソンサービスユニットはJOHNSON.ESU.K12.CA.USであるかもしれません。 そのようなサービス数ユニット(地区名で摩擦を避けて)がある状態において、K12の直接下にサービスユニットがあるかもしれません。 例えば
Cooper & Postel [Page 12] RFC 1480 The US Domain June 1993
クーパーとポステル[12ページ]RFC1480米国ドメイン1993年6月
TIES.K12.MN.US.
TIES.K12.MN.US。
The special public funded schools can be handled in a similar fashion. If there are many special schools in a state, a "pseudo district" should be established and all the special schools listed under it. For example, suppose there is a "pseudo district" in Massachusetts called SPCL, and there is a special school called the Progressive Computer Institute, then that school could have the name PCI.SPCL.K12.MA.US. If there are only a few special schools, they can be listed directly under K12 (avoiding name conflicts with district names). For example, the California Academy of Math and Science is CAMS.K12.CA.US. CAMS is sponsored by seven schools, the California Department of Education, and a University.
同様に特別な公立の資金を供給された学校を扱うことができます。 多くの専修学校が状態にあれば、「疑似地区」は設立されるべきでした、そして、すべての専修学校がそれの下に記載しました。 例えば、「疑似地区」がSPCLと呼ばれるマサチューセッツにあると仮定して、ProgressiveコンピュータInstituteと呼ばれる専修学校があります、そして、次に、その学校はPCI.SPCL.K12.MA.USという名前を持つことができました。 ほんのいくつかの専修学校があれば、K12(地区名との名前闘争を避ける)の直接下にそれらを記載できます。 例えば、MathとScienceのカリフォルニアAcademyはCAMS.K12.CA.USです。 CAMSは7つの学校、カリフォルニア教育省、および大学によって後援されます。
"PVT" Private Schools
"PVT"私立学校
Private schools may be thought of as businesses. Public schools are in districts, and districts provide a natural organizational structure for naming and delegation. For private schools there are no districts and they really do operate like businesses. But, many people are upset to think about their children in a private school being in a business category and not in K12 with the rest of the children. To accommodate both public and private schools, in each state's K12 branch, we've added an artificial district called private or "PVT". This gives a private school the option of registering like a business under "locality" or in the PVT.K12.<state-code>.US branch.
私立学校はビジネスとして考えられるかもしれません。 公立の学校が地区にあります、そして、地区は自然な組織体制を命名と代表団に提供します。 私立学校のために、地区は全くありません、そして、それらは本当にビジネスのように作動します。 しかし、多くの人々が、K12にはあるのではなく、子供の残りと共に適用事業にある私立学校で彼らの子供を思って、動揺しています。 各状態のK12ブランチで公衆と私立学校の両方を収容するために、私たちは個人的であると呼ばれる人工の地区か"PVT"を加えました。 これは「場所」の下、または、PVT.K12の企業のように登録するオプションを私立学校に与えます。<州コード>.USは分岐します。
For example:
例えば:
Crossroads.PVT.K12.CA.US
Crossroads-Santa-Monica.CA.US
Crossroads.PVT.K12.CA.US交差点サンタMonica.CA.US
A public school "Oak High" in the "Woodward" school district in California would have a name like "Oak-High.Woodward.K12.CA.US".
カリフォルニアの「ウッドワード」学区の公立の学校「オーク高値」には、「オーク-High.Woodward.K12.CA.US」のような名前があるでしょう。
A private school "Old Trail" in Pasadena, California could have the <locality> based name "Old-Trail.Pasadena.CA.US" or the private school base name "Old-Trail.PVT.K12.CA.US".
パサディナ(カリフォルニア)の私立学校「古い道」には、<の場所の>のベースの名の「古いTrail.Pasadena.CA.US」か私立学校基底名「古いTrail.PVT.K12.CA.US」があるかもしれません。
Some suggest that for private schools instead of a special pseudo district PVT to use a locality name. One reason to use district names is that, in time, it seems likely that school district administrators will take over the operation of the DNS for their district. One needs to be able to delegate at that branch point. One implication of delegation is that the delegatee is now in charge of a chunk of the name space and will be registering new names. To keep names unique one can't have two different people registering new things below identically named branches.
特別な疑似地区PVTの代わりに私立学校が場所名を使用するように、或るものはそれを示します。 地区名を使用する1つの理由は学区の管理者が時間DNSの操作が彼らの地区に引き継ぎそうであるということです。 人は、おまけに、ブランチポイントを代表として派遣することができる必要があります。 代表団の1つの含意は「反-遺産受取人」が現在、スペースという名前の塊を担当していて、新しい名前を登録するということです。 名前をユニークに保つために、1つで、2人の異なった人は同様に命名された支店の下に新しいものを登録できません。
Cooper & Postel [Page 13] RFC 1480 The US Domain June 1993
クーパーとポステル[13ページ]RFC1480米国ドメイン1993年6月
For example, if there is a school district named Pasadena and a city named Pasadena, the branch of the name space PASADENA.K12.CA.US might be delegated to the administrator of that public school district. If a private school in Pasadena wanted to be registered in the DNS, it would have to get the public school district administrator to do it (perhaps unlikely) or not be in the K12 branch at all (unless there is the PVT pseudo district).
例えば、パサディナという学区とパサディナという都市があれば、名前スペースPASADENA.K12.CA.USのブランチをその公立の学校地区の管理者へ代表として派遣するかもしれません。 DNSに登録されて欲しかったパサディナの私立学校であるなら、それは、公立の学校の地区の管理者がそれ(恐らくありそうもない)をするか、または全くK12ブランチにはいないのをさせなければならないでしょう(PVT疑似地区がない場合)。
So, if private schools are registered by <school>.<locality>.K12.<state-code>.US and public schools are registered by <school>.<district>.K12.<state-code>.US, there can't be any locality names that are the same as district names or the delegation of these will get very tricky later.
それで、私立学校が<学校><場所>.K12.<州コードによって登録されるなら、>.USと公立の学校は<学校>によって登録されます。<地区>.K12.<州コード>.US、後で地区名かこれらの代表団が非常に扱いにくくなるので、どんな同じである場所名もあるはずがありません。
If it is all done by locality names rather than district names, and public and private schools are mixed together, then finding an appropriate party to delegate the locality to may be difficult.
それが地区名よりむしろ場所名ですべてしていて、公共であるか、そして、私立学校は、難しい状態で一緒に混ぜられて、次に、であるかもしれない場所は代表として派遣するのが適切であるパーティーを見つけています。
Another suggestion was that private schools be registered directly under K12, while public schools must be under a district under K12. This would require the operator of the K12 branch to register all districts and private schools himself (checking for name uniqueness), he couldn't easily delegate the registration of the private schools to anyone else.
別の提案は私立学校がK12の直接下に登録されるということでした、K12の下の地区の下に公立の学校があるに違いありませんが。 これは自分ですべての地区と私立学校を登録するためにK12ブランチをオペレータに要求して(名前のユニークさがないかどうかチェックして)、彼は容易に私立学校の登録を他の誰へも代表として派遣することができませんでした。
Community Colleges and Technical Schools
コミュニティカレッジと専門学校
To distinguish Community Colleges and Technical/Vocational schools, the keywords "CC" and "TEC" have been created.
Community大学とTechnical/職業訓練所を区別するために、キーワード「CC」と「テック」を作成してあります。
Some School Examples
いくつかの学校の例
Hamilton.High.LA-Unified.K12.CA.US <== a public school Sherman-Oaks.Elem.LA-Unified.K12.CA.US <== a public school John-Muir.Middle.Santa-Monica.K12.CA.US <== a public school Crossroads-School.Santa-Monica.CA.US <== a private school SMCC.CC.CA.US <== a community college TECMCC.CC.CA.US <== a community college Brick-and-Basket-Institute.TEC.CA.US <== a technical college Northridge.CSU.STATE.CA.US <== a state university
工科大学Northridge.CSU.STATE.CA.USコミュニティカレッジBrickとかごのInstitute.TEC.CA.USコミュニティカレッジTECMCC.CC.CA.US私立学校SMCC.CC.CA.US公立の学校Crossroads-School.Santa-Monica.CA.US公立の学校ジョン-Muir.Middle.Santa-Monica.K12.CA.US公立の学校シャーマン-Oaks.Elem.LA-Unified.K12.CA.US Hamilton.High.LA-Unified.K12.CA.US<=<=<=<=<=<=<=<=州立大学
Cooper & Postel [Page 14] RFC 1480 The US Domain June 1993
クーパーとポステル[14ページ]RFC1480米国ドメイン1993年6月
2.4 State Agencies
2.4 州機関
Several states are setting up networks to interconnect the offices of state government agencies. The hosts in such networks should be registered under the STATE.<state-code>.US branch.
いくつかの州が、州の政府機関のオフィスとインタコネクトするためにネットワークを設立しています。 そのようなネットワークのホストは州の下に登録されるべきです。<州コード>.USは分岐します。
A US Domain name space has been established for the state government agencies. For example, in the State of Minnesota, the subdomain is STATE.MN.US.
米国のDomain名前スペースは州の政府機関のために確立されました。 例えば、ミネソタ州では、サブドメインがSTATE.MN.USです。
State Agencies:
---------------
州機関: ---------------
Senate.STATE.MN.US <== State Senate
MDH.STATE.MN.US <== Dept. of Health
CALTRANS.STATE.CA.US <== Dept. of Transportation
DMV.STATE.CA.US <== Dept. of Motor Vehicles
自動車の輸送DMV.STATE.CA.US<=部の健康CALTRANS.STATE.CA.US<=部の州上院MDH.STATE.MN.US<=Senate.STATE.MN.US<=部
2.5 Federal Agencies
2.5 連邦政府の機関
A federal name space has been established for the federal government agencies. For example, the subdomain for the Federal Reserve Bank of Minneapolis is MNPL.FRB.FED.US. Other examples are listed below.
連邦の名前スペースは連邦政府代理店のために確立されました。 例えば、ミネアポリス連邦準備銀行のためのサブドメインはMNPL.FRB.FED.USです。 他の例は以下にリストアップされています。
Federal Government Agencies:
---------------------------
連邦政府代理店: ---------------------------
Senate.FED.US <==== US Senate
DOD.FED.US <==== US Defense Dept.
USPS.FED.US <==== US Postal Service
VA.FED.US <==== US Veterans Administration
IRS.FED.US <==== US Internal Revenue Service
Yosemite.NPS.Interior.FED.US <==== A Federal agency
Senate.FED.US<。==== 米国上院DOD.FED.US<。==== 米国ディフェンス部 USPS.FED.US<。==== 米国郵便業務VA.FED.US<。==== 米国復員軍人援護局IRS.FED.US<。==== 米国国税庁Yosemite.NPS.Interior.FED.US<。==== 連邦政府の機関
2.6 Distributed National Institutes
2.6 分配された国家の研究所
The "DNI" branch was created directly under the top-level US. This is to be used for organizations that span state, regional, and other organizational boundaries; are national in scope, and have distributed facilities. An example would be:
"DNI"ブランチはトップレベルの米国の直接下に創設されました。 これは状態にかかる組織、地方の、そして、他の組織境界に使用されることになっています。 範囲で国家であり、施設を分配しました。 例は以下の通りでしょう。
Distributed National Institutes:
--------------------------------
分配された国家の研究所: --------------------------------
MetaCenter.DNI.US <==== The MetaCenter Supercomputer Centers
MetaCenter.DNI.US<。==== 傾心スーパーコンピュータセンター
Cooper & Postel [Page 15] RFC 1480 The US Domain June 1993
クーパーとポステル[15ページ]RFC1480米国ドメイン1993年6月
The MetaCenter domain encompasses the four NSF sponsored supercomputer centers. These are:
MetaCenterドメインは後援されたスーパーコンピュータが中心に置く4NSFを取り囲みます。 これらは以下の通りです。
San Diego Supercomputer Center (SDSC)
National Center for Supercomputing Applications (NCSA)
Pittsburgh Supercomputing Center (PSC)
Cornell Theory Center (CTC)
サンディエゴのスーパーコンピュータセンター(SDSC)国立スーパーコンピューター応用研究所(NCSA)ピッツバーグスーパーコンピューティングセンター(PSC)のコーネル理論センター(CTC)
The MetaCenter Network will enable applications and services like file systems and archival storage to be operated in a distributed fashion; thus, allowing the resources at the four centers to appear integrated and "seamless" to users of the centers.
MetaCenter Networkは、ファイルシステムとアーカイブ領域のようなアプリケーションとサービスが分配されたファッションで操作されるのを可能にするでしょう。 その結果、4つのセンターのリソースがセンターのユーザにとって統合して「シームレス」に見えるのを許容します。
2.7 General Independent Entities
2.7 一般独立実体
This name space was created for organizations that don't really fit anywhere else, such as state-wide associations, clubs, and "domain parks". Think of this as the miscellaneous category.
この名前スペースは本当に他のどこかに合わない組織のために作成されました、州全体の協会や、クラブや、「ドメイン公園」などのように。 種々雑多なカテゴリとしてこれを考えてください。
The examples are state-wide clubs. For example, the Garden Club of Arizona, might want to be "GARDEN.GEN.AZ.US". Such a club has membership from all over the state and is not associated with any one city (or locality). Another example is "domain parks" that have been established up-to-now as entities in ORG. For example, there is "LONESTAR.ORG", which is a kind of computer club in Texas that has lots of dial-in computers registered. In the US Domain such an entity might have a name like "LONESTAR.GEN.TX.US".
例は州全体のクラブです。 アリゾナの例えば、庭のClubは「GARDEN.GEN. AZ.US」でありたがっているかもしれません。 そのようなクラブは、状態から会員資格を持って、どんな都市(または、場所)にも関連づけられません。 別の例はこれまで実体とORGに書き立てられた「ドメイン公園」です。 例えば、"LONESTAR.ORG"が多くのダイヤルインのコンピュータを登録させるテキサスにあります。(それは、一種のコンピュータクラブです)。 米国Domainでは、そのような実体は「LONESTAR.GEN. TX.US」のような名前を持っているかもしれません。
The organizations registered in GEN may typically be non-profit entities. These organizations don't fit in a <locality> and are not a school, library, or state agency. Ordinary businesses are not registered in GEN.
GENに登録された組織は通常、非営利の実体であるかもしれません。 これらの組織は、<場所>をうまくはめ込まないで、また学校でなくて、またライブラリでなくて、また州機関でもありません。 普通のビジネスはGENに登録されません。
Some suggest that these kinds of organizations are just like all the other things and ought to be registered under some <locality>. This may be true, but sometimes one just can't find any way to convince the applicant that it is the right thing to do. One can argue that any organization has to have a headquarters, or an office, or something about it that is in a fixed place, and thus the organization could be registered in that place.
或るものは、これらの種類の組織がまさしく他のすべてのものに似ているのを示して、何らかの<場所>の下で登録されるべきです。 これは本当であるかもしれませんが、時々、人はただするのが、正しいものである応募者に納得させる少しの方法も見つけることができません。 1つは、どんな組織にも何か本部、オフィス、または一定の場所にあるそれに関するものがなければならないと主張できます、そして、その結果、その場所に組織は登録できました。
Some suggest that no token is needed, these entities could be directly under the <state-code>. The problem with not having a token, is that you can't delegate the responsibility for registering these entities to someone separate from whoever is responsible for the <state-code>. You want to be able to delegate for both name- uniqueness reasons, and operational management reasons. Having a token there makes both easy.
或るものは、象徴は全く必要でなく、これらの実体が<州コード>の直接下にあるかもしれないのを示します。 象徴を持たないことに関する問題はあなたが<州コード>に責任がある人なら誰でもからだれか別々の人にこれらの実体を示すことへの責任を代表として派遣することができないということです。 あなたは名前ユニークさの理由と運営管理の両方のために理由を代表として派遣することができるようになりたがっています。 そこに象徴を持っているのに、両方が簡単になります。
Cooper & Postel [Page 16] RFC 1480 The US Domain June 1993
クーパーとポステル[16ページ]RFC1480米国ドメイン1993年6月
General Independent Entities:
-----------------------------
一般独立実体: -----------------------------
CAL-Comp-Club.GEN.CA.US <==== The Computer Club of California
CALコンピュータClub.GEN.CA.US<。==== カリフォルニアコンピュータクラブ
2.8 Examples of Names
2.8 名前に関する例
For small entities like individuals or small businesses, there is
usually no problem with selecting locality based names.
個人や中小企業のような小規模団体のために、通常、場所に基づいている名前を選択することに関する問題は全くありません。
For example: Zuckys.Santa-Monica.CA.US
例えば: Zuckys.Santa-Monica.CA.US
For large entities like large corporations with multiple
facilities in several cities or states this often seems like an
unreasonable constraint (especially when compared with the
alternative of registering directly in the COM domain). However,
a company does have a headquarters office in a particular locality
and so could register with that name. Example: IBM.Armonk.NY.US
複数の施設がいくつかの都市か州にある大企業のような大きい実体に関しては、これは無理な規制のようにしばしば見えます(特に直接COMドメインに登録する代替手段と比べると)。 しかしながら、会社は、特定の場所の本部を持っているので、その名前とともに記名することができました。 例: IBM.Armonk.NY.US
PRIVATE (business or individual)
================================
兵士(ビジネスか個人)================================
Camp-Curry.Yosemite.CA.US <==== a business
IBM.Armonk.NY.US <==== a business
Dogwood.atl.GA.US <==== a business
Geo-Petrellis.Culver-City.CA.US <==== a restaurant
Zuckys.Santa-Monica.CA.US <==== a restaurant
Joe-Josts.Long-Beach.CA.US <==== a bar
Holodek.Santa-Cruz.CA.US <==== a personal computer
キャンプ-Curry.Yosemite.CA.US<。==== ビジネスIBM.Armonk.NY.US<。==== ビジネスDogwood.atl.GA.US<。==== ビジネスジオ-Petrellis.Culver-City.CA.US<。==== レストランZuckys.Santa-Monica.CA.US<。==== レストランジョー-Josts.Long-Beach.CA.US<。==== バーHolodek.Santa-Cruz.CA.US<。==== パーソナルコンピュータ
FEDERAL
=======
連邦=======
Senate.FED.US <==== US Senate
DOD.FED.US <==== US Defense Dept.
DOT.FED.US <==== US Transportation Dept.
USPS.FED.US <==== US Postal Service
VA.FED.US <==== US Veterans Administration
IRS.FED.US <==== US Internal Revenue Service
Yosemite.NPS.Interior.FED.US <==== a federal agency
MNPL.FRB.FED.US. <==== US Fed. Reserve Bank of Minneapolis
Senate.FED.US<。==== 米国上院DOD.FED.US<。==== 米国ディフェンス部 DOT.FED.US<。==== 米国輸送部 USPS.FED.US<。==== 米国郵便業務VA.FED.US<。==== 米国復員軍人援護局IRS.FED.US<。==== 米国国税庁Yosemite.NPS.Interior.FED.US<。==== 連邦機関MNPL.FRB.FED.US。 <== 米国は食べられました。 ミネアポリス準備銀行
Cooper & Postel [Page 17] RFC 1480 The US Domain June 1993
クーパーとポステル[17ページ]RFC1480米国ドメイン1993年6月
STATE
=====
状態=====
Senate.STATE.MN.US <==== state Senate
House.STATE.MN.US <==== state House of Reps
MDH.STATE.MN.US <==== state Health Dept.
HUD.STATE.CA.US <==== state House and Urban Dev. Dept.
DOT.STATE.MN.US <==== state Transportation Dept.
CALTRANS.STATE.CA.US <==== state Transportation Dept.
DMV.STATE.CA.US <==== state Motor Vehicles Dept.
Culver-City.DMV.STATE.CA.US <==== a local office of DMV
Senate.STATE.MN.US<。==== 州の上院House.STATE.MN.US<。==== Reps MDH.STATE.MN.US<州の家==== 州のHealth部 HUD.STATE.CA.US<。==== 下院とアーバンのデーウを述べてください。 部 DOT.STATE.MN.US<。==== 州のTransportation部 CALTRANS.STATE.CA.US<。==== 州のTransportation部 DMV.STATE.CA.US<。==== 州のMotor Vehicles部 カルバー-City.DMV.STATE.CA.US<。==== DMVの地方支店
DNI (distributed national Institutes)
======================================
DNI(分配された国家のInstitutes)======================================
METACENTER.DNI.US <==== a distributed nat'l Inst.
METACENTER.DNI.US<。==== 分配されたnat'l Inst。
GEN (General Independent Entities)
==================================
(一般独立実体)に情報を得てください。==================================
GARDEN.GEN.AZ.US <==== a garden club of Arizona
GARDEN.GEN. AZ.US<。==== アリゾナの園芸クラブ
CITY | CI | COUNTY | CO (locality)
==================================
都市| CI| カウンティー| CO(場所)==================================
Parks.CI.Culver-City.CA.US <==== a city department
Fire-Dept.CI.Los-Angeles.CA.US <==== a city department
Fire-Dept.CO.Los-Angeles.CA.US <==== a county department
Planning.CO.Fulton.GA.US. <==== a county department
Main.Library.CI.Los-Angeles.CA.US <==== a city department
MDR.Library.CO.Los-Angeles.CA.US <==== a county department
Parks.CI.Culver-City.CA.US<。==== 都市の部のFire-部のCI.Los-Angeles.CA.US<。==== 都市の部のFire-部のCO.Los-Angeles.CA.US<。==== カウンティーの部のPlanning.CO.Fulton.GA.US。 <== カウンティーの部のMain.Library.CI.Los-Angeles.CA.US<。==== 都市の部のMDR.Library.CO.Los-Angeles.CA.US<。==== カウンティーの部
TOWNSHIP | PARISH (locality)
============================
郡区| 教区(場所)============================
Police.TOWNSHIP.Green.OH.US <==== a township department
Administration.PARISH.Lafayette.LA.US <==== a parish department
Police.TOWNSHIP.Green.OH.US<。==== 郡区の部のAdministration.PARISH.Lafayette.LA.US<。==== 教区部
Cooper & Postel [Page 18] RFC 1480 The US Domain June 1993
クーパーとポステル[18ページ]RFC1480米国ドメイン1993年6月
DISTRICT | LIBRARY (agency)
============================
地区| ライブラリ(政府機関)============================
SCAQMD.DISTRICT.CA.US <==== a regional district
Bunker-Hill-Improvement.DISTRICT.LA.CA.US <==== a local district
SCAQMD.DISTRICT.CA.US<。==== 地方の地区BunkerヒルImprovement.DISTRICT.LA.CA.US<。==== 地方の地区
Huntington.LIB.CA.US <==== a private library
Venice.LA-City.LIB.CA.US <==== a city library
MDR.LA-County.LIB.CA.US <==== a county library
Huntington.LIB.CA.US<。==== 私用ライブラリVenice.LA-City.LIB.CA.US<。==== 市立図書館MDR.LA-County.LIB.CA.US<。==== 郡立図書館
K12 | PRIVATE SCHOOLS (PVT) | CC | TEC
======================================
K12| 私立学校(PVT)| CC| テック======================================
Hamilton.High.LA-Unified.K12.CA.US <==== a public school
Sherman-Oaks.Elem.LA-Unified.K12.CA.US <==== a public K12 school
John-Muir.Middle.Santa-Monica.K12.CA.US <==== a public K12 school
Culver-High.CCSD.K12.CA.US <==== a public K12 school
Hamilton.High.LA-Unified.K12.CA.US<。==== 公立の学校シャーマン-Oaks.Elem.LA-Unified.K12.CA.US<。==== 公共のK12学校ジョン-Muir.Middle.Santa-Monica.K12.CA.US<。==== 公共のK12学校カルバー-High.CCSD.K12.CA.US<。==== 公立のK12学校
St-Monica.High.Santa-Monica.CA.US <==== a private school
Crossroads-School.Santa-Monica.CA.US <==== a private school
Mary-Ellens.Montessori-School.LA.CA.US <==== a private school
Progress-Learning-Center.PVT.K12.CA.US <==== a private school
通り-Monica.High.Santa-Monica.CA.US<。==== 私立学校Crossroads-School.Santa-Monica.CA.US<。==== 私立学校メアリ-Ellens.Montessori-School.LA.CA.US<。==== 私立学校Progress学習Center.PVT.K12.CA.US<。==== 私立学校
SMCC.Santa-Monica.CC.CA.US <==== a public community college
Trade-Tech.Los-Angeles.CC.CA.US <==== a public community college
Valley.Los-Angeles.CC.CA.US <==== a public community college
SMCC.Santa-Monica.CC.CA.US<。==== 公共のコミュニティカレッジTrade-Tech.Los-Angeles.CC.CA.US<。==== 公共のコミュニティカレッジValley.Los-Angeles.CC.CA.US<。==== 公立のコミュニティカレッジ
Brick-and-Basket-Institute.TEC.CA.US <== a technical college
レンガとかごのInstitute.TEC.CA.US<=工科大学
When appropriate, subdomains are delegated and partioned in
various categories, such as:
適切であるときに、サブドメインは、以下などの様々なカテゴリで代表として派遣されて、partionedされます。
<locality>.<state>.US = city/locality based names
K12.<state>.US = kindergarten thru 12th grade
PVT.K12.<state.US = private kindergarten thru 12th grade
CC.<state>.US = community colleges
TEC.<state>.US = technical or vocational schools
LIB.<state>.US = libraries
STATE.<state>.US = state government agencies
<org-name>.FED.US = federal government agencies
<org-name>.DNI.US = distributed national institutes
<org-name>.GEN.<state>.US. = statewide assoc,clubs,domain parks
><州>.US=都市/場所が基礎づけた<場所は技術的であるか職業上のコミュニティカレッジTEC<州の>12年CC<州の>.US=.US=学校を通る私設の12年PVT.K12<state.US=幼稚園を通るK12<州の>.US=幼稚園をLIBと命名します; <州の>.USはライブラリ州と等しいです。州の政府機関<組織名><州の>.US=.FED.USは分配された国家の連邦政府政府機関<組織名>.DNI.US=研究所<組織名>.GEN.<州の>.USと等しいです。 = 州全体のassoc、クラブ、ドメイン公園
The Appendix-I contains the current US Domain Names BNF.
Appendix-Iは現在の米国Domain Names BNFを含んでいます。
Cooper & Postel [Page 19] RFC 1480 The US Domain June 1993
クーパーとポステル[19ページ]RFC1480米国ドメイン1993年6月
3. REGISTRATION
3. 登録
There are two types of registrations (1) Delegation, where a branch of the US Domain is delegated to an organization running name servers to support that branch; or (2) Direct Registration, in which the information is put directly into the main database.
2つのタイプの登録証明書(1)代表団があります。(そこでは米国Domainのブランチが支持する分岐するネームサーバを走らせる組織へ代表として派遣されます)。 (2) または、Registrationを指示してください。そこでは、情報が直接主なデータベースに置かれます。
In Direct Registration there are two cases: (a) an IP-host (with an IP address), and (b) non-IP host (for example, a UUCP host). Any particular registration will involve any one of these three situations.
Direct Registrationに、2つのケースがあります: (a) IP-ホスト(IPアドレスがある)、および(b)非IPホスト(例えば、UUCPホスト)。 どんな特定の登録もこれらの3つの状況のいずれにもかかわるでしょう。
3.1 Requirements
3.1 要件
Anyone requesting to register a host in the US Domain is sent a copy of the "Instructions for the US Domain Template", and must fill out a US Domain template.
米国Domainにホストを登録するよう要求するだれでも、「米国ドメインテンプレートのための指示」のコピーを送って、米国Domainテンプレートに書き込まなければなりません。
The US Domain template, is similar to the InterNIC Domain template, but it is not the same. To request a copy of the US Domain template, send a message to the US Domain registrar (us-domain@isi.edu).
米国DomainテンプレートはInterNIC Domainテンプレートと同様ですが、それは同じではありません。 米国Domainテンプレートのコピーを要求するには、米国のDomain記録係( us-domain@isi.edu )にメッセージを送ってください。
If you are registering a name in a delegated zone, please register with the contact for that zone. You can FTP the file "in-notes/us- domain-delegated.txt" from venera.isi.edu, via anonymous FTP. This information is also available via email from RFC-INFO@ISI.EDU (include as the only text in the message "Help: us_domain_delegated_domains").
代表として派遣されたゾーンに名前を登録しているなら、そのゾーンに接触とともに記名してください。 あなた、缶のFTP、ファイル、「注意の/、私たち、-、ドメイン-delegated.txt、」 公開FTPを通したvenera.isi.eduから。 また、この情報も RFC-INFO@ISI.EDU からのメールで利用可能である、(メッセージにおける唯一のテキストとしての包含、「ヘルプ: _ドメイン_が代表として派遣した私たち、_ドメイン、」、)
The key people must have electronic mailboxes (that work). Please provide all the information indicated in the "Administrator" and "Technical Contact" slots.
主要な人々はメールボックス(その仕事)を持たなければなりません。 「管理者」と「技術連絡担当者」スロットで示されたすべての情報を提供してください。
The administrator will be the point of contact for any administrative and policy questions about the domain. The administrator is usually the person who manages the organization being registered.
管理者は、ドメインに関していずれにおける、管理の連絡先と方針問題になるでしょう。 通常、管理者は登録されていて、組織を経営する人です。
The technical contact can also be administrator, or the systems person, or someone who is familiar with the technical details of the Internet. The technical contact should have a valid working email address. This is necessary in case something goes wrong.
また、技術連絡担当者は、管理者、システム人、またはインターネットに関する技術的詳細に詳しいだれかであるかもしれません。 技術連絡担当者には、有効な働くEメールアドレスがあるべきです。 何かが支障をきたすといけないので、これが必要です。
It is important that your "Return-Path" and "From" field indicate an Internet-style address. UUCP-style addresses such as "host1!user" will not work. This is fine within the UUCP world, but not the Internet. If you want people on the Internet to be able to send mail to you, your return path needs to be an Internet-style address such as: host1!user@Internet.gateway.host or user@Internet.gateway.host.
あなたの「リターンパス」と“From"分野がインターネットスタイルアドレスを示すのは、重要です。 「host1!ユーザ」などのUUCP-スタイルアドレスは働かないでしょう。 これはインターネットではなく、UUCP世界の中ですばらしいです。 あなたが、インターネットの人々にメールをあなたに送ることができて欲しいなら、あなたのリターンパスは、以下などのインターネットスタイルアドレスである必要があります。 host1!user@Internet.gateway.host かユーザ@Internet.gateway.host。
Cooper & Postel [Page 20] RFC 1480 The US Domain June 1993
クーパーとポステル[20ページ]RFC1480米国ドメイン1993年6月
It is also possible to register through one of the Internet service providers that have established working relationships with the US Domain Administrator.
また、米国Domain Administratorとの仕事上のお付き合いを確立したインターネット接続サービス業者の1つを通して登録するのも可能です。
If everything checks out, the turn around time for registering a host is usually a few days. The name servers are updated anywhere from 12 to 24 hours later.
すべてがチェックアウトされるなら、通常、ホストを登録するためのターンアラウンドタイムは数日です。 12〜24時間後にどこでもネームサーバをアップデートします。
There are two ways to be registered in the US Domain, directly, or by delegation.
2つの米国Domain、直接、または代表団によって登録されるべき方法があります。
3.2 Direct Entries
3.2 ダイレクトエントリー
Direct entry in the database of the US Domain appeals most to individuals and small companies. You may fill out the application and send it directly to the US Domain Administrator. If you are in an area where the zone is delegated to someone else your request will be forwarded to the zone administrator for your registration. Or, you may send the form directly to the manager of a delegated zone (see Section 3.1).
米国Domainのダイレクトデータベースへの登録は個人と小会社に最も上告されます。 あなたは、アプリケーションに書き込んで、直接米国Domain Administratorにそれを送ることができます。 あなたがゾーンが他の誰かへ代表として派遣される領域にいると、あなたの登録のためにあなたの要求をゾーンの管理者に転送するでしょう。 または、あなたは直接代表として派遣されたゾーンのマネージャにフォームを送ることができます(セクション3.1を見てください)。
3.2.1 IP-Hosts
3.2.1 IP-ホスト
These are hosts with IP addresses which correspond to "A" records in the DNS database.
これらはDNSデータベースでの記録に一致しているIPアドレスをもっているホストです。
3.2.2 Non-IP Hosts
3.2.2 非IPホスト
Many applicants have hosts in the UUCP world. Some are one hop away, some two and three hops away from their "Internet Forwarder", this is acceptable. What is important is getting an Internet host to be your forwarder. If you do not already have an Internet forwarder, there are several businesses that provide this service for a fee, such as UUNET.UU.NET (postmaster@uunet.uu.net), PSI (postmaster@UU2.PSI.COM) and CERFNET (help@cerf.net). Sometimes local colleges in your area are already on the Internet and may be willing to act as an Internet Forwarder. You would need to work this out with the systems administrator as we cannot make these arrangements for you.
多くの応募者には、UUCP世界にホストがいます。 或るものは遠くでワンバウンドです、そして、何らかの2であり、それらの「Internet混載業者」から遠くの3つのホップでありこれは許容できます。 重要なことは、インターネット・ホストがあなたの混載業者であることを得ています。 あなたにInternet混載業者が既にいないなら、有料でこのサービスを提供する数個のビジネスがあります、UUNET.UU.NET( postmaster@uunet.uu.net )や、PSI(郵便局長@UU2.PSI.COM)やCERFNET( help@cerf.net )などのように。 あなたの領域の地元大学は、時々、インターネットに既にあって、インターネットForwarderとして機能しても構わないと思っているかもしれません。 あなたは、私たちがあなたのためにこれらの手配をすることができないように上級システムアドミニストレータと共にこれを解決する必要があるでしょう。
Although we work with UUCP service providers, the Internet US Domain registration is not affiliated with the registration of UUCP Map entries. The UUCP map entry does not provide us with sufficient information. If you do not have a copy of the US Domain questionnaire template, please send a message to: us-domain@isi.edu and request one. See Appendix-II.
私たちはUUCPサービスプロバイダーと共に働いていますが、インターネット米国のDomain登録はUUCP Mapエントリーの登録に加わられません。 UUCP地図エントリーは十分な情報を私たちに提供しません。 米国Domainアンケートテンプレートのコピーがないなら、メッセージを以下に送ってください。 us-domain@isi.edu と要求1。 付録IIを見てください。
Cooper & Postel [Page 21] RFC 1480 The US Domain June 1993
クーパーとポステル[21ページ]RFC1480米国ドメイン1993年6月
The example below is not an appropriate registration for the US Domain.
以下の例は米国Domainのための適切な登録ではありません。
#N starl
#S Amiga 2500; AmigaDOS 2.04; Dillon's AmigaUUCP 1.15D
#O Starlight BBS
#C Stephen Baker
#E starl!sbaker
#T +1 305 378 1161
#P 1107 SW 200th St #303B Miami, Fl. 33157
#L 25 47 N / 88 10 W [city]
#R
#U mthvax
#W starl!sbaker (Stephen Baker); Mon Feb 24 19:58:24 EST 1992
starl mthvax(DAILY)
#N starl#S Amiga2500。 AmigaDOS2.04。 ディロンAmigaUUCP 1.15D#OのStarlight BBS#Cスティーブンベイカー#E starl!sbaker#T+1 305 378の1161年の#のP1107SW第200通り#303Bマイアミ(Fl)。 33157#L25 47N/88 10W[都市]##R U mthvax#W starl!sbaker(スティーブン・ベイカー)。 東部標準時1992年2月24日月曜日19時58分24秒starl mthvax(日刊誌)
If you are registering your host as a central site for a USENET group where other UUCP sites will feed from you, that's fine. These UUCP sites do not need to register. If however, the other sites become a subdomain of your hostname, then we will need to register them individually or add a wildcard record. (See Section 4.4. Wildcards).
あなたが他のUUCPサイトがあなたから食べられるUSENETグループのための主要なサイトとしてホストを登録しているなら、それはすばらしいです。 これらのUUCPサイトは登録する必要はありません。 しかしながら、他のサイトがあなたのホスト名に関するサブドメインになるなら、私たちは、個別にそれらを登録するか、またはワイルドカード記録を加える必要があるつもりです。 (セクション4.4個のワイルドカードを見ます。)
For example: bah.rochester.ny.us
host1.bah.rochester.ny.us
host2.bah.rochester.ny.us
例えば: bah.rochester.ny.us host1.bah.rochester.ny.us host2.bah.rochester.ny.us
To use US Domain names for non-IP hosts, there must be a forwarder host that is an IP host. There must be an administrative agreement and a technical procedure for relaying mail between the non-IP host and the forwarder host.
非IPホストに米国Domain名を使用するために、IPホストである混載業者ホストがいるに違いありません。 非IPホストと混載業者ホストの間には、管理協定とメールをリレーするための技術的な手順があるに違いありません。
Case 1: -------
ケース1: -------
Your host is not an IP host but does talk directly with a host that
is an IP host.
+-----------------+
+----------+ +---------+ | |
|your-host |---UUCP-----|forwarder|----IP/TCP--| INTERNET |
+----------+ +---------+ | |
+-----------------+
"Forwarder" must be an IP host on the Internet.
あなたのホストは、IPホストではありませんが、直接IPホストであるホストと話します。 +-----------------+ +----------+ +---------+ | | |あなた、-、ホスト|---UUCP-----|混載業者|----IP/TCP--| インターネット| +----------+ +---------+ | | +-----------------+ 「混載業者」はインターネットのIPホストであるに違いありません。
You must ask "forwarder" if they are willing to be the Internet forwarder for "your-host".
あなたが、彼らが、Internet混載業者であっても構わないと思っているかどうか「混載業者」に尋ねなければならない、「あなた、-、ホスト、」
In the US Domain of the DNS data base there must be an entry like
this:
"your-host" MX 10 "forwarder"
DNSデータベースの米国Domainに、このようなエントリーがあるに違いありません: 「あなた、-、ホスト、」 MX10「混載業者」
Cooper & Postel [Page 22] RFC 1480 The US Domain June 1993
クーパーとポステル[22ページ]RFC1480米国ドメイン1993年6月
This must be entered by the US Domain Administrator.
米国Domain Administratorはこれに入らなければなりません。
In the "forwarder" routing tables there must be information about "your-host" with a rule like: If I see mail for "your-host" I will send it via uucp by calling phone number "123-4567".
-、ホスト、」 aで、以下のように統治してください。 私がメールを見る、「あなた、-、ホスト、」 私は電話番号「123-4567」と呼ぶのによるuucpを通してそれを送るつもりです。
Case 2: -------
ケース2: -------
In this case your hosts talks to another host that ... that talks to
an IP host. In other words, there are multiple hops between your host
and the Internet.
+-----------------+
+----------+ +---------+ | |
|path-host |---UUCP-----|forwarder|----IP/TCP--| INTERNET |
+----------+ +---------+ | |
| +-----------------+
UUCP
|
+----------+
|your-host |
+----------+
この場合、別のものへのあなたのホスト会談はそれ…IPホストと話す を接待します。 言い換えれば、あなたのホストとインターネットの間には、複数のホップがあります。 +-----------------+ +----------+ +---------+ | | |経路ホスト|---UUCP-----|混載業者|----IP/TCP--| インターネット| +----------+ +---------+ | | | +-----------------+ UUCP| +----------+ |あなた、-、ホスト| +----------+
"Forwarder" must be an IP host on the Internet.
「混載業者」はインターネットのIPホストであるに違いありません。
You must ask "forwarder" if they are willing to be the Internet Forwarder for "Your-Host". You must ask "path-host" to relay your mail.
あなたが、彼らが、インターネットForwarderであっても構わないと思っているかどうか「混載業者」に尋ねなければならない、「あなた、-、ホスト、」 あなたは、あなたのメールをリレーするように「経路ホスト」に頼まなければなりません。
In the US Domain of the DNS Database there must be an entry like this:
DNS Databaseの米国Domainに、このようなエントリーがあるに違いありません:
"your-host" MX 10 "forwarder"
「あなた、-、ホスト、」 MX10「混載業者」
This must be entered by the US Domain Administrator.
米国Domain Administratorはこれに入らなければなりません。
In the "forwarder" routing tables there must be information about "your-host" with a rule like: If I see mail for "your-host" I will send it via UUCP to "path-host" by calling phone number "123-4567". and "path-host" must also know how to relay the mail to "your-host".
-、ホスト、」 aで、以下のように統治してください。 私がメールを見る、「あなた、-、ホスト、また「123-4567」 「経路ホスト」が、どのようにがメールをリレーするかを知らなければならない電話番号と呼ぶことによって」 私が「経路ホスト」へのUUCPを通してそれを送るつもりである、「あなた、-、ホスト、」
Note: It is assumed that "path-host" is already MXed to "forwarder". It is not appropriate to ask to MX "your-host" to "path-host" (this is sometimes called double MXing). The host on the right hand side of an MX entry must be a host on the Internet with an IP address (e.g., 128.9.2.32).
以下に注意してください。 「経路ホスト」が既に「混載業者」へのMXedであると思われます。 MXに尋ねるのが適切でない、「あなた、-、ホスト、」 「経路ホスト」(これは時々二重MXingと呼ばれる)に。 MXエントリーの右手の端の上のホストがIPアドレスがあるインターネットのホストであるに違いない、(例えば、128.9 .2 .32)。
Cooper & Postel [Page 23] RFC 1480 The US Domain June 1993
クーパーとポステル[23ページ]RFC1480米国ドメイン1993年6月
3.3 Delegated Subdomains
3.3 代表として派遣されたサブドメイン
Many branches of the US Domain are delegated. There must be a knowledgeable and competent technical contact, familiar with the Internet DNS. This requirement is easily satisified if the technical contact already runs some other name servers.
米国多岐Domainを代表として派遣します。 インターネットDNSに詳しい博識で有能な技術連絡担当者がいるに違いありません。 技術連絡担当者がある他のネームサーバを既に走らせるなら、この要件は容易にsatisifiedされます。
Examples of delegations are K12.TX.US for the Kindergarten through 12th Grade public schools in Texas, the locality "berkeley.ca.us", or the LIB.MN.US branch for the libraries in Minnesota.
代表団に関する例はテキサスの12番目のGrade公立の学校を通したKindergarten、場所"berkeley.ca.us"、またはライブラリへのミネソタのLIB.MN.USブランチのためのK12.TX.USです。
The administrator of the US Domain is responsible for the assignment of all the DNS names that end with ".US". Of course, one person or even one group can't handle all this in the long run so portions of the name space are delegated to others.
米国Domainの管理者はその終わりに「.US」と共にすべてのDNS名の課題に責任があります。 もちろん、1人の人か1つのグループさえ結局このすべてを扱うことができないので、スペースという名前の部分を他のものへ代表として派遣します。
The major concern in selecting a designated manager for a domain is that it be able to carry out the necessary responsibilities, and have the ability to do an equitable, just, honest, and competent job.
指定されたマネージャをドメインに選ぶことにおける主要な関心事は必要な責任を行って、公正なまさしく正直で、十分な仕事をする能力を持つことができるということです。
The key requirement is that for each domain there be a designated manager for supervising that domain's name space.
監督するための指定されたマネージャがそのドメインの名前スペースであったなら、主要な要件はそこの各ドメインへのそれです。
These designated authorities are trustees for the delegated domain, and have a duty to serve the community.
当局に指定されたこれらは、代表として派遣されたドメインへの受託者であり、共同体に役立つ義務を持っています。
The designated manager is the trustee of the domain for the domain itself and the global Internet community.
指定されたマネージャはドメイン自体と世界的なインターネット共同体へのドメインの受託者です。
Concerns about "rights" and "ownership" of domains are inappropriate. It is appropriate to be concerned about "responsibilities" and "service" to the community.
ドメインの「権利」と「所有権」に関する心配は不適当です。 「責任」と共同体への「サービス」に関して心配しているのは適切です。
The designated manager must be equitable to all groups in the domain that request domain names.
指定されたマネージャはそのドメインのドメイン名を要求するすべてのグループに公正であるに違いありません。
This means that the same rules are applied to all requests. All requests must be processed in a nondiscriminatory fashion, and academic and commercial (and other) users are treated on an equal basis. No bias shall be shown regarding requests that may come from customers of some other business related to the manager -- e.g., no preferential service for customers of a particular data network provider. There can be no requirement that a particular mail system (or other application), protocol, or product be used.
これは、同じ規則がすべての要求に適用されることを意味します。 nondiscriminatoryファッションですべての要求を処理しなければなりません、そして、アカデミックで商業の、そして、(他)のユーザは対等に扱われます。 要求に関してそれがマネージャと関係があるある他のビジネスの顧客から来るかもしれないのを偏見を全く示さないものとします--例えば、特定のデータ網プロバイダーの顧客にとっての優先ののサービスがありません。 特定のメールシステム(または、他のアプリケーション)、プロトコル、または製品が使用されるという要件が全くあるはずがありません。
There are no requirements on subdomains beyond the requirements on higher-level domains themselves. That is, the requirements are applied recursively. In particular, all subdomains shall be allowed
サブドメインに関する要件は全くよりハイレベルのドメイン自体に関する要件を超えていません。 すなわち、要件は再帰的に適用されます。 特に、すべてのサブドメインが許容されるものとします。
Cooper & Postel [Page 24] RFC 1480 The US Domain June 1993
クーパーとポステル[24ページ]RFC1480米国ドメイン1993年6月
to operate their own domain name servers, providing in them whatever information the subdomain manager sees fit (as long as it is true and correct).
それら自身のドメイン名サーバを操作するために、サブドメインマネージャが見るどんな情報もそれらに提供するのは合いました(それが本当であって、正しい限り)。
Significantly interested parties in the domain should agree that the designated manager is the appropriate party.
かなり、そのドメインの利害関係者は、指定されたマネージャが適切なパーティーであるのに同意するべきです。
The US Domain Administrator tries to have any contending parties reach agreement among themselves, and generally takes no action to change things unless all the contending parties agree; only in cases where the designated manager has substantially neglected their responsibilities would the US Domain Administrator step in.
米国Domain Administratorはどんな戦いパーティーにも自分たちの中で合意に達させようとして、すべての戦いパーティーが同意しないなら、一般に、ものを変えるために行動を全く取りません。 米国Domain Administratorは指定されたマネージャが実質的にそれらの責任を怠ったケースだけの中を干渉するでしょう。
The designated manager must do a satisfactory job of operating the DNS service for the domain.
指定されたマネージャはドメインのためのDNSサービスを操作する満足できる仕事をしなければなりません。
That is, the actual management of the assigning of domain names, delegating subdomains and operating name servers must be done with technical competence. This includes keeping the US Domain Administrator or other higher-level domain managers advised of the status of the domain, responding to requests in a timely manner, and operating the database with accuracy, robustness, and resilience.
すなわち、ドメイン名の割り当ての実際の管理、サブドメインを代表として派遣して、技術的能力でネームサーバを操作しなければなりません。 これは、米国のDomain Administratorか他の、よりハイレベルのドメインがドメインの状態が知らされているマネージャであることを保つのを含んでいます、直ちに要求に応じて、精度、丈夫さ、および弾力でデータベースを操作して。
There must be a primary and a secondary name server that have IP connectivity to the Internet and can be easily checked for operational status and database accuracy by the US Domain Administrator.
Domain AdministratorをIPの接続性をインターネットに持っている第一のネームサーバであって二次ネームサーバでなければならなく、米国は操作上の状態とデータベース精度がないかどうか容易にチェックできます。
One of the aspects of having two name servers for each domain (or zone), is for robustness. One concern under this heading is that the name service not go out entirely if there is a local power failure (earthquake, tornado, or other disaster).
各ドメイン(または、ゾーン)あたり2つのネームサーバを持つ局面の1つは丈夫さのためのそうです。 この見出しの下における1回の関心は完全に地方の停電(地震、竜巻、または他の災害)があれば名前サービスが出かけないということです。
Name Servers should be in distinctly separate physical locations. It is appropriate to have more than two name servers, but there must be at least two.
名前Serversが明瞭に別々の物理的な位置にあるはずです。 2つ以上のネームサーバを持っているのが適切ですが、少なくとも2があるに違いありません。
For any transfer of the designated manager trusteeship from one organization to another, the higher-level domain manager must receive communications from both the old organization and the new organization that assures the US Domain Administrator that the transfer in mutually agreed, and that the new organization understands its responsibilities.
指定されたマネージャ信託統治のどんなある組織から別の組織までの転送のためにも、よりハイレベルのドメインマネージャは古い組織と転送が中で互いに同意して、新しい組織が責任を理解していることを米国Domain Administratorに保証する新しい組織の両方からコミュニケーションを受け取らなければなりません。
It is also very helpful for the US Domain Administrator to receive communications from other parties that may be concerned or affected by the transfer.
また、米国Domain Administratorが転送で関係があるか、または影響を受けるかもしれない相手からコミュニケーションを受け取るのも、非常に役立っています。
Cooper & Postel [Page 25] RFC 1480 The US Domain June 1993
クーパーとポステル[25ページ]RFC1480米国ドメイン1993年6月
Delegation of cities, companies within cities, schools (K12), community colleges (CC), libraries (LIB), state government (STATE), and federal government agencies (FED), etc., is acceptable and practical.
都市の委譲(都市、学校(K12)、コミュニティカレッジ(CC)、ライブラリ(LIB)、州政府(州)、および連邦政府代理店(FED)などの中の会社)は、許容できて実用的です。
For a delegated portion of the name space, for example a city, no alterations can be made to that name, no abbreviations added, etc. unless applied for.
名前スペース、例えば、都市の代表として派遣された部分において、申し込まない場合変更を全くその名前、加えられなかった略語などに全くすることができません。
Sometimes there may be two people running name servers in the same city because different portions of the name space has been delegated to them. For example, someone may be delegated the <city>.<state>.US name space, and someone else from a state government agency may have the .STATE.<state>.US, portion. For example, Fred may run the name servers for Sacramento.CA.US and Joe may run the name servers for STATE.CA.US in Sacramento.
スペースという名前の異なった部分をそれらへ代表として派遣したので同じ都市でネームサーバを実行する2人の人が時々いるかもしれません。 例えば、だれかが代表として派遣して、><都市の<が>.US名前スペースを述べて、州の政府機関からの他の誰かが.STATE.<州の>.US(部分)を持っているかもしれないということであるかもしれません。 例えば、フレッドはSacramento.CA.USのためにネームサーバを実行するかもしれません、そして、ジョーはサクラメントのSTATE.CA.USのためにネームサーバを実行するかもしれません。
If a company would like to have wildcard records added, or run their own name servers in a city that we have delegated name space to, this is acceptable.
会社が私たちが名前スペースを代表として派遣した都市にワイルドカード記録を加えて頂きたいか、またはそれら自身のネームサーバを述べたいなら、これは許容できます。
Delegation of the whole State name space is not yet implemented. The delegated part of the name space is in the form of:
スペースという全体の州名の委譲はまだ実装されていません。 スペースという名前の代表として派遣された部分が以下の形にあります。
.<locality>.<state>.US.
.CI.<locality>.<state>.US.
.CO.<locality>.<state>.US.
.STATE.<state>.US.
.K12.<state>.US.
PVT.K12.<state>.US.
.CC.<state>.US.
.TEC.<state>.US.
.LIB.<state>.US.
.GEN.<state>.US.
.DNI.US.
.FED.US.
. ><場所<州の>.US。 >.CI.<場所<州の>.US。 >.CO.<場所<州の>.US。 .STATE.<州の>.US。 .K12.<州の>.US。 PVT.K12<州の>.US。 .CC.<州の>.US。 .TEC.<州の>.US。 .LIB.<州の>.US。 .GEN.<州の>.US。 .DNI.US。 .FED.US。
3.3.1. Delegation Requirements
3.3.1. 委譲要件
When a subdomain is delegated, the following requirements must be met:
サブドメインを代表として派遣するとき、以下の必要条件を満たさなければなりません:
1) There must be a knowledgeable and competent technical contact,
familiar with the Internet DNS. This requirement is easily
satisified if the technical contact already runs some other
name servers.
1) インターネットDNSに詳しい博識で有能な技術連絡担当者がいるに違いありません。 技術連絡担当者が既にある他のネームサーバを実行するなら、この要件は容易にsatisifiedされます。
Cooper & Postel [Page 26] RFC 1480 The US Domain June 1993
クーパーとポステル[26ページ]RFC1480米国ドメイン1993年6月
2) Organizations requesting delegations must provide at least two
independent (robust and reliable) DNS name servers in
physically separate locations on the Internet.
2) 委譲が少なくとも2独立者(強健で信頼できる)を提供しなければならないよう要求する組織 インターネットの肉体的に別々の位置のDNSネームサーバ。
3) The subdomain must accept all applicants on an equal basis.
3) サブドメインは対等にすべての応募者を受け入れなければなりません。
4) The subdomain must provide timely processing of requests. To
do this, it is helpful to have several individuals
knowledgeable about the procedures so that the operations are
not delayed due to one persons unavailability (for example, by
being on vacation).
4) サブドメインは要求のタイムリーな処理を提供しなければなりません。 これをするために、何人かの個人を手順に関して博識にするのが役立っているので、操作は1つの人々使用不能に当然の状態で遅れません(例えば休みをとっていることによって)。
5) The subdomain manager must tell the US Domain Administrator
when there are changes in the name servers that should be
reflected in the US Domain zone files, or changes in the
contact information.
5) サブドメインマネージャは、いつ、米国Domainゾーンファイルに反映されるべきであるネームサーバにおける変化、または問い合わせ先における変化があるかを米国Domain Administratorに言わなければなりません。
K12 Administrators
K12管理者
In the long term, registering schools will be a big job. So you
need to have in mind delegating parts of the work to various
school districts. If you can delegate every school district in
the state then you are finished, except for checking that they are
all operating correctly. However, initially you will have quite a
bit to do with educating people, helping them choose names and
getting name servers arranged. You are responsible for seeing
that the naming of schools follow the guidelines suggested in this
memo.
長期で、学校を登録するのは、大きい仕事でしょう。 それで、あなたは、仕事の代表として派遣することの部品を様々な学区に考える必要があります。 状態であらゆる学区を代表として派遣することができるなら、彼らが皆、正しく作動しているのをチェックするのを除いて、あなたは終わっています。 しかしながら、初めは、あなたは処理するかなりのビットに人々を教育させるでしょう、彼らが名前を選ぶのを助けて、ネームサーバをアレンジさせて。 学校の命名がこのメモに示されたガイドラインに従うのを見るのにあなたは責任があります。
All K12 Administrators will initially be responsible for managing
the "pseudo district" PVT for private schools. Private schools
have the option of registering as <school-name>.PVT.K12.<state>.US
or as a business under the city based names.
すべてのK12 Administratorsが初めは、私立学校のために「疑似地区」PVTを管理するのに責任があるでしょう。 私立学校には、<学校名の>.PVT.K12.<州の>.USとして、または、企業として都市に基づいている名前の下で登録するオプションがあります。
Locality Administrators
場所の管理者
If you have been delegated a locality subdomain, you will be
responsible for registering not only businesses directly under the
locality, but city and county agencies under the "CI" and "CO"
branches. When appropriate these branches should be delegated.
あなたが代表として派遣して、場所サブドメインでありビジネスだけを登録しないのに責任があるという"CI"の下の場所、都市だけ、およびカウンティーの代理店の直接下のことであるか、そして、「CO」は分岐します。 適切であるときに、これらのブランチを代表として派遣するべきです。
If you want, you may spell out "CITY" instead of "CI" or "COUNTY"
instead of "CO", but you must be consistent and use only one or
the other in a given locality. The whole city government should
be under one branch.
望んでいるなら、"CI"の代わりに「都市」か「CO」の代わりに「カウンティー」について詳しく説明できますが、あなたは、一貫していて、与えられた場所で1かもう片方だけを使用しなければなりません。 全市政府は1つ未満のブランチであるべきです。
Cooper & Postel [Page 27] RFC 1480 The US Domain June 1993
クーパーとポステル[27ページ]RFC1480米国ドメイン1993年6月
WHOIS Database
WHOISデータベース
Only the second and third level delegated name spaces will be
entered in the WHOIS database. For example, K12.CA.US would have
an entry in WHOIS. Anything under K12.CA.US will not be listed.
The US Domain Administrator will send the information that you
supplied on your US Domain template to the InterNIC. It is the
hope that in the future, each delegated subdomain will provide
their own WHOIS directory database for their branch.
空間という2番目と3番目の平らな代表として派遣された名前だけがWHOISデータベースに入れられるでしょう。 例えば、K12.CA.USはWHOISにエントリーを持っているでしょう。 K12.CA.USの下の何も記載されないでしょう。 米国Domain Administratorはあなたがあなたの米国Domainテンプレートの上に提供した情報をInterNICに送るでしょう。 それは彼らのブランチのためのそれら自身のWHOISディレクトリデータベースを将来的で、それぞれ代表として派遣されたサブドメインに提供する望みです。
3.3.2 Delegation Procedures
3.3.2 委譲手順
The procedure that is followed when a subdomain is delegated includes the following steps:
サブドメインを代表として派遣するとき従う手順は以下のステップを含んでいます:
1) Evaluate the technical contact's experience with DNS. Make
sure there is a need for the proposed delegation. Make sure
the technical contact has the information about the US Domain
and the suggested naming structure. Two contacts with email
addresses are necessary in case something goes wrong.
1) DNSの技術連絡担当者の経験を評価してください。 提案された委譲の必要があるのを確実にしてください。 技術連絡担当者には米国Domainと提案された命名構造の情報があるのを確実にしてください。 何かが支障をきたすといけないので、Eメールアドレスとの2つの接触が必要です。
2) Add the new technical contact to the "us-dom-adm" mailing list
for distributing updates concerning the US Domain policies and
procedures.
2) 新しい技術連絡担当者を加える、「私たち、-、dom-adm、」 米国Domain方針と手順に関してアップデートを広げるためのメーリングリスト。
3) Delete any hosts from our zone file that belongs in the newly
delegated subdomain and make sure they now have the hosts in
their zone file.
3) 新たに代表として派遣されたサブドメインにはある私たちのゾーンファイルからあらゆるホストを削除してください、そして、彼らにホストが現在彼らのゾーンファイルにいるのを確実にしてください。
4) Send them a copy of the zone file so their initial zone file
is identical to ours. For example:
4) それらの初期のゾーンファイルが私たちのものと同じであるようにゾーンファイルのコピーをそれらに送ってください。 例えば:
mil.wi.us. 69582 SOA spool.mu.edu.
manager.spool.mu.edu. (
930119 ;serial
28800 ;refresh
14400 ;retry
3600000 ;expire
86400 ) ;minim
mil.wi.us。 69582 SOA spool.mu.edu manager.spool.mu.edu。 (930119; 連続の28800;は14400をリフレッシュします; 3600000を再試行してください; 86400を吐き出してください) ; ミニム
mil.wi.us. 69582 NS spool.mu.edu.
spool.mu.edu. 85483 A 134.48.1.31
mil.wi.us. 69582 NS sophie.mscs.mu.edu.
sophie.mscs.mu.edu. 85483 A 134.48.4.6
solaria.mil.wi.us. 69582 HINFO Sun 3/60 SunOs
solaria.mil.wi.us. 69582 MX 10 spool.mu.edu.
nthomas.mil.wi.us. 69582 HINFO 386 Clone DOS
nthomas.mil.wi.us. 69582 MX 10 spool.mu.edu.
mil.wi.us。 69582 NS spool.mu.edu spool.mu.edu。 85483、134.48 .1 .31 mil.wi.us。 69582 NS sophie.mscs.mu.edu. sophie.mscs.mu.edu。 85483、134.48 .4 .6 solaria.mil.wi.us。 69582 HINFO Sun3/60SunOs solaria.mil.wi.us。 69582 MX10spool.mu.edu nthomas.mil.wi.us。 69582 HINFO386Clone DOS nthomas.mil.wi.us。 69582 MX10spool.mu.edu。
Cooper & Postel [Page 28] RFC 1480 The US Domain June 1993
クーパーとポステル[28ページ]RFC1480米国ドメイン1993年6月
rwmke.mil.wi.us. 69582 HINFO UNIX PC UNIX
rwmke.mil.wi.us. 69582 MX 10 spool.mu.edu.
milestn.mil.wi.us. 69582 MX 10 spool.mu.edu.
nrunner.mil.wi.us. 69582 HINFO MacIntosh System 7
nrunner.mil.wi.us. 69582 MX 10 spool.mu.edu.
dawley.mil.wi.us. 69582 HINFO 386 Clone DOS
dawley.mil.wi.us. 69582 MX 10 spool.mu.edu.
...
rwmke.mil.wi.us。 69582 HINFO UNIX PC UNIX rwmke.mil.wi.us。 69582 MX10spool.mu.edu milestn.mil.wi.us。 69582 MX10spool.mu.edu nrunner.mil.wi.us。 69582 HINFO MacIntosh System7nrunner.mil.wi.us。 69582 MX10spool.mu.edu dawley.mil.wi.us。 69582 HINFO386Clone DOS dawley.mil.wi.us。 69582 MX10spool.mu.edu。 ...
5) The US Domain zone file must have the following records,
showing the name, address, email, and phone number of the
technical contact for the delegated subdomain and the name of
the delegated name space and the names of the name servers.
5) 米国Domainゾーンファイルには、以下の記録がなければなりません、代表として派遣されたサブドメイン、スペースという代表として派遣された名前の名前、およびネームサーバの名前のために技術連絡担当者の名前、アドレス、メール、および電話番号を示して。
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
;Contact: Joseph Klein (tjk@spool.mu.edu)
; Marquette University
; (414) 288-6734
;
;Delegate mil.wi.us zone
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; 接触: ジョゼフクライン( tjk@spool.mu.edu )。 マーケット大学。 (414) 288-6734 ; ; 代表mil.wi.usゾーン
mil.wi.us. 604800 NS SPOOL.MU.EDU.
604800 NS SOPHIE.MSCS.MU.EDU.
mil.wi.us。 604800ナノ秒のSPOOL.MU.EDU。 604800ナノ秒のSOPHIE.MSCS.MU.EDU。
; A glue record is not needed this time. Glue records are
; needed when the name of the server is a subdomain of the
; delegated domain.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; 接着剤記録は必要な今回ではありません。 接着剤記録はそうです。 必要性、サーバの名前がいつでサブドメインであるか、。 ドメインを代表として派遣しました。 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
6) Check to see that delegated subdomain name servers are up and
running, and make sure the delegated hosts are installed in
their zone file. Now delete any hosts from the US Domain zone
file that belongs in the newly delegated subdomain.
6) チェックして、代表として派遣されたサブドメインネームサーバが活動していることを確認してください、代表として派遣されたホストが彼らのゾーンファイルにインストールされるのを確実にしてください。 今度は、新たに代表として派遣されたサブドメインにはある米国Domainゾーンファイルからあらゆるホストを削除してください。
7) Inform the technical contact of the newly delegated subdomain
that wildcard records are allowed in the zone file under the
organizational subdomain but no wildcard records are allowed
under the "city" or "state" domain.
7) ワイルドカード記録が組織的なサブドメインの下におけるゾーンファイルで許されていますが、ワイルドカード記録は全く「都市」か「状態」ドメインの下で許されていないことを新たに代表として派遣されたサブドメインの技術連絡担当者に知らせてください。
8) Make sure each administrator has a copy of this RFC and
follows the guidelines set forth.
8) 各管理者がこのRFCのコピーを持って、詳しく説明されたガイドラインに従うのを確実にしてください。
3.3.3 Subdomain Contacts
3.3.3 サブドメイン接触
The number of hosts registered under each subdomain is unknown. See Section 3.1 for information on the delegated domains and the contacts.
各サブドメインの下で登録されたホストの数は未知です。 代表として派遣されたドメインと接触で情報に関してセクション3.1を見てください。
Cooper & Postel [Page 29] RFC 1480 The US Domain June 1993
クーパーとポステル[29ページ]RFC1480米国ドメイン1993年6月
4. DATABASE INFORMATION
4. データベース情報
4.1. Name Servers
4.1. ネームサーバ
Name servers are the repositories of information that make up the domain database. The database is divided up into sections called zones, which are distributed among the name servers. While name servers can have several optional functions and sources of data, the essential task of a name server is to answer queries using data in its zones. The response to a query can always be generated using only local data, and either contains the answer to the question or a referral to other name servers "closer" to the desired information.
ネームサーバはドメインデータベースを作る情報の倉庫です。 データベースはネームサーバの中で分配されるゾーンと呼ばれるセクションに分割されます。 ネームサーバがデータのいくつかの任意の機能と源を持つことができる間、ネームサーバの不可欠のタスクはゾーンでデータを使用することで質問に答えることです。 質問への応答は、ローカルのデータだけを使用することでいつも生成することができて、「より近いところに必要な情報の」他のネームサーバに質問の答か紹介を含んでいます。
A given zone will be available from several name servers to insure its availability in spite of host or communication link failure. Every zone is required to be available on at least two servers, and many zones have more redundancy than that.
与えられたゾーンは、ホストか通信リンク失敗にもかかわらず、有用性を保障するためにいくつかのネームサーバから利用可能になるでしょう。 あらゆるゾーンが少なくとも2つのサーバで利用可能になるのに必要です、そして、多くのゾーンには、それより多くの冗長があります。
The US Domain is currently supported by seven name servers:
米国Domainは現在、7つのネームサーバによってサポートされます:
venera.isi.edu
ns.isi.edu
rs.internic.net
ns.csl.sri.com
ns.uu.net
adm.brl.mil
excalibur.usc.edu
venera.isi.edu ns.isi.edu rs.internic.net ns.csl.sri.com ns.uu.net adm.brl.mil excalibur.usc.edu
4.2 Zone Files
4.2 ゾーンファイル
A "zone" is a registry of domains kept by a particular organization. A zone registry is "authoritative", that is, the master copy of the registry is kept by the zone organization, and this copy is, by definition, always up-to-date. Copies of this registry may be distributed to other places and kept in caches, but these caches are not authoritative, and may be out-of-date.
「ゾーン」は特定の組織によって保たれたドメインの登録です。 ゾーン登録は「正式です」、そして、すなわち、登録のマスター写しはゾーン組織によって取っておかれます、そして、このコピーは定義上いつも最新です。 この登録の写しが他の場所に分配されて、キャッシュで取っておかれるかもしれませんが、これらのキャッシュは、正式でなく、時代遅れであるかもしれません。
Every zone has at least one node, and hence domain name, for which it is authoritative, and all of the nodes in a particular zone are connected. Given the tree structure, every zone has a highest node which is closer to the root than any other node in the zone. The name of this node is often used to identify the zone. The data that describes a zone has four major parts:
あらゆるゾーンは、少なくとも1つのノードを持っていて、したがって、ドメイン名を持っています、そして、特定のゾーンのノードのすべてが接続されています。(ドメイン名に、それは正式です)。 考えて、木構造、あらゆるゾーンには最も高いノードがあります(根のゾーンのいかなる他のノードよりも近くにあります)。 このノードの名前は、ゾーンを特定するのにしばしば使用されます。 ゾーンについて説明するデータは4つの大半を持っています:
1) Authoritative data for all nodes within the zone.
1) ゾーンの中のすべてのノードのための信頼すべきデータ。
2) Data that defines the top node of the zone
(can be thought of as part of the authoritative data).
2) ゾーン(信頼すべきデータの一部として考えることができる)のトップノードを定義するデータ。
Cooper & Postel [Page 30] RFC 1480 The US Domain June 1993
クーパーとポステル[30ページ]RFC1480米国ドメイン1993年6月
3) Data that describes delegated subzones, i.e., cuts
around the bottom of the zone,
3) それが説明するデータは「副-ゾーン」、すなわち、きり傷をゾーンの下部の周りへ代表として派遣しました。
4) Data that allows access to name servers for subzones
(sometimes called "glue" data).
4) それが許容するデータは「副-ゾーン」のために(時々呼ばれた「接着剤」データ)にネームサーバにアクセスします。
The zone administrator has to maintain the zones at all the name servers which are authoritative for the zone. When the changes are made, they must be distributed to all of the name servers.
ゾーンの管理者はすべてのゾーンに、正式のネームサーバでゾーンを維持しなければなりません。 変更が行われるとき、ネームサーバのすべてにそれらを分配しなければなりません。
Copies of the zone files are not available unless you are on the Internet. To look at the zone files use the "dig" program of the DNS domain name system.
あなたがインターネットにいない場合、ゾーンファイルのコピーは利用可能ではありません。 ゾーンファイルを見るには、DNSドメイン名システムに関する「皮肉」プログラムを使用してください。
dig @nshost host-your-checking axfr
@nshostあなたの照合を主催しているaxfrを掘ってください。
4.3 Resource Records
4.3 リソース記録
Records in the zone data files are called resource records (RRs). The standard Resource records (RR) are specified in STD 13, RFC 1034 and STD 13, RFC 1035 (3,4). An RR has a standard format as shown.
ゾーンデータファイルでの記録はリソース記録(RRs)と呼ばれます。 RFC1035、標準のResourceレコード(RR)が指定されたコネSTD13と、RFC1034とSTD13である、(3、4)。 RRには、標準書式が示されるようにあります。
<name> [<ttl>] [<class>] <type> <data>
<名前>[<ttl>][<のクラス>]<タイプ><データ>。
The first field is always the name of the domain record. The second field is an optional time to live field. This specifies how long this data will be stored in the data base. The third field is the address class; the class field specifies the protocol group most often this is the Internet class "IN". The fourth field states the type of the resource record. The fields after that are dependent on the Type of RR. The fifth field is the data field which is defined differently for each type and class of data. Here is a list of the current commonly used types:
いつも最初の分野はドメイン記録の名前です。 2番目の分野はライブ分野への任意の時間です。 これは、このデータがどれくらい長い間データベースの中に保存されるかを指定します。 3番目の分野はアドレスのクラスです。 類体はプロトコルグループを指定します。インターネットのクラス「IN。」 4番目の分野は、リソースのタイプが記録すると述べます。 その後の分野はRRのTypeに依存しています。 5番目の分野はそれぞれのタイプとクラスに関するデータのために異なって定義されるデータ・フィールドです。 ここに、現在の一般的に使用されたタイプのリストがあります:
SOA Start of Authority
NS Name Server
A Internet Address
CNAME Canonical Name (nickname pointer)
HINFO Host Information
WKS Well Known Services
MX Mail Exchanger
PTR Pointer
Authority NS Name Server AインターネットAddress CNAME Canonical Name(あだ名指針)HINFO Host情報WKS Well Known Services MXメールExchanger PTR PointerのSOA Start
Cooper & Postel [Page 31] RFC 1480 The US Domain June 1993
クーパーとポステル[31ページ]RFC1480米国ドメイン1993年6月
What do the fields mean?
分野は何を意味しますか?
foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU.
(1) (2) (3) (4) (5)
foo.LA.CA.US。 604800 MX10Venera.ISI.EDU。 (1) (2) (3) (4) (5)
1) domain name
2) time to live information
3) mail exchanger record
4) preference value to determine (if more than one
forwarder) which mailer to use first, lower number
higher preference
5) the Internet forwarding host.
1)ドメイン名2) ライブ情報3への時間) 交換器記録的な4) 好みの値を郵送して、どの郵送者を決定するか、そして、(1人以上の混載業者であるなら)最初に、より低く数の、より高い好み5) インターネット推進ホストを使用してください。
4.3.1 "A" Records
4.3.1 記録
Internet (IP) Address. The data for an "A" record is an Internet address in a dotted decimal form. A sample "A" record might look like:
インターネット(IP)アドレス。 「A」記録のためのデータはドット付き10進法フォームでのインターネット・アドレスです。 記録が似るかもしれないサンプル:
venera.isi.edu. A 128.9.0.32
(name) (A) (address)
venera.isi.edu。 A128.9.0.32(命名する)(A)(アドレス)
The name field is the machine name, and the address is the network address. There should be only one "A" record for each address of a host.
名前欄はマシン名です、そして、アドレスはネットワーク・アドレスです。 ホストの各アドレスのための1記録あたり1つしかあるべきではありません。
4.3.2 CNAME Records
4.3.2 CNAME記録
Canonical Name resource record, CNAME, specifies an alias for a canonical name. This is essentially a pointer to the official name for the requested name. All other RRs appear under this official name. A machine named FERNWOOD.MPK.CA.US may want to have the nickname ANTERIOR.MPK.CA.US. In that case, the following RR would be used:
正準なNameリソース記録(CNAME)は正準な名前に別名を指定します。 これは本質的には要求された名前のための正式名称へのポインタです。 他のすべてのRRsがこの正式名称の下に現れます。 FERNWOOD.MPK.CA.USというマシンはあだ名ANTERIOR.MPK.CA.USを必要とするかもしれません。 その場合、以下のRRは使用されるでしょう:
anterior.mpk.ca.us. CNAME fernwood.mpk.ca.us.
(alias nickname) (canonical name)
anterior.mpk.ca.us。 CNAME fernwood.mpk.ca.us。 (別名あだ名) (正準な名前)
Nicknames (the name associated with the RR is the nickname) may be added for awhile when a host changes its name, usually because it moves to another state. It helps to have this CNAME pointer so if any mail comes to the old address it will get forwarded to the new one. There cannot be any other RRs associated with a nickname of the same class.
ホストが改名するとき、あだ名(RRに関連している名前はあだ名である)はしばらく、加えられるかもしれません、通常、別の状態に動くので。 それが、このCNAMEポインタを持っているのを助けるので、何かメールが旧住所に来るなら、新しい方にそれを送るでしょう。 同じクラスに関するあだ名に関連しているいかなる他のRRsもあるはずがありません。
Cooper & Postel [Page 32] RFC 1480 The US Domain June 1993
クーパーとポステル[32ページ]RFC1480米国ドメイン1993年6月
4.3.3 MX Records
4.3.3 MX記録
Mail Exchanger records, MX, are used to specify a machine that knows how to deliver mail to a machine that is not directly connected to the Internet. For example, venera.isi.edu is the mail gateway that knows how to deliver mail to foo.la.ca.us, but other machines on the network cannot deliver mail directly to foo.la.ca.us. These two machines may have a private connection or use a different transport medium (such as uucp). The preference value (10) is the order that a mailer should follow when there is more than one way to deliver mail to a single machine. The lower the number the higher the preference.
メールExchanger記録(MX)は、直接インターネットに接続されないマシンにメールを配達する方法を知っているマシンを指定するのに使用されます。 例えば、venera.isi.eduはそれが、どのようにがメールをfoo.la.ca.usに配達するかを知っているメール・ゲートウェイですが、ネットワークの他のマシンは直接foo.la.ca.usにメールを配達できません。 これらの2台のマシンが、個人的な接続があるか、または異なった輸送培地(uucpなどの)を使用するかもしれません。 メールを単一マシンに配達する1つ以上の方法があるとき、好みの値(10)は郵送者がいうことになるはずであるオーダーです。 数が下位であれば下位であるほど、好みは、より高いです。
foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU.
foo.LA.CA.US. 604800 MX 20 relay1.uu.net.
foo.LA.CA.US。 604800 MX10Venera.ISI.EDU. foo.LA.CA.US。 604800 MX20relay1.uu.net。
4.3.4 HINFO Records
4.3.4 HINFO記録
Host information resource records, HINFO is for host specific data. This lists the hardware and operating system that are running at the listed host. It should be noted that a space separates the hardware information and the operating system information. If you want to include a space in the machine name you must quote the name. Host information is not specific to any class, so ANY may be used for the address class. There should be one HINFO record for each host.
情報リソース記録をホスティングしてください、そして、HINFOはホストの特定のデータのためのものです。 これは記載されたホストを動いているハードウェアとオペレーティングシステムをリストアップします。 スペースがハードウェア情報とオペレーティングシステム情報を切り離すことに注意されるべきです。 マシン名にスペースを含みたいなら、あなたは名前を引用しなければなりません。 ホスト情報は、どんなクラスにも特定でないので、アドレスのクラスに少しも使用されるかもしれません。 各ホストあたり1つのHINFO記録があるべきです。
acb.la.ca.us. HINFO VAX-11/780 UNIX
(Hardware) (Operating System)
acb.la.ca.us。 HINFOバックス-11/780UNIX(ハードウェア)(オペレーティングシステム)
The official HINFO types can be found in the latest Assigned Numbers RFC, the most recent edition being STD 2, RFC 1340 [9]. The hardware type is called the Machine Name, and the software type is called the System Name.
最新のAssigned民数記RFCで公式のHINFOタイプを見つけることができます、最新の版がSTD2であり、RFC1340[9]。 ハードウェアタイプはMachine Nameと呼ばれます、そして、ソフトウェアタイプはSystem Nameと呼ばれます。
The information users supply about this is often inconsistent or incomplete. Please follow the terms in the current "Assigned Numbers".
これに関する情報ユーザ供給は、しばしば無節操であるか、または不完全です。 現在の「規定番号」で用語に従ってください。
4.3.5 PTR Records
4.3.5 PTR記録
A Domain Name Pointer record, PTR, allows special names to point to some other location in the domain data base. These are typically used in setting up reverse pointers for the special IN-ADDR.ARPA domain. PTR names should be unique to the zone.
Domain Name Pointer記録(PTR)で、特別な名前はドメインデータベースの中にある他の位置を示すことができます。 これらは特別なIN-ADDR.ARPAドメインに逆のポインタをセットアップする際に通常使用されます。 PTR名はゾーンにユニークであるべきです。
0.0.9.128.in-addr.arpa PTR isi-net.isi.edu.
(special name) (real name)
addr.arpa PTR isi-net.isi.eduの0.0.9.128.。 (特別な名前) (本名)
Cooper & Postel [Page 33] RFC 1480 The US Domain June 1993
クーパーとポステル[33ページ]RFC1480米国ドメイン1993年6月
A PTR record is to be added to the IN-ADDR.ARPA domain for every "A" record registered in the US Domain. These PTR records need to be added by the administrator of the network where the host is connected. The US Domain Administration does not administer the network and cannot make these entries in the DNS database.
PTR記録は米国ドメインに登録されたあらゆる「A」記録のためにIN-ADDR.ARPAドメインに加えられることです。 これらのPTR記録は、ホストが接続されているネットワークの管理者によって加えられる必要があります。 米国Domain政権は、ネットワークを管理しないで、DNSデータベースにおけるこれらのエントリーをすることができません。
4.4 Wildcards
4.4 ワイルドカード
The wildcard records are of the form "*.<anydomain>", where <anydomain> is any domain name. The wildcards potentially apply to descendents of <anydomain>, but not to <anydomain> itself.
<anydomain>は「ワイルドカード記録は」 *フォーム<anydomain>のものである」あらゆるドメイン名です。 ワイルドカードは、潜在的に<anydomain>のdescendentsに適用しますが、<anydomain>自身に適用されるというわけではありません。
For example, suppose a large company located in California with a large, non-IP/TCP, network wanted to create a mail gateway. If the company was called DWP.LA.CA.US, and the IP/TCP capable gateway machine (Internet forwarder) was called ELROY.JPL.NASA.GOV, the following RRs might be entered into the .US zone.
例えば、大きい非IP/TCP、メール・ゲートウェイを作成して欲しかったネットワークと共にカリフォルニアに位置する大企業を仮定してください。 会社がDWP.LA.CA.USと呼ばれて、IP/TCPのできるゲートウェイマシン(Internet混載業者)がELROY.JPL.NASA.GOVと呼ばれるなら、以下のRRsは.USゾーンに入れられるでしょうに。
dwp.la.ca.us MX 10 ELROY.JPL.NASA.GOV
*.dwp.la.ca.us MX 10 ELROY.JPL.NASA.GOV
dwp.la.ca.us Mx10ELROY.JPL.NASA.GOV*.dwp.la.ca.us Mx10ELROY.JPL.NASA.GOV
The wildcard record *.DWP.LA.CA.US would cause an MX query for any domain name ending in DWP.LA.CA.US to return an MX RR pointing at ELROY.JPL.NASA.GOV. The entry without the "*" is needed so the host dwp can be found.
ワイルドカード記録*.DWP.LA.CA.USはELROY.JPL.NASA.GOVを指し示すMX RRを返すためにDWP.LA.CA.USに終わるどんなドメイン名のためのMX質問も引き起こすでしょう。「*」のないエントリーが、ホストdwpを見つけることができるように必要です。
In the US Domain, wildcard records are allowed in our zone files under the organizational subdomain (and where noted otherwise) but no wildcard records are allowed under the "City" or "State" domain.
米国Domainでは、ワイルドカード記録は組織的なサブドメインの下における私たちのゾーンファイルで許されていますが(別の方法で注意されるところで)、ワイルドカード記録は全く「市」か「状態」ドメインの下で許されていません。
The authors strongly believe that it is in everyone's
interest and good for the Internet to have each host
explicitly registered (that is, we believe that wildcards
should not be used), we also realize that not everyone
agrees with this belief. Thus, we will allow wildcard
records in the US Domain under groups or organizations.
For example, *.DWP.LA.CA.US.
作者はインターネットで明らかに各ホストを登録するのが皆の利益のためにはあって、良いと強く信じています(すなわち、私たちは、ワイルドカードが使用されるべきでないと信じています)、また、私たちは皆がこの信念に同意するというわけではないとわかります。 したがって、私たちはグループか組織で米国Domainでのワイルドカード記録を許すつもりです。 例えば、*.DWP.LA.CA.US。
The reason we feel single entries are the best is by the mere
fact that if anyone wanted to find one of the hosts in the
domain name system it would be there, and problems can be
detected more easily. When using wildcards records all the
hosts under a subdomain are hidden.
だれかがドメイン名システムでホストのひとりを見つけたいならそれがそこにあって、より容易に問題は検出できるという単なる事実で私たちが、単一のエントリーが最も良いと感じる理由があります。 ワイルドカード記録を使用するとき、サブドメインの下におけるすべてのホストが隠されます。
Cooper & Postel [Page 34] RFC 1480 The US Domain June 1993
クーパーとポステル[34ページ]RFC1480米国ドメイン1993年6月
5. REFERENCES
5. 参照
[1] Stahl, M., "Domain Administrators Guide", RFC 1032, SRI
International, November 1987.
[1] スタール、M.、「ドメイン管理者のガイド」、RFC1032、SRIインターナショナル、1987年11月。
[2] Lottor, M., "Domain Administrators Operations Guide" RFC 1033,
SRI International, November 1987.
[2]Lottor、M.、「操作が誘導するドメイン管理者」RFC1033、SRIインターナショナル、1987年11月。
[3] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, ISI, November 1987.
[3]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、ISI、11月1987日
[4] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, ISI, November 1987.
[4]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、ISI、11月1987日
[5] Dunlap, K., "Name Server Operations Guide for Bind,
Release 4.3", UC Berkeley, SMM:11-3.
[5] ダンラップ、K.、「ネームサーバ操作はひも、リリースのためにSMM: 4.3インチ、UCバークレー、11-3を誘導します」。
[6] Partridge, C., "Mail Routing and the Domain Name System",
STD 14, RFC 974, BBN, January 1986.
[6] ヤマウズラ、C.が「ルート設定とドメインネームシステムを郵送する」、STD14、RFC974、BBN、1月1986日
[7] Albitz, P., C. Liu, "DNS and Bind" Help for UNIX System
Administrators, O'Reilly and Associates, Inc., October 1992.
[7] Albitzと、P.と、C.リュウと、「DNSとひも」はUNIXシステム管理者、オライリー、および仲間Inc.、10月1992日のために助けます。
[8] ACM SIGUCCS Networking Taskforce, "Connecting to the Internet -
What Connecting Institutions Should Anticipate", FYI 16,
RFC 1359, August 1992.
[8] ACM SIGUCCSがTaskforceをネットワークでつなぐ場合、「インターネットに接続します--どんな接続団体が予期するべきである」、FYI16、RFC1359(1992年8月)
[9] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1340, ISI, July 1992.
[9] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1340、ISI、1992年7月。
6. Security Considerations
6. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Cooper & Postel [Page 35] RFC 1480 The US Domain June 1993
クーパーとポステル[35ページ]RFC1480米国ドメイン1993年6月
7. Authors' Addresses
7. 作者のアドレス
Ann Cooper USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: 1-310-822-1511 Email: cooper@isi.edu
アンクーパーUSC/Information Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292電話: 1-310-822-1511 メールしてください: cooper@isi.edu
Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: 1-310-822-1511 Email: postel@isi.edu
ジョンポステルUSC/Information Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292電話: 1-310-822-1511 メールしてください: postel@isi.edu
Cooper & Postel [Page 36] RFC 1480 The US Domain June 1993
クーパーとポステル[36ページ]RFC1480米国ドメイン1993年6月
APPENDIX-I: US DOMAIN NAMES BNF
================================
付録I: 米国ドメイン名BNF================================
<us-domain-name> ::= <us-name><dot><us>
<、私たち、-、ドメイン名>:、:= <、私たち、-ドット><と><を命名してください、私たち、>。
<us-name> ::= <state-name><dot><state-code> |
<fed-name><dot><fed>
<dni-name><dot><dni>
<、私たち、->を命名してください:、:= <州名の><ドット><州コード>。| ><dni-名の><ドット><dni>が与えられた<の食べさせられた名前の><ドット><。
<state-code> ::= <the two-letter code of a state from the
zip code directory>
<州コード>:、:= <郵便番号ディレクトリからの状態の2レター・コード>。
<state-name> ::= <local-name><dot><locality> |
<state-agency-name><dot><state> |
<regional-agency-name><dot><agency>
<州名の>:、:= <地方名><ドット><場所>。| <州代理店名の><ドット><州の>。| 地方の政府機関の名前の<の><ドット><代理店>。
<fed-name> ::= <the dotted hierarchical name of a US
federal government agency>
<の食べさせられた名前の>:、:= <は米国連邦政府政府機関>の点を打たされた階層的な名前です。
<dni-name> ::= <the dotted hierarchical name of a
distributed national institution>
<dni-名の>:、:= <は分配された国家の団体>の点を打たされた階層的な名前です。
<locality> ::= <the full name of a city from the
zip code directory> |
<a short code name for a city> |
<the full name of a county, township,
or parish> |
<other well known and commonly used
locality name>
<場所>:、:= 完全が命名する郵便番号ディレクトリ>からの都市の<。| <は都市の>に、短いコードネームです。| 完全が命名するカウンティー、郡区、または教区>の<。| 他のよく知られていて一般的に使用された場所が>と命名する<。
<local-name> ::= <entity-name> |
<city-name><dot><city> |
<county-name><dot><county> |
<local-agency-name><dot><local-agency>
<地方名>:、:= <実体名の>。| <都市名の><ドット><都市の>。| <カウンティー名の><ドット><カウンティーの>。| 地方の政府機関の名前の<の><ドット><地方政府機関>。
<state-agency-name> ::= <the dotted hierarchical name of a state
government agency>
<州代理店名の>:、:= <は州の政府機関>の点を打たされた階層的な名前です。
<regional-agency-name> ::= <the dotted hierarchical name of a
special agency or district not an
element of the state government and
typically larger than a single city or
county, for example, the Southern
California Air Quality Management District>
<の地方の政府機関の名前の>:、:= <は単一の都市かカウンティーより州政府の要素と通常大きくない特別な政府機関か地区の点を打たされた階層的な名前、例えば、南カリフォルニアAir Quality Management District>です。
Cooper & Postel [Page 37] RFC 1480 The US Domain June 1993
クーパーとポステル[37ページ]RFC1480米国ドメイン1993年6月
<entity-name> ::= <the dotted hierarchical name of an
entity within a city, for example: a
company, business, private school, club,
organization, or individual>
<実体名の>:、:= <、例えば、都市の中で実体の階層的な名前に点を打たせます: 会社、ビジネス、私立学校、クラブ、組織、または個々の>。
<city-name> ::= <the dotted hierarchical name of a city
government agency>
<都市名の>:、:= <は市庁政府機関>の点を打たされた階層的な名前です。
<county-name> ::= <the dotted hierarchical name of a county,
township, or parish government agency>
<カウンティー名の>:、:= <はカウンティー、郡区、または教区政府機関>の点を打たされた階層的な名前です。
<local-agency-name> ::= <the dotted hierarchical name of a special
agency or district not an element of a
city or county government and typically
equal or smaller than a single city or
county, for example, the Bunker Hill
Improvement District>
<の地方の政府機関の名前の>:、:= 特別な政府機関か地区の点を打たされた階層的な名前が都市か郡政府の要素と通常等しくない<かシングルより小さい都市かカウンティー、例えば、バンカー・ヒルImprovement District>。
<city> ::= "CI" | "CITY"
<都市の>:、:= "CI"| 「都市」
<county> ::= "CO" | "COUNTY" | "TOWNSHIP" | "PARISH"
<カウンティーの>:、:= 「CO」| 「カウンティー」| 「郡区」| 「教区」
<dot> ::= "."
<ドット>:、:= "."
<fed> ::= "FED"
<は>に食べさせました:、:= 「食べます」。
<dni> ::= "DNI"
<dni>:、:= "DNI"
<state> ::= "STATE" | "COMMONWEALTH"
<州の>:、:= 「状態」| 「連邦」
<agency> ::= "AGENCY" | "DISTRICT" | "K12" | "CC" | "LIB" |
"GEN" | "TEC"
<代理店>:、:= 「政府機関」| 「地区」| "K12""| 「CC」| 「リブ」| 「情報を得てください」| 「テック」
<local-agency> ::= "AGENCY" | "DISTRICT"
<地方政府機関>:、:= 「政府機関」| 「地区」
<us> ::= "US"
<、私たち、>:、:= 「米国」
Notes:
注意:
Within States:
州の中で:
"K12" may be used for public school districts. A special name "PVT" can be used in the place of a school district name for private schools.
「K12"は公立の学校地区に使用されるかもしれません。」 私立学校に学区名の場所で特別な名前"PVT"を使用できます。
"CC" may be used only for public community colleges.
「CC」は公立のコミュニティカレッジにだけ使用されるかもしれません。
Cooper & Postel [Page 38] RFC 1480 The US Domain June 1993
クーパーとポステル[38ページ]RFC1480米国ドメイン1993年6月
"LIB" may be only used by libraries.
"LIB"はライブラリによって使用されるだけであるかもしれません。
"TEC" is used only for technical and vocational schools and colleges.
"TEC"は技術的で職業上の学校と大学にだけ使用されます。
"GEN" is for general independent entities, that is, organizations that don't really fit anywhere else (such as statewide associations, clubs, and "domain parks").
"GEN"は一般的な独立実体(すなわち、本当に、他のどこか(州全体の協会や、クラブや、「ドメイン公園」などの)に合わない組織)のためのものです。
"STATE" may be used only for state government entities.
「州」は州の政府の法人にだけ使用されるかもしれません。
Below US, parallel to States:
米国の下では、Statesに以下に沿ってください。
"FED" is for agencies of the federal government.
"FED"は連邦政府の政府機関のためのものです。
"DNI" is for distributed national institutes; organizations that span state, regional, and other organizational boundaries; that are national in scope, and have distributed facilities.
"DNI"は分配された国家の研究所のためのものです。 状態にかかる組織、地方の、そして、他の組織境界。 それは、範囲で国家であり、施設を分配しました。
Examples: =========
例: =========
Geo-Petrellis.Culver-City.CA.US <== resturant
ジオ-Petrellis.Culver-City.CA.US<=resturant
Joe-Josts.Long-Beach.CA.US <== bar
ジョー-Josts.Long-Beach.CA.US<=バー
IBM.Armonk.NY.US <== business
IBM.Armonk.NY.US<=ビジネス
Camp-Curry.Yosemite.CA.US <== business
キャンプ-Curry.Yosemite.CA.US<=ビジネス
Yosemite.NPS.Interior.FED.US <== federal agency
Yosemite.NPS.Interior.FED.US<=連邦機関
Senate.FED.US <== US Senate
米国Senate.FED.US<=上院
DOD.FED.US <== US Defense Dept.
DOD.FED.US<=米国ディフェンス部
DOT.FED.US <== US Transportation Dept.
DOT.FED.US<=米国輸送部
MNPL.FRB.FED.US <== the Minneapolis branch of
the Federal Reserve Bank
連邦準備銀行のミネアポリスMNPL.FRB.FED.US<=支店
MetaCenter.DNI.US <== distributed Nat'l Inst
MetaCenter.DNI.US<=はNat'l Instを分配しました。
Senate.STATE.MN.US <== state Senate
州のSenate.STATE.MN.US<=上院
House.STATE.MN.US <== state House of Reps
Reps House.STATE.MN.US<=州の家
Assembly.STATE.CA.US <== state Assembly
州のAssembly.STATE.CA.US<=議会
Cooper & Postel [Page 39] RFC 1480 The US Domain June 1993
クーパーとポステル[39ページ]RFC1480米国ドメイン1993年6月
MDH.STATE.MN.US <== state Health Dept.
州のHealth MDH.STATE.MN.US<=部
DOT.STATE.MN.US <== state Transportation Dept
州のTransportation DOT.STATE.MN.US<=部
CALTRANS.STATE.CA.US <== state Transportation Dept
州のTransportation CALTRANS.STATE.CA.US<=部
DMV.STATE.CA.US <== state Motor Vehicles Dept
州のMotor Vehicles DMV.STATE.CA.US<=部
Culver-City.DMV.STATE.CA.US <== local office of DMV
DMVのカルバー-City.DMV.STATE.CA.US<=地方支店
Police.CI.Culver-City.CA.US <== city department
都市のPolice.CI.Culver-City.CA.US<=部
Fire-Dept.CI.Los-Angeles.CA.US <== city department
都市の炎部のCI.Los-Angeles.CA.US<=部
Fire-Dept.CO.Los-Angeles.CA.US <== county department
カウンティーの炎部のCO.Los-Angeles.CA.US<=部
Main.Library.CI.Los-Angeles.CA.US <== city department
都市のMain.Library.CI.Los-Angeles.CA.US<=部
MDR.Library.CO.Los-Angeles.CA.US <== county department
カウンティーのMDR.Library.CO.Los-Angeles.CA.US<=部
Huntington.LIB.CA.US <== private library
Huntington.LIB.CA.US<=私用ライブラリ
SMCC.Santa-Monica.CC.CA.US <== public community college
公立のSMCC.Santa-Monica.CC.CA.US<=コミュニティカレッジ
Trade-Tech.Los-Angeles.CC.CA.US <== public community college
公立の貿易-Tech.Los-Angeles.CC.CA.US<=コミュニティカレッジ
Valley.Los-Angeles.CC.CA.US <== public community college
公立のValley.Los-Angeles.CC.CA.US<=コミュニティカレッジ
Hamilton.High.LA-Unified.K12.CA.US <== public school
Hamilton.High.LA-Unified.K12.CA.US<=公立の学校
Sherman-Oaks.Elem.LA-Unified.K12.CA.US <== public school
シャーマン-Oaks.Elem.LA-Unified.K12.CA.US<=公立の学校
John-Muir.Middle.Santa-Monica.K12.CA.US <== public school
ジョン-Muir.Middle.Santa-Monica.K12.CA.US<=公立の学校
St-Monicas.High.Santa-Monica.CA.US <== private school
通り-Monicas.High.Santa-Monica.CA.US<=私立学校
Crossroads-School.Santa-Monica.CA.US <== private school
交差点-School.Santa-Monica.CA.US<=私立学校
Mary-Ellens-Montessori-School.LA.CA.US <== private school
メアリEllensモンテッソーリSchool.LA.CA.US<=私立学校
Progress-Learning-Center.PVT.K12.CA.US <== private school
進歩学習Center.PVT.K12.CA.US<=私立学校
Brick-and-Basket-Institute.TEC.CA.US <== technical college
レンガとかごのInstitute.TEC.CA.US<=工科大学
Bunker-Hill.DISTRICT.Los-Angeles.CA.US <== local district
地方のバンカー-Hill.DISTRICT.Los-Angeles.CA.US<=地区
SCAQMD.DISTRICT.CA.US <== regional district
地方のSCAQMD.DISTRICT.CA.US<=地区
Cooper & Postel [Page 40] RFC 1480 The US Domain June 1993
クーパーとポステル[40ページ]RFC1480米国ドメイン1993年6月
Berkeley.UC.STATE.CA.US <== "CAL"
Berkeley.UC.STATE.CA.US<=「CAL」
Los-Angeles.UC.STATE.CA.US <== UCLA
ロス-Angeles.UC.STATE.CA.US<=UCLA
Irvine.UC.STATE.CA.US <== UC Irvine
UC Irvine.UC.STATE.CA.US<=アーバイン
Northridge.CSU.STATE.CA.US <== CSUN
Northridge.CSU.STATE.CA.US<=CSUN
Los-Angeles.CSU.STATE.CA.US <== Cal State LA
カル州のロス-Angeles.CSU.STATE.CA.US<=LA
Leland-Stanford-Jr-University.Stanford.CA.US <== private school
リーランドスタンフォードJr-University.Stanford.CA.US<=私立学校
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Cooper & Postel [Page 41] RFC 1480 The US Domain June 1993
クーパーとポステル[41ページ]RFC1480米国ドメイン1993年6月
APPENDIX-II: US DOMAIN QUESTIONNAIRE FOR HOST ENTRY
付録II: ホストエントリーのための米国のドメインアンケート
To register a host in the US domain, the US Domain Template must be sent to the US Domain Registrar (US-Domain@ISI.EDU). The first few pages explain each question on the attached template. FILL OUT THE TWO PAGE TEMPLATE AT THE END. Questions may be sent by electronic mail to the above address, or by phone to Ann Cooper, USC/Information Sciences Institute, (310) 822-1511.
米国ドメインにホストを登録するために、米国Domain Registrar( US-Domain@ISI.EDU )に米国Domain Templateを送らなければなりません。 最初の数ページで、付属テンプレートの各質問がわかります。 終わりに2ページのテンプレートに書き込んでください。 上のアドレスへの電子メール、またはアン・クーパーへの電話で質問を送るかもしれません、USC/情報Sciences Institute、(310)822-1511。
(1) Please specify whether this is a new application, modification to
an existing registration, or deletion.
(1) これが新しいアプリケーション、既存の登録、または削除への変更であるかどうか指定してください。
(2) The name of the domain. This is the name that will be used in
tables and lists associating the domain with the domain server
addresses. See RFC 1480 - The US Domain for more details.
(2) ドメインの名前。 これはドメインサーバアドレスにドメインを関連づけながらテーブルとリストで使用される名前です。 RFC1480を見てください--その他の詳細のための米国Domain。
<host>.<city/locality>.<state>.US. = city/locality based names
<school>.<district>.K12.<state>.US. = kindergarten thru 12th grade
<school>.PVT.K12.<state>.US. = private K thru 12th grade
<school>.<locality>.<state>.US. = PVT sch opt: locality names
<school>.CC.<state>.US. = community colleges
<school>.TEC.<state>.US. = technical or vocational schools
<lib-name>.LIB.<state>.US. = libraries
<org-name>.STATE.<state>.US. = state government agencies
<org-name>.FED.US. = federal government agencies
<org-name>.DNI.US. = distributed national institutes
<org>.GEN.<state>.US. = statewide assoc,clubs,domain parks
<ホスト><都市/場所><州の>.US。 = 都市/場所は名前<学校><地区>.K12.<州の>.USを基礎づけました。 = 12年<学校>.PVT.K12.<州の>.USを通した幼稚園。 = >12年<学校><場所<州の>.USを通した個人的なK。 = PVT schは選びます: 場所は.CC.<州の>.USと<学校>を命名します。 = コミュニティカレッジ<学校>.TEC.<は>.USを述べます。 = 技術的であるか職業上の学校<リブ名の>.LIB.<州の>.US。 = ライブラリ<組織名>.STATE.<は>.USを述べます。 = 政府機関<組織名>.FED.USを述べてください。 = 連邦政府政府機関<組織名>.DNI.US。 = 分配された国家の研究所<org>.GEN.<州の>.US。 = 州全体のassoc、クラブ、ドメイン公園
For example: networthy.santa-clara.ca.us.
例えば: networthy.santa-clara.ca.us。
(3) The name of the entity represented, that is, the organization
being named. For example: The Networthy Corporation. Not the
name of the organization submitting the request.
実体の名前が表した(3)、すなわち、命名される組織。 例えば: Networthy社。 要求を提出する組織名でない。
(4) Please describe the domain briefly.
(4) 簡潔にドメインについて説明してください。
For example: The Networthy Corporation is a consulting
organization of people working with UNIX and the C language
in an electronic networking environment. It sponsors two
technical conferences annually and distributes a bimonthly
newsletter.
例えば: Networthy社は、UNIXと共に働いている人々のコンサルティング組織と電子ネットワーク環境でC言語です。 それは、毎年2つの技術的な会議を後援して、隔月のニュースレターを分配します。
(5) The date you expect the domain to be fully operational.
(5) あなたがドメインが完全に操作上であると予想する日付。
Cooper & Postel [Page 42] RFC 1480 The US Domain June 1993
クーパーとポステル[42ページ]RFC1480米国ドメイン1993年6月
For every registration, we need both the Administrative and the Technical contacts of a domain (questions 6 & 7) and we MUST have a network mailbox for each. If you have a NIC handle (a unique NIC database identifier) please enter it. (If you don't know what a NIC handle is leave it blank). Also the title, mailing address, phone number, organization, and network mailbox.
あらゆる登録のために、私たちはAdministrativeとドメイン(質問6と7)のTechnical接触の両方を必要とします、そして、それぞれのためのネットワークメールボックスを持たなければなりません。 NICに(ユニークなNICデータベース識別子)を扱わせるなら、それに入ってください。 (NICハンドルが何であるかを知らないなら、それを空白の状態でおいてください。) タイトル、郵送先住所、電話番号、組織、およびネットワークメールボックスも。
(6) The name of the administrative head of the "organization". The
administrator is the contact point for administrative and policy
questions about the domain. The Domain administrator should work
closely with the personnel he has designated as the "technical
contact" for his domain. In this example the Domain Administrator
would be the Administrator of the Networthy Corporation, not the
Administrator of the organization running the name server
(unless it is the same person).
(6) 「組織」の管理ヘッドの名前。 管理者はドメインに関する管理と方針質問のための接点です。 Domain管理者は彼が彼のドメインへの「技術連絡担当者」として任命した人員と共に緊密に働くべきです。 この例では、Domain Administratorはネームサーバを実行する組織のAdministratorではなく、Networthy社のAdministrator(それが同じ人でないなら)でしょう。
(7) The name of the technical and zone contact. The technical and
zone contact handles the technical aspects of maintaining the
domain's name server and resolver software, and database files.
He keeps the name server running. More than likely, this person
would be the technical contact running the primary name server.
(7) 技術的、そして、ゾーン接触の名前。 技術的、そして、ゾーン接触はドメインのネームサーバ、レゾルバソフトウェア、およびデータベース・ファイルを維持する技術的側面を扱います。 彼はネームサーバが稼働させ続けます。 十二分にありそうであることで、この人はプライマリネームサーバを実行する技術連絡担当者でしょう。
***********************************************************************
***********************************************************************
PLEASE READ: There are several types of registrations.
読んでください: いくつかのタイプの登録証明書があります。
(a) Delegation (i.e., a portion of the US Domain name space is
given to an organization running name servers to support that
branch; For example, K12.TX.US, for all K12 schools in Texas).
For (a) answer questions 8 and 9.
(a) 委譲(すなわち、スペースという米国Domain名の部分をサポートする分岐するネームサーバを実行する組織に与えます; 例えば、K12.TX.US、すべてに関して、K12はテキサスに群がります)。 (a)に、質問8と9に答えてください。
(b) Direct Registration of an IP Host.
For (b) answer question 10.
(b) IPホストの登録を指示してください。 質問10に(b)に答えてください。
(c) Direct Registration of a non-IP Host.
For (c) answer question 11 and 12.
(c) 非IPホストの登録を指示してください。 質問11と12に(c)に答えてください。
***********************************************************************
***********************************************************************
QUESTIONS FOR DELEGATIONS
委譲のための問題
(8) PRIMARY SERVER Information. It is required to supply both the
Contact information as well as hardware/software information of
the primary name server.
(8) プライマリサーバ情報。 それが、Contact情報とプライマリネームサーバのハードウェア/ソフトウェア情報の両方を提供するのに必要です。
(9)* SECONDARY SERVER Information. It is required to supply the
hardware and software information of all secondary name servers.
(9)* セカンダリサーバ情報。 それが、すべてのセカンダリネームサーバの情報をハードウェアとソフトウェアに提供するのに必要です。
Cooper & Postel [Page 43] RFC 1480 The US Domain June 1993
クーパーとポステル[43ページ]RFC1480米国ドメイン1993年6月
Domains must provide at least two independent servers that provide the domain service for translating names to addresses for hosts in this domain. If you are applying for a domain and a network number assignment simultaneously and a host on your proposed network will be used as a server for the domain, you must wait until you receive your network number assignment and have given the server(s) a net- address before sending in the domain application. Establishing the servers in physically separate locations and on different PSNs and/or networks is strongly recommended.
ドメインはこのドメインのホストのために名前をアドレスに翻訳するためのドメインサービスを提供する少なくとも2つの独立しているサーバを提供しなければなりません。 あなたが同時に、ドメインとネットワーク・ナンバー課題に申し込んで、あなたの提案されたネットワークのホストがドメインにサーバとして使用されるなら、あなたは、あなたがネットワーク・ナンバー課題を受け取るまで待たなければならなくて、ドメインアプリケーションを送る前に、ネットのアドレスをサーバに与えました。 肉体的に別々の位置と異なったPSNs、そして/または、ネットワークの上でサーバを確立するのは強く推薦されます。
NOTE: For those applicants not able to run name servers, or for non-IP hosts the Name Server information is not applicable. (See #10 and #11). ======================================================================= QUESTION FOR DIRECT IP HOSTS (If you answered 8 & 9 do not answer 10, 11, or 12).
以下に注意してください。 走行ネームサーバ、または非IPホストには、有能でないそれらの応募者にとって、Name Server情報は適切ではありません。 (#10、と#11、を見ます。) ======================================================================= QUESTION FOR DIRECT IP HOSTS(あなたが8に答えて、9が10、11、または12に答えないなら)。
(10) What Domain Name System (DNS) Resource Records (RR) and values are
to be entered for your IP host (must have an "A" record).
(10) どんなドメインネームシステム(DNS)リソースRecords(RR)と値があなたのIPホストのために入られる(「A」を記録させなければなりません)ことですか?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Example: RRs for an INTERNET hosts.
+++++++++++++++++++++++++++++++++++++++++ + + + + + + + + + + + + + + + + + + + + + + + + + 例: インターネット・ホストのためのRRs。
(a) DOMAIN NAME (required)...: Networthy.Santa-Clara.CA.US.
(b) IP ADDRESS (required)....: A 128.9.3.123 (required)
(c) HARDWARE (opt)...........: SUN-3/11O
(d) OPERATING SYS (opt)......: UNIX
(e) WKS (opt)........: 128.9.3.123. UDP (echo tftp) TCP (ftp)
(f) MX (opt).................: 10 RELAY.ISI.EDU.
(a) ドメイン名(必要です)…: Networthy.Santa-Clara.CA.US。 (b) IPアドレス(必要です)…: A128.9.3.123(必要である)(c)ハードウェア(選びます)…: SYS(選ぶ)を操作する太陽-3/11O(d)…: (e) UNIX WKS(選びます)…: 128.9.3.123. UDP(エコーtftp)TCP(ftp)(f)MX(選びます)…: 10 RELAY.ISI.EDU。
It is your responsibility to see that an IN-ADDR pointer record is entered in the DNS database. (For Internet hosts only). Contact the administrator of the IP network your host is on to have this done. The US Domain administration does not administer the network and cannot make these entries in the DNS database.
IN-ADDR指針記録がDNSデータベースに入力されるのを確実にするのは、あなたの責任です。 (インターネット・ホストだけのための。) これを完了させるためにあなたのホストがいるIPネットワークの管理者に連絡してください。 米国のDomain運営は、ネットワークを管理しないで、DNSデータベースにおけるこれらのエントリーをすることができません。
======================================================================= QUESTIONS FOR NON-IP HOSTS (such as UUCP).
======================================================================= 非IPホスト(UUCPなどの)のための問題。
Many applicants have hosts in the UUCP world. Some are one hop away, some two and three hops away from their "Internet Forwarder", this is ok. What is important is getting an Internet host to be your forwarder. If you do not already have an Internet forwarder, there are several businesses that provide this service for a fee, (see RFC 1359 - Connecting to the Internet What Connecting Institutions Should Anticipate, ACM SIGUCCS, August 1992). Sometimes local colleges in your area are already on the Internet and may be willing to act as an Internet Forwarder. You would need to work this out with the systems administrator. We cannot make these arrangements for you.
多くの応募者には、UUCP世界にホストがいます。 或るものは遠くでワンバウンドです、そして、何らかの2であり、それらの「Internet混載業者」から遠くの3つのホップでありこれは間違いありません。 重要なことは、インターネット・ホストがあなたの混載業者であることを得ています。 あなたにInternet混載業者が既にいないなら、数個のビジネスがあります。それは、(RFC1359を見てください--1992年8月にインターネットWhat Connecting Institutions Should Anticipate、ACM SIGUCCSに接続します。)と有料でこのサービスを前提とします。 あなたの領域の地元大学は、時々、インターネットに既にあって、インターネットForwarderとして機能しても構わないと思っているかもしれません。 あなたは、上級システムアドミニストレータと共にこれを解決する必要があるでしょう。 私たちはあなたのためにこれらの手配をすることができません。
Cooper & Postel [Page 44] RFC 1480 The US Domain June 1993
クーパーとポステル[44ページ]RFC1480米国ドメイン1993年6月
(11) Internet Forwarding Host Information
(11) インターネット推進ホスト情報
(11a) What is the name of your Internet forwarding host?
For example: The host Yacht-Club.MDR.CA.US uses
UUCP to connect to RELAY.ISI.EDU which is an Internet
host. (i.e., RELAY.ISI.EDU is the forwarding host).
(11a)、あなたのインターネット推進ホストの名前は何ですか? 例えば: ホストYacht-Club.MDR.CA.USは、インターネット・ホストであるRELAY.ISI.EDUに接続するのにUUCPを使用します。 (すなわち、RELAY.ISI.EDUは推進ホストです。)
(11b) What is the name of your contact person at forwarding host?
The Administrator of RELAY.ISI.EDU must agree to be the
forwarding host for Yacht-Club.MDR.CA.US, and the
forwarding host must know a delivery method and route to
Networthy. No double MXing.
(11b) 推進ホストのあなたの連絡窓口の名前は何ですか? RELAY.ISI.EDUのAdministratorは、Yacht-Club.MDR.CA.USの推進ホストであるのに同意しなければなりません、そして、推進ホストはNetworthyにおいて発送方法とルートを知らなければなりません。 二重MXingがありません。
(11c) What is the mailbox of your contact?
What is the mailbox of the administrator of the forwarding
host.
(11c) あなたの接触のメールボックスは何ですか? 推進ホストの管理者のメールボックスであること。
Example: Contact Name......: John Smith
Contact Email.....: js@RELAY.ISI.EDU
例: 名前に連絡してください…: ジョンスミス連絡Email…: js@RELAY.ISI.EDU
(12) What Domain Name System (DNS) Resource Records (RR) and values
are to be entered for your NON-IP host.
(12) どんなドメインネームシステム(DNS)リソースRecords(RR)と値があなたのNON-IPホストのために入られることですか?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Example: RRs for a NON-IP host (uucp).
+++++++++++++++++++++++++++++++++++++++++ + + + + + + + + + + + + + + + + + + + + + + + + + 例: NON-IPのためのRRsは(uucp)を接待します。
(a) DOMAIN NAME (required).....: Yacht-Club.MDR.CA.US.
(b) HARDWARE (opt).............: SUN-3/11O
(c) OPERATING SYS (opt)........: UNIX
(d) MX (required)..............: 10 RELAY.ISI.EDU.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
(a) ドメイン名(必要です)…: ヨット-Club.MDR.CA.US。 (b) ハードウェア(選びます)…: SYS(選ぶ)を操作する太陽-3/11O(c)…: (d) UNIX MX(必要です)…: 10 RELAY.ISI.EDU。 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PLEASE ALLOW AT LEAST 8 WORKING DAYS FOR PROCESSING THIS APPLICATION
少なくとも8営業日の間、処理には、このアプリケーションを許容してください。
Cooper & Postel [Page 45] RFC 1480 The US Domain June 1993
クーパーとポステル[45ページ]RFC1480米国ドメイン1993年6月
US DOMAIN TEMPLATE [6/93]
米国ドメインテンプレート[6/93]
PLEASE SUBMIT THE FOLLOWING TWO PAGE TEMPLATE TO (Us-Domain@isi.edu).
Sections or fields of this form marked with an asterisk (*) may be
copied as many times as necessary. (For example: If you had two phone
numbers for the Administrative Contact, you would use the same number
"6h" twice. PLEASE DO NOT ALTER THIS APPLICATION IN ANY WAY.
=====================================================================
1. REGISTRATION TYPE
(N)ew (M)odify (D)elete..:
以下の2ページのテンプレートを( Us-Domain@isi.edu )に提出してください。 アスタリスク(*)でマークされたこのフォームのセクションか分野が必要な同じくらい何回もコピーされるかもしれません。 あなたがAdministrative Contactのための2つの電話番号を持っているなら、あなたは同じ数の"6h"2倍PLEASE DO NOT ALTER THIS APPLICATION IN ANY WAYを使用するでしょうに。(例えば、: = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 1REGISTRATION TYPE(N)ew(M)が(D) eleteをodifyする、:
2.* FULLY-QUALIFIED DOMAIN NAME:
2. *完全修飾ドメイン名:
3. ORGANIZATION INFORMATION
3a. Organization Name.....:
3b. Address Line 1........:
3b. Address Line 2........:
3c. City..................:
3d. State.................:
3e. Zip/Code..............:
3. 組織情報3a。 組織名…: 3b。 線1を扱ってください…: 3b。 線2を扱ってください…: 3c。 市…: 3d。 状態…: 3e。 郵便番号/コード…:
4. DESCRIPTION OF ORG/DOMAIN:
4. ORG/ドメインの記述:
5. Date Operational......:
5. 操作上で、デートしてください…:
6. ADMINISTRATIVE CONTACT OF ORG/DOMAIN
6a. NIChandle (if known)..:
6b. Whole Name............:
6c. Organization Name.....:
6d. Address Line 1........:
6d. Address Line 2........:
6e. City..................:
6f. State.................:
6g. Zip/Code..............:
6h.* Voice Phone...........:
6i.* Electronic Mailbox....:
6. ORG/ドメイン6aのドメイン管理者。 NIChandle(知られているなら)。: 6b。 全体の名前…: 6c。 組織名…: 6d。 線1を扱ってください…: 6d。 線2を扱ってください…: 6e。 市…: 6f。 状態…: 6g。 郵便番号/コード…: 6h.*音声電話…: 6i.*メールボックス…:
7. TECHNICAL AND ZONE CONTACT
7a. NIChandle (if known)..:
7b. Whole Name............:
7c. Organization Name.....:
7d. Address Line 1........:
7d. Address Line 2........:
7e. City..................:
7f. State.................:
7g. Zip/Code..............:
7h.* Voice Phone...........:
7i.* Electronic Mailbox....:
7. 技術的なANDゾーン接触7a。 NIChandle(知られているなら)。: 7b。 全体の名前…: 7c。 組織名…: 7d。 線1を扱ってください…: 7d。 線2を扱ってください…: 7e。 市…: 7f。 状態…: 7g。 郵便番号/コード…: 7h.*音声電話…: 7i.*メールボックス…:
Cooper & Postel [Page 46] RFC 1480 The US Domain June 1993
クーパーとポステル[46ページ]RFC1480米国ドメイン1993年6月
FILL OUT QUESTIONS 8 AND 9 FOR DELEGATIONS ONLY (i.e., those organizations running name servers for a branch of the US Domain name space, for example: k12.<state>.us).
FILL OUT QUESTIONS8AND9FOR DELEGATIONS ONLY(すなわち、スペースという米国Domain名: (例えば、k12)の<州の>.usのブランチのためにネームサーバを実行するそれらの組織)。
8. PRIMARY SERVER: CONTACT INFO, HOSTNAME, NETADDRESS
8a. NIChandle (if known)..:
8b. Whole Name............:
8c. Organization Name.....:
8d. Address Line 1........:
8d. Address Line 2........:
8e. City..................:
8f. State.................:
8g. Zip/Code..............:
8h.* Voice Phone...........:
8i.* Electronic Mailbox....:
8j. Hostname..............:
8k.* IP Address............:
8l.* HARDWARE..............:
8m.* OPERATING SYS.........:
8. プライマリサーバ: NETADDRESS 8a、インフォメーション、ホスト名に連絡してください。 NIChandle(知られているなら)。: 8b。 全体の名前…: 8c。 組織名…: 8d。 線1を扱ってください…: 8d。 線2を扱ってください…: 8e。 市…: 8f。 状態…: 8g。 郵便番号/コード…: 8h.*音声電話…: 8i.*メールボックス…: 8j。 ホスト名…: 8k.*IPアドレス…: 8l.*ハードウェア…: SYSを操作する8m.*…:
9. * SECONDARY SERVER: HOSTNAME, NETADDRESS
9a.* Hostname..............:
9b.* IP Address............:
9c.* HARDWARE..............:
9d.* OPERATING SYS.........:
9. * セカンダリサーバ: ホスト名、NETADDRESS 9a.*ホスト名…: 9b.*IPアドレス…: 9c.*ハードウェア…: SYSを操作する9d.*…:
FILL OUT QUESTION 10 FOR DIRECT REGISTRATIONS IP HOSTS
ダイレクト登録証明書IPホストのために質問10に書き込んでください。
10. RESOURCE RECORDS (RRs) FOR IP INTERNET HOSTS
10a. DOMAIN NAME...........:
10b.* IP ADDRESS (required).:
10c. HARDWARE..............:
10d. OPERATING SYS.........:
10e. WKS ..................:
10f.* MX....................:
10. IPインターネットのためのリソース記録(RRs)は10aを接待します。 ドメイン名…: 10b.*IPアドレス(必要である)、: 10c。 ハードウェア…: 10d。 SYSを操作します…: 10e。 WKS…: 10f.*MX…:
FILL OUT QUESTIONS 11 AND 12 FOR NON-IP HOSTS (such as UUCP)
非IPホストのために質問11と12に書き込んでください。(UUCPなどの)
11. FORWARDING HOST INFORMATION
11a. Forwarding Host......:
11b. Contact Name.........:
11c. Contact Email........:
11. ホスト情報11aを進めます。 推進ホスト…: 11b。 名前に連絡してください…: 11c。 メールに連絡してください…:
12. RESOURCE RECORDS (RRs) FOR NON-IP HOSTS (UUCP)
12a. DOMAIN NAME...........:
12b. HARDWARE..............:
12c. OPERATING SYS.........:
12d.* MX (required).........:
12. 非IPのためのリソース記録(RRs)は(UUCP)12aを接待します。 ドメイン名…: 12b。 ハードウェア…: 12c。 SYSを操作します…: 12d.*MX(必要です)…:
Cooper & Postel [Page 47]
クーパーとポステル[47ページ]
一覧
スポンサーリンク
