RFC3597 日本語訳

Network Working Group                                      A. Gustafsson
Request for Comments: 3597                                  Nominum Inc.
Category: Standards Track                                 September 2003

コメントを求めるワーキンググループA.グスタファソンの要求をネットワークでつないでください: 3597年のNominum株式会社カテゴリ: 標準化過程2003年9月

           Handling of Unknown DNS Resource Record (RR) Types

未知のDNSリソース記録(RR)タイプの取り扱い

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)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

Abstract

要約

   Extending the Domain Name System (DNS) with new Resource Record (RR)
   types currently requires changes to name server software.  This
   document specifies the changes necessary to allow future DNS
   implementations to handle new RR types transparently.

現在新しいResource Record(RR)タイプでドメインネームシステム(DNS)を広げるのはネームサーバソフトウェアへの変化を必要とします。 このドキュメントは将来のDNS実装が透過的に新しいRRタイプを扱うのを許容するのに必要な変化を指定します。

1.  Introduction

1. 序論

   The DNS is designed to be extensible to support new services through
   the introduction of new resource record (RR) types.  In practice,
   deploying a new RR type currently requires changes to the name server
   software not only at the authoritative DNS server that is providing
   the new information and the client making use of it, but also at all
   slave servers for the zone containing it, and in some cases also at
   caching name servers and forwarders used by the client.

DNSは、新しいリソース記録(RR)タイプの導入で新種業務をサポートするのにおいて広げることができるように設計されています。 実際には、現在新しいRRがタイプであると配布するのが新情報を提供している正式のDNSサーバとそれを利用するクライアントで必要であるだけではなく、すべての奴隷サーバでもクライアントによってそれを含んで、また、いくつかの場合、ネームサーバと混載業者をキャッシュするのに使用されたゾーンにネームサーバソフトウェアへの変化を必要とします。

   Because the deployment of new server software is slow and expensive,
   the potential of the DNS in supporting new services has never been
   fully realized.  This memo proposes changes to name servers and to
   procedures for defining new RR types aimed at simplifying the future
   deployment of new RR types.

新しいサーバソフトウェアの展開が遅くて、高価であるので、新種業務をサポートすることにおける、DNSの可能性は完全に一度も実現されたことがありません。 このメモは新しい新しいRRタイプの今後の展開を簡素化するのが目的とされたRRタイプを定義するためのネームサーバと、そして、手順への変化を提案します。

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

Gustafsson                  Standards Track                     [Page 1]

RFC 3597            Handling of Unknown DNS RR Types      September 2003

グスタファソンStandardsは2003年9月に未知のDNS RRタイプのRFC3597取り扱いを追跡します[1ページ]。

2.  Definition

2. 定義

   An "RR of unknown type" is an RR whose RDATA format is not known to
   the DNS implementation at hand, and whose type is not an assigned
   QTYPE or Meta-TYPE as specified in [RFC 2929] (section 3.1) nor
   within the range reserved in that section for assignment only to
   QTYPEs and Meta-TYPEs.  Such an RR cannot be converted to a type-
   specific text format, compressed, or otherwise handled in a type-
   specific way.

「未知のタイプのRR」は[RFC2929]で指定されること(セクション3.1)と、そして、QTYPEsとMeta-TYPEsだけへの課題のためにそのセクションで予約された範囲の中のタイプが割り当てられたRDATA形式がDNS実装に手元に知られないで、またQTYPEでなくて、またMeta-TYPEでもないRRです。 そのようなRRをタイプの特定のテキスト形式に変換できないか、圧縮できないか、別の方法でタイプの特定の方法で扱うことができません。

   In the case of a type whose RDATA format is class specific, an RR is
   considered to be of unknown type when the RDATA format for that
   combination of type and class is not known.

RDATA形式がクラス特有であるタイプの場合では、タイプとクラスのその組み合わせのためのRDATA書式が知られていないとき、未知のタイプにはRRがいると考えられます。

3.  Transparency

3. 透明

   To enable new RR types to be deployed without server changes, name
   servers and resolvers MUST handle RRs of unknown type transparently.
   That is, they must treat the RDATA section of such RRs as
   unstructured binary data, storing and transmitting it without change
   [RFC1123].

