RFC2181 日本語訳

Network Working Group                                             R. Elz
Request for Comments: 2181                       University of Melbourne
Updates: 1034, 1035, 1123                                        R. Bush
Category: Standards Track                                    RGnet, Inc.
                                                               July 1997

Elzがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2181のメルボルン大学アップデート: 1034、1035、1123R.ブッシュカテゴリ: 標準化過程RGnet Inc.1997年7月

                Clarifications to the DNS Specification

DNS仕様への明確化

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

1. Abstract

1. 要約

   This document considers some areas that have been identified as
   problems with the specification of the Domain Name System, and
   proposes remedies for the defects identified.  Eight separate issues
   are considered:

このドキュメントは、特定されたいくつかの領域がドメインネームシステムの仕様に関する問題であるとみなして、特定された欠陥のための療法を提案します。 8つの別個問題が考えられます:

     + IP packet header address usage from multi-homed servers,
     + TTLs in sets of records with the same name, class, and type,
     + correct handling of zone cuts,
     + three minor issues concerning SOA records and their use,
     + the precise definition of the Time to Live (TTL)
     + Use of the TC (truncated) header bit
     + the issue of what is an authoritative, or canonical, name,
     + and the issue of what makes a valid DNS label.

+ IPパケットのヘッダーが用法を扱う、マルチ、家へ帰り、サーバ、+ + 同じ名前、クラス、およびタイプがある記録のセットにおけるTTLs、ゾーンカットの正しい取り扱い、+ 3未成年者は+ TC(先端を切られる)ヘッダービットのLive(TTL)+使用へのTimeのSOAに関する記録と彼らの使用、厳密な定義に+ 有効なDNSラベルを作ることに関する正式の、または、正準な名前であることに関する問題、+、および問題を発行します。

   The first six of these are areas where the correct behaviour has been
   somewhat unclear, we seek to rectify that.  The other two are already
   adequately specified, however the specifications seem to be sometimes
   ignored.  We seek to reinforce the existing specifications.

これら最初の6つは正しいふるまいがいくらか不明瞭である、私たちがそれを正そうとする領域です。 他の2は既に適切に指定されて、しかしながら、仕様は時々無視されるように思えます。 私たちは既存の仕様を補強しようとします。

Elz & Bush                  Standards Track                     [Page 1]

RFC 2181        Clarifications to the DNS Specification        July 1997

ElzとブッシュStandardsは仕様1997年7月にRFC2181明確化をDNSに追跡します[1ページ]。

Contents

コンテンツ

    1  Abstract  ...................................................   1
    2  Introduction  ...............................................   2
    3  Terminology  ................................................   3
    4  Server Reply Source Address Selection  ......................   3
    5  Resource Record Sets  .......................................   4
    6  Zone Cuts  ..................................................   8
    7  SOA RRs  ....................................................  10
    8  Time to Live (TTL)  .........................................  10
    9  The TC (truncated) header bit  ..............................  11
   10  Naming issues  ..............................................  11
   11  Name syntax  ................................................  13
   12  Security Considerations  ....................................  14
   13  References  .................................................  14
   14  Acknowledgements  ...........................................  15
   15  Authors' Addresses  .........................................  15

1つの要約… 1 2序論… 2 3用語… 3 4サーバ回答ソースアドレス選択… 3 5リソース記録はセットします… 4 6ゾーンは切れます… 8 7SOA RRs… 10 生きる8時間(TTL)… 10 9 TC(先端を切られる)ヘッダーは噛み付きました… 11 10命名冊… 11 11は構文を命名します… 13 12のセキュリティ問題… 14 13の参照箇所… 14 14の承認… 15 15人の作者のアドレス… 15

2. Introduction

2. 序論

   Several problem areas in the Domain Name System specification
   [RFC1034, RFC1035] have been noted through the years [RFC1123].  This
   document addresses several additional problem areas.  The issues here
   are independent.  Those issues are the question of which source
   address a multi-homed DNS server should use when replying to a query,
   the issue of differing TTLs for DNS records with the same label,
   class and type, and the issue of canonical names, what they are, how
   CNAME records relate, what names are legal in what parts of the DNS,
   and what is the valid syntax of a DNS name.

ドメインネームシステム仕様[RFC1034、RFC1035]によるいくつかの問題領域が何年間[RFC1123]もにわたって注意されています。 このドキュメントはいくつかの追加問題領域を扱います。 ここの問題は独立しています。 それらの問題がどのソースがaを扱うかに関する質問である、マルチ、家へ帰り、疑問に答えるときサーバが使用するべきであるDNS、DNSのための異なったTTLsの問題は同じラベル、クラスと、タイプと、それらが正準な名前の問題、ものであることでCNAME記録がどのように関係するか、そして、どんな名前がDNSのどんな部分で法的であるか、そして、何がDNS名の有効な構文であるかを記録します。

   Clarifications to the DNS specification to avoid these problems are
   made in this memo.  A minor ambiguity in RFC1034 concerned with SOA
   records is also corrected, as is one in the definition of the TTL
   (Time To Live) and some possible confusion in use of the TC bit.

このメモでこれらの問題を避けるDNS仕様への明確化をします。 また、SOA記録に関するRFC1034の小さい方のあいまいさは1のようにTTL(時間To Live)の定義とTCビットで使用中の何らかの可能な混乱で修正されます。

Elz & Bush                  Standards Track                     [Page 2]

RFC 2181        Clarifications to the DNS Specification        July 1997

ElzとブッシュStandardsは仕様1997年7月にRFC2181明確化をDNSに追跡します[2ページ]。

3. Terminology

3. 用語

   This memo does not use the oft used expressions MUST, SHOULD, MAY, or
   their negative forms.  In some sections it may seem that a
   specification is worded mildly, and hence some may infer that the
   specification is optional.  That is not correct.  Anywhere that this
   memo suggests that some action should be carried out, or must be
   carried out, or that some behaviour is acceptable, or not, that is to
   be considered as a fundamental aspect of this specification,
   regardless of the specific words used.  If some behaviour or action
   is truly optional, that will be clearly specified by the text.

しばしば、中古の式はそうしなければなりません、SHOULD、5月、または、それらのネガが形成されます。このメモが使用しない、数人のセクションでは、仕様が穏やかに言い表されて、したがって、或るものが、仕様が任意であると推論するかもしれないように思えるかもしれません。 それは正しくはありません。 どこでも、このメモが、何らかの動作を行われなければならないべきであるか、または行わなければならない、さもなければ、それが何らかのふるまいを行うのを示すのが、許容できるそれはこの仕様の基本的な面であるとみなされることになっています、使用される特定の単語にかかわらず。 何らかのふるまいか動作が本当に任意であるなら、それはテキストによって明確に指定されるでしょう。

4. Server Reply Source Address Selection

4. サーバ回答ソースアドレス選択

   Most, if not all, DNS clients, expect the address from which a reply
   is received to be the same address as that to which the query
   eliciting the reply was sent.  This is true for servers acting as
   clients for the purposes of recursive query resolution, as well as
   simple resolver clients.  The address, along with the identifier (ID)
   in the reply is used for disambiguating replies, and filtering
   spurious responses.  This may, or may not, have been intended when
   the DNS was designed, but is now a fact of life.

そうでなければ、すべて(DNSクライアント)が回答が回答を引き出す質問が送られたそれと同じアドレスになるように受け取られるアドレスを最も予想します。 反復クエリー解決の目的のためのクライアントとして機能するサーバに、これは本当です、純真なレゾルバクライアントと同様に。 アドレスであり、識別子と共に、回答における(ID)は、回答のあいまいさを除いて、スプリアス・レスポンスをフィルターにかけるのに使用されます。 これは意図するかもしれませんが、DNSが設計されたときには意図してくださいが、現在の現実は意図しましたか?

   Some multi-homed hosts running DNS servers generate a reply using a
   source address that is not the same as the destination address from
   the client's request packet.  Such replies will be discarded by the
   client because the source address of the reply does not match that of
   a host to which the client sent the original request.  That is, it
   appears to be an unsolicited response.

