RFC973 日本語訳
0973 Domain system changes and observations. P.V. Mockapetris. January 1986. (Format: TXT=22364 bytes) (Obsoleted by RFC1034, RFC1035) (Updates RFC0882, RFC0883) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Paul Mockapetris Request for Comments: 973 ISI January 1986
ネットワークワーキンググループポールMockapetrisはコメントのために以下を要求します。 973 ISI1986年1月
Domain System Changes and Observations
ドメインシステム変化と観測
STATUS OF THIS MEMO
このメモの状態
This RFC documents updates to Domain Name System specifications RFC-882 [1] and RFC-883 [2], suggests some operational guidelines, and discusses some experiences and problem areas in the present system. Distribution of this memo is unlimited.
このRFCは現行制度でドメインネームシステム仕様のRFC-882[1]とRFC-883[2]にアップデートを記録して、いくつかの運用指針を勧めて、いくつかの経験と問題領域について議論します。 このメモの分配は無制限です。
This document includes all changes to the Domain System through January, 1986. Change notices and additional discussion are available online in file [USC-ISIB.ARPA]<DOMAIN>DOMAIN.CHANGES.
このドキュメントは1986年1月までDomain Systemへのすべての変化を含んでいます。 変更通知と追加議論はファイル[USC-ISIB.ARPA]<DOMAIN>DOMAIN.CHANGESでオンラインで利用可能です。
OVERVIEW
概観
This memo is divided into four major sections:
このメモは4つの主要なセクションに分割されます:
"UPDATES" which discusses changes to the domain specification which are in widespread use and should be regarded as being part of the specification.
仕様のあるとき、普及使用にはあって、見なされるべきであるドメイン仕様への変化について議論する「UPDATES」部分。
"OPERATION GUIDELINES" which suggests rules-of-thumb for using the domain system and configuring your database which are appropriate in most cases, but which may have rare exceptions.
ドメインシステムを使用して、あなたのデータベースを構成するための多くの場合適切ですが、まれな例外を持っているかもしれない経験則を示す「OPERATION GUIDELINES。」
"EXPERIENCES" which discusses some unusual situations and common bugs which are encountered in the present system, and should be helpful in problem determination and tuning.
現行制度で遭遇して、問題決断に役立っていて調整していて、いくつかの異例の状況について議論する「EXPERIENCES」と一般的なそうするバグは遭遇するべきでした。
"PROBLEM AREAS" which discusses some shortcomings in the present system which may be addressed in future versions.
将来のバージョンに記述されるかもしれない現行制度のいくつかの短所について議論する「PROBLEM AREAS。」
UPDATES
アップデート
This section discusses changes to the specification which are final, and should be incorporated in all domain system software.
このセクションは、仕様への最終的な変化について議論して、すべてのドメインシステムソフトで組み込んでいるべきです。
TTL timeouts too small
TTLタイムアウト、も小ささ
The 16 bit TTL field in RRs could not represent a large enough time interval. The 16 bit field, using seconds for units, has a maximum period of approximately 18 hours.
RRsの16ビットのTTL分野は十分大きい時間間隔を表すことができませんでした。 16ビットの分野には、ユニットに秒を使用して、最大およそ18時間の期間があります。
All time values, including all TTLs and the MINIMUM field of the SOA RR, are expanded to 32 bits.
SOA RRのすべてのTTLsとMINIMUM分野を含むすべての時間的価値が32ビットに広げられます。
Mockapetris [Page 1]
Mockapetris[1ページ]
RFC 973 January 1986 Domain System Changes and Observations
RFC973 1986年1月ドメインシステム変更と観測
CLASS changes
CLASS変化
Class 2, originally reserved for CSNET, is obsolete. Class 3 has been assigned for use by CHAOS.
元々CSNETのために予約されたクラス2は時代遅れです。 クラス3は使用のためにCHAOSによって割り当てられました。
CNAME usage
CNAME用法
The specification allows CNAME RRs to exist with other RRs at the same node. This creates difficulties since the other RRs stored with the CNAME at the alias might not agree with the RRs stored at the primary name.
仕様で、CNAME RRsは同じノードの他のRRsと共に存在できます。 別名におけるCNAMEと共に格納された他のRRsが第一の名前で格納されたRRsに同意しないかもしれないので、これは困難を作成します。
If a node has a CNAME RR, it should have no other RRs.
ノードにCNAME RRがあるなら、それは他のRRsを全く持つべきではありません。
* semantics
* 意味論
The use of * to represent a single label wildcard, along with the possibility of multiple * labels, led to difficult server implementations and complicated search algorithms. There were also questions regarding whether a * based specification could refer to names that were not contained in the zone which had the * specification.
単一のラベルワイルドカードを表す*の使用は複数の*ラベルの可能性と共に難しいサーバ実現と複雑な検索アルゴリズムにつながりました。*ベースの仕様が*仕様を持っていたゾーンに保管されていなかった名前を示すことができたかどうかに関する質問もありました。
While we might want the "inheritability" for some cases, it leads to implementation difficulties. The first of these is that whenever we can't find a RR in a particular zone, we have to search all parent zones to look for a suitable * result. (Alternatively we could develop some automatic method for insuring consistency or insist on careful duplication of inherited data.) We also must deal with conflicts, i.e. what if a subdomain doesn't want to inherit defaults.
私たちは、いくつかのケースのために"「不-遺伝率」"が欲しいと思うかもしれませんが、それは実現困難に通じます。 これらの1番目は特定のゾーンでRRを見つけることができないときはいつも、私たちが適当な*結果を探すためにすべての親ゾーンを捜さなければならないということです。 (あるいはまた、私たちは、一貫性を保障するための何らかの自動方法を開発するか、または引き継いでいるデータの慎重な複製を主張できました。) また、私たちは闘争に対処しなければなりません、すなわち、サブドメインが世襲したくないか場合どうなるかがデフォルトとします。
Given these difficulties, the solution is to insist that delegation of authority cancels the * defaults. This is quite simple to implement; all you need to do is to check for delegation before looking for * RRs.
これらの困難を考えて、解決策は権限の委任が*デフォルトを取り消すと主張することです。 これは実行するのはかなり簡単です。 あなたがする必要があるすべては*RRsを探す前に代表団がないかどうかチェックすることです。
A second difficulty is the restriction that * match a single label. Thus if a name server is looking for RRs for the name A.B.C.D.E.F, it must check for *.B.C.D.E.F, *.*.C.D.E.F, *.*.*.D.E.F, etc. This check must also be careful of zone boundaries and multiplies the effort to handle a query.
2番目の困難は*が単一のラベルに合っているという制限です。 したがって、ネームサーバが名前A.紀元前D.E.FのためにRRsを探しているなら、それは***.B.C.D.E.F、**.C.D.E.F、*.D.E.Fなどがないかどうかチェックしなければなりません。 このチェックは、また、ゾーン境界に注意していなければならなくて、質問を扱うための努力を掛けます。
The solution adopted is to allow a single * label in the leftmost part of a name stored in a zone, and to allow this label to match
採用された解決策は、ゾーンに格納された名前の一番左部分に単一の*ラベルを許容して、このラベルが合っているのを許容することです。
Mockapetris [Page 2]
Mockapetris[2ページ]
RFC 973 January 1986 Domain System Changes and Observations
RFC973 1986年1月ドメインシステム変更と観測
any number of unknown labels or a single known label in the query name. However, the * match is only taken for parts of the tree which are neither delegated or explicitly represented.
いろいろな未知のラベルか質問名の単一の知られているラベル。 しかしながら、*マッチは代表として派遣しないか、または明らかに表さない木の部分に取り入れられるだけです。
The algorithm for performing the search in a tree structured database has the following steps:
木の構造型データベースにおける検索を実行するためのアルゴリズムには、以下のステップがあります:
1) Descend in the tree matching labels from right to left. If a delegation is found return that; if the specified node is found go to step 2, if the tree ends go to step 3.
1) 木の合っているラベルを左への権利から下ってください。 代表団が見つけられるなら、それを返してください。 指定されたノードが見つけられるなら、木の終わりがステップ3へ去るなら、ステップ2に行ってください。
2) Look for RRs that answer the query. If any are found, return them as the answer. If none are found, look for answers in a * node which has the same name as the query name except for the rightmost label. (e.g. if you can't find an answer at F.ISI.ARPA, look for a RR at *.ISI.ARPA)
2) 質問に答えるRRsを探してください。 いずれか見つけられるなら、答えとしてそれらを返してください。 なにも見つけられないなら、一番右のラベル以外の質問名と同じ名前を持っている*ノードにおける答えを探してください。 (例えば、F. ISI.ARPAで答えを見つけることができないなら、*.ISI.ARPAでRRを探してください)
3) The search for a desired name has failed; look for a node whose name is * plus however much matched. Look for answers there. (e.g. If you are looking for X.Y.ISI.ARPA and the tree ends at ISI.ARPA, look at *.ISI.ARPA. The same thing holds for Y.ISI.ARPA, or any name of the form <anything>.Z.ISI.ARPA, where Z is a label that doesn't exist under ISI.ARPA)
3) 必要な名前の検索は失敗しました。 名前がしかしながら、そのうえ、たくさん合わせられた*であるノードを探してください。 そこで答えを探してください。 (例えば、あなたがX. Y. ISI.ARPAと木の終わりにISI.ARPAを見るIf、*.ISI.ARPAを見てください。 同じものが、Y. ISI.ARPA、またはフォーム<のどんな名前のためにも何が>.Z. ISI.ARPAであることでも保持する、)。(そこでは、ZがISI.ARPAの下に存在しないラベルです)。
Note that this interpretation means that * matches names that are not in the tree, no matter how much of the tree is missing, and also matches one level's worth of known tree.
この解釈が、*が木にない名前に合っていることを意味することに注意してください、木のいくらがなくなり、また、1つのレベルの知られている木の価値に合っても。
AA semantics
AA意味論
When a name server is responding to a query for a particular name and finds a CNAME, it may optionally restart the search at the canonical name. If the server uses the restart feature, the answer section of the returned query contains one (or more) CNAMEs, possibly followed by answers for the primary name. The canonical name will usually be in the same zone as the alias, but this need not be the case. If the server is authoritative for one of the names but not both, it is not clear whether the AA bit should be set.
ネームサーバが特定の名前のための質問に応じていて、CNAMEを見つけるとき、それは正準な名前で検索を任意に再開するかもしれません。 サーバが再開機能を使用するなら、返された質問の答え部は1(さらに)CNAMEsを含みます、ことによると、続いて第一の名前のための答えを含みます。 正準な名前が別名と同じゾーンに通常あるでしょうが、これはそうである必要はありません。 サーバが名前の1つに正式ですが、ともに正式であるというわけではないなら、AAビットが設定されるべきであるかどうかは、明確ではありません。
The solution adopted is to make the AA refer to the original query name.
採用された解決策はAAにオリジナルの質問名を示させることです。
Mockapetris [Page 3]
Mockapetris[3ページ]
RFC 973 January 1986 Domain System Changes and Observations
RFC973 1986年1月ドメインシステム変更と観測
Master file format
基本ファイル形式
The present specification uses a somewhat awkward method for representing domain names in master files.
現在の仕様は、ドメイン名を表すのに基本ファイルでいくらか厄介な方法を使用します。
The change adopted is that all domain names in this file will be represented as either absolute or relative. An absolute domain name ends with a ".". A free standing "." is assumed to refer to the root. A relative domain name doesn't end with a dot, and is assumed to be relative to the current origin.
採用された変化はこのファイルのすべてのドメイン名が絶対か相対的であるとして表されるということです。 「絶対ドメイン名はa」で終わります。」 「A無料の地位」 」 根について言及すると思われます。 相対的なドメイン名は、ドットで終わらないで、現在の起源に比例していると思われます。
SERIAL number size
SERIAL数のサイズ
If the master file changes rapidly, an infrequently updated copy may miss the wrapping of the sequence number in the SERIAL field of the SOA, or misinterpret the number of updates that have taken place.
基本ファイルが急速に変化するなら、まれにアップデートされたコピーは、SOAのSERIAL分野における、一連番号のラッピングをなくすか、または行われたアップデートの数を誤解するかもしれません。
The SERIAL field is increased to 32 bits.
SERIAL分野は32ビットまで増加します。
MD and MF replaced by MX
MXに取り替えられたMDとMF
The original specification uses MD and MF RRs for mail agent binding. The problem is that a mailer making a MAILA query, which asks for both types, can't use the cache since the cache might have the results for a MD or MF query. That is, the presence of one of these types of information in the cache doesn't imply anything about the other type. The result was that either mailers would have to always consult authoritative servers or try to use partial information; neither of these is really acceptable.
正式仕様書はメールエージェント結合にMDとMF RRsを使用します。 問題はキャッシュにはMDかMF質問のための結果があるかもしれないので両方のタイプを求めるMAILA質問をしている郵送者がキャッシュを使用できないということです。 すなわち、キャッシュにおける、情報のこれらのタイプのひとりの存在はもう片方のタイプに関して何も含意しません。 結果はいつも正式のサーバに相談しなければならない、さもなければ、郵送者が部分的な情報を使用しようとしなければならないだろうということでした。 これらのどちらも本当に許容できません。
The change is to replace MD and MF with a new type of RR called MX which conveys similar information in a single RR type. MX has been assigned a type code of 15 decimal. The format of the MX RR is a 16 bit preference value followed by a domain name. A node may have multiple MX RRs, and multiple MX RRs with the same preference value are allowed at a given node.
変化はMDを取り替えることになっています、そして、RRの新しいタイプが独身のRRの同様の情報を伝えるMXと呼ばれているMFはタイプします。 15小数のタイプコードをMXに割り当ててあります。 MX RRの形式はドメイン名がいうことになった16ビットの好みの値です。 ノードには複数のMX RRsがあるかもしれません、そして、同じ好みの値がある複数のMX RRsが与えられたノードに許容されています。
Mockapetris [Page 4]
Mockapetris[4ページ]
RFC 973 January 1986 Domain System Changes and Observations
RFC973 1986年1月ドメインシステム変更と観測
The preference values denote the relative preference that the mail destination places on the mail agents, with lower values being "better". A mailer is expected to at least try the mail agent(s) with the lowest preference value. The significance of particular preference values, the units of preference, and the linearity of preference values are not defined but left open; preference values should only be used to establish relative rankings.
好みの値はメールの目的地がメールエージェントに置く相対的選好を指示します、下側の値が「より良い」状態で。 郵送者が最も低い好みの値でメールエージェントを少なくとも裁くと予想されます。 特定の好みの値の意味、好みの単位、および好みの値の直線形は、定義されませんが、開くままにされます。 好みの値は、相対的なランキングを証明するのに使用されるだけであるべきです。
For example, the current RRs:
例えば、現在のRRs:
MAIL-ORG MD HOST1 MD HOST2 MF HOST3
メール-ORG MD HOST1MD HOST2mf HOST3
might be replaced by:
取り替えるかもしれません:
MAIL-ORG MX 10 HOST1 MX 10 HOST2 MX 20 HOST3
メール-ORG HOST1Mx Mx10 10HOST2Mx20HOST3
The values 10 and 20 have no significance other than 10<20. A detailed discussion of the use of MX is the subject of [3].
値10と20には、10<20以外の意味が全くありません。 MXの使用の詳細な論議は[3]の対象です。
Zone transfer
ゾーン転送
The original specification states that zone transfers take place in breadth first order. The intent was to make the transfer easier for the accepting name server to handle. This now doesn't work out to be very helpful, and is a severe pain for implementers using various hashing algorithms. The new rule is that you can transmit the records in any order you choose, so long as the SOA node of the zone is transmitted first and last, and no other duplication occurs.
正式仕様書は、ゾーン転送が幅の第1オーダーに起こると述べます。 意図は受諾ネームサーバが転送を扱うのをより簡単にすることでした。 これは、今非常に役立つように解決しないで、様々な論じ尽くすアルゴリズムを使用するimplementersのための激痛です。新しい規則はあなたがあなたが選ぶどんなオーダーでも記録を伝えることができるということです、ゾーンのSOAノードが最初にと最後に伝えられて、他の複製が全く起こらない限り。
IN-ADDR domain renamed
改名されたIN-ADDRドメイン
The name of the IN-ADDR domain is now IN-ADDR.ARPA. This change was made because many felt that the use of a top-level name was inappropriate to network-specific information.
現在、IN-ADDRドメインの名前はIN-ADDR.ARPAです。 多くが、トップレベル名の使用がネットワーク特有の情報に不適当であると感じたので、この変更は行われました。
Mockapetris [Page 5]
Mockapetris[5ページ]
RFC 973 January 1986 Domain System Changes and Observations
RFC973 1986年1月ドメインシステム変更と観測
OPERATIONAL GUIDELINES
運用指針
This section suggests rules-of-thumb for using the domain system and configuring your database which are appropriate in most cases, but which may have rare exceptions.
このセクションはドメインシステムを使用して、あなたのデータベースを構成するための多くの場合適切ですが、まれな例外を持っているかもしれない経験則を示します。
Zone delegation
ゾーン代表団
When a domain wishes to become independent from its parent, the RRs which mark the delegation in the parent and child zones should be carefully synchronized to minimize the possibility that resolvers become confused.
ドメインが親から独立するようになりたがっているとき、親子ゾーンで代表団をマークするRRsは、レゾルバが混乱するようになる可能性を最小にするために慎重に連動するべきです。
For example, suppose that we wish to create a new zone called ISI.EDU under an existing EDU zone, and that the servers for the child zone are X.ISI.EDU and Y.GOV.
例えば、子供ゾーンへのサーバが既存のEDUゾーンの下のISI.EDUと呼ばれる新しいゾーンを作成したいと思って、X. ISI.EDUとY. GOVであると仮定してください。
We might add the following to the parent zone:
私たちは親ゾーンに以下を追加するかもしれません:
ISI.EDU. 10000 NS X.ISI.EDU. 10000 NS Y.GOV. X.ISI.EDU. 10000 A <address of X.ISI.EDU.> Y.GOV. 10000 A <address of Y.GOV.>
ISI.EDU。 10000ナノ秒のX.ISI.EDU。 10000ナノ秒のY.知事X.ISI.EDU。 10000 X.ISI.EDUの<アドレス。>Y.GOV10000 Y.GOV>の<アドレス
and the following to the child zone:
子供ゾーンへの以下:
ISI.EDU. 10000 NS X.ISI.EDU. 10000 NS Y.GOV. 50000 SOA <SOA information> X.ISI.EDU. 10000 A <address of X.ISI.EDU.> Y.GOV. 10000 A <address of Y.GOV.>
ISI.EDU。 10000ナノ秒のX.ISI.EDU。 10000 NS Y. GOV50000 SOA<SOA情報>X. ISI.EDU。 10000 X.ISI.EDUの<アドレス。>Y.GOV10000 Y.GOV>の<アドレス
Note the following:
以下に注意してください:
In both cases, the A RR for Y.GOV is included, even though Y.GOV isn't in the EDU or ISI.EDU domains. This RR isn't authoritative, but is included to guarantee that the address of Y.GOV is passed with delegations to it. Strictly speaking this RR need not be in either zone, but its presence is recommended. The X.ISI.EDU A RR is absolutely essential. The only time that a server should use the glue RRs is when it is returning the NS RRs and doesn't otherwise have the address of the server. For example, if the parent server also was authoritative for GOV, the glue RR would typically not be consulted. However, it is still a good idea for it to be present, so that the zone is self-sufficient.
どちらの場合も、Y. GOVがEDUかISI.EDUドメインにありませんが、Y. GOVのためのA RRは含まれています。 このRRは、Y. GOVのアドレスが代表団と共にそれに通過されるのを保証するために正式であり、含まれていません。 厳密に言うと、このRRはどちらのゾーンにもある必要はありませんが、存在はお勧めです。 X. ISI.EDU A RRは絶対に不可欠です。 サーバが接着剤RRsを使用するべきである唯一の時間がNS RRsを返していてそうでなければそれがサーバのアドレスを持っていない時です。例えば、GOVに、親サーバも正式であるなら、接着剤RRは通常相談されないでしょうに。 しかしながら、それでも、それが存在しているのが、名案であるので、ゾーンは自給自足しています。
Mockapetris [Page 6]
Mockapetris[6ページ]
RFC 973 January 1986 Domain System Changes and Observations
RFC973 1986年1月ドメインシステム変更と観測
The child zone and the parent zone have identical NS RRs for the ISI.EDU domain. This guarantees that no matter which server is asked about the ISI.EDU domain, the same set of name servers is returned.
子供ゾーンと親ゾーンには、ISI.EDUドメインへの同じNS RRsがあります。 これは、どのサーバがISI.EDUドメインに関して尋ねられても、同じセットのネームサーバが返されるのを保証します。
The child zone and the parent zone have A RRs for the name servers in the NS RRs that delegate the ISI.EDU domain. This guarantees that in addition to knowing the name servers for the ISI.EDU domain, the addresses of the servers are known as well.
子供ゾーンと親ゾーンはISI.EDUドメインを代表として派遣するNS RRsにネームサーバのためのA RRsを持っています。 これは、また、ISI.EDUドメインにネームサーバを知っていることに加えてサーバのアドレスが知られているのを保証します。
The TTLs for the NS RRs that delegate the ISI.EDU domain and the A RRs that represent the addresses of the name servers are all the same. This guarantees that all of these RRs will timeout simultaneously. In this example, the value 10000 has no special significance, but the coincidence of the TTLs is significant.
NS RRsのためのISI.EDUドメインを代表として派遣するTTLsとネームサーバのアドレスを表すA RRsはちょうど同じです。 これは、これらのRRsのすべては同時のタイムアウトがそうするのを保証します。 この例では、値10000はどんな特別な意味も持っていませんが、TTLsの偶然の一致は重要です。
These guidelines haven't changed any of the flexibility of the system; the name of a name server and the domains it serves are still independent.
これらのガイドラインはシステムの柔軟性のいずれも変えていません。 ネームサーバの名前とそれが役立つドメインはまだ独立しています。
It might also be the case that the organization called ISI wanted to take over management of the IN-ADDR domain for an internal network, say 128.99.0.0. In this case, we would have additions to the parent zone, say IN-ADDR.ARPA.
また、たとえば、ISIと呼ばれる組織が内部のネットワークのためにIN-ADDRドメインのマネージメントを引き継ぎたがっていたのが、事実であるかもしれない、128.99、.0、.0 IN-ADDR.ARPAは、この場合私たちが親ゾーンに追加を持っていると言います。
We might add the following to the parent zone:
私たちは親ゾーンに以下を追加するかもしれません:
99.128.IN-ADDR.ARPA. 2000 NS Q.ISI.EDU. 2000 NS XX.MIT.EDU. Q.ISI.EDU. 2000 A <address of Q.ISI.EDU.> XX.MIT.EDU. 2000 A <address of XX.MIT.EDU.>
ADDR.ARPAの99.128.。 2000ナノ秒のQ.ISI.EDU。 2000ナノ秒のXX.MIT.EDU。 Q.ISI.EDU。 2000 Q.ISI.EDUの<アドレス。>XX.MIT.EDU。 2000 XX.MIT.EDU>の<アドレス
and the following to the child zone:
子供ゾーンへの以下:
99.128.IN-ADDR.ARPA. 2000 NS Q.ISI.EDU. 2000 NS XX.MIT.EDU. 5000 SOA <SOA information> Q.ISI.EDU. 2000 A <address of Q.ISI.EDU.> XX.MIT.EDU. 2000 A <address of XX.MIT.EDU.>
ADDR.ARPAの99.128.。 2000ナノ秒のQ.ISI.EDU。 2000ナノ秒のXX.MIT.EDU。 5000 SOA<SOA情報>Q. ISI.EDU。 2000 Q.ISI.EDUの<アドレス。>XX.MIT.EDU。 2000 XX.MIT.EDU>の<アドレス
SOA serials
SOAシリーズ
The serial field of the SOA RR for a domain is supposed to be a continuously increasing (mod 2**32) value which denotes the
SOA RRの連続の分野が絶え間なく(モッズ風の2**32)を増強しながらドメインがaであるべきであるのでどれを評価するか、指示
Mockapetris [Page 7]
Mockapetris[7ページ]
RFC 973 January 1986 Domain System Changes and Observations
RFC973 1986年1月ドメインシステム変更と観測
version of the database. The idea is that you can tell that a zone has changed by comparing serial numbers. When you change a zone, you should increment the serial field of the SOA.
データベースのバージョン。 考えはあなたが、ゾーンが通し番号を比較することによって変化したと言うことができるということです。 ゾーンを変えると、あなたはSOAの連続の分野を増加するべきです。
All RRs with the same name, class, and type should have the same TTL.
同じ名前、クラス、およびタイプがあるすべてのRRsには、同じTTLがあるはずです。
The logic here is that all of them will timeout simultaneously if cached and hence the cache can be reliably used.
ここの論理はキャッシュされるなら彼らが皆、同時にタイムアウトを望んでいるということです、そして、したがって、キャッシュは確かに使用できます。
Case consistency
ケースの一貫性
The domain system is supposed to preserve case, but be case insensitive. However, it does nobody any good to put both RRs for domain name xxx and XXX in the data base - It merely makes caching ambiguous and decreases the efficiency of compression. This consistency should also exist in the duplicate RRs that mark delegation in the delegator and delegatee. For example, if you ask the NIC to delegate UZOO.EDU to you, your database shouldn't say uzoo.edu.
ドメインシステムはケースを保存するべきですが、大文字と小文字を区別しなくいてください。 しかしながら、少しも、ドメイン名xxxのためのRRsとXXXの両方をデータベースに置くためにだれも良くしません--それは、単にキャッシュをあいまいにして、圧縮の効率を減少させます。 また、この一貫性は「反-遺贈者」と「反-遺産受取人」で委譲をマークする写しRRsで存在するべきです。 例えば、あなたがあなたへの代表UZOO.EDUにNICを招くなら、あなたのデータベースはuzoo.eduを言うべきではありません。
Inappropriate use of aliases
別名の誤用
Canonical names are preferred to aliases in all RRs. One reason is that the canonical names are closer to the information associated with a name. A second is that canonical names are unique, and aliases are not, and hence comparisons will work.
正準な名前はすべてのRRsの別名より好まれます。 1つの理由は正準な名前が名前に関連している情報の、より近くにあるということです。 1秒は正準な名前がユニークであり、別名がユニークでないということです、そして、したがって、比較は働くでしょう。
In particular, the use of aliases in PTR RRs of the IN-ADDR domain or in NS RRs that mark delegation is discouraged.
IN-ADDRドメインのPTR RRsか委譲をマークするNS RRsにおける別名の使用は特に、お勧めできないです。
EXPERIENCES
経験
This section discusses some unusual situations and common bugs which are encountered in the present system, and should be helpful in problem determination and tuning. Put differently, you should try to make your code defend against these attacks, and you should expect to be the object of complaint if you make these attacks.
このセクションは、現行制度で遭遇するいくつかの異例の状況と一般的なバグについて議論して、問題決断とチューニングに役立っているべきです。 異なって置かれて、あなたはこれらの攻撃に対してコードを防御させようとするべきです、そして、これらの攻撃をするなら、苦情の対象であると予想するべきです。
UDP addresses
UDPアドレス
When you send a query to a host with multiple addresses, you might expect the response to be from the address to which you sent the query. This isn't the case with almost all UNIX implementations.
複数のアドレスをもっているホストに質問を送るとき、あなたは、応答があなたが質問を送ったアドレスから来ていると予想するかもしれません。 これはほとんどすべてのUNIX実装があるそうではありません。
Mockapetris [Page 8]
Mockapetris[8ページ]
RFC 973 January 1986 Domain System Changes and Observations
RFC973 1986年1月ドメインシステム変更と観測
UDP checksums
UDPチェックサム
Many versions of UNIX generate incorrect UDP checksums, and most ignore the checksum of incoming UDP datagrams. The typical symptom is that your UNIX domain code works fine with other UNIXes, but won't communicate with TOPS-20 or other systems. (JEEVES, the TOPS-20 server used for 3 of the 4 root servers, ignores datagrams with bad UDP checksums.)
UNIXの多くのバージョンが不正確なUDPチェックサムを生成します、そして、大部分は入って来るUDPデータグラムのチェックサムを無視します。典型的な兆候はあなたのUNIXドメインコードが他のUNIXesと共にきめ細かに働いていますが、TOPS-20か他のシステムとコミュニケートしないということです。(JEEVES(4つのルートサーバーのうち3に使用されるTOPS-20サーバ)は悪いUDPチェックサムがあるデータグラムを無視します。)
Making up data
データを作ります。
There are lots of name servers which return RRs for the root servers with 99999999 or similar large values in the TTL. For example, some return RRs that suggest that ISIF is a root server. (It was months ago, but is no longer.)
99999999があるルートサーバーのためにRRsを返す多くのネームサーバか同様の大きい値がTTLにあります。 例えば、或るものはISIFがルートサーバーであると示唆するRRsを返します。(何カ月も前のであるもうです。)
One of the main ideas of the domain system is that everybody can get a chunk of the name space to manage as they choose. However, you aren't supposed to lie about other parts of the name space. Its OK to remember about other parts of the name space for caching or other purposes, but you are supposed to follow the TTL rules.
ドメインシステムの本旨の1つはみんなが選ぶようにスペースという名前の塊を管理させることができるということです。 しかしながら、あなたはスペースという名前の他の部分に関して嘘をつくべきではありません。 他の部品に関して覚えていられるOKはキャッシュのための名前スペースかしかし、他の目的、あなたがTTL規則に従うべきです。
Now it may be that you put such records in your server or whatever to ensure a server of last resort. That's fine. But if you export these in answers to queries, you should be shot. These entries get put in caches and never die.
現在多分、あなたは、切り札のサーバを確実にするためにあなたのサーバか何でもにそのような記録を入れます。 それはすばらしいです。 しかし、質問の答えでこれらをエクスポートするなら、あなたは撃たれるべきです。 これらのエントリーは、キャッシュに入れられて、決して死にません。
Suggested domain meta-rule:
提案されたドメインメタ規則:
If you must lie, lie only to yourself.
横たわらなければならないなら、自分だけに嘘をついてください。
PROBLEM AREAS
問題領域
This section discusses some shortcomings in the present system which may be addressed in future versions.
このセクションは将来のバージョンで扱われるかもしれない現行制度のいくつかの短所について論じます。
Compression and types
圧縮とタイプ
The present specification attempts to allow name servers and resolvers to cache RRs for classes they don't "understand" as well as to allow compression of domain names to minimize the size of UDP datagrams. These two goals conflict in the present scheme since the only way to expand a compressed name is to know that a name is expected in that position.
現在の仕様は、ネームサーバとレゾルバが、それらが「理解していない」クラスのためにRRsをキャッシュして、ドメイン名の要約がUDPデータグラムのサイズを最小にするのを許すのを許容するのを試みます。圧縮された名前を広げる唯一の方法が名前がその位置で予想されるのを知ることであるので、これらの2つの目標が現在の体系で闘争します。
One technique for addressing this problem would be to preface binary data (i.e. anything but a domain name) with a length octet.
このその問題を訴えるための1つのテクニックは長さの八重奏でバイナリ・データ(すなわち、ドメイン名以外の何でも)について前書きするだろうことです。
Mockapetris [Page 9]
Mockapetris[9ページ]
RFC 973 January 1986 Domain System Changes and Observations
RFC973 1986年1月ドメインシステム変更と観測
The high order two bits of the length octet could contain either 01 or 10, which are illegal for domain names. To compensate for the additional bytes of data, we could omit the RDATA length field and terminate each RR with a binary length field of zero.
長さの八重奏の高位2ビットは01か10を含むかもしれません。(ドメイン名に、10は不法です)。 私たちは、追加バイトのデータを補うために、RDATA長さの分野を省略して、ゼロの2進の長さの分野がある各RRを終えることができました。
Caching non-existent names
実在しない名前をキャッシュします。
In the present system, a resolver has no standard method for caching the result that a name does not exist, which seems to make up a larger than expected percentage of queries. Some resolvers create "does not exist" RRs with TTLs to guarantee against repetitive queries for a non-existent name.
現行制度では、レゾルバは名前(予想より大きい百分率の質問を作るように思える)が存在していないという結果をキャッシュするための標準方法を全く持っていません。 レゾルバが作成する或るものが「存在していない」という実在しない名前のための反復性の質問に対する保証へのTTLsとRRs。
A standard technique might be to return the SOA RR for the zone (note that only authoritative servers can say name does not exist) in the reply, and define the semantics to be that the requester is free to assume that the name does not exist for a period equal to the MINIMUM field of the SOA.
標準のテクニックは、回答でSOA RRをゾーンに返して(正式のサーバだけが、名前が存在しないと言うことができることに注意します)、リクエスタが、名前がしばらくSOAのMINIMUM分野と等しい状態で存在しないと自由に仮定できるということになるように意味論を定義することであるかもしれません。
Cache conflicts
キャッシュ闘争
When a resolver is processing a reply, it may well decide to cache all RRs found in sections of the reply. The problem is that the resolver's cache may already contain a subset of these RRs, probably with different TTLs.
レゾルバが回答を処理しているとき、それは、回答のセクションで見つけられたすべてのRRsをキャッシュするとたぶん決めるでしょう。 問題はリゾルバのキャッシュが既にこれらのRRsと、たぶん異なったTTLsとの部分集合を含むかもしれないということです。
If the RRs are from authoritative data in the answer section, then the cache RRs should be replaced. In other cases, the correct strategy isn't completely clear. Note that if the authoritative data's TTL has changed, then the resolver doesn't have enough information to make the correct decision in all cases.
RRsが答え部の信頼すべきデータから来ているなら、キャッシュRRsを取り替えるべきです。 他の場合では、正しい戦略は完全に明確であるというわけではありません。 信頼すべきデータのTTLが変化したならレゾルバにはすべての場合における正しい決定をすることができるくらいの情報がないことに注意してください。
This issue is tricky, and deserves thought.
この問題は、扱いにくく、考えに値します。
REFERENCES
参照
[1] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC-882, USC Information Sciences Institute, November 1983.
[1]Mockapetris、P.、「ドメイン名--、概念と施設、」、RFC-882、科学が設けるUSC情報、11月1983
[2] Mockapetris, P., "Domain Names - Implementation and Specification", RFC-883, USC Information Sciences Institute, November 1983.
[2]Mockapetris、P.、「ドメイン名--、実装と仕様、」、RFC-883、科学が設けるUSC情報、11月1983
[3] Partridge, C., "Mail Routing and the Domain System", RFC-974, CSNET-CIC, BBN Laboratories, January 1986.
[3] ヤマウズラと、C.と、「メールルート設定とドメインシステム」、RFC-974、CSNET-CIC、BBN研究所、1月1986
Mockapetris [Page 10]
Mockapetris[10ページ]
一覧
スポンサーリンク