新しいRRタイプがサーバ変化、ネームサーバ、およびレゾルバなしで配布されるのを可能にするのが透過的に未知のタイプのRRsを扱わなければなりません。 すなわち、彼らはそのようなRRsのRDATA部を不統一なバイナリ・データとして扱わなければなりません、変化[RFC1123]なしでそれを保存して、伝えて。

   To ensure the correct operation of equality comparison (section 6)
   and of the DNSSEC canonical form (section 7) when an RR type is known
   to some but not all of the servers involved, servers MUST also
   exactly preserve the RDATA of RRs of known type, except for changes
   due to compression or decompression where allowed by section 4 of
   this memo.  In particular, the character case of domain names that
   are not subject to compression MUST be preserved.

また、平等比較(セクション6)とDNSSEC標準形(セクション7)の正しい操作を確実にするために、RRタイプがすべてではなく、かかわったサーバのいくつかに知られていると、サーバはまさにこのメモのセクション4によって許容されているところに圧縮か減圧による変化以外の知られているタイプのRRsのRDATAを保存しなければなりません。 特に、圧縮を受けることがないドメイン名のキャラクタ事件を保存しなければなりません。

4.  Domain Name Compression

4. ドメイン名圧縮

   RRs containing compression pointers in the RDATA part cannot be
   treated transparently, as the compression pointers are only
   meaningful within the context of a DNS message.  Transparently
   copying the RDATA into a new DNS message would cause the compression
   pointers to point at the corresponding location in the new message,
   which now contains unrelated data.  This would cause the compressed
   name to be corrupted.

透過的にRDATA部分に圧縮指針を含むRRsは扱うことができません、圧縮指針がDNSメッセージの文脈の中で重要であるだけであるので。 圧縮指針は透過的に新しいDNSメッセージにRDATAをコピーするのに新しいメッセージの対応する位置を指し示すでしょう。(メッセージは現在、関係ないデータを含みます)。 これで、圧縮された名前を崩壊させるでしょう。

   To avoid such corruption, servers MUST NOT compress domain names
   embedded in the RDATA of types that are class-specific or not well-
   known.  This requirement was stated in [RFC1123] without defining the
   term "well-known"; it is hereby specified that only the RR types
   defined in [RFC1035] are to be considered "well-known".

そのような不正を避けるために、サーバはクラス特有のタイプのRDATAに埋め込まれているか、またはよく知られないドメイン名を圧縮してはいけません。 「よく知られる」という用語を定義しないで、この要件は[RFC1123]に述べられました。 [RFC1035]で定義されたRRタイプだけが「よく知られる」と考えられることになっているとこれにより指定されます。

Gustafsson                  Standards Track                     [Page 2]

RFC 3597            Handling of Unknown DNS RR Types      September 2003

グスタファソンStandardsは2003年9月に未知のDNS RRタイプのRFC3597取り扱いを追跡します[2ページ]。

   The specifications of a few existing RR types have explicitly allowed
   compression contrary to this specification: [RFC2163] specified that
   compression applies to the PX RR, and [RFC2535] allowed compression
   in SIG RRs and NXT RRs records.  Since this specification disallows
   compression in these cases, it is an update to [RFC2163] (section 4)
   and [RFC2535] (sections 4.1.7 and 5.2).

いくつかの既存のRRタイプの仕様はこの仕様とは逆に明らかに圧縮を許しました: [RFC2163]は、圧縮がPX RRに適用されると指定しました、そして、[RFC2535]はSIG RRsとNXT RRsでの圧縮に記録を許しました。 この仕様がこれらの場合における圧縮を禁じるので、それは[RFC2163](セクション4)と[RFC2535](セクション4.1 .7と5.2)へのアップデートです。

   Receiving servers MUST decompress domain names in RRs of well-known
   type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
   NXT, NAPTR, and SRV (although the current specification of the SRV RR
   in [RFC2782] prohibits compression, [RFC2052] mandated it, and some
   servers following that earlier specification are still in use).