いくつか、マルチ、家へ帰り、DNSサーバを実行するホストが、クライアントのリクエスト・パケットからの送付先アドレスと同じでないソースアドレスを使用することで回答を生成します。 回答のソースアドレスがクライアントがオリジナルの要求を送ったホストのものに合っていないので、そのような回答はクライアントによって捨てられるでしょう。 すなわち、それは求められていない応答であるように見えます。

4.1. UDP Source Address Selection

4.1. UDPソースアドレス選択

   To avoid these problems, servers when responding to queries using UDP
   must cause the reply to be sent with the source address field in the
   IP header set to the address that was in the destination address
   field of the IP header of the packet containing the query causing the
   response.  If this would cause the response to be sent from an IP
   address that is not permitted for this purpose, then the response may
   be sent from any legal IP address allocated to the server.  That
   address should be chosen to maximise the possibility that the client
   will be able to use it for further queries.  Servers configured in
   such a way that not all their addresses are equally reachable from
   all potential clients need take particular care when responding to
   queries sent to anycast, multicast, or similar, addresses.

UDPを使用することで質問に応じるとき、これらの問題を避けるために、サーバで、ソースアドレス・フィールドがIPヘッダーセットにある状態で、質問を含んでいて、応答を引き起こしながらパケットのIPヘッダーの目的地アドレス・フィールドにあったアドレスに回答を送らなければなりません。 このために受入れられません、次に、サーバに割り当てられたどんな法的なIPアドレスからも応答を送るかもしれません。クライアントがさらなる質問にそれを使用できる可能性を最大にするためにこれでそのアドレスを選ぶべきであるということであるIPアドレスから応答を送るなら。 anycast(マルチキャストの、または、同様のアドレス)に送られた質問に応じるとき、それらのすべてのアドレスがどんな可能なクライアントが必要とするすべてから等しく届くというわけではないような方法で構成されたサーバは特定の注意を払います。

Elz & Bush                  Standards Track                     [Page 3]

RFC 2181        Clarifications to the DNS Specification        July 1997

ElzとブッシュStandardsは仕様1997年7月にRFC2181明確化をDNSに追跡します[3ページ]。

4.2. Port Number Selection

4.2. ポートナンバー選択

   Replies to all queries must be directed to the port from which they
   were sent.  When queries are received via TCP this is an inherent
   part of the transport protocol.  For queries received by UDP the
   server must take note of the source port and use that as the
   destination port in the response.  Replies should always be sent from
   the port to which they were directed.  Except in extraordinary
   circumstances, this will be the well known port assigned for DNS
   queries [RFC1700].

それらが送られたポートにすべての質問に関する回答を向けなければなりません。 TCPを通して質問を受けるとき、これはトランスポート・プロトコルの固有の部分です。 UDPによって受けられた質問のために、サーバは、ソースポートに注目して、仕向港として応答にそれを使用しなければなりません。 それらが向けられたポートから回答をいつも送るべきです。 特別事情以外の、これはDNS質問[RFC1700]のために割り当てられたよく知られているポートになるでしょう。

5. Resource Record Sets

5. リソースレコードセット

   Each DNS Resource Record (RR) has a label, class, type, and data.  It
   is meaningless for two records to ever have label, class, type and
   data all equal - servers should suppress such duplicates if
   encountered.  It is however possible for most record types to exist
   with the same label, class and type, but with different data.  Such a
   group of records is hereby defined to be a Resource Record Set
   (RRSet).

各DNS Resource Record(RR)には、ラベル、クラス、タイプ、およびデータがあります。 2つの記録でラベル、クラス、タイプ、およびデータがすべて等しくなるのは、無意味です--遭遇するなら、サーバはそのような写しを抑圧するべきです。 ほとんどのレコード種類が同じラベル、クラス、およびタイプにもかかわらず、異なったデータで存在するのにおいてどんなに可能であってもそれはそうです。 記録のそのようなグループは、Resource Record Set(RRSet)になるようにこれにより定義されます。

5.1. Sending RRs from an RRSet

5.1. RRSetからRRsを送ります。

   A query for a specific (or non-specific) label, class, and type, will
   always return all records in the associated RRSet - whether that be
   one or more RRs.  The response must be marked as "truncated" if the
   entire RRSet will not fit in the response.

特定の、そして、(特定されない)のラベル、クラス、およびタイプのための質問はそれが1RRsであるか否かに関係なく、いつも関連RRSetでのすべての記録を返すでしょう。 全体のRRSetが応答をうまくはめ込まないなら「先端を切られる」ように応答をマークしなければなりません。

5.2. TTLs of RRs in an RRSet

5.2. RRSetのRRsのTTLs

   Resource Records also have a time to live (TTL).  It is possible for
   the RRs in an RRSet to have different TTLs.  No uses for this have
   been found that cannot be better accomplished in other ways.  This
   can, however, cause partial replies (not marked "truncated") from a
   caching server, where the TTLs for some but not all the RRs in the
   RRSet have expired.

また、リソースRecordsには、生きる時間(TTL)があります。 RRSetのRRsには異なったTTLsがあるのは、可能です。 これへの他の方法で実行しないことができないほうがよい用途は全く見つけられました。 しかしながら、これはキャッシュサーバから部分的な回答(「端が欠けていること」はマークされない)を引き起こす場合があります、RRSetのすべてのRRsではなく、いくつかのためのTTLsが期限が切れたところで。

   Consequently the use of differing TTLs in an RRSet is hereby
   deprecated, the TTLs of all RRs in an RRSet must be the same.

その結果、RRSetにおける異なったTTLsの使用がこれにより推奨しない、RRSetのすべてのRRsのTTLsは同じであるに違いありません。

   Should a client receive a response containing RRs from an RRSet with
   differing TTLs, it should treat this as an error.  If the RRSet
   concerned is from a non-authoritative source for this data, the
   client should simply ignore the RRSet, and if the values were
   required, seek to acquire them from an authoritative source.  Clients
   that are configured to send all queries to one, or more, particular
   servers should treat those servers as authoritative for this purpose.
   Should an authoritative source send such a malformed RRSet, the

クライアントが異なったTTLsとRRSetからRRsを含む応答を受けるなら、それは誤りとしてこれを扱うべきです。 関するRRSetがこのデータのための非権威筋から来ているなら、クライアントは単にRRSetを無視するべきです、そして、値が必要であったなら、権威筋からそれらを取得するようにしてください。 すべての質問を1つ以上に送るために構成されるクライアント、特定のサーバは正式であるとしてこのためにそれらのサーバを扱うべきです。 権威筋はそのような奇形のRRSetを送るはずです。

Elz & Bush                  Standards Track                     [Page 4]

RFC 2181        Clarifications to the DNS Specification        July 1997

ElzとブッシュStandardsは仕様1997年7月にRFC2181明確化をDNSに追跡します[4ページ]。

   client should treat the RRs for all purposes as if all TTLs in the
   RRSet had been set to the value of the lowest TTL in the RRSet.  In
   no case may a server send an RRSet with TTLs not all equal.

まるでRRSetのすべてのTTLsがRRSetの最も低いTTLの値に用意ができていたかのようにクライアントはすべての目的のためにRRsを扱うべきです。 すべての同輩はサーバでTTLsとRRSetに決して、行かないというわけではなくしますように。

5.3. DNSSEC Special Cases

5.3. DNSSECの特別なケース

   Two of the record types added by DNS Security (DNSSEC) [RFC2065]
   require special attention when considering the formation of Resource
   Record Sets.  Those are the SIG and NXT records.  It should be noted
   that DNS Security is still very new, and there is, as yet, little
   experience with it.  Readers should be prepared for the information
   related to DNSSEC contained in this document to become outdated as
   the DNS Security specification matures.

Resource Record Setsの構成を考えるとき、DNS Security(DNSSEC)[RFC2065]によって加えられた2つのレコード種類が特別な注意を必要とします。 それらは、SIGとNXT記録です。 DNS Securityがまだ非常に新しく、それには経験がまだほとんどないことに注意されるべきです。 読者は本書では含まれたDNSSECに関連する情報のためにDNS Security仕様が熟すのに応じて時代遅れになる用意ができているべきです。

