RFC2219 日本語訳
2219 Use of DNS Aliases for Network Services. M. Hamilton, R. Wright. October 1997. (Format: TXT=17858 bytes) (Also BCP0017) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Hamilton Request for Comments: 2219 Loughborough University BCP: 17 R. Wright Category: Best Current Practice Lawrence Berkeley Laboratory October 1997
コメントを求めるワーキンググループM.ハミルトンの要求をネットワークでつないでください: 2219年のラフバラ大学BCP: 17R.職人カテゴリ: 最も良い現在の練習ローレンスバークレイ研究所1997年10月
Use of DNS Aliases for Network Services
DNS別名のネットワーク・サービスの使用
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Abstract
要約
It has become a common practice to use symbolic names (usually CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to refer to network services such as anonymous FTP [RFC-959] servers, Gopher [RFC-1436] servers, and most notably World-Wide Web HTTP [RFC-1945] servers. This is desirable for a number of reasons. It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programmatically discover that an organization runs, say, a World- Wide Web server.
公開FTP[RFC-959]サーバや、ゴーファー[RFC-1436]サーバや、最も著しくWWW HTTP[RFC-1945]サーバなどのネットワーク・サービスについて言及するのに、Domain Name Service(DNS--[RFC-1034、RFC-1035])の英字名(通常CNAMEs)を使用するのは一般的な習慣になりました。 これは様々な意味で望ましいです。 それは透過的にあるマシンから別のマシンまでのサービスを動かす方法、および人々かエージェントが、組織がたとえばWorldの広いウェブサーバを実行するとプログラムに基づいて発見するかもしれないメカニズムを提供します。
Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names. This document seeks to rectify this situation by gathering together the extant 'folklore' on naming conventions, and proposes a mechanism for accommodating new protocols.
このアプローチはほとんど一般に取られましたが、これらの一般的に使用された名前のためのどんな規格文書も同様の仕様もありません。 このドキュメントは、実在の'民俗学'を命名規則に集めることによってこの事態を収拾しようとして、新しいプロトコルに対応するためにメカニズムを提案します。
It is important to note that these naming conventions do not provide a complete long term solution to the problem of finding a particular network service for a site. There are efforts in other IETF working groups to address the long term solution to this problem, such as the Server Location Resource Records (DNS SRV) [RFC-2052] work.
これらの命名規則が特定のネットワークがサイトのためのサービスであることがわかるという問題に完全な長期解決法を提供しないことに注意するのは重要です。 この問題に長期ソリューションを扱うために、他のIETFワーキンググループには取り組みがあります、Server Location Resource Records(DNS SRV)[RFC-2052]仕事などのように。
1. Rationale
1. 原理
In order to locate the network services offered at a particular Internet domain one is faced with the choice of selecting from a growing number of centralized databases - typically Web or Usenet News "wanderers", or attempting to infer the existence of network services from whatever DNS information may be available. The former approach is not practical in some cases, notably when the entity seeking service information is a program.
特定のインターネットドメインで提供されたネットワーク・サービスの場所を見つけるように、1は増加している数の集中データベースから選び抜くことの選択に直面しています--いかなる利用可能であるかもしれないDNS情報からもネットワーク・サービスの存在を推論する通常ウェブ、Usenet News「放浪者」、または試み。 サービス情報を求める実体がプログラムであるときに、前のアプローチはいくつかの場合、そして、著しく実用的ではありません。
Hamilton & Wright Best Current Practice [Page 1] RFC 2219 DNS Aliases October 1997
ハミルトンと職人の最も良い電流はDNS別名1997年10月にRFC2219を練習します[1ページ]。
Perhaps the most visible example of the latter approach at work is in the case of World-Wide Web HTTP servers. It is common practice to try prefixing the domain name of an organization with "http://www." in order to reach its World-Wide Web site, e.g. taking "hivnet.fr" and arriving at "http://www.hivnet.fr." Some popular World-Wide Web browsers have gone so far as to provide automatic support for this domain name expansion.
WWW HTTPサーバの場合には恐らく仕事における後者のアプローチの最も目に見える例があります。 " http://www "との組織のドメイン名を前に置いてみるのが、一般的な習慣である、例えば"hivnet.fr"を取って、" http://www.hivnet.fr "に到着しながら、WWWサイトに達してください。 このドメイン名拡張の自動サポートを提供さえしたポピュラーなウェブ・ブラウザーもいました。
Ideally, the DNS or some complementary directory service would provide a means for programs to determine automatically the network services which are offered at a particular Internet domain, the protocols which are used to deliver them, and other technical information. Unfortunately, although much work has been done to develop said directory service technologies and to define new types of DNS resource record to provide this type of information, there is no widely agreed upon or widely deployed solution to the problem - except in a small number of cases.
理想的に、DNSかある補足的なディレクトリサービスが、自動的に特定のインターネットドメイン(それら、および他の技術資料を提供するのにおいて使用されたプロトコル)で提供されるネットワーク・サービスを決定するためにプログラムのための手段を提供するでしょう。 残念ながら、前述のディレクトリサービス技術を開発して、この情報の種類を提供するために新しいタイプに関するDNSリソース記録を定義するために多くの仕事をしましたが、少ない数のケース以外に、問題への広く同意されたか、または広く配布している解決が全くありません。
The first case is where the DNS already provides a lookup capability for the type of information being sought after. For example: Mail Exchanger (MX) records specify how mail to a particular domain should be routed [RFC-974], the Start of Authority (SOA) records make it possible to determine who is responsible for a given domain, and Name Server (NS) records indicate which hosts provide DNS name service for a given domain.
最初のケースはDNSが既にルックアップ能力を得ようとされる情報の種類に提供するところです。 例えば: メールExchanger(MX)記録は特定のドメインへのメールがどう発送されるべきであるかを[RFC-974]指定します、そして、Authority(SOA)記録のStartはだれが与えられたドメインに責任があるかを決定するのを可能にします、そして、Name Server(NS)記録はどのホストが与えられたドメインのための名前サービスをDNSに供給するかを示します。
The second case is where the DNS does not provide an appropriate lookup capability, but there is some widely accepted convention for finding this information. Some use has been made of Text (TXT) [RFC-1035] records in this scenario, but in the vast majority of cases a Canonical Name (CNAME) or Address (A) record pointer is used to indicate the host or hosts which provide the service. This document proposes a slight formalization of this well-known alias approach.
2番目のケースはDNSが適切なルックアップ能力を提供しないところですが、この情報を見つけるためのいくらかの広く受け入れられたコンベンションがあります。 このシナリオでのText(TXT)[RFC-1035]記録で何らかの使用をしましたが、ホストかホストを示すのに非常に多くの場合にCanonical Name(CNAME)かAddress(A)記録指針を使用します(サービスを提供します)。 このドキュメントはこのよく知られる別名アプローチのわずかな形式化を提案します。
It should be noted that the DNS provides a Well Known Services (WKS) [RFC-1035] lookup capability, which makes it possible to determine the network services offered at a given domain name. In practice this is not widely used, perhaps because of the absence of a suitable programming interface. Use of WKS for mail routing was deprecated in the Host Requirements specification [RFC-1123] in favour of the MX record, and in the long term it is conceivable that SRV records will supersede both WKS and MX.
DNSがWell Known Services(WKS)[RFC-1035]にルックアップ能力を供給することに注意されるべきです。(能力は与えられたドメイン名で提供されたネットワーク・サービスを決定するのを可能にします)。 実際には、これは恐らく適当なプログラミングインターフェースの不在のために広く使用されません。 WKSのメールルーティングの使用はMX記録を支持してHost Requirements仕様[RFC-1123]で推奨しなかったです、そして、長期に、SRV記録がWKSとMXの両方に取って代わるのが想像できます。
Hamilton & Wright Best Current Practice [Page 2] RFC 2219 DNS Aliases October 1997
ハミルトンと職人の最も良い電流はDNS別名1997年10月にRFC2219を練習します[2ページ]。
2. A generic framework
2. ジェネリックフレームワーク
Our approach to dealing with aliases for protocols is straightforward. We define a standard set of DNS aliases for the most popular network services that currently exist (see the "Special Cases" section below). For protocols that are not explicitly listed in this document, the protocol specification must propose a name.
プロトコルのための別名に対処することへの私たちのアプローチは簡単です。 私たちは現在存在する最もポピュラーなネットワーク・サービスのためにDNS別名の標準セットを定義します(下の「特別なケース」セクションを見てください)。 明らかに本書では記載されていないプロトコルのために、プロトコル仕様は名前を提案しなければなりません。
3. Special cases
3. 特別なケース
Special Cases: ----------------------------------------------------------- Alias Service ----------------------------------------------------------- archie archie [ARCHIE] finger Finger [RFC-1288] ftp File Transfer Protocol [RFC-959] gopher Internet Gopher Protocol [RFC-1436] ldap Lightweight Directory Access Protocol [RFC-1777] mail SMTP mail [RFC-821] news Usenet News via NNTP [RFC-977] ntp Network Time Protocol [RFC-1305] ph CCSO nameserver [PH] pop Post Office Protocol [RFC-1939] rwhois Referral WHOIS [RFC-1714] wais Wide Area Information Server [RFC-1625] whois NICNAME/WHOIS [RFC-954] www World-Wide Web HTTP [RFC-1945] -----------------------------------------------------------
特別なケース: ----------------------------------------------------------- 別名サービス----------------------------------------------------------- NNTP[RFC-977]ntp Network Timeプロトコル[RFC-1305]ph CCSOネームサーバ[ペーハー]を通したarchie archie[アーチー]指のFinger[RFC-1288]ftp File Transferプロトコル[RFC-959]リスインターネットゴーファープロトコル[RFC-1436]ldapライトウェイト・ディレクトリ・アクセス・プロトコル[RFC-1777]メールSMTPメール[RFC-821]ニュースUsenet Newsはポストオフィスプロトコル[RFC-1939]rwhois Referral WHOIS[RFC-1714]wais Wide Area情報Server[RFC-1625]whois NICNAME/WHOIS[RFC-954]www WWW HTTP[RFC-1945]を飛び出させます。-----------------------------------------------------------
4. (Ab)Use of the DNS as a directory service
4. (腹筋)ディレクトリサービスとしてのDNSの使用
The widespread use of these common aliases effectively means that it is sometimes possible to "guess" the domain names associated with an organization's network services, though this is becoming more difficult as the number of organizations registered in the DNS increases.
事実上、これらの一般的な別名の普及使用は、組織のネットワーク・サービスに関連しているドメイン名が「推測」であることが時々可能であることを意味します、DNSに登録された組織の数が増加するのに従って、これは、より難しくなっていますが。
It should be understood by implementors that the existence of a DNS entry such as
それが作成者に解釈されるべきである、それ、DNSエントリーの存在
www.hivnet.fr
www.hivnet.fr
does not constitute a registration of a World-Wide Web service. There is no requirement that the domain name resolve to an IP address or addresses. There is no requirement that a host be listening for
WWWサービスの登録を構成しません。 ドメイン名がアドレスかアドレスをIPに決議するという要件が全くありません。 そこ、ホストがいるというどんな要件も聞こうとしていません。
Hamilton & Wright Best Current Practice [Page 3] RFC 2219 DNS Aliases October 1997
ハミルトンと職人の最も良い電流はDNS別名1997年10月にRFC2219を練習します[3ページ]。
HTTP connections, or if it is, that the HTTP server be running on port 80. Finally, even if all of these things are true, there can be no guarantee that the World-Wide Web server will be prepared to honor requests from arbitrary clients.
それがそうなら、HTTP接続であり、HTTPサーバが走ることであることが80を移植します。 最終的に、これらのもののすべてが本当であっても、WWWサーバが任意のクライアントからの要求を光栄に思うように準備されるという保証が全くあるはずがありません。
Having said this, the aliases do provide useful "hints" about the services offered. We propose that they be taken in this spirit.
これを言ったので、別名は提供されたサービスに関して役に立つ「ヒント」を提供します。 私たちは、それらがこの精神で取られるよう提案します。
The conventions described in this document are, essentially, only useful when the organization's domain name can be determined - e.g. from some external database. A number of groups, including the IETF, have been working on ways of finding domain names given a set of information such as organization name, location, and business type. It is hoped that one or more of these will eventually make it possible to augment the basic lookup service which the DNS provides with a more generalized search and retrieval capability.
組織のドメイン名が決定できるときだけ、本書では説明されたコンベンションは本質的には役に立ちます--例えば、何らかの外部のデータベースから。 1セットの組織名や、位置や、ビジネスタイプなどの情報を考えて、IETFを含む多くのグループがドメイン名を見つける方法に取り組んでいます。 これらの1つ以上でDNSがさらに一般化された検索と検索能力に提供する基本的なルックアップサービスを増大させるのが結局可能になることが望まれています。
5. DNS server configuration
5. DNSサーバ構成
In the short term, whilst directory service technology and further types of DNS resource record are being developed, domain name administrators are encouraged to use these common names for the network services they run. They will make it easier for outsiders to find information about your organization, and also make it easier for you to move services from one machine to another.
短期で、ディレクトリサービス技術とさらなるタイプに関するDNSリソース記録が開発していることにされるのである間、ドメイン名管理者がそれらが実行するネットワーク・サービスにこれらの一般名を使用するよう奨励されます。 彼らで、部外者があなたの組織の情報を見つけるのをより簡単にして、また、あなたが1台のマシンから別のマシンまでのサービスを動かすのが、より簡単になるでしょう。
There are two conventional approaches to creating these DNS entries. One is to add a single CNAME record to your DNS server's configuration, e.g.
これらのDNSエントリーを作成することへの2つの従来のアプローチがあります。 人は例えばあなたのDNSサーバの構成にただ一つのCNAME記録を加えることになっています。
ph.hivnet.fr. IN CNAME baby.hivnet.fr.
ph.hivnet.fr。 IN CNAME baby.hivnet.fr。
Note that in this scenario no information about ph.hivnet.fr should exist in the DNS other than the CNAME record. For example, ph.hivnet.fr could not contain a MX record.
ph.hivnet.frの情報が全くCNAME記録以外のDNSにこのシナリオでは、存在するべきでないことに注意してください。 例えば、ph.hivnet.frはMX記録を含むことができませんでした。
An alternative approach would be to create an A record for each of the IP addresses associated with ph.hivnet.fr, e.g.
代替的アプローチは例えばph.hivnet.frに関連づけられたそれぞれのIPアドレスのためのA記録を作成するだろうことです。
ph.hivnet.fr. IN A 194.167.157.2
ph.hivnet.fr。 IN A194.167.157、.2
It isn't a simple matter of recommending CNAMEs over A records. Each site has it's own set of requirements that may make one approach better than the other. RFC 1912 [RFC-1912] discusses some of the configuration issues involved in using CNAMEs.
それはA記録の上でCNAMEsを推薦する簡単な事柄ではありません。 それぞれがサイトが、主張する1つのアプローチをもう片方より良くするかもしれない要件の自身のセットです。 RFC1912[RFC-1912]はCNAMEsを使用するのにかかわる構成問題のいくつかについて議論します。
Hamilton & Wright Best Current Practice [Page 4] RFC 2219 DNS Aliases October 1997
ハミルトンと職人の最も良い電流はDNS別名1997年10月にRFC2219を練習します[4ページ]。
Recent DNS server implementations provide a "round-robin" feature which causes the host's IP addresses to be returned in a different order each time the address is looked up.
最近のDNSサーバ実装はアドレスが調べられるたびに異なったオーダーでホストのIPアドレスを返す「連続」の特徴を提供します。
Network clients are starting to appear which, when they encounter a host with multiple addresses, use heuristics to determine the address to contact - e.g. picking the one which has the shortest round-trip- time. Thus, if a server is mirrored (replicated) at a number of locations, it may be desirable to list the IP addresses of the mirror servers as A records of the primary server. This is only likely to be appropriate if the mirror servers are exact copies of the original server.
アドレスが連絡することを決定する発見的教授法を使用してください--彼らが複数のアドレスでホストに遭遇すると、ネットワーククライアントはどれを現れさせ始めているか、例えば、最も短い往復の間を過すものを選びます。 したがって、サーバが多くの位置で反映されるなら(模写されます)、プライマリサーバに関するA記録にミラーサーバのIPアドレスについて記載するのは望ましいかもしれません。これはミラーサーバがオリジナルのサーバの正確なコピーであるなら単に適切である傾向があります。
6. Limitations of this approach
6. このアプローチの制限
Some services require that a client have more information than the server's domain name. For example, an LDAP client needs to know a starting search base within the Directory Information Tree in order to have a meaningful dialogue with the server. This document does not attempt to address this problem.
いくつかのサービスが、クライアントにはサーバのドメイン名より多くの情報があるのを必要とします。 例えば、LDAPクライアントは、サーバとの有意義な対話を持つためにディレクトリ情報Treeの中で始めの検索ベースを知る必要があります。このドキュメントは、このその問題を訴えるのを試みません。
7. CCSO service name
7. CCSOサービス名
There are currently at least three different aliases in common use for the CCSO nameserver - e.g. "ph", "cso" and "ns". It would appear to be in everyone's interest to narrow the choice of alias down to a single name. "ns" would seem to be the best choice since it is the most commonly used name. However, "ns" is also being used by DNS to point to the DNS server. In fact, the most prevalent use of "ns" is to name DNS servers. For this reason, we suggest the use of "ph" as the best name to use for CCSO nameservers.
現在、CCSOネームサーバに、共用の少なくとも3つの異なった別名があります--例えば、"ph"、"cso"、および「ナノ秒。」 それは別名の選択をただ一つの名前まで狭くするために皆の利益のためにはあるように見えるでしょう。 「ナノ秒」はそれが最も一般的に使用された名前であるので最も良い選択であるように思えるでしょう。 しかしながら、また、「ナノ秒」は、DNSサーバを示すのにDNSによって使用されています。事実上、「ナノ秒」の最も一般的な使用はDNSをサーバと命名することです。 この理由で、私たちはCCSOネームサーバに使用する最高の名前として"ph"の使用を勧めます。
Sites with existing CCSO servers using some of these aliases may find it desirable to use all three. This increases the likelihood of the service being found.
既存のCCSOサーバがこれらの別名のいくつかを使用しているサイトによって、すべての3を使用するのが望ましいのがわかるかもしれません。 これは見つけられるサービスの可能性を広げます。
As noted earlier, implementations should be resilient in the event that the name does not point to the expected service.
より早く注意されるように、名前が予想されたサービスを示さない場合、実装は弾力があるべきです。
8. Security Considerations
8. セキュリティ問題
The DNS is open to many kinds of "spoofing" attacks, and it cannot be guaranteed that the result returned by a DNS lookup is indeed the genuine information. Spoofing may take the form of denial of service, such as directing of the client to a non-existent address, or a passive attack such as an intruder's server which masquerades as the legitimate one.
DNSは多くの種類の「スプーフィング」攻撃に開かれています、そして、本当に、DNSルックアップによって返された結果が本物の情報であることを保証できません。 スプーフィングは実在しないアドレス、または正統のもののふりをする侵入者のサーバなどの受け身の攻撃にクライアントの指示などのサービスの否定の形を連れて行くかもしれません。
Hamilton & Wright Best Current Practice [Page 5] RFC 2219 DNS Aliases October 1997
ハミルトンと職人の最も良い電流はDNS別名1997年10月にRFC2219を練習します[5ページ]。
Work is ongoing to remedy this situation insofar as the DNS is concerned [RFC-2065]. In the meantime it should be noted that stronger authentication mechanisms such as public key cryptography with large key sizes are a pre-requisite if the DNS is being used in any sensitive situations. Examples of these would be on-line financial transactions, and any situation where privacy is a concern - such as the querying of medical records over the network. Strong encryption of the network traffic may also be advisable, to protect against TCP connection "hijacking" and packet sniffing.
仕事はDNSに関する[RFC-2065]限り、この事態を改善することにおいて進行中です。 差し当たり、DNSがどんな微妙な状況にも使用されているなら大きい主要なサイズがある公開鍵暗号などの、より強い認証機構が前提条件であることに注意されるべきです。 これらに関する例は、オンライン金融取引と、プライバシーがネットワークの上のカルテの質問などの関心であるあらゆる状況でしょう。 また、ネットワークトラフィックの強い暗号化も、TCP接続「ハイジャック」とパケットスニフィングから守るために賢明であるかもしれません。
9. Conclusions
9. 結論
The service names listed in this document provide a sensible set of defaults which may be used as an aid in determining the hosts which offer particular services for a given domain name.
本書では記載されたサービス名は援助としてホストを決定する際に使用されるかもしれない分別があるデフォルトを提供します(与えられたドメイン名のために特定のサービスを提供します)。
This document has noted some exceptions which are either inherently unsuitable for this treatment, or already have a substantial installed base using alternative aliases.
このドキュメントは本来この処理に不適当であるか、または代替の別名を使用することで既にかなりのインストールされたベースを持っているいくつかの例外に注意しました。
10. Acknowledgements
10. 承認
Thanks to Jeff Allen, Tom Gillman, Renato Iannella, Thomas Lenggenhager, Bill Manning, Andy Powell, Sri Sataluri, Patrik Faltstrom, Paul Vixie and Greg Woods for their comments on draft versions of this document.
このドキュメントの草案バージョンの彼らのコメントをジェフ・アレン、トム・ギルマン、レナートIannella、トーマスLenggenhager、ビル・マニング、アンディ・パウエル、Sri Sataluri、パトリクFaltstrom、ポールVixie、およびグレッグ・ウッズをありがとうございます。
This work was supported by UK Electronic Libraries Programme (eLib) grant 12/39/01, the European Commission's Telematics for Research Programme grant RE 1004, and U. S. Department of Energy Contract Number DE-AC03-76SF00098.
この仕事はイギリスのElectronic図書館Programme(eLib)交付金12/39/01、Research Programme交付金RE1004のための欧州委員会のTelematics、およびU.S.エネルギー省Contract Number DE-AC03-76SF00098によってサポートされました。
11. References
11. 参照
Request For Comments (RFC) documents are available from <URL:ftp://ftp.internic.net/rfc> and numerous mirror sites.
For Comments(RFC)ドキュメントが<URLから利用可能であるよう要求してください: ftp://ftp.internic.net/rfc >と多数のミラーサイト。
[ARCHIE] A. Emtage, P. Deutsch. "archie - An Electronic Directory Service for the Internet", Winter Usenix Conference Proceedings 1992. Pages 93-110.
[アーチー] P. A.Emtage、ドイツ語。 「archie--、インターネットのための電子ディレクトリサービス、」、冬のUsenix会議の議事録1992 93-110ページ。
[PH] R. Hedberg, S. Dorner, P. Pomes. "The CCSO Nameserver (Ph) Architecture", Work in Progress.
[PH] R.ヘドバーグ、S.デルナー、P.梨果。 「CCSOネームサーバ(Ph)アーキテクチャ」、進行中の仕事。
[RFC-768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC-768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
Hamilton & Wright Best Current Practice [Page 6] RFC 2219 DNS Aliases October 1997
ハミルトンと職人の最も良い電流はDNS別名1997年10月にRFC2219を練習します[6ページ]。
[RFC-793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC-793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC-821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[RFC-954] Harrenstien, K., Stahl, M., and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985.
1985年10月の[RFC-954]HarrenstienとK.とスタール、M.とE.Feinler、「NICNAME/WHOIS」RFC954。
[RFC-959] Postel, J., and J.K. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC-959] ポステル、J.とJ.K.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。
[RFC-974] Partridge, C., "Mail routing and the domain System", STD 14, RFC 974, January 1986.
ヤマウズラ(C.)が「ルーティングとドメインSystemに郵送する」[RFC-974]、STD14、RFC974、1986年1月。
[RFC-977] Kantor, B., and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[RFC-977] カンター、B.とP.ラプスリー、「ネットワークの電子情報を転送するプロトコル」、RFC977、1986年2月。
[RFC-1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC-1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC-1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC-1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC-1123] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989.
[RFC-1123] ブレーデンと、R.と、「インターネット・ホスト--アプリケーションのための要件とサポート」、STD3、RFC1123、10月1989日
[RFC-1288] Zimmerman, D., "The Finger User Information Protocol", RFC 1288, December 1992.
[RFC-1288] ジンマーマン、D.、「指のユーザー情報プロトコル」、RFC1288、1992年12月。
[RFC-1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC-1305] 工場、D.、「ネットワーク時間プロトコル(バージョン3)仕様、実装」RFC1305、3月1992日
[RFC-1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D., and B. Albert, "The Internet Gopher Protocol (a distributed document search and retrieval protocol)", RFC 1436, March 1993.
[RFC-1436] Anklesaria、F.、McCahill、M.、リントナー、P.、ジョンソン、D.、トーリー、D.、およびB.アルバート、「インターネットゴーファープロトコル(分配されたドキュメント検索と検索プロトコル)」、RFC1436(1993年3月)。
[RFC-1590] Postel, J., "Media Type Registration Procedure", RFC 1590, March 1994.
[RFC-1590] ポステル、J.、「メディアは登録手順をタイプする」RFC1590、1994年3月。
[RFC-1625] St. Pierre, M., Fullton, J., Gamiel, K., Goldman, J., Kahle, B., Kunze, J., Morris, H., and F. Schiettecatte, "WAIS over Z39.50-1988", RFC 1625, June 1994.
[RFC-1625]サン・ピエール島とM.とFulltonとJ.とGamielとK.とゴールドマンとJ.とカーレとB.とクンツェとJ.とモリス、H.とF.Schiettecatte、「Z39.50-1988の上のWAIS」RFC1625(1994年6月)。
[RFC-1700] Reynolds, J.K., and J. Postel, "ASSIGNED NUMBERS", STD 2, RFC 1700, October 1994.
[RFC-1700] レイノルズ、J.K.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
Hamilton & Wright Best Current Practice [Page 7] RFC 2219 DNS Aliases October 1997
ハミルトンと職人の最も良い電流はDNS別名1997年10月にRFC2219を練習します[7ページ]。
[RFC-1714] Williamson, S., and M. Kosters, "Referral Whois Protocol (RWhois)", RFC 1714, November 1994.
[RFC-1714] ウィリアムソン、S.とM.Kosters、「紹介Whoisプロトコル(RWhois)」、RFC1714、1994年11月。
[RFC-1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.
[RFC-1777] YeongとW.とハウズ、T.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル」、RFC1777、1995年3月。
[RFC-1912] Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, Feburary 1996.
[RFC-1912] バール、D.、「DNS操作上と構成の一般的な誤り」、RFC1912、Feburary1996。
[RFC-1939] Myers, J., and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC-1939] マイアーズ、J.、およびM.ローズ、「バージョン3インチ、STD53、RFC1939、1996年POP--5月。」
[RFC-1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC-1945] バーナーズ・リー、T.、フィールディング、R.、およびH.ニールセン、「HTTP/1インチ、RFC1945、1996年ハイパーテキスト転送プロトコル--5月。」
[RFC-2052] Gulbrandsen, A., and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
[RFC-2052] Gulbrandsen、A.、およびP.Vixie、「サービスの位置を指定するためのDNS RR(DNS SRV)」、RFC2052(1996年10月)。
[RFC-2065] Eastlake, D., and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[RFC-2065] イーストレーク、D.とC.コーフマン、「ドメインネームシステムセキュリティ拡大」、RFC2065、1997年1月。
12. Authors' Addresses
12. 作者のアドレス
Martin Hamilton Department of Computer Studies Loughborough University of Technology Leics. LE11 3TU, UK
コンピュータのマーチンハミルトン部は技術Leicsのラフバラ大学を研究します。 LE11 3TU、イギリス
EMail: m.t.hamilton@lut.ac.uk
メール: m.t.hamilton@lut.ac.uk
Russ Wright Information & Computing Sciences Division Lawrence Berkeley National Laboratory 1 Cyclotron Road, Berkeley Mail-Stop: 50A-3111 CA 94720, USA
1つのラス職人の情報と電子計算学事業部ローレンス・バークレーNationalの研究所サイクロトロン道路、バークレーのメール停止: 50A-3111カリフォルニア 94720、米国
EMail: wright@lbl.gov
メール: wright@lbl.gov
Hamilton & Wright Best Current Practice [Page 8]
ハミルトンと職人の最も良い現在の習慣[8ページ]
一覧
スポンサーリンク