サーバを受け取ると、よく知られるタイプのRRsのドメイン名は減圧されなければなりません、そして、また、SHOULDはタイプRP、AFSDB、RT、SIG、PX、NXT、NAPTR、およびSRVのRRsを減圧します([RFC2782]のSRV RRの現在の仕様は圧縮を禁止します、そして、[RFC2052]はそれを強制しました、そして、その以前の仕様に従ういくつかのサーバがまだ使用中ですが)。

   Future specifications for new RR types that contain domain names
   within their RDATA MUST NOT allow the use of name compression for
   those names, and SHOULD explicitly state that the embedded domain
   names MUST NOT be compressed.

それらのRDATA MUST NOTの中にドメイン名を含む新しいRRタイプへの将来の仕様は名前圧縮のそれらの名前の使用を許します、そして、SHOULDは埋め込まれたドメイン名を圧縮してはいけないと明らかに述べます。

   As noted in [RFC1123], the owner name of an RR is always eligible for
   compression.

[RFC1123]に述べられるように、圧縮に、所有者名(RR)はいつも適任です。

5.  Text Representation

5. テキスト表現

   In the "type" field of a master file line, an unknown RR type is
   represented by the word "TYPE" immediately followed by the decimal RR
   type number, with no intervening whitespace.  In the "class" field,
   an unknown class is similarly represented as the word "CLASS"
   immediately followed by the decimal class number.

基本ファイル系列の「タイプ」分野では、未知のRRタイプが「タイプ」という10進RR形式数がすぐにあとに続いた言葉によって代理をされます、介入している空白なしで。 「クラス」分野では、10進クラス番号に従って「クラス」という言葉がすぐに従ったので、未知のクラスが同様に表されます。

   This convention allows types and classes to be distinguished from
   each other and from TTL values, allowing the "[<TTL>] [<class>]
   <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
   [RFC1035] to both be unambiguously parsed.

このコンベンションは、タイプとクラスが互いとTTL値と区別されるのを許容します、[RFC1035]の「[<TTL>][<のクラス>]<タイプ><RDATA>」と「[<のクラス>][<TTL>]<タイプ><RDATA>」フォームがともに明白に分析されるのを許容して。

   The RDATA section of an RR of unknown type is represented as a
   sequence of white space separated words as follows:

余白の系列が以下の単語を切り離したので、未知のタイプのRRのRDATA部は代表されます:

      The special token \# (a backslash immediately followed by a hash
      sign), which identifies the RDATA as having the generic encoding
      defined herein rather than a traditional type-specific encoding.

特別なトークン\#(ハッシュサインがすぐに支えたバックスラッシュ)。(その\はコード化がここに伝統的なタイプ特有のコード化よりむしろ定義したジェネリックを持っているとしてRDATAを特定します)。

      An unsigned decimal integer specifying the RDATA length in octets.

八重奏におけるRDATAの長さを指定する未署名の10進整数。

      Zero or more words of hexadecimal data encoding the actual RDATA
      field, each containing an even number of hexadecimal digits.

それぞれ16進数字の偶数を含んでいて、実際のRDATA分野をコード化する16進データのゼロか、より多くの単語。

   If the RDATA is of zero length, the text representation contains only
   the \# token and the single zero representing the length.

RDATAがゼロ・レングスのものであるなら、テキスト表現は\#トークンだけと長さを表すただ一つのゼロを含んでいます。

Gustafsson                  Standards Track                     [Page 3]

RFC 3597            Handling of Unknown DNS RR Types      September 2003

グスタファソンStandardsは2003年9月に未知のDNS RRタイプのRFC3597取り扱いを追跡します[3ページ]。

   An implementation MAY also choose to represent some RRs of known type
   using the above generic representations for the type, class and/or
   RDATA, which carries the benefit of making the resulting master file
   portable to servers where these types are unknown.  Using the generic
   representation for the RDATA of an RR of known type can also be
   useful in the case of an RR type where the text format varies
   depending on a version, protocol, or similar field (or several)
   embedded in the RDATA when such a field has a value for which no text
   format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
   0.