5.3.1. SIG records and RRSets

5.3.1. SIG記録とRRSets

   A SIG record provides signature (validation) data for another RRSet
   in the DNS.  Where a zone has been signed, every RRSet in the zone
   will have had a SIG record associated with it.  The data type of the
   RRSet is included in the data of the SIG RR, to indicate with which
   particular RRSet this SIG record is associated.  Were the rules above
   applied, whenever a SIG record was included with a response to
   validate that response, the SIG records for all other RRSets
   associated with the appropriate node would also need to be included.
   In some cases, this could be a very large number of records, not
   helped by their being rather large RRs.

SIG記録はDNSの別のRRSetのための署名(合法化)データを提供します。 ゾーンが署名されたところでは、ゾーンのあらゆるRRSetがそれに関連しているSIG記録を持っていてしまうでしょう。 RRSetに関するデータ型は、このSIG記録がどの特定のRRSetに関連しているかを示すためにSIG RRに関するデータに含まれています。 また、SIG記録が応答で含まれて、その応答を有効にしたときはいつも、上の規則が適用されるなら、適切なノードに関連している他のすべてのRRSetsのためのSIG記録は、含まれる必要があるでしょうに。 いくつかの場合、それらがかなり大きいRRsであることによって助けられるのではなく、これは非常に多くの記録であるかもしれません。

   Thus, it is specifically permitted for the authority section to
   contain only those SIG RRs with the "type covered" field equal to the
   type field of an answer being returned.  However, where SIG records
   are being returned in the answer section, in response to a query for
   SIG records, or a query for all records associated with a name
   (type=ANY) the entire SIG RRSet must be included, as for any other RR
   type.

したがって、それは権威部が返される答えのタイプ分野と等しい「カバーされたタイプ」分野があるそれらのSIG RRsだけを含むことが明確に許可されています。 しかしながら、答え部でSIG記録を返しているところでは、SIG記録のための質問、または名前に関連づけられたすべての記録のための質問(= 何でもタイプする)に対応して、全体のSIG RRSetを含まなければなりません、いかなる他のRRタイプのようにも。

   Servers that receive responses containing SIG records in the
   authority section, or (probably incorrectly) as additional data, must
   understand that the entire RRSet has almost certainly not been
   included.  Thus, they must not cache that SIG record in a way that
   would permit it to be returned should a query for SIG records be
   received at that server.  RFC2065 actually requires that SIG queries
   be directed only to authoritative servers to avoid the problems that
   could be caused here, and while servers exist that do not understand
   the special properties of SIG records, this will remain necessary.
   However, careful design of SIG record processing in new
   implementations should permit this restriction to be relaxed in the
   future, so resolvers do not need to treat SIG record queries
   specially.

または、権威部にSIG記録を保管している応答を受けるサーバ、(たぶん、不当に)、追加データ、必須が、全体のRRSetがほぼ確実に含まれていないのを理解しているとき。 したがって、彼らはそのサーバでSIG記録のための質問を受けるならそれが返されることを許可する方法でそのSIG記録をキャッシュしてはいけません。RFC2065は、実際にSIG質問がここで引き起こされる場合があった問題を避けるよう正式のサーバだけに指示されるのを必要とします、そして、SIG記録の特別な性質を理解していないサーバが存在している間、これは必要なままで残るでしょう。 しかしながら、新しい実装におけるSIG記録処理の慎重なデザインが、この規制が将来緩和されることを許可するべきであるので、特に、レゾルバはSIG記録質問を扱う必要はありません。

Elz & Bush                  Standards Track                     [Page 5]

RFC 2181        Clarifications to the DNS Specification        July 1997

ElzとブッシュStandardsは仕様1997年7月にRFC2181明確化をDNSに追跡します[5ページ]。

   It has been occasionally stated that a received request for a SIG
   record should be forwarded to an authoritative server, rather than
   being answered from data in the cache.  This is not necessary - a
   server that has the knowledge of SIG as a special case for processing
   this way would be better to correctly cache SIG records, taking into
   account their characteristics.  Then the server can determine when it
   is safe to reply from the cache, and when the answer is not available
   and the query must be forwarded.

時折SIG記録に関する受信された要求がキャッシュにおけるデータから答えられるよりむしろ正式のサーバに転送されるべきであると述べられています。 これは必要ではありません--SIGに関する知識が処理のために特殊なものとしてこのようにあるサーバは正しくSIG記録をキャッシュするために、より良いでしょう、それらの特性を考慮に入れて。 次に、サーバはキャッシュから返答するのがいつ安全であるか、そして、答えがいつ利用可能でないかを決定できます、そして、質問を進めなければなりません。

5.3.2. NXT RRs

5.3.2. NXT RRs

   Next Resource Records (NXT) are even more peculiar.  There will only
   ever be one NXT record in a zone for a particular label, so
   superficially, the RRSet problem is trivial.  However, at a zone cut,
   both the parent zone, and the child zone (superzone and subzone in
   RFC2065 terminology) will have NXT records for the same name.  Those
   two NXT records do not form an RRSet, even where both zones are
   housed at the same server.  NXT RRSets always contain just a single
   RR.  Where both NXT records are visible, two RRSets exist.  However,
   servers are not required to treat this as a special case when
   receiving NXT records in a response.  They may elect to notice the
   existence of two different NXT RRSets, and treat that as they would
   two different RRSets of any other type.  That is, cache one, and
   ignore the other.  Security aware servers will need to correctly
   process the NXT record in the received response though.

次のResource Records(NXT)はさらに奇妙です。 1つのNXT記録しか特定のラベルのためのゾーンにないので、表面的に、RRSet問題は些細です。 しかしながら、ゾーンカットのときに、親ゾーンと子供ゾーンの両方(RFC2065用語の「スーパー-ゾーン」と「副-ゾーン」)には、同じ名前のためのNXT記録があるでしょう。 それらの2つのNXT記録はRRSetを形成しません、両方のゾーンが同じサーバで収容さえされるところで。NXT RRSetsはいつもまさしく独身のRRを含んでいます。 両方のNXT記録が目に見えるところでは、2RRSetsが存在しています。 しかしながら、サーバは、応答におけるNXT記録を受け取るとき、特殊なものとしてこれを扱うのに必要ではありません。 彼らは、いかなる他のタイプの2異なったRRSetsも選ぶように2異なったNXT RRSetsの存在に気付いて、それを扱うのを選ぶかもしれません。 すなわち、1つをキャッシュしてください、そして、もう片方を無視してください。 セキュリティの意識しているサーバは、もっとも、正しく容認された応答におけるNXT記録を処理する必要があるでしょう。

5.4. Receiving RRSets

5.4. RRSetsを受けます。

   Servers must never merge RRs from a response with RRs in their cache
   to form an RRSet.  If a response contains data that would form an
   RRSet with data in a server's cache the server must either ignore the
   RRs in the response, or discard the entire RRSet currently in the
   cache, as appropriate.  Consequently the issue of TTLs varying
   between the cache and a response does not cause concern, one will be
   ignored.  That is, one of the data sets is always incorrect if the
   data from an answer differs from the data in the cache.  The
   challenge for the server is to determine which of the data sets is
   correct, if one is, and retain that, while ignoring the other.  Note
   that if a server receives an answer containing an RRSet that is
   identical to that in its cache, with the possible exception of the
   TTL value, it may, optionally, update the TTL in its cache with the
   TTL of the received answer.  It should do this if the received answer
   would be considered more authoritative (as discussed in the next
   section) than the previously cached answer.

サーバは、RRSetを形成するために彼らのキャッシュでRRsを応答からRRsに決して合併してはいけません。 応答がサーバのキャッシュにおけるデータでRRSetを形成するデータを含んでいるなら、サーバは、応答でRRsを無視しなければならないか、または現在キャッシュで全体のRRSetを捨てなければなりません、適宜。 その結果、キャッシュと応答の間で異なるTTLsの問題は心配をかけないで、1つは無視されるでしょう。 答えからのデータがキャッシュにおけるデータと異なっているなら、すなわち、データセットの1つはいつも不正確です。 サーバがデータセットについてどれを決定するかことであるので、挑戦はもう片方を無視している間、それを1つがそうなら修正して、保有することです。 サーバがキャッシュがそれと同じRRSetを含む答えを受けるなら、TTL価値の可能な例外で、容認された答えのTTLと共にキャッシュでTTLを任意にアップデートするかもしれないことに注意してください。 容認された答えが以前にキャッシュされた答えより正式であると(次のセクションで議論するように)考えられるなら、それはこれをするべきです。

Elz & Bush                  Standards Track                     [Page 6]

RFC 2181        Clarifications to the DNS Specification        July 1997

ElzとブッシュStandardsは仕様1997年7月にRFC2181明確化をDNSに追跡します[6ページ]。

5.4.1. Ranking data

5.4.1. データを格付けします。

   When considering whether to accept an RRSet in a reply, or retain an
   RRSet already in its cache instead, a server should consider the
   relative likely trustworthiness of the various data.  An
   authoritative answer from a reply should replace cached data that had
   been obtained from additional information in an earlier reply.
   However additional information from a reply will be ignored if the
   cache contains data from an authoritative answer or a zone file.

回答でRRSetを受け入れるか、または代わりに既にキャッシュでRRSetを保有するかを考えるとき、サーバは様々なデータの相対的なありそうな信頼できることを考えるべきです。 回答からの正式の答えは以前の回答における追加情報から得られたキャッシュされたデータに取って代わるべきです。 しかしながら、キャッシュが正式の答えかゾーンファイルからのデータを含んでいると、回答からの追加情報は無視されるでしょう。

   The accuracy of data available is assumed from its source.
   Trustworthiness shall be, in order from most to least:

データの利用可能な精度はソースから想定されます。 信頼できることが大部分から最少までのオーダーにあるものとします:

     + Data from a primary zone file, other than glue data,
     + Data from a zone transfer, other than glue,
     + The authoritative data included in the answer section of an
       authoritative reply.
     + Data from the authority section of an authoritative answer,
     + Glue from a primary zone, or glue from a zone transfer,
     + Data from the answer section of a non-authoritative answer, and
       non-authoritative data from the answer section of authoritative
       answers,
     + Additional information from an authoritative answer,
       Data from the authority section of a non-authoritative answer,
       Additional information from non-authoritative answers.

+ プライマリゾーンからのデータはゾーン転送から+ 接着剤データ以外のデータをファイルします、接着剤を除いて、正式の回答の答え部に+ 信頼すべきデータを含んでいて。 + 正式の答えの権威部からのデータ、+ プライマリゾーン、またはゾーン転送からの接着剤からの接着剤、+ 非正式の答えの答え部からのデータ、および正式の答えの答え部からの非正式のデータ、+ 正式の答えからの追加情報、非正式の答えの権威部からのData、非正式であるのからのAdditional情報に答えます。

   Note that the answer section of an authoritative answer normally
   contains only authoritative data.  However when the name sought is an
   alias (see section 10.1.1) only the record describing that alias is
   necessarily authoritative.  Clients should assume that other records
   may have come from the server's cache.  Where authoritative answers
   are required, the client should query again, using the canonical name
   associated with the alias.

通常、正式の答えの答え部が信頼すべきデータだけを含むことに注意してください。 しかしながら、探すという名前が別名(セクション10.1.1を見る)であるときに、その別名について説明する記録だけが必ず正式です。 クライアントは、他の記録がサーバのキャッシュから来たかもしれないと仮定するべきです。 別名に関連している正準な名前を使用して、クライアントは、再び正式の答えがどこで必要であるかを質問するべきです。

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.

容認された質問に対応するようなそれらがかつて返される方法ですなわち、それらの組分け、追加資料課からの最も信頼できないデータから受け取られて、キャッシュされたUnauthenticated RRs、および非正式の答えの権威部からのデータをキャッシュするべきではありません。 追加情報として適切であるところにそれらを返すかもしれません。 これを無視するのは、比較的信頼できないデータの信頼できることが原因も口実なしで増強されるのを許容するでしょう。

   When DNS security [RFC2065] is in use, and an authenticated reply has
   been received and verified, the data thus authenticated shall be
   considered more trustworthy than unauthenticated data of the same
   type.  Note that throughout this document, "authoritative" means a
   reply with the AA bit set.  DNSSEC uses trusted chains of SIG and KEY

DNSセキュリティ[RFC2065]が使用中であり、認証された回答が受け取られて、確かめられたとき、このようにして認証されたデータは同じタイプに関するデータを非認証したより信頼できると考えられるものとします。 このドキュメント、「正式」の手段中でAAビットによる回答がセットしたことに注意してください。 DNSSECはSIGとKEYの信じられたチェーンを使用します。

Elz & Bush                  Standards Track                     [Page 7]

RFC 2181        Clarifications to the DNS Specification        July 1997

ElzとブッシュStandardsは仕様1997年7月にRFC2181明確化をDNSに追跡します[7ページ]。

   records to determine the authenticity of data, the AA bit is almost
   irrelevant.  However DNSSEC aware servers must still correctly set
   the AA bit in responses to enable correct operation with servers that
   are not security aware (almost all currently).

データの信憑性を決定する記録であり、AAビットはほとんど無関係です。 しかしながら、DNSSECの意識しているサーバが、応答におけるAAビットにセキュリティでないサーバで正しい操作を可能にするようにまだ正しく意識していた状態で設定しなければならない、(ほとんどすべて、現在)

   Note that, glue excluded, it is impossible for data from two
   correctly configured primary zone files, two correctly configured
   secondary zones (data from zone transfers) or data from correctly
   configured primary and secondary zones to ever conflict.  Where glue
   for the same name exists in multiple zones, and differs in value, the
   nameserver should select data from a primary zone file in preference
   to secondary, but otherwise may choose any single set of such data.
   Choosing that which appears to come from a source nearer the
   authoritative data source may make sense where that can be
   determined.  Choosing primary data over secondary allows the source
   of incorrect glue data to be discovered more readily, when a problem
   with such data exists.  Where a server can detect from two zone files
   that one or more are incorrectly configured, so as to create
   conflicts, it should refuse to load the zones determined to be
   erroneous, and issue suitable diagnostics.

除かれた接着剤、正しく構成されたプライマリの、そして、セカンダリのゾーンからの2個の正しく構成されたプライマリゾーンファイル、2つの正しく構成されたセカンダリゾーン(ゾーン転送からのデータ)またはデータからのデータが闘争するのが、不可能であることに注意してください。 同じ名前のための接着剤が複数のゾーンに存在していて、値において異なるところでは、ネームサーバは、セカンダリに優先してプライマリゾーンファイルから資料を選別するべきですが、別の方法でそのようなどんなただ一つのデータも選ぶかもしれません。 それが決定できるところで信頼すべきデータソースの、より近くのソースから来るように見えるそれを選ぶのは理解できるかもしれません。 セカンダリの上でプライマリデータを選ぶのは、不正確な接着剤データの源が、より容易に発見されるのを許容します、そのようなデータに関する問題が存在していると。 サーバが2個のゾーンファイルからそれを検出できるか、または以上が不当に構成されるところでは、それは、闘争を引き起こすために誤ることを決定しているゾーンをロードするのを拒否して、適当な病気の特徴を発行するべきです。

   "Glue" above includes any record in a zone file that is not properly
   part of that zone, including nameserver records of delegated sub-
   zones (NS records), address records that accompany those NS records
   (A, AAAA, etc), and any other stray data that might appear.

「接着剤」上は適切に離れないことであるそのゾーンのゾーンファイルでのどんな記録も含んでいます、代表として派遣されたサブゾーン(NS記録)に関するネームサーバ記録、それらのNS記録(A、AAAAなど)に伴うアドレス記録、および現れるかもしれないいかなる他の折に触れているデータも含んでいて。

5.5. Sending RRSets (reprise)

5.5. 送付RRSets(反復)

   A Resource Record Set should only be included once in any DNS reply.
   It may occur in any of the Answer, Authority, or Additional
   Information sections, as required.  However it should not be repeated
   in the same, or any other, section, except where explicitly required
   by a specification.  For example, an AXFR response requires the SOA
   record (always an RRSet containing a single RR) be both the first and
   last record of the reply.  Where duplicates are required this way,
   the TTL transmitted in each case must be the same.

Resource Record Setは一度、どんなDNS回答にも含まれているだけであるべきです。 それは必要に応じてAnswer、Authority、またはAdditional情報部のいずれにも起こるかもしれません。 しかしながら、同じくらいでそれを繰り返すべきではありませんか、またはいかなる他の(セクション)も仕様が明らかに必要であるところで除かれます。 例えば、AXFR応答は両方が回答に関する1番目と最後の記録であったならSOA記録(いつも独身のRRを含むRRSet)を必要とします。 写しがこのように必要であるところでは、その都度伝えられたTTLは同じであるに違いありません。

6. Zone Cuts

6. ゾーンカット

   The DNS tree is divided into "zones", which are collections of
   domains that are treated as a unit for certain management purposes.
   Zones are delimited by "zone cuts".  Each zone cut separates a
   "child" zone (below the cut) from a "parent" zone (above the cut).
   The domain name that appears at the top of a zone (just below the cut
   that separates the zone from its parent) is called the zone's
   "origin".  The name of the zone is the same as the name of the domain
   at the zone's origin.  Each zone comprises that subset of the DNS
   tree that is at or below the zone's origin, and that is above the

DNS木は「ゾーン」に分割されます。(それは、ある管理目的のために一体にして扱われるドメインの収集です)。 ゾーンは「ゾーンカット」で区切られます。 それぞれのゾーンカットは「親」ゾーン(カットを超えた)と「子供」ゾーン(カットの下における)を切り離します。 ゾーン(まさしく親とゾーンを切り離すカットの下における)の先端に現れるドメイン名はゾーンの「発生源」と呼ばれます。 ゾーンの名前はゾーンの発生源でドメインの名前と同じです。 各ゾーンは発生源において、または、ゾーンの発生源の下とすなわち、上にあるDNS木のその部分集合を包括します。

Elz & Bush                  Standards Track                     [Page 8]

RFC 2181        Clarifications to the DNS Specification        July 1997

ElzとブッシュStandardsは仕様1997年7月にRFC2181明確化をDNSに追跡します[8ページ]。

   cuts that separate the zone from its children (if any).  The
   existence of a zone cut is indicated in the parent zone by the
   existence of NS records specifying the origin of the child zone.  A
   child zone does not contain any explicit reference to its parent.

子供(もしあれば)とゾーンを切り離すカット。 ゾーンカットの存在は、子供ゾーンの発生源を指定しながら、親ゾーンでNS記録の存在によって示されます。 子供ゾーンは親についての少しの明白な言及も含んでいません。

6.1. Zone authority

6.1. ゾーン権威

   The authoritative servers for a zone are enumerated in the NS records
   for the origin of the zone, which, along with a Start of Authority
   (SOA) record are the mandatory records in every zone.  Such a server
   is authoritative for all resource records in a zone that are not in
   another zone.  The NS records that indicate a zone cut are the
   property of the child zone created, as are any other records for the
   origin of that child zone, or any sub-domains of it.  A server for a
   zone should not return authoritative answers for queries related to
   names in another zone, which includes the NS, and perhaps A, records
   at a zone cut, unless it also happens to be a server for the other
   zone.

ゾーンへの正式のサーバがゾーンの発生源のためのNS記録で列挙される、どれ、Authority(SOA)記録のStartと共に、あらゆるゾーンでの義務的な記録はそうであるか。 ゾーンでの別のゾーンにあるというわけではないすべてのリソース記録に、そのようなサーバは正式です。 ゾーンが切れたのを示すNSレコードは、その子供ゾーンの発生源のためのいかなる他の記録のようにも作成された子供ゾーンの特性かそれに関するあらゆるサブドメインです。 ゾーンへのサーバはNS、および恐らくAを含んでいる別のゾーンで名前に関連する質問のための正式の答えを返すべきではありません、ゾーンカットにおける記録、また、もう片方のゾーンへのサーバであることが起こらない場合。

   Other than the DNSSEC cases mentioned immediately below, servers
   should ignore data other than NS records, and necessary A records to
   locate the servers listed in the NS records, that may happen to be
   configured in a zone at a zone cut.

すぐに以下に言及されたDNSSECケースを除いて、サーバはNS記録に記載されたサーバの場所を見つけるゾーンカットのときにゾーンでたまたま構成されるかもしれないNS記録、および必要なA記録以外のデータを無視するべきです。

6.2. DNSSEC issues

6.2. DNSSEC問題

   The DNS security mechanisms [RFC2065] complicate this somewhat, as
   some of the new resource record types added are very unusual when
   compared with other DNS RRs.  In particular the NXT ("next") RR type
   contains information about which names exist in a zone, and hence
   which do not, and thus must necessarily relate to the zone in which
   it exists.  The same domain name may have different NXT records in
   the parent zone and the child zone, and both are valid, and are not
   an RRSet.  See also section 5.3.2.

DNSセキュリティー対策[RFC2065]はこれをいくらか複雑にします、他のDNS RRsと比べるとレコード種類が加えた新しいリソースのいくつかが非常に珍しいので。 NXT(「次」の)RRタイプは、特に、どの名前がゾーンに存在しているか、そして、したがって、どれが存在しないかに関して情報を含んでいて、その結果、必ず、それが存在するゾーンに関連しなければなりません。 同じドメイン名が親ゾーンと子供ゾーンに異なったNXT記録を持っているかもしれなくて、両方が、有効であり、RRSetではありません。 また、セクション5.3.2を見てください。

   Since NXT records are intended to be automatically generated, rather
   than configured by DNS operators, servers may, but are not required
   to, retain all differing NXT records they receive regardless of the
   rules in section 5.4.

NXT記録はDNSでオペレータ、サーバがそうするかもしれないのを構成するより自動的にむしろ生成されることを意図しますが、必要でないので、彼らがセクション5.4の規則にかかわらず受け取るすべての異なったNXT記録を保有してください。

   For a secure parent zone to securely indicate that a subzone is
   insecure, DNSSEC requires that a KEY RR indicating that the subzone
   is insecure, and the parent zone's authenticating SIG RR(s) be
   present in the parent zone, as they by definition cannot be in the
   subzone.  Where a subzone is secure, the KEY and SIG records will be
   present, and authoritative, in that zone, but should also always be
   present in the parent zone (if secure).

安全な親ゾーンが、「副-ゾーン」が不安定であることをしっかりと示すように、DNSSECは、「副-ゾーン」が不安定であることを示すKEY RRと、親ゾーンがSIG RR(s)を認証するのが、親ゾーンに存在しているのを必要とします、彼らが定義上「副-ゾーン」にいるはずがないとき。 KEYとSIG記録は、現在であって、正式になるでしょう、「副-ゾーン」が安全であるところでは、また、いつも親ゾーンで現在と(安全)であるべきであり、そのゾーンで安全です。

Elz & Bush                  Standards Track                     [Page 9]

RFC 2181        Clarifications to the DNS Specification        July 1997

ElzとブッシュStandardsは仕様1997年7月にRFC2181明確化をDNSに追跡します[9ページ]。

   Note that in none of these cases should a server for the parent zone,
   not also being a server for the subzone, set the AA bit in any
   response for a label at a zone cut.

これらの場合のどれかにおけるそれはまた、「副-ゾーン」のためのサーバである、AAがゾーンカットのときにラベルのためのどんな応答でも噛み付いたセットではなく、親ゾーンへのサーバがそうするべきであるというわけではないことに注意してください。

7. SOA RRs

7. SOA RRs

   Three minor issues concerning the Start of Zone of Authority (SOA)
   Resource Record need some clarification.

Authority(SOA)リソースRecordのZoneのStartに関する3つの小さな問題が何らかの明確化を必要とします。

7.1. Placement of SOA RRs in authoritative answers

7.1. 正式の答えにおける、SOA RRsのプレースメント

   RFC1034, in section 3.7, indicates that the authority section of an
   authoritative answer may contain the SOA record for the zone from
   which the answer was obtained.  When discussing negative caching,
   RFC1034 section 4.3.4 refers to this technique but mentions the
   additional section of the response.  The former is correct, as is
   implied by the example shown in section 6.2.5 of RFC1034.  SOA
   records, if added, are to be placed in the authority section.

セクション3.7で、RFC1034は、正式の答えの権威部が答えが得られたゾーンのためのSOA記録を含むかもしれないのを示します。 否定的キャッシュについて議論するとき、RFC1034セクション4.3.4はこのテクニックを示しますが、応答の追加セクションについて言及します。 前者は.5セクション6.2RFC1034に示された例によって含意されるように正しいです。 SOA記録は加えられるなら権威部に置かれることです。

7.2. TTLs on SOA RRs

7.2. SOA RRsの上のTTLs

   It may be observed that in section 3.2.1 of RFC1035, which defines
   the format of a Resource Record, that the definition of the TTL field
   contains a throw away line which states that the TTL of an SOA record
   should always be sent as zero to prevent caching.  This is mentioned
   nowhere else, and has not generally been implemented.
   Implementations should not assume that SOA records will have a TTL of
   zero, nor are they required to send SOA records with a TTL of zero.

コネが3.2にResource Recordの書式を定義する.1RFC1035を区分するのが観測されるかもしれなくて、TTL分野の定義が遠くに一投を含んでいるのがSOA記録のTTLがキャッシュするのを防ぐためにゼロとしていつも送られるべきであるどの州を裏打ちするか。 これは、ほかにどこにも言及されないで、また一般に、実装されていません。 実装は、SOA記録にはゼロのTTLがあると仮定するべきではありません、そして、それらはゼロのTTLがある記録をSOAに送る必要はありません。

7.3. The SOA.MNAME field

7.3. SOA.MNAME分野

   It is quite clear in the specifications, yet seems to have been
   widely ignored, that the MNAME field of the SOA record should contain
   the name of the primary (master) server for the zone identified by
   the SOA.  It should not contain the name of the zone itself.  That
   information would be useless, as to discover it, one needs to start
   with the domain name of the SOA record - that is the name of the
   zone.

それは、仕様でかなり明確ですが、広く無視されたように思えて、SOAのMNAME分野が記録するのがSOAによって特定されたゾーンへのプライマリ(マスター)サーバの名前を含むべきです。 それはゾーン自体の名前を含むべきではありません。 その情報は役に立たないでしょう、それ、人はSOA記録のドメイン名から始まる必要があります--それがゾーンの名前であると発見するほど。

8. Time to Live (TTL)

8. 生きる時間(TTL)

   The definition of values appropriate to the TTL field in STD 13 is
   not as clear as it could be, with respect to how many significant
   bits exist, and whether the value is signed or unsigned.  It is
   hereby specified that a TTL value is an unsigned number, with a
   minimum value of 0, and a maximum value of 2147483647.  That is, a
   maximum of 2^31 - 1.  When transmitted, this value shall be encoded
   in the less significant 31 bits of the 32 bit TTL field, with the

STD13のTTL分野に適切な値の定義は最も明確であったはずがありません、値がいくつの重要なビットが存在しているか、そして、署名されるか、または未署名であるかに関して。 TTL値が符号のない数であるとこれにより指定されます、0の最小値、および2147483647の最大値で。 すなわち、最大2^31--1。 伝えられると、この値は32ビットのTTL分野のそれほど重要でない31ビットでコード化されるものとします。

Elz & Bush                  Standards Track                    [Page 10]

RFC 2181        Clarifications to the DNS Specification        July 1997

ElzとブッシュStandardsは仕様1997年7月にRFC2181明確化をDNSに追跡します[10ページ]。

   most significant, or sign, bit set to zero.

最も重要である、または、ゼロに合わせるために設定していた状態で噛み付かれたサイン。

   Implementations should treat TTL values received with the most
   significant bit set as if the entire value received was zero.

実装はまるで全体の対価領収がゼロであるかのように設定される中で最も重要なビットで受け取られたTTL値を扱うべきです。

   Implementations are always free to place an upper bound on any TTL
   received, and treat any larger values as if they were that upper
   bound.  The TTL specifies a maximum time to live, not a mandatory
   time to live.

実装は、受け取られたどんなTTLにも上限を置いて、まるでそれらがその上限であるかのようにいつも自由にどんなより大きい値も扱うことができます。 TTLは生きる義務的な時間ではなく、生きる最大の時間を指定します。

9. The TC (truncated) header bit

9. TC(先端を切られる)ヘッダービット

   The TC bit should be set in responses only when an RRSet is required
   as a part of the response, but could not be included in its entirety.
   The TC bit should not be set merely because some extra information
   could have been included, but there was insufficient room.  This
   includes the results of additional section processing.  In such cases
   the entire RRSet that will not fit in the response should be omitted,
   and the reply sent as is, with the TC bit clear.  If the recipient of
   the reply needs the omitted data, it can construct a query for that
   data and send that separately.

TCビットをRRSetが応答の一部として必要であるときにだけ、応答で設定されるべきでしたが、全体として含むことができませんでした。 単に、何らかのその他の情報が含まれたかもしれませんでしたが、不十分な余地があったので、TCビットを設定するべきではありません。 これは追加セクション処理の結果を含んでいます。 そのような場合応答をうまくはめ込まない全体のRRSetは省略されるべきでした、そして、回答はそのままで発信しました、TCビットが明確な状態で。 回答の受取人が省略されたデータを必要とするなら、それは、そのデータのための質問を構成して、別々にそれを送ることができます。

   Where TC is set, the partial RRSet that would not completely fit may
   be left in the response.  When a DNS client receives a reply with TC
   set, it should ignore that response, and query again, using a
   mechanism, such as a TCP connection, that will permit larger replies.

TCが用意ができているところでは、完全に合うというわけではない部分的なRRSetは応答で残されるかもしれません。 TCがセットした状態でDNSクライアントが回答を受け取るとき、再びその応答、および質問を無視するべきです、より大きい回答を可能にするTCP接続などのメカニズムを使用して。

10. Naming issues

10. 問題を命名します。

   It has sometimes been inferred from some sections of the DNS
   specification [RFC1034, RFC1035] that a host, or perhaps an interface
   of a host, is permitted exactly one authoritative, or official, name,
   called the canonical name.  There is no such requirement in the DNS.

DNS仕様[RFC1034、RFC1035]の数人のセクションから時々まさに正準な名前と呼ばれる1つの正式の、または、公式の名前がホスト、または恐らくホストのインタフェースに受入れられると推論されました。 どんなそのような要件もDNSにありません。

10.1. CNAME resource records

10.1. CNAMEリソース記録

   The DNS CNAME ("canonical name") record exists to provide the
   canonical name associated with an alias name.  There may be only one
   such canonical name for any one alias.  That name should generally be
   a name that exists elsewhere in the DNS, though there are some rare
   applications for aliases with the accompanying canonical name
   undefined in the DNS.  An alias name (label of a CNAME record) may,
   if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
   other data.  That is, for any label in the DNS (any domain name)
   exactly one of the following is true:

DNS CNAME(「正準な名前」)記録は、関連するという正準な名前に別名を提供するために存在しています。 どんな別名のためのそのような名前の正準な1つしかもないかもしれません。 一般に、その名前はDNSのほかの場所に存在する名前であるべきです、DNSで未定義の付随の正準な名前がある別名のいくつかのまれな利用がありますが。 別名(CNAME記録のラベル)には、DNSSECが使用中であるならSIG、NXT、およびKEY RRsを持っていますが、他のデータは全くないかもしれません。 すなわち、DNS(どんなドメイン名も)のどんなラベルに関してはも、ちょうど以下の1つは本当です:

