Skip to content

Instantly share code, notes, and snippets.

@akkijp
Created March 24, 2016 17:36
Show Gist options
  • Save akkijp/3672b447edfc002b3cf6 to your computer and use it in GitHub Desktop.
Save akkijp/3672b447edfc002b3cf6 to your computer and use it in GitHub Desktop.
RFC 1034.md

[RFC 1034] DOMAIN NAMES - CONCEPTS AND FACILITIES 「ドメイン名 - 概念と機能」

1. STATUS OF THIS MEMO 「この文書の状態」

This RFC is an introduction to the Domain Name System (DNS), and omits many details which can be found in a companion RFC, "Domain Names - Implementation and Specification" [RFC-1035]. That RFC assumes that the reader is familiar with the concepts discussed in this memo. このRFCはドメインネームシステム(DNS)の紹介であり、関連するRFC「ドメイン名-実装と仕様書」[RFC-1035]に記載してる細部は書いていません。RFC1035は読者がこのメモで論じた概念に精通していると想定します。

A subset of DNS functions and data types constitute an official protocol. The official protocol includes standard queries and their responses and most of the Internet class data formats (e.g., host addresses).

DNS機能とデータタイプの一部が公式プロトコルです。公式プロトコルは標準問合せとその回答とほとんどのインターネットクラスデータフォーマットを含みます(例えば、ホストアドレス)。

However, the domain system is intentionally extensible. Researchers are continuously proposing, implementing and experimenting with new data types, query types, classes, functions, etc. Thus while the components of the official protocol are expected to stay essentially unchanged and operate as a production service, experimental behavior should always be expected in extensions beyond the official protocol. Experimental or obsolete features are clearly marked in these RFCs, and such information should be used with caution.

ドメインシステムは意図的に拡大可能です。研究者が常に新しいデータタイプや問合せ種別やクラスや機能などを提案し実装し実験しています。そのため公式プロトコルの内容が本質的に変化していなく実用サービスとして機能することを期待されていても、実験的な行動が常に公式プロトコルを拡張して行なわれると思うべきです。実験的か時代遅れの機能はこのRFCで明示します、このような情報には注意すべきです。

The reader is especially cautioned not to depend on the values which appear in examples to be current or complete, since their purpose is primarily pedagogical. Distribution of this memo is unlimited.

手本に示す値は教育的な目的で記載してるので、読者はそれが現在の値であるとか正しい値であるとか思わないように注意してください。このメモの配布は無制限です。

2. INTRODUCTION 「はじめに」

This RFC introduces domain style names, their use for Internet mail and host address support, and the protocols and servers used to implement domain name facilities.

このRFCはドメインスタイル名を導入し、これはインターネットメールやホストアドレス検索やドメイン名機能を使うプロトコルやサービスで使われます。

2.1. The history of domain names 「ドメイン名の歴史」

The impetus for the development of the domain system was growth in the Internet:

ドメインシステムの開発のきっかけはインターネットの増加でした:

  • Host name to address mappings were maintained by the NetworkInformation Center (NIC) in a single file (HOSTS.TXT) whichwas FTPed by all hosts [RFC-952, RFC-953]. The total networkbandwidth consumed in distributing a new version by thisscheme is proportional to the square of the number of hosts inthe network, and even when multiple levels of FTP are used,the outgoing FTP load on the NIC host is considerable.Explosive growth in the number of hosts didn't bode well forthe future
  • ホスト名とアドレスの対応はネットワーク情報センター(NIC)で維持され、これは1つのファイル(HOSTS.TXT)を全てのホストへFTPで送ることで行っていました[RFC-952,RFC-953]。この方法で新版を配るために消費された全体のネットワークバンド幅はネットワークホスト数の2乗に比例します、そして多段レベルのFTPを使ていても、NICホストの外へのFTP負荷はかなりです。ホスト数の爆発的増加は将来の良い前兆ではありませんでした
  • The network population was also changing in character. Thetimeshared hosts that made up the original ARPANET were beingreplaced with local networks of workstations. Localorganizations were administering their own names andaddresses, but had to wait for the NIC to change HOSTS.TXT tomake changes visible to the Internet at large. Organizationsalso wanted some local structure on the name space
  • ネットワーク利用者の性格も同じく変化していました。昔のARPANETを構成したタイムシェアリングホストはワークステーションを使ったローカルネットワークで置き換えられていました。ローカル組織が自分自身の名前とアドレスを管理していました、しかしインターネットから見えるようにするにはNICのHOSTS.TXTが変わるまで待たなければなりませんでした。組織が名前空間になんらかのローカルな空間を欲していました
  • The applications on the Internet were getting moresophisticated and creating a need for general purpose nameservice
  • インターネット上のアプリケーションはより凝ったものになり、汎用のネームサービスの要求が生まれました。