また、実装は、タイプ、クラス、そして/または、RDATAの上のジェネリック表現を使用することで知られているタイプのいくつかのRRsを表すのを選ぶかもしれません。RDATAは結果として起こる基本ファイルをサーバに携帯用にする利益をこれらのタイプが未知であるところまで運びます。 また、知られているタイプのRRのRDATAのジェネリック表現を使用するのもそのような分野にテキスト書式が全く知られていない値があるとRDATAに埋め込まれたバージョン、プロトコル、または同様のフィールド(または、数個)によって、テキスト形式が異なるRRタイプの場合で役に立つ場合があります、例えば、0以外のバージョンがあるLOC RR[RFC1876]。

   Even though an RR of known type represented in the \# format is
   effectively treated as an unknown type for the purpose of parsing the
   RDATA text representation, all further processing by the server MUST
   treat it as a known type and take into account any applicable type-
   specific rules regarding compression, canonicalization, etc.

事実上、\#形式で代理をされた知られているタイプのRRがRDATAテキスト表現を分析する目的のための未知のタイプとして扱われて、サーバによるさらなるすべての処理が、圧縮に関して知られているタイプとしてそれを扱って、どんな適切なタイプ特定の規則も考慮に入れなければなりませんが、canonicalizationですなど。

   The following are examples of RRs represented in this manner,
   illustrating various combinations of generic and type-specific
   encodings for the different fields of the master file format:

↓これはこの様に表されたRRsに関する例です、ジェネリックとタイプ特有のencodingsの様々な組み合わせを基本ファイル形式の異なった分野に例証して:

      a.example.   CLASS32     TYPE731         \# 6 abcd (
                                               ef 01 23 45 )
      b.example.   HS          TYPE62347       \# 0
      e.example.   IN          A               \# 4 0A000001
      e.example.   CLASS1      TYPE1           10.0.0.2

a. 例。 CLASS32 TYPE731\#6abcd(ef01 23 45)b.の例。 HS TYPE62347\#0e.の例。 IN A\#4 0A000001e.の例。 CLASS1 TYPE1 10.0.0、.2

6.  Equality Comparison

6. 平等比較

   Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
   to be compared for equality.  Two RRs of the same unknown type are
   considered equal when their RDATA is bitwise equal.  To ensure that
   the outcome of the comparison is identical whether the RR is known to
   the server or not, specifications for new RR types MUST NOT specify
   type-specific comparison rules.

あるDNSプロトコル(著しくダイナミック・アップデート[RFC2136])は、RRsが平等のために比較されるのを必要とします。 彼らのRDATAが同輩をbitwiseすることであるときに、同じ未知のタイプの2RRsが等しいと考えられます。 比較の結果が確実にRRがサーバに知られているか否かに関係なく、同じになるようにするために、新しいRRタイプへの仕様はタイプ特有の比較規則を指定してはいけません。

   This implies that embedded domain names, being included in the
   overall bitwise comparison, are compared in a case-sensitive manner.

これが、それがドメイン名を埋め込んだのを含意して、総合的に含まれているのは、比較をbitwiseして、大文字と小文字を区別する方法で比較されます。

   As a result, when a new RR type contains one or more embedded domain
   names, it is possible to have multiple RRs owned by the same name
   that differ only in the character case of the embedded domain
   name(s).  This is similar to the existing possibility of multiple TXT
   records differing only in character case, and not expected to cause
   any problems in practice.

新しいRRタイプが1つ以上の埋め込まれたドメイン名を含むとき、その結果、埋め込まれたドメイン名のキャラクタ事件だけにおいて異なるのと同じ名前で複数のRRsを所有させるのは可能です。 これは、キャラクタ事件だけにおいて異なる複数のTXT記録の既存の可能性と同様であり、実際にはどんな問題も引き起こさないと予想されます。

Gustafsson                  Standards Track                     [Page 4]

RFC 3597            Handling of Unknown DNS RR Types      September 2003

グスタファソンStandardsは2003年9月に未知のDNS RRタイプのRFC3597取り扱いを追跡します[4ページ]。

7.  DNSSEC Canonical Form and Ordering

7. DNSSEC標準形と注文

   DNSSEC defines a canonical form and ordering for RRs [RFC2535]
   (section 8.1).  In that canonical form, domain names embedded in the
   RDATA are converted to lower case.

DNSSECはRRs[RFC2535](セクション8.1)のために標準形と注文を定義します。 その標準形では、RDATAに埋め込まれたドメイン名は、ケースを下ろすために変換されます。

   The downcasing is necessary to ensure the correctness of DNSSEC
   signatures when case distinctions in domain names are lost due to
   compression, but since it requires knowledge of the presence and
   position of embedded domain names, it cannot be applied to unknown
   types.

ドメイン名におけるケース区別が圧縮のため失われているとき、downcasingがDNSSEC署名の正当性を確実にするのに必要ですが、存在に関する知識と埋め込まれたドメイン名の位置を必要とするので、未知のタイプにそれを適用できません。

   To ensure continued consistency of the canonical form of RR types
   where compression is allowed, and for continued interoperability with
   existing implementations that already implement the [RFC2535]
   canonical form and apply it to their known RR types, the canonical
   form remains unchanged for all RR types whose whose initial
   publication as an RFC was prior to the initial publication of this
   specification as an RFC (RFC 3597).

この仕様の初期の公表の前に、RFC(RFC3597)としてRFCとしての初期の公表があった圧縮が許されていて、既に[RFC2535]標準形を実装して、彼らの知られているRRタイプ、すべてに、変わりのない標準形の残りにそれを適用する既存の実装がある継続的な相互運用性のために、RRがだれのものをタイプするRRタイプの標準形の長引く一貫性を確実にするために。

   As a courtesy to implementors, it is hereby noted that the complete
   set of such previously published RR types that contain embedded
   domain names, and whose DNSSEC canonical form therefore involves
   downcasing according to the DNS rules for character comparisons,
   consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
   HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
   DNAME, and A6.

作成者への礼儀として、完全なそのようなものが以前に埋め込まれたドメイン名を含んで、したがってDNSSEC標準形がキャラクタ比較のためのDNS規則に従ってdowncasingすることを伴うRRタイプを発行して、RRタイプNS、MD、MF、CNAME、SOA、MB、MG、さん、PTR、HINFO、MINFO、Mx、HINFO、RP、AFSDB、RT、SIG、PX、NXT、NAPTR、KX、SRV、DNAME、およびA6から成ることにこれにより注意されます。

   This document specifies that for all other RR types (whether treated
   as unknown types or treated as known types according to an RR type
   definition RFC more recent than RFC 3597), the canonical form is such
   that no downcasing of embedded domain names takes place, and
   otherwise identical to the canonical form specified in [RFC2535]
   section 8.1.

このドキュメントは、埋め込まれたドメイン名のdowncasingでないのが他のすべてのRRタイプ(未知のタイプとして扱われるか、または知られているように扱われることにかかわらずRRに従ったタイプはRFC3597より最近の定義RFCをタイプする)において、標準形がそのようなものであるので場所で、そうでなければ、[RFC2535]セクション8.1で指定された標準形と同じ状態で取ると指定します。

   Note that the owner name is always set to lower case according to the
   DNS rules for character comparisons, regardless of the RR type.

存在という所有者名がいつもセットしたことに注意して、キャラクタ比較のためのDNS規則に応じて、RRタイプにかかわらずケースを下ろしてください。

   The DNSSEC canonical RR ordering is as specified in [RFC2535] section
   8.3, where the octet sequence is the canonical form as revised by
   this specification.

DNSSECの正準なRR注文は[RFC2535]セクション8.3でこの仕様で改訂されるのと同じくらい指定されます。そこでは、八重奏系列が標準形です。

8.  Additional Section Processing

8. 追加セクション処理

   Unknown RR types cause no additional section processing.  Future RR
   type specifications MAY specify type-specific additional section
   processing rules, but any such processing MUST be optional as it can
   only be performed by servers for which the RR type in case is known.

未知のRRタイプはどんな追加セクション処理も引き起こしません。 将来のRRタイプ仕様はタイプ特有の追加セクション処理規則を指定するかもしれませんが、そのようなどんな処理も、場合におけるRRタイプが知られているサーバでそれを実行できるだけであるので、任意であるに違いありません。

Gustafsson                  Standards Track                     [Page 5]