Elz & Bush                  Standards Track                    [Page 11]

RFC 2181        Clarifications to the DNS Specification        July 1997

ElzとブッシュStandardsは仕様1997年7月にRFC2181明確化をDNSに追跡します[11ページ]。

     + one CNAME record exists, optionally accompanied by SIG, NXT, and
       KEY RRs,
     + one or more records exist, none being CNAME records,
     + the name exists, but has no associated RRs of any type,
     + the name does not exist at all.

+ 1つのCNAME記録が存在していて、SIG、NXTによって任意に伴われて、KEY RRsであり+ 1つ以上の記録が存在していて、なにもがCNAME記録であり、+ 名前には、存在していますが、どんなタイプのどんな関連RRsもなくて、また+ 名前は全く存在していません。

10.1.1. CNAME terminology

10.1.1. CNAME用語

   It has been traditional to refer to the label of a CNAME record as "a
   CNAME".  This is unfortunate, as "CNAME" is an abbreviation of
   "canonical name", and the label of a CNAME record is most certainly
   not a canonical name.  It is, however, an entrenched usage.  Care
   must therefore be taken to be very clear whether the label, or the
   value (the canonical name) of a CNAME resource record is intended.
   In this document, the label of a CNAME resource record will always be
   referred to as an alias.

CNAME記録のラベルを「CNAME」と呼ぶのは伝統的です。 これは不幸です、"CNAME"が「正準な名前」の略語であり、CNAME記録のラベルが最も確かに正準な名前でないので。 しかしながら、それは強固な用法です。 注意はそうしなければなりません、したがって、ラベル、または値であることにかかわらず非常に明確になるように取ってください。CNAMEリソース記録の(正準な名前)は意図します。 本書では、CNAMEリソース記録のラベルはいつも別名と呼ばれるでしょう。

10.2. PTR records

10.2. PTR記録

   Confusion about canonical names has lead to a belief that a PTR
   record should have exactly one RR in its RRSet.  This is incorrect,
   the relevant section of RFC1034 (section 3.6.2) indicates that the
   value of a PTR record should be a canonical name.  That is, it should
   not be an alias.  There is no implication in that section that only
   one PTR record is permitted for a name.  No such restriction should
   be inferred.

正準な名前に関する混乱はPTR記録がRRSetにちょうど1RRを持つべきであるという信念にリードを持っています。 これが不正確である、RFC1034(セクション3.6.2)の関連セクションはPTR記録の価値が正準な名前であることを示します。 すなわち、それは別名であるべきではありません。 1つのPTR記録だけが名前のために受入れられるというそのセクションでの含意が全くありません。 どんなそのような制限も推論するべきではありません。

   Note that while the value of a PTR record must not be an alias, there
   is no requirement that the process of resolving a PTR record not
   encounter any aliases.  The label that is being looked up for a PTR
   value might have a CNAME record.  That is, it might be an alias.  The
   value of that CNAME RR, if not another alias, which it should not be,
   will give the location where the PTR record is found.  That record
   gives the result of the PTR type lookup.  This final result, the
   value of the PTR RR, is the label which must not be an alias.

PTR記録の価値が別名であるはずがありませんが、PTR記録を決議するプロセスがどんな別名にも遭遇しないという要件が全くないことに注意してください。 PTR値のために見上げられているラベルで、CNAMEは記録するかもしれません。 すなわち、それは別名であるかもしれません。 そのCNAME RRの値(別の別名でなくても)はPTR記録が見つけられる位置を与えるでしょう。それは別名がそうであるべきではありません。 その記録はPTRタイプルックアップの結果を与えます。 この最終的な結果(PTR RRの値)は別名であるはずがないラベルです。

10.3. MX and NS records

10.3. MXとNS記録

   The domain name used as the value of a NS resource record, or part of
   the value of a MX resource record must not be an alias.  Not only is
   the specification clear on this point, but using an alias in either
   of these positions neither works as well as might be hoped, nor well
   fulfills the ambition that may have led to this approach.  This
   domain name must have as its value one or more address records.
   Currently those will be A records, however in the future other record
   types giving addressing information may be acceptable.  It can also
   have other RRs, but never a CNAME RR.

NSリソース記録の価値、またはMXリソース記録の価値の一部として中古のドメイン名は別名であるはずがありません。 仕様がこの点だけに関して明確であるのではなく、これらの位置のどちらかで別名を使用するのは、働いていて、望まれているかもしれなくて、このアプローチにつながったかもしれない野心をよく実現させます。 このドメイン名には、値として1つ以上のアドレス記録がなければなりません。 アドレス指定情報を与える他のレコード種類がどんなに将来許容できても、現在の、それらはA記録になるでしょう。 また、それは他のRRs、しかし、決してどんなCNAME RRも持つことができません。

Elz & Bush                  Standards Track                    [Page 12]

RFC 2181        Clarifications to the DNS Specification        July 1997

ElzとブッシュStandardsは仕様1997年7月にRFC2181明確化をDNSに追跡します[12ページ]。

   Searching for either NS or MX records causes "additional section
   processing" in which address records associated with the value of the
   record sought are appended to the answer.  This helps avoid needless
   extra queries that are easily anticipated when the first was made.

NSかMX記録のどちらかを検索すると、求められる記録の価値に関連しているアドレス記録が答えに追加される「追加セクション処理」は引き起こされます。 これは、1番目が作られたとき容易に予期される不必要な付加的な質問を避けるのを助けます。

   Additional section processing does not include CNAME records, let
   alone the address records that may be associated with the canonical
   name derived from the alias.  Thus, if an alias is used as the value
   of an NS or MX record, no address will be returned with the NS or MX
   value.  This can cause extra queries, and extra network burden, on
   every query.  It is trivial for the DNS administrator to avoid this
   by resolving the alias and placing the canonical name directly in the
   affected record just once when it is updated or installed.  In some
   particular hard cases the lack of the additional section address
   records in the results of a NS lookup can cause the request to fail.

追加セクション処理はCNAME記録、まして別名から得られた正準な名前に関連するかもしれないアドレス記録を含んでいません。 したがって、別名がNSの値として使用されるか、またはMXが記録すると、NSかMX値と共にアドレスを全く返さないでしょう。 これはあらゆる質問での付加的な質問、および付加的なネットワーク負担を引き起こす場合があります。 DNS管理者がそれをアップデートするか、またはインストールするとき、一度だけ直接影響を受ける記録に別名を決議して、正準な名前を置くことによってこれを避けるのは、些細です。 いくつかの特定の困難な場合では、NSルックアップの結果における、追加セクションアドレス記録の不足は失敗するという要求を引き起こす場合があります。

11. Name syntax

11. 名前構文

   Occasionally it is assumed that the Domain Name System serves only
   the purpose of mapping Internet host names to data, and mapping
   Internet addresses to host names.  This is not correct, the DNS is a
   general (if somewhat limited) hierarchical database, and can store
   almost any kind of data, for almost any purpose.

時折、ドメインネームシステムがインターネットホスト名をデータに写像して、インターネット・アドレスをホスト名に写像する目的だけに役立つと思われます。 これが正しくなく、DNSは一般的な(いくらか制限されるなら)階層型データベースであり、ほとんどどんな種類のデータも保存できます、ほとんどどんな目的のためにも。

   The DNS itself places only one restriction on the particular labels
   that can be used to identify resource records.  That one restriction
   relates to the length of the label and the full name.  The length of
   any one label is limited to between 1 and 63 octets.  A full domain
   name is limited to 255 octets (including the separators).  The zero
   length full name is defined as representing the root of the DNS tree,
   and is typically written and displayed as ".".  Those restrictions
   aside, any binary string whatever can be used as the label of any
   resource record.  Similarly, any binary string can serve as the value
   of any record that includes a domain name as some or all of its value
   (SOA, NS, MX, PTR, CNAME, and any others that may be added).
   Implementations of the DNS protocols must not place any restrictions
   on the labels that can be used.  In particular, DNS servers must not
   refuse to serve a zone because it contains labels that might not be
   acceptable to some DNS client programs.  A DNS server may be
   configurable to issue warnings when loading, or even to refuse to
   load, a primary zone containing labels that might be considered
   questionable, however this should not happen by default.

