RFC1386 日本語訳
1386 The US Domain. A. Cooper, J. Postel. December 1992. (Format: TXT=62310 bytes) (Obsoleted by RFC1480) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Cooper
Request for Comments: 1386 J. Postel
December 1992
The US Domain
コメントを求めるワーキンググループA.桶屋要求をネットワークでつないでください: 1386 J.ポステル1992年12月の米国ドメイン
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 ............................................ 5
2.2 City Codes or Locality Names............................ 5
2.3 Examples of Names....................................... 5
3. Registration ................................................ 8
3.1 Requirements ........................................... 8
3.2 Direct Entries ......................................... 9
3.2.1 UUCP Hosts .......................................... 9
3.2.2 Non-IP Hosts ........................................ 10
3.3 Delegated Subdomains ................................... 12
3.3.1 Schools ............................................. 12
3.3.2 State Agencies ...................................... 14
3.3.3 Federal Agencies .................................... 14
3.3.4 Delegation Requirement............................... 14
3.3.5 Delegation Procedures ............................... 15
3.3.6 Subdomain Contacts................................... 18
4. Database Information......................................... 19
4.1 Name Servers ........................................... 19
4.2 Zone files ............................................. 20
4.3 Resource Records ....................................... 21
4.3.1 A Records ........................................... 22
4.3.2 CNAME Records ....................................... 22
4.3.3 MX Records .......................................... 22
4.3.4 HINFO Records ....................................... 23
4.3.5 PTR Records ......................................... 23
4.4 Wildcards .............................................. 23
5. References .................................................. 24
6. Security Considerations ..................................... 25
7. Author's Address ............................................ 25
Appendix-I: US Domain Names BNF................................. 26
Appendix-II: US Domain Questionnaire for Host Entry.............. 28
1. 序論… 2 1.1 インターネットドメインネームシステム… 2 1.2は平らなドメインを上回っています… 3 1.3 米国ドメイン… 4 2. 構造を命名します… 4 2.1 コードを述べてください… 5 2.2 市のコードか場所名… 5 名前に関する2.3の例… 5 3. 登録… 8 3.1の要件… 8 3.2 エントリーを指示してください… 9 3.2 .1 UUCPホスト… 9 3.2 .2 非IPホスト… 10 3.3はサブドメインを代表として派遣しました… 12 3.3 .1 群がります… 12 3.3 .2の州機関… 14 3.3 .3の連邦機関… 14 3.3 .4代表団要件… 14 3.3 .5 代表団手順… 15 3.3 .6 サブドメイン接触… 18 4. データベース情報… 19 4.1のネームサーバ… 19 4.2ゾーンはファイルされます… 20 4.3 リソース記録… 21 4.3 .1 記録… 22 4.3 .2 CNAMEは記録します… 22 4.3 .3 MXは記録します… 22 4.3 .4 HINFOは記録します… 23 4.3 .5 PTRは記録します… 23 4.4個のワイルドカード… 23 5. 参照… 24 6. セキュリティ問題… 25 7. 作者のアドレス… 25、付録I: 米国ドメイン名BNF… 26、付録II: ホストエントリーのための米国のドメインアンケート… 28
Cooper & Postel [Page 1] RFC 1386 The US Domain December 1992
クーパーとポステル[1ページ]RFC1386米国ドメイン1992年12月
1. INTRODUCTION
1. 序論
1.1 The Internet Domain Name System
1.1 インターネットドメインネームシステム
The Domain Name System (DNS) provides for the translation between host names 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 assigned by the Network Information Center (Hostmaster@NIC.DDN.MIL).
32ビットのIPアドレスの課題は別々の活動です。 IPアドレスはNetworkインフォメーション・センター( Hostmaster@NIC.DDN.MIL )によって割り当てられます。
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 registration 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 host name to address mappings were maintained by the Network Information Center (NIC) in a single file, called HOSTS.TXT, which was FTPed by all the hosts on the Internet. The network population was changing in character. The timeshared 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 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 hierarcy levels. A design using a distributed database and generalized resources was implemented.
ドメインシステムの開発の理由はインターネットでの成長でした。 アドレス・マッピングへのホスト名はHOSTS.TXTと呼ばれるインターネットのすべてのホストによるFTPedであった一列でNetworkインフォメーション・センター(NIC)によって維持されました。 ネットワーク人口はぴったりした変化しました。 オリジナルのアルパネットを作ったtimesharedホストをワークステーションの企業内情報通信網に取り替えていました。 地方の組織は、それら自身の名前とアドレスを管理していましたが、NICが変更を全体のインターネットに目に見えるようにするようにHOSTS.TXTの変更を行うのを待たなければなりませんでした。 また、組織はスペースという名前の何らかのローカルの構造が欲しかったです。 インターネットにおけるアプリケーションは、より洗練されるようになって、汎用の名前サービスの必要性を作成しています。 「階層構造がおよそ組織体制に対応している、名前が使用されている階層的な名前スペースの考え」、」 hierarcyレベルの間の境界をマークするキャラクタとして。 分散データベースと一般化されたリソースを使用するデザインは実行されました。
The domain system provides standard formats for resource data,
ドメインシステムはリソースデータに標準書式を提供します。
Cooper & Postel [Page 2] RFC 1386 The US Domain December 1992
クーパーとポステル[2ページ]RFC1386米国ドメイン1992年12月
standard methods for querying the database, and standard methods for name servers to refresh local data from other name servers.
データベースについて質問するための標準方法、およびネームサーバが他のネームサーバからのローカルのデータをリフレッシュする標準方法。
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.
DNSの最上位のドメインは、EDUと、COMと、GOVと、MILと、ORGと、INTと、NETと、すべて、ISO-3166の国のリストからの2文字の国名略号です。
Even though the intention was that any educational institution any where 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, similiary 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 it's own way about organizing its domain, and many have.
意志ですが、それはあらゆる学園でした。いくらか、EDUドメインの下でいったいどこを登録できたか、実際にはそれが合衆国のものだけがEDUの下に示したわずかな例外で判明した、COM(コマーシャルのための)とsimiliary。 他国では、すべてが2文字の国名略号の下でしばしば何らかの下位区分に登録されます。 例えば、韓国(KR)では、2番目の平らな名前が学界、コマーシャルのためのCO、政府のためのGO、および調査のためのREのための西暦です。 各国がどのように行っても、ずっとドメインを組織化することに関して自己です、そして、多くは自己でした。
Their are no plans of putting all of the organizational domains .EDU
.GOV .COM etc., under .US.
それら、.EDU .GOV .COMの組織的なドメインなどのすべてを置くプランがない、下の.USはそうです。
However, there are some states registered in the .GOV domain (11 by 2 letter code), and 3 by full names)
しかしながら、フルネームによって.GOVドメイン(11×2レター・コード)、および3で示されたいくつかの州がある、)
ca.gov la.gov ohio.gov va.gov
co.gov md.gov or.gov wa.gov
hawaii.gov nc.gov sc.gov
ia.gov ny.gov texas.gov
ca.gov la.gov ohio.gov va.gov co.gov md.gov or.gov wa.gov hawaii.gov nc.gov sc.gov ia.gov ny.gov texas.gov
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 ".NA" for North America (this conflicts with the official Internet code for Namibia).
他の名前は最上位のドメイン名として時々現れます。 人々の中にはDNS管理と調整するか、またはともに記名しないでDNSスタイルで名前を作った人もいました。 通常現れるいくつかの名前が、大陸のための".BITNET"と、".UUCP"と、2レター・コードです、北アメリカへの".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スタイル名はアマチュア無線ネットワークに使用されます。 これらのアドレスはインターネットに決して現れるべきではありませんが、それらは時折します。 アマチュア無線ネットワークの人々はそれら自身の命名計画を作成しました、そして、それは時々インターネット・アドレスを妨げます。
Cooper & Postel [Page 3] RFC 1386 The US Domain December 1992
クーパーとポステル[3ページ]RFC1386米国ドメイン1992年12月
1.3 The US Domain
1.3 米国ドメイン
The US Domain is an official top-level domain in the DNS of the Internet community. It is registered with the Network Information Center. 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の公式の最上位のドメインです。 それはNetworkインフォメーション・センターに登録されます。 ドメイン管理者は、南カリフォルニア(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 NIC the same way other country domains are.
米国が合衆国へのISO-3166の2文字の国名略号であり、その結果、米国Domainは他の国のドメインがある同じように最上位のドメインとして設立されて、NICに登録されます。
Because organizations in the United States have registered primarily in the EDU and COM domains, little use was initially made of the US domain.
合衆国での組織が主としてEDUとCOMドメインに登録されたので、初めは、米国ドメインで使用をほとんどしませんでした。
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, private schools, libraries, county agencies, and city utilities, to name a few.
過去に、コンピュータが家にある状態で、米国Domainに登録されたコンピュータは小会社か個人によって主として所有されていました。 しかしながら、米国Domainは、成長して、現在、いくつかを命名するために連邦政府代理店のホスト、州の政府機関、K12学校、コミュニティカレッジ、私立学校、ライブラリ、カウンティーの代理店、および都市のユーティリティを登録します。
The administration of the US Domain was managed solely by the Domain Registrar in the past. However, due to the increase of hosts, 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 namespace under .US is the state namespace, then the city namespace, then organization or computer name and so on.
米国Domain階層構造は政治地理学に基づいています。 .USの下の名前空間が州の名前空間であり、その時は、都市の名前空間か当時の組織かコンピュータ名などです。
For example:
例えば:
SPK.WA.US
VANC.WA.US
SPK.WA.US VANC.WA.US
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記録と呼ばれます。
Cooper & Postel [Page 4] RFC 1386 The US Domain December 1992
クーパーとポステル[4ページ]RFC1386米国ドメイン1992年12月
The use of un-registered names is not effective and causes problems for other users. Inventing your own name and using it without registering is not a good idea.
登録されていない名前の使用は、有効でなく、他のユーザのために問題を起こします。 あなた自身の名前を発明して、登録しないでそれを使用するのは、名案ではありません。
2.1 State Codes
2.1 州のコード
The state codes are the two letter US Postal abbreviations.
州のコードは2つの手紙米国Postal略語です。
2.2 City Codes or Locality Names
2.2 市のコードか場所名
Cities may be named (designated) by their full name (spelled out with hyphens replacing spaces (e.g., Los-Angeles or New-York)), or by a city code. The first choice is the full city name, the second choice is the city codes from Western Union's "City Mnemonics" list, and a third choice is a code for your city chosen by the applicant. However, it is very desirable that all users in the same city use the same designator for the city.
都市はそれらのフルネーム(ハイフンが空間(例えば、ロサンゼルスかニューヨーク)を取り替えていて、詳しく説明される)、または都市名コードによって命名されるかもしれません(指定されます)。 最初の選択は完全な都市の名です、そして、第二希望はウェスタンユニオンの「市のニーモニック」リストからの都市名コードです、そして、3番目の選択は応募者によって選ばれたあなたの都市へのコードです。 しかしながら、同じ都市のすべてのユーザが都市に同じ指示子を使用するのは、非常に望ましいです。
Abbreviated city names are a good idea, particularly when the city name is long, as there is much to type already. One of the problems is that the city codes in the Western Union City Mnemonics list are sometimes not very good abbreviations. Users sometimes tend to prefer abbreviations that are commonly used already from that region. Such as SF for San Francisco, MPK for Menlo Park.
簡略化された都市の名は名案です、特に都市の名が長いときに、既にタイプするために多くがあるとき。 問題の1つはウェスタンユニオン市のMnemonicsリストの都市名コードが時々非常に良い略語でないということです。 ユーザは、時々既にその領域から一般的に使用される略語を好む傾向があります。 サンフランシスコへのSF、メンローパークへのMPKなどのように。
Exceptions have been made in the abbreviations, even though this causes extra work to keep track of these abbreviations. One abbreviation for one city. Applicants are told what codes are currently in use, however, if a city code is not used yet, and they would prefer to use a different code that is more common among the natives, then the new code is allowed. However, once it's registered, then everyone else who registers in that city will have to use that code or spell out the full city name.
時間外労働はこれでこれらの略語の動向をおさえますが、例外は略語で作られています。 1つの都市への1つの略語。 応募者はどんなコードが現在使用中であるかと言われて、都市名コードがまだ使用されていなくて、ネイティブの中では、より一般的な異なったコードを使用するのを好むなら、しかしながら、新法は許容されています。 しかしながら、いったん登録すると、そして、その都市に登録する他の人皆は、そのコードを使用しなければならないか、または完全な都市の名について詳しく説明しなければならないでしょう。
Some applicants have tried to get a copy of the Western Union City Mnemonics code list but it is no longer available from Western Union. However, we do have a copy but it is not online. If you are requesting an abbreviated city code please let us know and we will gladly look it up for you.
何人かの応募者がウェスタンユニオン市のMnemonicsコードリストのコピーを手に入れようとしましたが、それはもうウェスタンユニオンから利用可能ではありません。 しかしながら、私たちには、コピーがありますが、それはオンラインではありません。 簡略化された都市名コードを要求しているなら、私たちにお知らせください。そうすれば、私たちはあなたのために喜んでそれを見上げるつもりです。
2.3 Examples of Names
2.3 名前に関する例
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
Cooper & Postel [Page 5] RFC 1386 The US Domain December 1992
クーパーとポステル[5ページ]RFC1386米国ドメイン1992年12月
For large entities like large corporations with multiple facilities in several cities or states this often seems like a 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.
複数の施設がいくつかの都市か州にある大企業のような大きい実体に関しては、これは無理な規制のようにしばしば見えます(特に直接.COMドメインに登録する代替手段と比べると)。 しかしながら、会社は、特定の場所の本部を持っているので、その名前とともに記名することができました。
For example: IBM.Armonk.NY.US
例えば: IBM.Armonk.NY.US
EXAMPLES OF THE NAMING STRUCTURE IN THE US DOMAIN
米国ドメインの命名構造に関する例
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サンタ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
Senate.FED.US<。==== 米国上院DOD.FED.US<。==== 米国ディフェンス部 DOT.FED.US<。==== 米国輸送部 USPS.FED.US<。==== 米国郵便業務VA.FED.US<。==== 米国復員軍人援護局IRS.FED.US<。==== 米国国税庁Yosemite.NPS.Interior.FED.US<。==== 連邦機関
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の地方支店
Cooper & Postel [Page 6] RFC 1386 The US Domain December 1992
クーパーとポステル[6ページ]RFC1386米国ドメイン1992年12月
CITY | COUNTY ==============
都市| カウンティー==============
Police.CITY.Culver-City.CA.US <==== a city department Fire-Dept.CITY.Los-Angeles.CA.US <==== a city department Fire-Dept.COUNTY.Los-Angeles.CA.US <==== a county department
Police.CITY.Culver-City.CA.US <==== a city department Fire-Dept.CITY.Los-Angeles.CA.US <==== a city department Fire-Dept.COUNTY.Los-Angeles.CA.US <==== a county department
REGIONAL | DISTRICT | LIBRARY =============================
REGIONAL | DISTRICT | LIBRARY =============================
SCAQMD.DISTRICT.CA.US <==== a regional district Bunker-Hill-Improvement.DISTRICT.LA.CA.US <==== a local district
SCAQMD.DISTRICT.CA.US <==== a regional district Bunker-Hill-Improvement.DISTRICT.LA.CA.US <==== a local district
Huntington.LIB.LA.US <==== a private library Venice.LA-City.LIB.CA.US <==== a city library MDR.LA-County.LIB.CA.US <==== a county library
Huntington.LIB.LA.US <==== a private library Venice.LA-City.LIB.CA.US <==== a city library MDR.LA-County.LIB.CA.US <==== a county library
K12 | CC | STATE UNIV | PRIVATE SCHOOLS =======================================
K12 | CC | STATE UNIV | PRIVATE SCHOOLS =======================================
Los-Angeles.UC.STATE.CA.US <==== UCLA Berkeley.UC.STATE.CA.US <==== "CAL" Irvine.UC.STATE.CA.US <==== University of Calif. Irvine Santa-Cruz.UC.STATE.CA.US <==== University of Calif. Santa Cruz Northridge.CSU.STATE.CA.US <==== Calif. State. Univ. Northridge Fullerton.CSU.STATE.CA.US <==== Calif. State. Univ. Fullerton Sonoma.CSU.STATE.CA.US <==== Calif. State. Univ. Sonoma
Los-Angeles.UC.STATE.CA.US <==== UCLA Berkeley.UC.STATE.CA.US <==== "CAL" Irvine.UC.STATE.CA.US <==== University of Calif. Irvine Santa-Cruz.UC.STATE.CA.US <==== University of Calif. Santa Cruz Northridge.CSU.STATE.CA.US <==== Calif. State. Univ. Northridge Fullerton.CSU.STATE.CA.US <==== Calif. State. Univ. Fullerton Sonoma.CSU.STATE.CA.US <==== Calif. State. Univ. Sonoma
SMCC.Santa-Monica.CC.CA.US <==== a public community college Trade-Tech.Los-Angeles.CC.CA.US <==== a public community college
SMCC.Santa-Monica.CC.CA.US <==== a public community college Trade-Tech.Los-Angeles.CC.CA.US <==== a public community college
Hamilton.High.LA-Unified.K12.CA.US <==== a public K12 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
Hamilton.High.LA-Unified.K12.CA.US <==== a public K12 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
St-Monica.High.Santa-Monica.CA.US <==== a private high school St-Monica.Elem.Santa-Monica.CA.US <==== a private elem. school Crossroads-School.Santa-Monica.CA.US <==== a private school Mary-Ellens.Montessori-School.LA.CA.US <==== a private school Leland-Stanford-Jr-Univ.Stanford.CA.US <==== a private school Loyola-Marymount-Univ.Los-Angeles.CA.US <==== a private school
St-Monica.High.Santa-Monica.CA.US <==== a private high school St-Monica.Elem.Santa-Monica.CA.US <==== a private elem. school Crossroads-School.Santa-Monica.CA.US <==== a private school Mary-Ellens.Montessori-School.LA.CA.US <==== a private school Leland-Stanford-Jr-Univ.Stanford.CA.US <==== a private school Loyola-Marymount-Univ.Los-Angeles.CA.US <==== a private school
Cooper & Postel [Page 7] RFC 1386 The US Domain December 1992
Cooper & Postel [Page 7] RFC 1386 The US Domain December 1992
When appropriate, subdomains are delegated and partioned in various categories, such as:
When appropriate, subdomains are delegated and partioned in various categories, such as:
K12.<state>.US = kindegarten thru 12th grade
CC.<state>.US = community colleges
LIB.<state>.US = libraries
STATE.<state>.US = state government agencies
<org-name>.FED.US = federal government agencies
K12.<state>.US = kindegarten thru 12th grade CC.<state>.US = community colleges LIB.<state>.US = libraries STATE.<state>.US = state government agencies <org-name>.FED.US = federal government agencies
The Appendix-I contains the current US Domain Names BNF, but in actuality, the names under these subdomains may vary according to the decision of the administrators of these subdomains.
The Appendix-I contains the current US Domain Names BNF, but in actuality, the names under these subdomains may vary according to the decision of the administrators of these subdomains.
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 host name. Cities and in some cases counties are used.
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 host name. Cities and in some cases counties are used.
3. REGISTRATION
3. REGISTRATION
3.1 Requirements
3.1 Requirements
Anyone requesting to register a host in the US Domain is sent a copy of the US Domain policy and procedure, and must fill out a US Domain questionnaire.
Anyone requesting to register a host in the US Domain is sent a copy of the US Domain policy and procedure, and must fill out a US Domain questionnaire.
The US Domain template, is similar to the NIC Domain template however, it is not the same. To request a copy of the US Domain questionnaire, send a message to the US Domain registrar (us- domain@isi.edu).
The US Domain template, is similar to the NIC Domain template however, it is not the same. To request a copy of the US Domain questionnaire, send a message to the US Domain registrar (us- domain@isi.edu).
Note: If you are registering a name in a delegated zone
(see Section 3.3.6). Please register with the
contact for that zone.
Note: If you are registering a name in a delegated zone (see Section 3.3.6). Please register with the contact for that zone.
The key people must have electronic mailboxes (that work). Please provide all the information indicated in the "Administrator" and "Technical Contact" slot. This person will be the point of contact for any administrative and policy questions about the domain.
The key people must have electronic mailboxes (that work). Please provide all the information indicated in the "Administrator" and "Technical Contact" slot. This person 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 e-mail address. This is necessary in case something goes wrong.
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 e-mail address. This is necessary in case something goes wrong.
Cooper & Postel [Page 8] RFC 1386 The US Domain December 1992
Cooper & Postel [Page 8] RFC 1386 The US Domain December 1992
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.
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.
It is also possible to register through one of the Internet service providers that have established working relationships with the US domain administrator.
It is also possible to register through one of the Internet service providers that have established working relationships with the US domain administrator.
If everything checks out, turn around time for registering a host is usually a day or two. The nameservers are updated anywhere from 12 to 24 hours later.
If everything checks out, turn around time for registering a host is usually a day or two. The nameservers are updated anywhere from 12 to 24 hours later.
There are two ways to be registered in the US Domain, directly, or by delegation.
There are two ways to be registered in the US Domain, directly, or by delegation.
3.2 Direct Entries
3.2 Direct Entries
Direct entry in the database of the US Domain appeals most to individuals and small companies. 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.
Direct entry in the database of the US Domain appeals most to individuals and small companies. 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.
3.2.1 UUCP Hosts
3.2.1 UUCP Hosts
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, 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 we cannot make these arrangements for you.
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, 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 we cannot make these arrangements for you.
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.
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.
Cooper & Postel [Page 9] RFC 1386 The US Domain December 1992
Cooper & Postel [Page 9] RFC 1386 The US Domain December 1992
This is not an appropriate registration for the US Domain.
This is not an appropriate registration for the US 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 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)
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.
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.
For example: bah.rochester.ny.us
host1.bah.rochester.ny.us
host2.bah.rochester.ny.us
For example: bah.rochester.ny.us host1.bah.rochester.ny.us host2.bah.rochester.ny.us
3.2.2 NON-IP Hosts
3.2.2 NON-IP Hosts
To use US Domain names for non-IP hosts, there must be a forwarder host that is an IP host. There must be an adminstrative agreement and a technical procedure for relaying mail between the non-IP host and the forwarder host.
To use US Domain names for non-IP hosts, there must be a forwarder host that is an IP host. There must be an adminstrative agreement and a technical procedure for relaying mail between the non-IP host and the forwarder host.
Case 1: -------
Case 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.
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.
You must ask "forwarder" if they are willing to be the internet forwarder for "your-host".
You must ask "forwarder" if they are willing to be the internet forwarder for "your-host".
In the US Domain of the DNS data base there must be an entry like
In the US Domain of the DNS data base there must be an entry like
Cooper & Postel [Page 10] RFC 1386 The US Domain December 1992
Cooper & Postel [Page 10] RFC 1386 The US Domain December 1992
this:
"your-host" MX 10 "forwarder"
this: "your-host" MX 10 "forwarder"
This must be entered by the US Domain administrator.
This must be entered by the US 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".
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".
Case 2: -------
Case 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 |
+----------+
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 | +----------+
"Forwarder" must be an IP host on the internet.
"Forwarder" must be an IP host on the internet.
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.
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.
In the US Domain of the DNS DataBase there must be an entry like this:
In the US Domain of the DNS DataBase there must be an entry like this:
"your-host" MX 10 "forwarder"
"your-host" MX 10 "forwarder"
This must be entered by the US Domain Administrator.
This must be entered by the US 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".
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".
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).
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).
Cooper & Postel [Page 11] RFC 1386 The US Domain December 1992
Cooper & Postel [Page 11] RFC 1386 The US Domain December 1992
3.3 Delegated Subdomains
3.3 Delegated Subdomains
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.
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.
Delegation of cities, companies within cities, schools (K12), community colleges (CC), libraries (LIB), state government (STATE), and federal government agencies, departments, etc., is acceptable and practical.
Delegation of cities, companies within cities, schools (K12), community colleges (CC), libraries (LIB), state government (STATE), and federal government agencies, departments, etc., is acceptable and practical.
For a delegated portion of the namespace, for example a city, no alterations can be made to that name, no abbreviations added, etc. unless applied for.
For a delegated portion of the namespace, 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.
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.
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 ok.
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 ok.
Delegation of the whole State namespace is not yet implemented. The delegated part of the name space is in the form of:
Delegation of the whole State namespace is not yet implemented. The delegated part of the name space is in the form of:
.STATE.<state>.US.
.K12.<state>.US.
.CC.<state>.US.
.LIB.<state>.US.
.<org-name>.<city>.<state>.US.
.CITY.<city-name>.<state>.US.
.<org-name>.FED.US.
.STATE.<state>.US. .K12.<state>.US. .CC.<state>.US. .LIB.<state>.US. .<org-name>.<city>.<state>.US. .CITY.<city-name>.<state>.US. .<org-name>.FED.US.
3.3.1 Schools
3.3.1 Schools
As schools begin to join the Internet, there ought to be a consistent scheme for naming them. A "K12" name branch has been established in each state in the US Domain for this purpose.
As schools begin to join the Internet, there ought to be a consistent scheme for naming them. A "K12" name branch has been established in each state in the US Domain for this purpose.
Public schools are usually organized by districts which can be larger or smaller than a city or county.
Public schools are usually organized by districts which can be larger or smaller than a city or county.
Cooper & Postel [Page 12] RFC 1386 The US Domain December 1992
Cooper & Postel [Page 12] RFC 1386 The US Domain December 1992
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.
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.
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 when they are needed, if the school's name is unique without such keywords don't use them.
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 when they are needed, if the school's name is unique without such keywords don't use them.
Typical K12 school names currently used are like:
Typical K12 school names currently used are like:
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.US OHS.EUNION.K12.CA.US BOHS.BREA.K12.CA.US
These names could be long. Given the large number of schools, organizing by school district and state seems appropriate. When there are many things to name some of the names must be long.
These names could be long. Given the large number of schools, organizing by school district and state seems appropriate. When there are many things to name some of the names must be long.
In some cases there may be appropriate abbreviations that can be used. For example Hamilton High School in Los Angeles could be:
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
Some School Examples:
---------------------
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
Northridge.CSU.STATE.CA.US <== a state university
コミュニティカレッジNorthridge.CSU.STATE.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<=<=<=<=<=<=州立大学
If a school has a bunch 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…
Cooper & Postel [Page 13] RFC 1386 The US Domain December 1992
クーパーとポステル[13ページ]RFC1386米国ドメイン1992年12月
3.2.2 State Agencies
3.2.2 州機関
US Domain namespace has been delegated to the state goverment agencies. For example, in the State of Minnesota, the subdomain is STATE.MN.US
米国Domain名前空間を州のgoverment代理店へ代表として派遣しました。 例えば、ミネソタ州では、サブドメインがSTATE.MN.USです。
This means that the person running the namservers for state.mn.us are responsible for naming agencies, of the state govermnent. For example:
人がstate.mn.usのためにnamserversを走らせて、状態の政府機関をgovermnentと命名するのに原因となるこの手段。 例えば:
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<=部
3.3.3 Federal Agencies
3.3.3 連邦機関
A federal namespace has been delegated to 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<。==== 連邦政府の機関
3.3.4 Delegation Requirements
3.3.4 代表団要件
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 Domain Name System. This
requirement is easily satisified if the technical contact
already runs some other nameservers.
1) インターネットドメインネームシステムに詳しい博識で有能な技術連絡担当者がいるに違いありません。 技術連絡担当者がある他のネームサーバを既に走らせるなら、この要件は容易にsatisifiedされます。
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ネームサーバ。
Cooper & Postel [Page 14] RFC 1386 The US Domain December 1992
クーパーとポステル[14ページ]RFC1386米国ドメイン1992年12月
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つの人々使用不能に当然の状態で遅れません(例えば、休みをとっていることによって)。
3.3.5 Delegation Procedures
3.3.5 代表団手順
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.
1) DNSの技術連絡担当者の経験を評価してください。 提案された代表団の必要があるのを確実にしてください。 技術連絡担当者には米国Domainと提案された命名構造の情報があるのを確実にしてください。
2) Note: In the past there was the concept of a "coordinator" for
a group or a club or "Domain Park". They would arrange to
coordinate the registration of all the computers used by
members of the club and forward all the information for the
group to the US Domain Administrator. Most coordinators have
moved into the position of administrator of that now delegated
subdomain.
2) 以下に注意してください。 そこの過去に、グループの「コーディネータ」、クラブまたは「ドメイン公園」の概念がありました。 彼らはクラブのメンバーによって使用されたすべてのコンピュータの登録を調整して、グループのためのすべての情報を米国Domain Administratorに転送するように手配するでしょう。 ほとんどのコーディネータがその現在代表として派遣されたサブドメインの管理者の所定の位置に移りました。
3) Add the new technical contact to the "us-dom-adm" mailing list
for distributing updates to the US Domain policies and
procedures, or other pertinent information.
3) 新しい技術連絡担当者を加える、「私たち、-、dom-adm、」 分配のためのメーリングリストは方針と手順か、他の適切な情報を米国Domainにアップデートします。
4) 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.
4) 新たに代表として派遣されたサブドメインにはある私たちのゾーンファイルからあらゆるホストを削除してください、そして、彼らにホストが現在彼らのゾーンファイルにいるのを確実にしてください。
Cooper & Postel [Page 15] RFC 1386 The US Domain December 1992
クーパーとポステル[15ページ]RFC1386米国ドメイン1992年12月
5) Send them a copy of the zone file so their initial zone file
is identical to ours. For example:
5) それらの初期のゾーンファイルが私たちのものと同じであるようにゾーンファイルのコピーをそれらに送ってください。 例えば:
mil.wi.us. 86400 SOA spool.mu.edu. manager.spool.mu.edu. (
920904 ;serial
28800 ;refresh
14400 ;retry
3600000 ;expire
86400 ) ;minim
mil.wi.us。 86400 SOA spool.mu.edu manager.spool.mu.edu。 (920904; 連続の28800;は14400をリフレッシュします; 3600000を再試行してください; 86400を吐き出してください) ; ミニム
mil.wi.us. 86400 NS spool.mu.edu.
spool.mu.edu. 50400 A 134.48.1.31
mil.wi.us. 86400 NS sophie.mscs.mu.edu.
mil.wi.us。 86400 NS spool.mu.edu spool.mu.edu。 50400、134.48 .1 .31 mil.wi.us。 86400 NS sophie.mscs.mu.edu。
sophie.mscs.mu.edu. 50400 A 134.48.4.6
solaria.mil.wi.us. 86400 HINFO Sun 3/60 SunOs
solaria.mil.wi.us. 86400 MX 10 spool.mu.edu.
nthomas.mil.wi.us. 86400 HINFO 386 Clone DOS
nthomas.mil.wi.us. 86400 MX 10 spool.mu.edu.
rwmke.mil.wi.us. 86400 HINFO UNIX PC UNIX
rwmke.mil.wi.us. 86400 MX 10 spool.mu.edu.
milestn.mil.wi.us. 86400 HINFO PC AT ENIX
milestn.mil.wi.us. 86400 MX 10 spool.mu.edu.
dawley.mil.wi.us. 86400 HINFO 386 Clone DOS
dawley.mil.wi.us. 86400 MX 10 spool.mu.edu.
...
-------------------------------------
sophie.mscs.mu.edu。 50400、134.48 .4 .6 solaria.mil.wi.us。 86400 HINFO Sun3/60SunOs solaria.mil.wi.us。 86400 MX10spool.mu.edu nthomas.mil.wi.us。 86400 HINFO386Clone DOS nthomas.mil.wi.us。 86400 MX10spool.mu.edu rwmke.mil.wi.us。 86400 HINFO UNIX PC UNIX rwmke.mil.wi.us。 86400 MX10spool.mu.edu milestn.mil.wi.us。 86400 HINFO PC AT ENIX milestn.mil.wi.us。 86400 MX10spool.mu.edu dawley.mil.wi.us。 86400 HINFO386Clone DOS dawley.mil.wi.us。 86400 MX10spool.mu.edu。 ... -------------------------------------
Cooper & Postel [Page 16] RFC 1386 The US Domain December 1992
クーパーとポステル[16ページ]RFC1386米国ドメイン1992年12月
6) The US Domain zone file must have the following records,
showing the name, address, e-mail, and phone number of the
technical contact for the delegated subdomain and the name of
the delegated name space and the names of the nameservers.
6) 米国Domainゾーンファイルには、以下の記録がなければなりません、代表として派遣されたサブドメイン、スペースという代表として派遣された名前の名前、およびネームサーバの名前のために技術連絡担当者の名前、アドレス、メール、および電話番号を示して。
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
;Delegated zone: .mil.wi.us
;Contact: Steven Goodman
; manager@spool.mu.edu
; Marquette University
; (414) 288-6734
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; ゾーンを代表として派遣します: .mil.wi.us; 接触: スティーブンGoodman。 manager@spool.mu.edu 。 マーケット大学。 (414) 288-6734
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.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; 接着剤記録は必要な今回ではありません。 接着剤記録はそうです。 必要性、サーバの名前がいつでサブドメインであるか、。 ドメインを代表として派遣しました。 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
7) 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.
7) チェックして、代表として派遣されたサブドメインネームサーバが活動していることを確認してください、代表として派遣されたホストが彼らのゾーンファイルにインストールされるのを確実にしてください。 今度は、新たに代表として派遣されたサブドメインにはある米国Domainゾーンファイルからあらゆるホストを削除してください。
8) 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.
8) ワイルドカード記録が組織的なサブドメインの下におけるゾーンファイルで許されていますが、ワイルドカード記録は全く「都市」か「状態」ドメインの下で許されていないことを新たに代表として派遣されたサブドメインの技術連絡担当者に知らせてください。
Cooper & Postel [Page 17] RFC 1386 The US Domain December 1992
クーパーとポステル[17ページ]RFC1386米国ドメイン1992年12月
3.3.6 Subdomain Contacts
3.3.6 サブドメイン接触
Approximately 680 individual hosts are registered, but we have delegated the following portions of the namespace. We do not know how many hosts are registered under each of these subsdomains.
およそ680人の個々のホストが登録されていますが、私たちは名前空間の以下の部分を代表として派遣しました。 私たちは、何人のホストがそれぞれのこれらのsubsdomainsの下に登録されるかを知りません。
DELEGATED ZONE CONTACT
============== =======
代表として派遣されたゾーン接触============== =======
TUCSON.AZ.US leonard@arizona.edu
SF.CA.US sf-hostmaster@apple.com
PREMENOS.SF.CA.US jenkins@premenos.sf.ca.us
SCVL.CA.US sinster@scintilla.capitola.ca.us
SANTA-CRUZ.CA.US sinster@scintilla.capitola.ca.us
APTOS.CA.US sinster@scintilla.capitola.ca.us
CAMPBELL.CA.US sinster@scintilla.capitola.ca.us
CAPITOLA.CA.US sinster@scintilla.capitola.ca.us
FELTON.CA.US sinster@scintilla.capitola.ca.us
ZAYANTE.CA.US sinster@scintilla.capitola.ca.us
BOULDER-CREEK.CA.US sinster@scintilla.capitola.ca.us
DARWIN.PTVY.CA.US brian@angband.stanford.edu
LOGAN-HS.UNIONCITY.CA.US cjw@marmot.nersc.gov
BOULDER.CO.US trent@XOR.COM
COLOSPGS.CO.US trent@XOR.COM
DENVER.CO.US trent@XOR.COM
DVR.CO.US trent@XOR.COM
CHI.IL.US matt@oddjob.uchicago.edu
EUGENE.OR.US meyer@oregon.uoregon.edu
SPRINGFIELD.OR.US meyer@oregon.uoregon.edu
MULTNOMAH.LIB.OR.US brianw@polaris.admin.ogi.edu
PGH.PA.US ecd@CERT.ORG
SPK.WA.US root@dogear.spk.wa.us
MIL.WI.US manager@spool.mu.edu
ATL.GA.US charvey@gatech.gatech.edu
Mt-PARK.GA.US charvey@gatech.gatech.edu
CLARKSTON.GA.US charvey@gatech.gatech.edu
STATE.MN.US dfazio@mr.net
MNPL.FRB.FED.US dfazio@mr.net
TUCSON.AZ.US leonard@arizona.edu SF.CA.US sf-hostmaster@apple.com PREMENOS.SF.CA.US jenkins@premenos.sf.ca.us SCVL.CA.US sinster@scintilla.capitola.ca.us SANTA-CRUZ. CA.US sinster@scintilla.capitola.ca.us APTOS.CA.US sinster@scintilla.capitola.ca.us CAMPBELL.CA.US sinster@scintilla.capitola.ca.us CAPITOLA.CA.US sinster@scintilla.capitola.ca.us FELTON.CA.US sinster@scintilla.capitola.ca.us ZAYANTE.CA.US sinster@scintilla.capitola.ca.us ボウルダー-CREEK.CA.US sinster@scintilla.capitola.ca.us DARWIN.PTVY.CA; 米国 brian@angband.stanford.edu ローガン-HS.UNIONCITY.CA.US cjw@marmot.nersc.gov BOULDER.CO.米国 trent@XOR.COM COLOSPGS.CO.米国 trent@XOR.COM DENVER.CO.米国 trent@XOR.COM DVR.CO.米国 trent@XOR.COM CHI.IL.US matt@oddjob.uchicago.edu EUGENE.OR.US meyer@oregon.uoregon edu SPRINGFIELD.OR.US meyer@oregon.uoregon.edu MULTNOMAH.LIB.OR.US brianw@polaris.admin.ogi.edu PGH.PA.US ecd@CERT.ORG SPK.WA.US root@dogear.spk.wa.us MIL.WI.US manager@spool.mu.edu ATL.GA.US charvey@gatech.gatech.edu Mt-PARK.GA.米国の charvey@gatech.gatech.edu クラークSTON.GA.米国 charvey@gatech.gatech.edu STATE.MN.US dfazio@mr.net MNPL.FRB.FED.US dfazio@mr.net
K12.CA.US mdm@NIC.CSU.NET
CC.CA.US mdm@NIC.CSU.NET
K12.MI.US sandra.s.waite@um.cc.umich.edu
K12.TX.US bmanning@is.rice.edu
K12.NJ.US becker@nisc.jvnc.net
K12.MS.US fwp@msstate.edu
dmhs.jcps.K12.KY.US lentner@sura.net
TIES.K12.MN.US dfazio@mr.net
K12.CA.US mdm@NIC.CSU.NET CC.CA.US mdm@NIC.CSU.NET K12.MI.US sandra.s.waite@um.cc.umich.edu K12.TX.US bmanning@is.rice.edu K12.NJ.US becker@nisc.jvnc.net K12.MS.US fwp@msstate.edu dmhs.jcps.K12.KY.米国 lentner@sura.net TIES.K12.MN.US dfazio@mr.net
Cooper & Postel [Page 18] RFC 1386 The US Domain December 1992
クーパーとポステル[18ページ]RFC1386米国ドメイン1992年12月
The following MD.US counties have been delegated to
(butler@brl.mil).
以下のMD.USカウンティーは委任されました( butler@brl.mil )。
AL.MD.US. Allegany
AA.MD.US. Anne Arundel
BA.MD.US. Baltimore
CAL.MD.US. Calvert
CAR.MD.US. Caroline
CE.MD.US. Cecil
CH.MD.US. Charles
DO.MD.US. Dorchester
FR.MD.US. Frederick
GA.MD.US. Garrett
HA.MD.US. Harford
HO.MD.US. Howard
KE.MD.US. Kent
MO.MD.US. Montgomery
PG.MD.US. Prince George"s
QA.MD.US. Queen Anne's
SM.MD.US. St. Mary's
SO.MD.US. Somerset
TA.MD.US. Talbot
WA.MD.US. Washington
WI.MD.US. Wicomico
WO.MD.US. Worcester
AL.MD.米国。 Allegany AA.MD.US。 アンアランデルBA.MD.US。 ボルチモアCAL.MD.US。 カルバートCAR.MD.US。 キャロラインCE.MD.US。 セシルCH.MD.US。 チャールズDO.MD.US。 ドーチェスターFR.MD.US。 フレディリックGA.MD.US。 ギャレットHA.MD.US。 ハーフォードHO.MD.US。 ハワードKE.MD.US。 ケントMO.MD.US。 モンゴメリPG.MD.US。 プリンスジョージ「s QA.MD.US。」 アン女王のSM.MD.US。 セント・マリーのSO.MD.US。 サマセットTA.MD.US。 タルボーWA.MD.US。 ワシントンWI.MD.US。 Wicomico WO.MD.US。 ウスター
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つのサーバで利用可能になるのに必要です、そして、多くのゾーンには、それより多くの冗長があります。
Cooper & Postel [Page 19] RFC 1386 The US Domain December 1992
クーパーとポステル[19ページ]RFC1386米国ドメイン1992年12月
The US Domain is currently supported by six name servers.
米国Domainは現在、6つのネームサーバによって支持されます。
venera.isi.edu
ns.isi.edu
ns.hercules.csl.sri.com
nnsc.nsf.net
ns.uu.net
adm.brl.mil
venera.isi.edu ns.isi.edu ns.hercules.csl.sri.com nnsc.nsf.net ns.uu.net adm.brl.mil
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) ゾーン(信頼すべきデータの一部として考えることができる)のトップノードを定義するデータ。
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 namservers which are authoritative for the zone. When the changes are made they must be distributed to all of the name servers.
ゾーンの管理者はすべてのゾーンに、正式のnamserversでゾーンを維持しなければなりません。 いつ変化が人工のそれらであるかネームサーバのすべてに分配しなければなりません。
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を掘ってください。
Cooper & Postel [Page 20] RFC 1386 The US Domain December 1992
クーパーとポステル[20ページ]RFC1386米国ドメイン1992年12月
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
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) インターネット推進ホストを使用してください。
Cooper & Postel [Page 21] RFC 1386 The US Domain December 1992
クーパーとポステル[21ページ]RFC1386米国ドメイン1992年12月
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もあるはずがありません。
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。
Cooper & Postel [Page 22] RFC 1386 The US Domain December 1992
クーパーとポステル[22ページ]RFC1386米国ドメイン1992年12月
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 RFC 1340. The hardware type is called the Machine Name, and the software type is called the System Name.
最新の版がRFC1340であるなら最新のAssigned民数記RFCで公式のHINFOタイプを見つけることができます。 ハードウェアタイプは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.。 (特別な名前) (本名)
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記録は米国Domainに登録されたあらゆる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
例えば、大きい非IP/TCP、メール・ゲートウェイを作成して欲しかったネットワークと共にカリフォルニアに位置する大企業を仮定してください。 会社がDWP.LA.CA.US、およびIP/TCPのできるゲートウェイマシンと呼ばれたなら、(Internet混載業者)はELROY.JPL.NASA.GOVと呼ばれました。
Cooper & Postel [Page 23] RFC 1386 The US Domain December 1992
クーパーとポステル[23ページ]RFC1386米国ドメイン1992年12月
following RRs might be entered into the .US zone.
次の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.
だれかがドメイン名システムでホストのひとりを見つけたいならそれがそこにあって、より容易に問題は検出できるという単なる事実で私たちが、単一のエントリーが最も良いと感じる理由があります。 ワイルドカード記録を使用するとき、サブドメインの下におけるすべてのホストが隠されます。
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日
Cooper & Postel [Page 24] RFC 1386 The US Domain December 1992
クーパーとポステル[24ページ]RFC1386米国ドメイン1992年12月
6. SECURITY CONSIDERATIONS
6. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
7. AUTHORS' ADDRESSES
7. 作者のアドレス
Ann Cooper USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
アンクーパーUSC/Information Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: 1-310-822-1511 Email: cooper@isi.edu
以下に電話をしてください。 1-310-822-1511 メールしてください: cooper@isi.edu
Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ジョンポステルUSC/Information Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: 1-310-822-1511 Email: postel@isi.edu
以下に電話をしてください。 1-310-822-1511 メールしてください: postel@isi.edu
Cooper & Postel [Page 25] RFC 1386 The US Domain December 1992
クーパーとポステル[25ページ]RFC1386米国ドメイン1992年12月
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>
<、私たち、->を命名してください:、:= <州名の><ドット><州コード>。| >が与えられた<の食べさせられた名前の><ドット><。
<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>
<の食べさせられた名前の>:、:= <は米国連邦政府政府機関>の点を打たされた階層的な名前です。
<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><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>です。
<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>
<都市名の>:、:= <は市庁政府機関>の点を打たされた階層的な名前です。
Cooper & Postel [Page 26] RFC 1386 The US Domain December 1992
クーパーとポステル[26ページ]RFC1386米国ドメイン1992年12月
<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> ::= "CITY"
<都市の>:、:= 「都市」
<county> ::= "COUNTY" | "TOWNSHIP" | "PARISH"
<カウンティーの>:、:= 「カウンティー」| 「郡区」| 「教区」
<dot> ::= "."
<ドット>:、:= "."
<fed> ::= "FED"
<は>に食べさせました:、:= 「食べます」。
<agency> ::= "AGENCY" | "DISTRICT" | "K12" | "CC" | "LIB"
<代理店>:、:= 「政府機関」| 「地区」| "K12""| 「CC」| 「リブ」
<state> ::= "STATE" | "COMMONWEALTH"
<州の>:、:= 「状態」| 「連邦」
<us> ::= "US"
<、私たち、>:、:= 「米国」
Note: "K12" may be used for public school districts, only.
and "CC" may be used only for public community colleges,
and "LIB" can only be used by libraries.
以下に注意してください。 「K12"は公立の学校地区だけに使用されるかもしれません、そして、公立のコミュニティカレッジにだけ「CC」を使用するかもしれません、そして、ライブラリは「リブ」を使用できるだけです。」
Cooper & Postel [Page 27] RFC 1386 The US Domain December 1992
クーパーとポステル[27ページ]RFC1386米国ドメイン1992年12月
APPENDIX-II: US DOMAIN QUESTIONNAIRE FOR HOST ENTRY
付録II: ホストエントリーのための米国のドメインアンケート
To register a host in the US domain, the following information must be sent to the US Domain Registrar (Us-Domain@ISI.EDU). Questions may be sent by electronic mail to the above address, or by phone to Ann Cooper (310-822-1511).
米国ドメインにホストを登録するために、米国Domain Registrar( Us-Domain@ISI.EDU )に以下の情報を送らなければなりません。 上のアドレスへの電子メール、またはアン・クーパー(310-822-1511)への電話は質問を送るかもしれません。
(1) The name of the top-level domain to join.
(1) 接合する最上位のドメインの名前。
For example: US
例えば: 米国
(2) The name of the administrative head of the organization, including
title, mailing address, phone number, organization, and network
mailbox. This is the contact point for administrative and policy
questions about the domain. In the case of a research project,
this should be the principal investigator.
(2) タイトル、郵送先住所、電話番号、組織、およびネットワークメールボックスを含む組織の管理代表の名前。 これはドメインに関する管理と方針質問のための接点です。 研究計画の場合では、これは実験責任者であるべきです。
For example:
例えば:
Administrator
管理者
Organization The NetWorthy Corporation
Name Penelope Q. Sassafrass
Title President
Mail Address The NetWorthy Corporation
4676 Andrews Way, Suite 100
Santa Clara, CA 94302-1212
Phone Number (415) 123-4567
Net Mailbox Sassafrass@ECHO.TNC.COM
NetWorthy社NameペネロペQ.Sassafrass Title社長が郵送する組織は、NetWorthyが社4676のアンドリュースWayであると扱います、100サンタクララ、Suiteカリフォルニア94302-1212電話番号(415)123-4567ネットメールボックス Sassafrass@ECHO.TNC.COM
Cooper & Postel [Page 28] RFC 1386 The US Domain December 1992
クーパーとポステル[28ページ]RFC1386米国ドメイン1992年12月
(3) The name of the technical contact for the entry, including title,
mailing address, phone number, organization, and network mailbox.
This is the contact point for problems concerning the domain or
zone, as well as for updating information about the domain or zone.
(3) タイトル、郵送先住所、電話番号、組織、およびネットワークメールボックスを含むエントリーへの技術連絡担当者の名前。 これは、ドメインかゾーンに関する問題と、ドメインかゾーンに関して情報をアップデートするための接点です。
For example:
例えば:
Technical Contact
技術連絡担当者
Organization The NetWorthy Corporation
Name Ansel A. Aardvark
Title Executive Director
Mail Address The NetWorthy Corporation
4676 Andrews Way, Suite 100
Santa Clara, CA. 94302-1212
Phone Number (415) 123-6789
Net Mailbox Aardvark@ECHO.TNC.COM
NetWorthy社4676のアンドリュース道、100サンタクララ、組織NetWorthy社の名前アンセルA.ツチブタタイトル専務郵便の宛先Suiteカリフォルニア。 94302-1212 電話番号(415)123-6789ネットメールボックス Aardvark@ECHO.TNC.COM
(4) The name of the host. This is the name that will be used in tables
and lists associating the domain with the domain server addresses.
[While, from a technical standpoint, domain names can be quite long
(programmers beware), shorter names are easier for people to cope
with.]
(4) ホストの名前。 これはドメインサーバアドレスにドメインを関連づけながらテーブルとリストで使用される名前です。 [ドメイン名がかなり技術的な見地から長い間であることができる(プログラマは注意します)、人々には、より短い名前は対処するのは、より簡単です。]
For example: NetWorthy.Santa-Clara.CA.US
例えば: NetWorthy.Santa-Clara.CA.US
Or: Alpha.NetWorthy.Santa-Clara.CA.US
Beta.NetWorthy.Santa-Clara.CA.US
または、: Alpha.NetWorthy.Santa-Clara.CA.US Beta.NetWorthy.Santa-Clara.CA.US
(5) If this machine is not directly on the internet, how does it
communicate with the Internet. Through UUCP, CREN, etc? Which
forwarding host?
(5) このマシンが直接インターネットにないなら、それはインターネットでどのように交信しますか? UUCP、CRENなどを通して? どの推進ホスト?
For example: The host "Networthy.Santa-Clara.CA.US" uses UUCP
to connect to "RELAY.ISI.EDU" which is an Internet host.
例えば: ホスト「Networthy.Santa-Clara.CA.US」は、インターネット・ホストである"RELAY.ISI.EDU"に接続するのにUUCPを使用します。
The administrator of RELAY.ISI.EDU must agree to be the
forwarding host for Networthy.Santa-Clara.CA.US, and the
forwarding host must know a delivery method and route to it.
No double MXing.
RELAY.ISI.EDUの管理者は、Networthy.Santa-Clara.CA.USの推進ホストであるのに同意しなければなりません、そして、推進ホストは発送方法とルートをそれに知らなければなりません。 二重MXingがありません。
Cooper & Postel [Page 29] RFC 1386 The US Domain December 1992
クーパーとポステル[29ページ]RFC1386米国ドメイン1992年12月
If you are requesting an indirect connection, that is, a Mail
Exchanger (MX) record, what is the name and mailbox of the
administrator of the forwarding host.
あなたが、すなわち、間接的な接続、メールExchanger(MX)が記録するよう要求しているなら、推進ホストの管理者の名前とメールボックスであることです。
For example:John Smith
js@RELAY.ISI.EDU
: 例えば、ジョンスミス js@RELAY.ISI.EDU
(6) Please describe your organization briefly.
(6) 簡潔に組織について説明してください。
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つの技術的な会議を後援して、隔月のニュースレターを分配します。
(7) What Domain Name System (DNS) Resource Records (RR) and values are
to be entered.
(7) どんなドメインネームシステム(DNS)リソースRecords(RR)と値が入られることですか?
a. A Internet Address (internet hosts only)
b. HINFO Host Information, Machine System
c. WKS Well Known Services, Protocols, Ports (internet hosts only)
d. MX Mail Exchanger (required for UUCP, and CREN hosts)
a。 インターネットAddress(インターネットホスト専用)b。 HINFO Host情報、Machine System c。 WKS Well Known Services、プロトコル、Ports(インターネットホスト専用)d。 MXは交換器を郵送します。(UUCP、およびCRENのために、ホストを必要とします)
An example of RRs for an internet host.
インターネットホストのためのRRsに関する例。
NetWorthy.Santa-Clara.CA.US IN A 128.9.3.123
IN HINFO SUN-3/11OC UNIX
IN MX 10 ISI.EDU
IN WKS 128.9.3.123. UDP (echo
tftp)
IN WKS 128.9.3.133. TCP (telnet
ftp
tftp
finger)
WKSのMX10ISI.EDUのA128.9.3.123IN HINFO Sun-3/11OC UNIXのNetWorthy.Santa-Clara.CA.US、128.9、.3、.123 UDP(エコーtftp)IN WKS128.9.3.133。 TCP(telnet ftp tftp指)
An example of RRs for a non-internet host.
非インターネットホストのためのRRsに関する例。
Beta.NetWorthy.Santa-Clara.CA.US MX 10 RELAY.ISI.EDU
HINFO SUN-3/11OC UNIX
Beta.NetWorthy.Santa-Clara.CA.US Mx10RELAY.ISI.EDU HINFO Sun-3/11OC UNIX
Cooper & Postel [Page 30] RFC 1386 The US Domain December 1992
クーパーとポステル[30ページ]RFC1386米国ドメイン1992年12月
(8) Where is the IN-ADDR pointer record to be entered. (For internet
hosts only.) It is your responsibility to see that this is done.
Contact the administrator of the IP network your host is on. The
US Domain administration does not administer the network and cannot
make these entries in the DNS database.
(8) IN-ADDR指針記録によってどこに入られることになっていますか? (インターネットホストだけのための。) これが完了しているのがわかるのは、あなたの責任です。 あなたのホストがいるIPネットワークの管理者に連絡してください。 米国のDomain運営は、ネットワークを管理しないで、DNSデータベースにおけるこれらのエントリーをすることができません。
For example:
例えば:
123.3.9.128.IN-ADDR.ARPA. PTR NetWorthy.Santa-Clara.CA.US
ADDR.ARPAの123.3.9.128.。 PTR NetWorthy.Santa-Clara.CA.US
Who is the contact for the zone of the IN-ADDR.ARPA data, where
this record will be entered?
この記録が入力されるIN-ADDR.ARPAデータのゾーンに関する接触はだれですか?
(9) What Time to Live (TTL)? TTL is the time (in seconds) that a
resolver will use the data it got from the domain server before it
asks it again for the data. A typical TTL is One Week 604800.
(NOTE: TTL is not applicable to non-Internet hosts.)
(9) ライブ(TTL)への何時? TTLはデータのために再びそれを尋ねる前にレゾルバがそれがドメインサーバから得たデータを使用する時間(秒の)です。 典型的なTTLはキートンのマイホーム604800です。 (注意: TTLは非インターネット・ホストに適切ではありません。)
For example:
例えば:
One Week 604800
キートンのマイホーム604800
Cooper & Postel [Page 31]
クーパーとポステル[31ページ]
一覧
スポンサーリンク