RFC 3597            Handling of Unknown DNS RR Types      September 2003

グスタファソンStandardsは2003年9月に未知のDNS RRタイプのRFC3597取り扱いを追跡します[5ページ]。

9.  IANA Considerations

9. IANA問題

   This document does not require any IANA actions.

このドキュメントは少しのIANA動作も必要としません。

10.  Security Considerations

10. セキュリティ問題

   This specification is not believed to cause any new security
   problems, nor to solve any existing ones.

どんな新しい警備上の問題も引き起こして、この仕様がどんな既存のものも解決すると信じられていません。

11.  Normative References

11. 引用規格

   [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
               Specifications", STD 13, RFC 1035, November 1987.

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

   [RFC1123]   Braden, R., Ed., "Requirements for Internet Hosts --
               Application and Support", STD 3, RFC 1123, October 1989.

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

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2535]   Eastlake, D., "Domain Name System Security Extensions",
               RFC 2535, March 1999.

[RFC2535] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。

   [RFC2163]   Allocchio, C., "Using the Internet DNS to Distribute
               MIXER Conformant Global Address Mapping (MCGAM)", RFC
               2163, January 1998.

[RFC2163] Allocchio、C.、「(MCGAM)を写像するミキサーConformantグローバルアドレスを分配するのにインターネットDNSを使用します」、RFC2163、1998年1月。

   [RFC2929]   Eastlake, D., Brunner-Williams, E. and B. Manning,
               "Domain Name System (DNS) IANA Considerations", BCP 42,
               RFC 2929, September 2000.

[RFC2929] イーストレークとD.とブルンナー-ウィリアムズとE.とB.マニング、「ドメインネームシステム(DNS)IANA問題」、BCP42、RFC2929、2000年9月。

12.  Informative References

12. 有益な参照

   [RFC1876]   Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
               Means for Expressing Location Information in the Domain
               Name System", RFC 1876, January 1996.

[RFC1876] デイヴィスとC.とVixieとP.とグッドウィンとT.とI.ディキンソン、「ドメインネームシステムにおける位置情報を言い表すための手段」、RFC1876、1996年1月。

   [RFC2052]   Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
               the location of services (DNS SRV)", RFC 2052, October
               1996.

[RFC2052]GulbrandsenとA.とP.Vixie、「サービス(DNS SRV)の位置を指定するためのDNS RR」、RFC2052、1996年10月。

   [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
               RFC 2136, April 1997.

[RFC2136]Vixie、P.(エド)とトムソンとS.とRekhterとY.とJ.バウンド、「ドメインネームシステム(DNSアップデート)におけるダイナミックなアップデート」RFC2136(1997年4月)。

Gustafsson                  Standards Track                     [Page 6]

RFC 3597            Handling of Unknown DNS RR Types      September 2003

グスタファソンStandardsは2003年9月に未知のDNS RRタイプのRFC3597取り扱いを追跡します[6ページ]。

   [RFC2782]   Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
               specifying the location of services (DNS SRV)", RFC 2782,
               February 2000.

[RFC2782]GulbrandsenとA.とVixieとP.とL.Esibov、「サービス(DNS SRV)の位置を指定するためのDNS RR」、RFC2782、2000年2月。

13.  Intellectual Property Statement

13. 知的所有権声明

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。

14.  Author's Address

14. 作者のアドレス

   Andreas Gustafsson
   Nominum, Inc.
   2385 Bay Rd
   Redwood City, CA 94063
   USA

アンドレアスグスタファソンNominum Inc.2385湾のカリフォルニア94063第レッドウッドシティー(米国)

   Phone: +1 650 381 6004
   EMail: gson@nominum.com

以下に電話をしてください。 +1 6004年の650 381メール: gson@nominum.com

Gustafsson                  Standards Track                     [Page 7]

RFC 3597            Handling of Unknown DNS RR Types      September 2003

グスタファソンStandardsは2003年9月に未知のDNS RRタイプのRFC3597取り扱いを追跡します[7ページ]。

15.  Full Copyright Statement

15. 完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Gustafsson                  Standards Track                     [Page 8]

グスタファソン標準化過程[8ページ]