DNS自身はリソース記録を特定するのに使用できる特定のラベルに関して1つの制限だけを課します。 その1つの制限がラベルの長さとフルネームに関連します。 どんなラベルの長さも1〜63の八重奏に制限されます。 完全なドメイン名は255の八重奏に制限されます(分離符を含んでいて)。 「ゼロ・レングスフルネームとして、DNS木の根を表すと定義して、通常書いて、表示する」、」 それらの制限は別として、どんなバイナリーもどんなリソース記録のラベルとしても使用できるものなら何でも結びます。 同様に、どんな2進のストリングも価値(SOA、NS、Mx、PTR、CNAME、および加えられるどんな他のものも)のいくつかかすべてとしてドメイン名を含んでいるどんな記録の価値としても機能できます。 DNSプロトコルの実装は使用できるラベルに関してどんな制限も課してはいけません。 特に、DNSサーバは、いくつかのDNSクライアントプログラムに許容できないかもしれないラベルを含んでいるのでゾーンに役立つのを拒否してはいけません。ロードするか、または積み込む廃物、プライマリゾーンにさえ疑わしいと考えられるかもしれないラベルを含むとき、DNSサーバが警告を発行するのにおいて構成可能であるかもしれない、しかしながら、これはデフォルトで起こるべきではありません。

   Note however, that the various applications that make use of DNS data
   can have restrictions imposed on what particular values are
   acceptable in their environment.  For example, that any binary label
   can have an MX record does not imply that any binary name can be used
   as the host part of an e-mail address.  Clients of the DNS can impose

しかしながら、DNSデータを利用する様々なアプリケーションでどんな特定の値に制限を課すことができるかが彼らの環境で許容できることに注意してください。 例えば、MXがどんな2進のラベルでも記録できるのがEメールアドレスのホスト部分としてどんな2進の名前も使用できるのを含意しません。 DNSのクライアントはでしゃばることができます。

Elz & Bush                  Standards Track                    [Page 13]

RFC 2181        Clarifications to the DNS Specification        July 1997

ElzとブッシュStandardsは仕様1997年7月にRFC2181明確化をDNSに追跡します[13ページ]。

   whatever restrictions are appropriate to their circumstances on the
   values they use as keys for DNS lookup requests, and on the values
   returned by the DNS.  If the client has such restrictions, it is
   solely responsible for validating the data from the DNS to ensure
   that it conforms before it makes any use of that data.

それらがDNSルックアップ要求にキーとして使用する値、およびDNSによって返された値に関するそれらの事情に適切ないかなる制限。 クライアントにそのような制限があるなら、それのどんな使用もデータにする前にそれが従うのを保証するのは唯一DNSからのデータを有効にするのに責任があります。

   See also [RFC1123] section 6.1.3.5.

また、.5に[RFC1123]セクション6.1.3を見てください。

12. Security Considerations

12. セキュリティ問題

   This document does not consider security.

このドキュメントはセキュリティを考えません。

   In particular, nothing in section 4 is any way related to, or useful
   for, any security related purposes.

セクション4の何はも特に、関連するあらゆる道ではありませんでも役に立って、どんなセキュリティも目的を関係づけました。

   Section 5.4.1 is also not related to security.  Security of DNS data
   will be obtained by the Secure DNS [RFC2065], which is mostly
   orthogonal to this memo.

セクション5.4 .1 また、セキュリティに関連されません。 DNSデータのセキュリティはSecure DNS[RFC2065]によって得られるでしょう。(Secure DNSはこのメモとほとんど直交しています)。

   It is not believed that anything in this document adds to any
   security issues that may exist with the DNS, nor does it do anything
   to that will necessarily lessen them.  Correct implementation of the
   clarifications in this document might play some small part in
   limiting the spread of non-malicious bad data in the DNS, but only
   DNSSEC can help with deliberate attempts to subvert DNS data.

何も本書ではDNSと共に存在するどんな安全保障問題にも加えて、それに何もしないと信じられていなくて、必ず彼らを少なくするということです。 明確化の正しい実装はDNSの非悪意がある悪いデータの普及を制限する際に本書では何らかの小さい部分を果たすかもしれませんが、DNSSECだけがDNSデータを打倒する慎重な試みで助けることができます。

13. References

13. 参照

   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and Facilities",
               STD 13, RFC 1034, November 1987.

[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
               Specification", STD 13, RFC 1035, November 1987.

[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日

   [RFC1123]   Braden, R., "Requirements for Internet Hosts - application
               and support", STD 3, RFC 1123, January 1989.

[RFC1123]ブレーデン、R.、「インターネットHostsのための要件--、アプリケーションとサポート、」、STD3、RFC1123、1月1989日

   [RFC1700]   Reynolds, J., Postel, J., "Assigned Numbers",
               STD 2, RFC 1700, October 1994.

[RFC1700] レイノルズ、J.、ポステル、J.、「規定番号」、STD2、RFC1700、1994年10月。

   [RFC2065]   Eastlake, D., Kaufman, C., "Domain Name System Security
               Extensions", RFC 2065, January 1997.

[RFC2065] イーストレーク、D.、コーフマン、C.、「ドメインネームシステムセキュリティ拡大」、RFC2065、1997年1月。

Elz & Bush                  Standards Track                    [Page 14]

RFC 2181        Clarifications to the DNS Specification        July 1997

ElzとブッシュStandardsは仕様1997年7月にRFC2181明確化をDNSに追跡します[14ページ]。

14. Acknowledgements

14. 承認

   This memo arose from discussions in the DNSIND working group of the
   IETF in 1995 and 1996, the members of that working group are largely
   responsible for the ideas captured herein.  Particular thanks to
   Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the
   DNSSEC issues in this document, and to John Gilmore for pointing out
   where the clarifications were not necessarily clarifying.  Bob Halley
   suggested clarifying the placement of SOA records in authoritative
   answers, and provided the references.  Michael Patton, as usual, and
   Mark Andrews, Alan Barrett and Stan Barber provided much assistance
   with many details.  Josh Littlefield helped make sure that the
   clarifications didn't cause problems in some irritating corner cases.

このメモは1995年と1996年に議論からIETFのDNSINDワーキンググループで起こって、そのワーキンググループのメンバーはここに得られた考えに主に責任感が強いです。 DNSSEC問題がこのドキュメントにある助けのためのドナルド・E.イーストレーク、3番目、およびOlafurグドムンソンと、そして、明確化が必ずどこではっきりさせられていたというわけではないかを指摘するためのジョン・ギルモアへの特定の感謝。 ボブ・ハレーは、正式の答えにおける、SOA記録のプレースメントをはっきりさせることを提案して、参照を前提としました。 マイケル・パットン、通常通りであるのとマーク・アンドリュース、アラン・バーレット、およびスタン・バーバーは多くの詳細を多くの支援に提供しました。 ジョッシュ・リトルフィールドは、明確化がいくつかのいらだたしい角の場合で問題を起こさないのを確実にするのを助けました。

15. Authors' Addresses

15. 作者のアドレス

   Robert Elz
   Computer Science
   University of Melbourne
   Parkville, Victoria, 3052
   Australia.

メルボルンParkville、ビクトリア、3052オーストラリアのロバートElzコンピュータサイエンス大学。

   EMail: kre@munnari.OZ.AU

メール: kre@munnari.OZ.AU

   Randy Bush
   RGnet, Inc.
   5147 Crystal Springs Drive NE
   Bainbridge Island, Washington,  98110
   United States.

ランディブッシュRGnet Inc.5147水晶スプリングスドライブNeベーンブリッジ島、ワシントン、98110合衆国。

   EMail: randy@psg.com

メール: randy@psg.com

Elz & Bush                  Standards Track                    [Page 15]

Elzとブッシュ標準化過程[15ページ]