The result was several ideas about name spaces and their management [IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a common thread was the idea of a hierarchical name space, with the hierarchy roughly corresponding to organizational structure, and names using "." as the character to mark the boundary between hierarchy levels. A design using a distributed database and generalized resources was described in [RFC-882, RFC-883]. Based on experience with several implementations, the system evolved into the scheme described in this memo.

名前空間とその管理に関する数々のアイデアが出ました[IEN-116, RFC-799,RFC-819, RFC-830]。提案はいろいろ変わりましたが、階層的な名前空間を使うことと、階層が組織に対応した構造にする事と、名前に"."の文字を使い階層の区切りとすることが、共通認識となりました。分散データベースと一般化された資源を使うデザインが[RFC-882, RFC-883]で記述されました。いくつかの実装経験に基づいて、システムはこのメモで記述された形に発展しました。

The terms "domain" or "domain name" are used in many contexts beyond theDNS described here. Very often, the term domain name is used to referto a name with structure indicated by dots, but no relation to the DNS.This is particularly true in mail addressing [Quarterman 86].

用語「ドメイン」あるいは「ドメイン名」がここで記述されたDNS以外で多くの文脈で使われます。非常によく、ドメイン名という用語はDNSの関係ではなく、点で区切られた構造の名前に使われます。これはメールアドレスで特に本当です[Quarterman 86]。

2.2. DNS design goals 「DNS構想の目標」

The design goals of the DNS influence its structure. They are:

DNS構想の目標はその構造に影響を与えます。これは:

  • The primary goal is a consistent name space which will be usedfor referring to resources. In order to avoid the problemscaused by ad hoc encodings, names should not be required tocontain network identifiers, addresses, routes, or similarinformation as part of the name.
  • 主要な目標は資源を参照するのに使う一貫した名前空間です。特別なコーディングにより起こる問題を避けるために、名前の一部にネットワーク識別子、アドレス、ルート、あるいは類似の情報を含むように要求されるべきではありません。
  • The sheer size of the database and frequency of updatessuggest that it must be maintained in a distributed manner,with local caching to improve performance. Approaches thatattempt to collect a consistent copy of the entire databasewill become more and more expensive and difficult, and henceshould be avoided. The same principle holds for the structureof the name space, and in particular mechanisms for creatingand deleting names; these should also be distributed.
  • データベースの薄い大きさと更新の頻度は、データベースが分散的に管理されなければならないことを示唆し、ローカルキャッシュが性能を改善します。全部のデータベースの完全なコピーを集める方法は高くつくし難しいので避けるべきです。同じ事は名前空間の構造でも真実で、特に名前を作るのと削除する方法は、これも分散して行えるべきです。
  • Where there tradeoffs between the cost of acquiring data, thespeed of updates, and the accuracy of caches, the source ofthe data should control the tradeoff.
  • データ獲得のコストと更新の速さとキャッシュの正確さのトレードオフがあり、データ生成源がトレードオフをコントロールするべきです。
  • The costs of implementing such a facility dictate that it begenerally useful, and not restricted to a single application.We should be able to use names to retrieve host addresses,mailbox data, and other as yet undetermined information. Alldata associated with a name is tagged with a type, and queriescan be limited to a single type.
  • このような機能を実装するコストは、これがひとつのアプリケーションに限定されず、一般的に有用なことを必要とします。名前がホストアドレスとメールボックスデータと他のまだ存在しない情報を検索するための名前に利用可能であるべきです。ある名前と関連する全てのデータが種別札をつけられ、問合せが1つの札に限定できます。
  • Because we want the name space to be useful in dissimilarnetworks and applications, we provide the ability to use thesame name space with different protocol families ormanagement. For example, host address formats differ betweenprotocols, though all protocols have the notion of address.The DNS tags all data with a class as well as the type, sothat we can allow parallel use of different formats for dataof type address.
  • 我々が異なるネットワークとアプリケーションで利用できる名前空間を欲するので、我々は異なるプロトコルファミリーや管理で同じ名前空間を使う能力に提供します。例えば、ホストアドレスフォーマットはプロトコル毎に異なりますが、すべてのプロトコルがアドレスの考えを持ちます。DNSはデータに種別札だけでなくクラス札もつけます、これで我々は異なったフォーマットのアドレス種別データを平行して扱えます。
  • We want name server transactions to be independent of thecommunications system that carries them. Some systems maywish to use datagrams for queries and responses, and onlyestablish virtual circuits for transactions that need thereliability (e.g., database updates, long transactions); othersystems will use virtual circuits exclusively.
  • 我々はネームサーバ処理がそれを運ぶ通信システムから独立していることを望みます。あるシステムが問合せと回答にデータグラムを使い、そして信頼性が必要な処理にだけ仮想回路を接続するのを望むかもしれません(例えば、データベース更新、長い処理);他のシステムが排他的に仮想の回路を使うでしょう。
  • The system should be useful across a wide spectrum of hostcapabilities. Both personal computers and large timesharedhosts should be able to use the system, though perhaps indifferent ways.
  • システムは様々な能力のホストで使えるべきです。パーソナル・コンピュータと大きなタイムシェアリングホストの両方が、多分異なった方法ですが、システムを使えるべきです。

2.3. Assumptions about usage 「利用に関する仮定」

The organization of the domain system derives from some assumptions about the needs and usage patterns of its user community and is designed to avoid many of the the complicated problems found in general purpose database systems.

ドメインシステムの組織は、ユーザ共同体の要求と使い方のパターンにある仮定をし、一般的な目的のデータベースシステムの複雑な問題を避けています。

The assumptions are:

その仮定は:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment