RFC5001 日本語訳

Network Working Group                                         R. Austein
Request for Comments: 5001                                           ISC
Category: Standards Track                                    August 2007

Austeinがコメントのために要求するワーキンググループR.をネットワークでつないでください: 5001年のISCカテゴリ: 標準化過程2007年8月

                DNS Name Server Identifier (NSID) Option

DNSネームサーバ識別子(NSID)オプション

Status of This 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 IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

Abstract

要約

   With the increased use of DNS anycast, load balancing, and other
   mechanisms allowing more than one DNS name server to share a single
   IP address, it is sometimes difficult to tell which of a pool of name
   servers has answered a particular query.  While existing ad-hoc
   mechanisms allow an operator to send follow-up queries when it is
   necessary to debug such a configuration, the only completely reliable
   way to obtain the identity of the name server that responded is to
   have the name server include this information in the response itself.
   This note defines a protocol extension to support this functionality.

1つ以上のDNSネームサーバがただ一つのIPアドレスを共有できるDNS anycast、ロードバランシング、および他のメカニズムの増強された使用によって、言うのは時々難しいです(ネームサーバのプールについて特定の質問に答えました)。 そのような構成をデバッグするのが必要であるときに、オペレータが既存の臨時のメカニズムで追跡している質問を送ることができる間、応じたネームサーバのアイデンティティを得る唯一の完全に信頼できる方法はネームサーバに応答自体にこの情報を含ませることです。 この注意は、この機能性をサポートするためにプロトコル拡大を定義します。

Austein                     Standards Track                     [Page 1]

RFC 5001                        DNS NSID                     August 2007

Austein規格はDNS NSID2007年8月にRFC5001を追跡します[1ページ]。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Resolver Behavior  . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Name Server Behavior . . . . . . . . . . . . . . . . . . .  3
     2.3.  The NSID Option  . . . . . . . . . . . . . . . . . . . . .  4
     2.4.  Presentation Format  . . . . . . . . . . . . . . . . . . .  4
   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  The NSID Payload . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  NSID Is Not Transitive . . . . . . . . . . . . . . . . . .  7
     3.3.  User Interface Issues  . . . . . . . . . . . . . . . . . .  7
     3.4.  Truncation . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 リザーブドワード. . . . . . . . . . . . . . . . . . . . . . 3 2。 .32.1について議定書の中で述べてください。 レゾルバの振舞い. . . . . . . . . . . . . . . . . . . . 3 2.2。 ネームサーバの振舞い. . . . . . . . . . . . . . . . . . . 3 2.3。 NSIDオプション. . . . . . . . . . . . . . . . . . . . . 4 2.4。 プレゼンテーション形式. . . . . . . . . . . . . . . . . . . 4 3。 議論. . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1。 NSID有効搭載量. . . . . . . . . . . . . . . . . . . . . 4 3.2。 NSIDは他動詞. . . . . . . . . . . . . . . . . . 7 3.3ではありません。 ユーザーインタフェースは.73.4を発行します。 トランケーション. . . . . . . . . . . . . . . . . . . . . . . . 8 4。 IANA問題. . . . . . . . . . . . . . . . . . . . . 8 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 9 6。 承認. . . . . . . . . . . . . . . . . . . . . . . 9 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 9 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 10

1.  Introduction

1. 序論

   With the increased use of DNS anycast, load balancing, and other
   mechanisms allowing more than one DNS name server to share a single
   IP address, it is sometimes difficult to tell which of a pool of name
   servers has answered a particular query.

1つ以上のDNSネームサーバがただ一つのIPアドレスを共有できるDNS anycast、ロードバランシング、および他のメカニズムの増強された使用によって、言うのは時々難しいです(ネームサーバのプールについて特定の質問に答えました)。

   Existing ad-hoc mechanisms allow an operator to send follow-up
   queries when it is necessary to debug such a configuration, but there
   are situations in which this is not a totally satisfactory solution,
   since anycast routing may have changed, or the server pool in
   question may be behind some kind of extremely dynamic load balancing
   hardware.  Thus, while these ad-hoc mechanisms are certainly better
   than nothing (and have the advantage of already being deployed), a
   better solution seems desirable.

そのような構成をデバッグするのが必要ですが、これが完全に満足できるソリューションであるというわけではない状況があるとき、オペレータは既存の臨時のメカニズムで追跡している質問を送ることができます、anycastルーティングが変化したかもしれないか、またはある種の非常にダイナミックなロードバランシングハードウェアの後ろに問題のサーバプールがあるかもしれないので。 したがって、これらの臨時のメカニズムは確かにないよりましですが(既に配布される利点を持ってください)、より良いソリューションは望ましく思えます。

   Given that a DNS query is an idempotent operation with no retained
   state, it would appear that the only completely reliable way to
   obtain the identity of the name server that responded to a particular
   query is to have that name server include identifying information in
   the response itself.  This note defines a protocol enhancement to
   achieve this.

DNS質問が保有された状態がなければベキ等元操作であるなら、特定の質問に応じたネームサーバのアイデンティティを得る唯一の完全に信頼できる方法がそのネームサーバに応答自体に身元が分かる情報を含ませることであるように見えるでしょう。 この注意は、これを達成するためにプロトコル増進を定義します。

Austein                     Standards Track                     [Page 2]

RFC 5001                        DNS NSID                     August 2007

Austein規格はDNS NSID2007年8月にRFC5001を追跡します[2ページ]。

1.1.  Reserved Words

1.1. リザーブドワード

   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 [RFC2119].

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

2.  Protocol

2. プロトコル

   This note uses an EDNS [RFC2671] option to signal the resolver's
   desire for information identifying the name server and to hold the
   name server's response, if any.

この注意は、ネームサーバを特定する情報、もしあればネームサーバの応答を保持するリゾルバの願望に合図するのにEDNS[RFC2671]オプションを使用します。

2.1.  Resolver Behavior

2.1. レゾルバの振舞い

   A resolver signals its desire for information identifying a name
   server by sending an empty NSID option (Section 2.3) in an EDNS OPT
   pseudo-RR in the query message.

レゾルバは質問メッセージのEDNS OPT疑似RRで(セクション2.3)を空のNSIDオプションに送ることによってネームサーバを特定する情報に関する願望に合図します。

   The resolver MUST NOT include any NSID payload data in the query
   message.

レゾルバは質問メッセージの少しのNSIDペイロードデータも入れてはいけません。

   The semantics of an NSID request are not transitive.  That is: the
   presence of an NSID option in a query is a request that the name
   server which receives the query identify itself.  If the name server
   side of a recursive name server receives an NSID request, the client
   is asking the recursive name server to identify itself; if the
   resolver side of the recursive name server wishes to receive
   identifying information, it is free to add NSID requests in its own
   queries, but that is a separate matter.

NSID要求の意味論は遷移的ではありません。 それは以下の通りです。 質問における、NSIDオプションの存在は質問を受けるネームサーバがそれ自体を特定するという要求です。 再帰的なネームサーバのネームサーバ側がNSID要求を受け取るなら、クライアントは、それ自体を特定するように再帰的なネームサーバに頼んでいます。 再帰的なネームサーバのレゾルバ側が身元が分かる情報を受け取りたいなら、自由にそれ自身の質問におけるNSID要求を加えることができますが、それは別々の問題です。

2.2.  Name Server Behavior

2.2. ネームサーバの振舞い

   A name server that understands the NSID option and chooses to honor a
   particular NSID request responds by including identifying information
   in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR in the
   response message.

NSIDオプションを理解して、特定のNSID要求を光栄に思うのを選ぶネームサーバは、EDNS OPT疑似RRのNSIDオプション(セクション2.3)に応答メッセージで身元が分かる情報を含んでいることによって、応じます。

   The name server MUST ignore any NSID payload data that might be
   present in the query message.

ネームサーバはどんな質問メッセージに存在するかもしれないNSIDペイロードデータも無視しなければなりません。

   The NSID option is not transitive.  A name server MUST NOT send an
   NSID option back to a resolver which did not request it.  In
   particular, while a recursive name server may choose to add an NSID
   option when sending a query, this has no effect on the presence or
   absence of the NSID option in the recursive name server's response to
   the original client.

NSIDオプションは遷移的ではありません。 ネームサーバはレゾルバへのそれを要求しなかったNSIDオプションを送ってはいけません。 再帰的なネームサーバは、質問を送るとき、NSIDオプションを加えるのを選ぶかもしれませんが、特に、これはオリジナルのクライアントへの再帰的なネームサーバの応答における、NSIDオプションの存在か欠如のときに効き目がありません。

Austein                     Standards Track                     [Page 3]

RFC 5001                        DNS NSID                     August 2007

Austein規格はDNS NSID2007年8月にRFC5001を追跡します[3ページ]。

   As stated in Section 2.1, this mechanism is not restricted to
   authoritative name servers; the semantics are intended to be equally
   applicable to recursive name servers.

セクション2.1に述べられているように、このメカニズムは正式のネームサーバに制限されません。 意味論が等しく再帰的なネームサーバに適切であることを意図します。

2.3.  The NSID Option

2.3. NSIDオプション

   The OPTION-CODE for the NSID option is 3.

NSIDオプションのためのOPTION-CODEは3歳です。

   The OPTION-DATA for the NSID option is an opaque byte string, the
   semantics of which are deliberately left outside the protocol.  See
   Section 3.1 for discussion.

NSIDオプションのためのOPTION-DATAは不透明なバイトストリングです。それの意味論は故意にプロトコルの外で残されます。 議論に関してセクション3.1を見てください。

2.4.  Presentation Format

2.4. プレゼンテーション形式

   User interfaces MUST read and write the contents of the NSID option
   as a sequence of hexadecimal digits, two digits per payload octet.

ユーザインタフェースは16進数字(ペイロード八重奏あたり2ケタ)の系列としてNSIDオプションのコンテンツを読み書きしなければなりません。

   The NSID payload is binary data.  Any comparison between NSID
   payloads MUST be a comparison of the raw binary data.  Copy
   operations MUST NOT assume that the raw NSID payload is null-
   terminated.  Any resemblance between raw NSID payload data and any
   form of text is purely a convenience, and does not change the
   underlying nature of the payload data.

NSIDペイロードはバイナリ・データです。 NSIDペイロードでのどんな比較も生のバイナリ・データの比較であるに違いありません。 コピー操作は、生のNSIDペイロードが終えられた状態でヌルであると仮定してはいけません。 生のNSIDペイロードデータとテキストのどんなフォームの間のどんな類似も、純粋に便利であり、ペイロードデータの基本的な本質を変えません。

   See Section 3.3 for discussion.

議論に関してセクション3.3を見てください。

3.  Discussion

3. 議論

   This section discusses certain aspects of the protocol and explains
   considerations that led to the chosen design.

このセクションは、プロトコルのある一定の局面について論じて、選ばれたデザインにつながった問題について説明します。

3.1.  The NSID Payload

3.1. NSID有効搭載量

   The syntax and semantics of the content of the NSID option are
   deliberately left outside the scope of this specification.

NSIDオプションの内容の構文と意味論は故意にこの仕様の範囲の外に残されます。

   Choosing the NSID content is a prerogative of the server
   administrator.  The server administrator might choose to encode the
   NSID content in such a way that the server operator (or clients
   authorized by the server operator) can decode the NSID content to
   obtain more information than other clients can.  Alternatively, the
   server operator might choose unencoded NSID content that is equally
   meaningful to any client.

NSID内容を選ぶのは、サーバアドミニストレータの特権です。 サーバアドミニストレータは、サーバオペレータ(または、サーバオペレータによって権限を与えられたクライアント)が他のクライアントより多くの情報を得るためにNSID内容を解読できる方法がそうすることができるそのようなものでNSID内容をコード化するのを選ぶかもしれません。 あるいはまた、サーバオペレータはどんなクライアントにも、等しく重要な暗号化されていないNSID内容を選ぶかもしれません。

   This section describes some of the kinds of data that server
   administrators might choose to provide as the content of the NSID
   option, and explains the reasoning behind specifying a simple opaque
   byte string in Section 2.3.

このセクションは、サーバアドミニストレータがNSIDオプションの内容として提供するのを選ぶかもしれないデータの数種類について説明して、セクション2.3で簡単な不透明なバイトストリングを指定する後ろで推理について説明します。

Austein                     Standards Track                     [Page 4]

RFC 5001                        DNS NSID                     August 2007

Austein規格はDNS NSID2007年8月にRFC5001を追跡します[4ページ]。

   There are several possibilities for the payload of the NSID option:

NSIDオプションのペイロードのためのいくつかの可能性があります:

   o  It could be the "real" name of the specific name server within the
      name server pool.

o それはネームサーバプールの中の種名サーバの「本当」の名前であるかもしれません。

   o  It could be the "real" IP address (IPv4 or IPv6) of the name
      server within the name server pool.

o それはネームサーバプールの中のネームサーバの「本当」のIPアドレスであるかもしれません(IPv4かIPv6)。

   o  It could be some sort of pseudo-random number generated in a
      predictable fashion somehow using the server's IP address or name
      as a seed value.

o それは種子値としてどうにかサーバのIPアドレスか名前を使用しながら予測できるファッションで生成されたある種の擬似乱数であるかもしれません。

   o  It could be some sort of probabilistically unique identifier
      initially derived from some sort of random number generator then
      preserved across reboots of the name server.

o それは初めはある種の乱数発生器から次に、ネームサーバのリブートの向こう側に保存されていた状態で得られたある種のprobabilisticallyにユニークな識別子であるかもしれません。

   o  It could be some sort of dynamically generated identifier so that
      only the name server operator could tell whether or not any two
      queries had been answered by the same server.

o それは、ネームサーバオペレータだけが、何か2つの質問が同じサーバによって答えられていたかどうか言うことができるためのある種のダイナミックに生成している識別子であるかもしれません。

   o  It could be a blob of signed data, with a corresponding key which
      might (or might not) be available via DNS lookups.

o または、それは署名しているデータの一滴であるかもしれません、対応するそうするかもしれないキーで()、DNSルックアップで利用可能であるかもしれなくなってください。

   o  It could be a blob of encrypted data, the key for which could be
      restricted to parties with a need to know (in the opinion of the
      server operator).

o 暗号化されたデータの一滴、キーがどれがあることができるように知る(サーバオペレータの意見で)必要性があるパーティーに制限されているかなら、それはそうすることができるでしょうに。

   o  It could be an arbitrary string of octets chosen at the discretion
      of the name server operator.

o それはネームサーバオペレータの裁量で選ばれた八重奏の任意のストリングであるかもしれません。

   Each of these options has advantages and disadvantages:

それぞれのこれらのオプションには、利点と損失があります:

   o  Using the "real" name is simple, but the name server may not have
      a "real" name.

o 「本当」の名前を使用するのは簡単ですが、ネームサーバには、「本当」の名前がないかもしれません。

   o  Using the "real" address is also simple, and the name server
      almost certainly does have at least one non-anycast IP address for
      maintenance operations, but the operator of the name server may
      not be willing to divulge its non-anycast address.

o また、「本当」のアドレスを使用するのも簡単です、そして、ネームサーバには、メインテナンス操作のための少なくとも1つの非anycast IPアドレスがほぼ確実にありますが、ネームサーバのオペレータは非anycastアドレスを明かすことを望んでいないかもしれません。

   o  Given that one common reason for using anycast DNS techniques is
      an attempt to harden a critical name server against denial of
      service attacks, some name server operators are likely to want an
      identifier other than the "real" name or "real" address of the
      name server instance.

o anycast DNSのテクニックを使用する1つの一般的な理由がサービス不能攻撃に対して重要なネームサーバを堅くする試みであるなら、何人かのネームサーバオペレータがネームサーバインスタンスの「本当」の名前か「本当」のアドレス以外の識別子が欲しそうです。

   o  Using a hash or pseudo-random number can provide a fixed length
      value that the resolver can use to tell two name servers apart

o ハッシュか擬似乱数を使用すると、レゾルバが2つのネームサーバより見分けるのに使用できる固定長値を提供できます。

Austein                     Standards Track                     [Page 5]

RFC 5001                        DNS NSID                     August 2007

Austein規格はDNS NSID2007年8月にRFC5001を追跡します[5ページ]。

      without necessarily being able to tell where either one of them
      "really" is, but makes debugging more difficult if one happens to
      be in a friendly open environment.  Furthermore, hashing might not
      add much value, since a hash based on an IPv4 address still only
      involves a 32-bit search space, and DNS names used for servers
      that operators might have to debug at 4am tend not to be very
      random.

必ずそれらのどちらかが「本当に」ありますが、デバッグをするところで言うことができる存在がなければ、より難しいのが1であるならたまたま好意的なオープンな環境にあります。 その上、論じ尽くすのは多くの価値を高めないかもしれません、まだIPv4アドレスに基づいているハッシュだけが32ビットの検索スペースにかかわって、オペレータが午前4時にデバッグしなければならないかもしれないサーバに使用されるDNS名が、それほど無作為でない傾向があるので。

   o  Probabilistically unique identifiers have properties similar to
      hashed identifiers, but (given a sufficiently good random number
      generator) are immune to the search space issues.  However, the
      strength of this approach is also its weakness: there is no
      algorithmic transformation by which even the server operator can
      associate name server instances with identifiers while debugging,
      which might be annoying.  This approach also requires the name
      server instance to preserve the probabilistically unique
      identifier across reboots, but this does not appear to be a
      serious restriction, since authoritative nameservers almost always
      have some form of non-volatile storage.  In the rare case of a
      name server that does not have any way to store such an
      identifier, nothing terrible will happen if the name server
      generates a new identifier every time it reboots.

o Probabilisticallyにユニークな識別子は、論じ尽くされた識別子と同様の特性を持っていますが、検索スペース問題に免疫です(十分良い乱数発生器を与えます)。 しかしながら、また、このアプローチの強さは弱点です: サーバオペレータさえデバッグしている間にネームサーバインスタンスを識別子に関連づけることができる(煩わしいかもしれません)どんなアルゴリズムの変換もありません。 また、このアプローチはリブートの向こう側にprobabilisticallyにユニークな識別子を保存するためにネームサーバインスタンスを必要としますが、これは重大な制限であるように見えません、正式のネームサーバには何らかのフォームの非揮発性記憶装置がほとんどいつもあるので。 そのような識別子を保存する少しの方法も持っていないネームサーバのまれなケースでは、リブートするときはいつも、ネームサーバが新しい識別子を生成すると、ひどいものは何も起こらないでしょう。

   o  Using an arbitrary octet string gives name server operators yet
      another setting to configure, or mis-configure, or forget to
      configure.  Having all the nodes in an anycast name server
      constellation identify themselves as "My Name Server" would not be
      particularly useful.

o 忘れてください。または、任意の八重奏ストリングを使用すると構成するさらに別の設定をネームサーバオペレータに与える、誤、構成、構成します。 anycastネームサーバ星座のすべてのノードに自分たちが「私のネームサーバ」であると認識させるのは、特に役に立たないでしょう。

   o  A signed blob is not particularly useful as an NSID payload unless
      the signed data is dynamic and includes some kind of replay
      protection, such as a timestamp or some kind of data identifying
      the requestor.  Signed blobs that meet these criteria could
      conceivably be useful in some situations but would require
      detailed security analysis beyond the scope of this document.

o 署名しているデータがダイナミックであり、ある種の反復操作による保護を含んでいない場合、署名している一滴はNSIDペイロードとして特に役に立ちません、要請者を特定するタイムスタンプかある種のデータなどのように。 これらの評価基準を満たす署名している一滴が、多分いくつかの状況で役に立つかもしれませんが、このドキュメントの範囲を超えて詳細な証券分析を必要とするでしょう。

   o  A static encrypted blob would not be particularly useful, as it
      would be subject to replay attacks and would, in effect, just be a
      random number to any party that does not possess the decryption
      key.  Dynamic encrypted blobs could conceivably be useful in some
      situations but, as with signed blobs, dynamic encrypted blobs
      would require detailed security analysis beyond the scope of this
      document.

o 静的な暗号化された一滴は特に役に立たないでしょう、それが、反射攻撃を受けることがあって、事実上、まさしく復号化キーを所有していないどんなパーティーへの乱数でしょう、したがって。 ダイナミックな暗号化された一滴は多分いくつかの状況で役に立つかもしれませんが、署名している一滴なら、ダイナミックな暗号化された一滴はこのドキュメントの範囲を超えて詳細な証券分析を必要とするでしょう。

   Given all of the issues listed above, there does not appear to be a
   single solution that will meet all needs.  Section 2.3 therefore
   defines the NSID payload to be an opaque byte string and leaves the
   choice of payload up to the implementor and name server operator.

上に記載された問題のすべてを考えて、すべての需要を満たすただ一つのソリューションはあるように見えません。 セクション2.3は、したがって、不透明なバイトストリングになるようにNSIDペイロードを定義して、作成者とネームサーバオペレータにペイロードの選択を任せます。

Austein                     Standards Track                     [Page 6]

RFC 5001                        DNS NSID                     August 2007

Austein規格はDNS NSID2007年8月にRFC5001を追跡します[6ページ]。

   The following guidelines may be useful to implementors and server
   operators:

以下のガイドラインは作成者とサーバオペレータの役に立つかもしれません:

   o  Operators for whom divulging the unicast address is an issue could
      use the raw binary representation of a probabilistically unique
      random number.  This should probably be the default implementation
      behavior.

o ユニキャストアドレスを明かすのが、問題であるオペレータはprobabilisticallyにユニークな乱数の生の2進法表示を使用できました。 これはたぶんデフォルト実装の振舞いであるべきです。

   o  Operators for whom divulging the unicast address is not an issue
      could just use the raw binary representation of a unicast address
      for simplicity.  This should only be done via an explicit
      configuration choice by the operator.

o ユニキャストアドレスを明かすのが、問題でないオペレータは簡単さにただユニキャストアドレスの生の2進法表示を使用できました。 オペレータによる明白な構成選択でこれをするだけであるべきです。

   o  Operators who really need or want the ability to set the NSID
      payload to an arbitrary value could do so, but this should only be
      done via an explicit configuration choice by the operator.

o 本当に任意の値にNSIDペイロードを設定する能力が必要である、または欲しいオペレータはそうすることができましたが、オペレータによる明白な構成選択でこれをするだけであるべきです。

   This approach appears to provide enough information for useful
   debugging without unintentionally leaking the maintenance addresses
   of anycast name servers to nogoodniks, while also allowing name
   server operators who do not find such leakage threatening to provide
   more information at their own discretion.

このアプローチはまた、そのような漏出が、一存で詳しい情報を提供すると脅かしているのがわからないネームサーバオペレータを許容している間、anycastネームサーバのメインテナンスアドレスを役立たずに何気なく漏らさないで役に立つデバッグのための十分な情報を提供するように見えます。

3.2.  NSID Is Not Transitive

3.2. NSIDは遷移的ではありません。

   As specified in Section 2.1 and Section 2.2, the NSID option is not
   transitive.  This is strictly a hop-by-hop mechanism.

セクション2.1とセクション2.2で指定されるように、NSIDオプションは遷移的ではありません。 これによる厳密に、aがホップでメカニズムに飛び乗るということです。

   Most of the discussion of name server identification to date has
   focused on identifying authoritative name servers, since the best
   known cases of anycast name servers are a subset of the name servers
   for the root zone.  However, given that anycast DNS techniques are
   also applicable to recursive name servers, the mechanism may also be
   useful with recursive name servers.  The hop-by-hop semantics support
   this.

これまでのネームサーバ識別の議論の大部分は、正式のネームサーバを特定するのは焦点を合わせました、anycastネームサーバの最もよく知られているケースがルートゾーンへのネームサーバの部分集合であるので。 しかしながら、また、anycast DNSのテクニックも再帰的なネームサーバに適切であるなら、また、メカニズムも再帰的なネームサーバによって役に立つかもしれません。 ホップごとの意味論はこれをサポートします。

   While there might be some utility in having a transitive variant of
   this mechanism (so that, for example, a stub resolver could ask a
   recursive server to tell it which authoritative name server provided
   a particular answer to the recursive name server), the semantics of
   such a variant would be more complicated, and are left for future
   work.

このメカニズムの遷移的な異形を持つのにおいて何らかのユーティリティがあるかもしれない間(例えば、スタッブレゾルバが、どの正式のネームサーバが再帰的なネームサーバの特定の答えを提供したかそれに言うように再帰的なサーバに頼むことができるように)、そのような異形の意味論は、より複雑であるだろう、今後の活動に残されます。

3.3.  User Interface Issues

3.3. ユーザーインタフェース問題

   Given the range of possible payload contents described in
   Section 3.1, it is not possible to define a single presentation
   format for the NSID payload that is efficient, convenient,

セクション3.1で説明された可能なペイロードコンテンツの範囲を考えて、効率的なNSIDペイロードのためのただ一つのプレゼンテーション書式を定義するのは可能ではありません、便利です。

Austein                     Standards Track                     [Page 7]

RFC 5001                        DNS NSID                     August 2007

Austein規格はDNS NSID2007年8月にRFC5001を追跡します[7ページ]。

   unambiguous, and aesthetically pleasing.  In particular, while it is
   tempting to use a presentation format that uses some form of textual
   strings, attempting to support this would significantly complicate
   what's intended to be a very simple debugging mechanism.

明白であって、美しく微笑ましいです。 特に、何らかの形式の原文のストリングを使用するプレゼンテーション形式を使用するのに誘惑している間、これをサポートするのを試みるのが非常に簡単なデバッグメカニズムであることを意図したことをかなり複雑にするでしょう。

   In some cases the content of the NSID payload may be binary data
   meaningful only to the name server operator, and may not be
   meaningful to the user or application, but the user or application
   must be able to capture the entire content anyway in order for it to
   be useful.  Thus, the presentation format must support arbitrary
   binary data.

いくつかの場合、NSIDペイロードの内容は、ネームサーバオペレータだけに、重要なバイナリ・データであるかもしれなく、ユーザかアプリケーションに重要でないかもしれませんが、ユーザかアプリケーションが、それが役に立つようにとにかく全体の内容を得ることができなければなりません。 したがって、プレゼンテーション形式は任意のバイナリ・データをサポートしなければなりません。

   In cases where the name server operator derives the NSID payload from
   textual data, a textual form such as US-ASCII or UTF-8 strings might
   at first glance seem easier for a user to deal with.  There are,
   however, a number of complex issues involving internationalized text
   which, if fully addressed here, would require a set of rules
   significantly longer than the rest of this specification.  See
   [RFC2277] for an overview of some of these issues.

ネームサーバオペレータがNSIDペイロードに原文のデータに由来している場合では、米国-ASCIIかUTF-8ストリングなどの原文のフォームは一見したところではユーザが対処するのが、より簡単に見えるかもしれません。 しかしながら、ここで完全に扱われるならこの仕様の残りよりかなり長い規則をセットに要求する国際化しているテキストにかかわる多くの複雑な問題があります。 これらの問題のいくつかの概要に関して[RFC2277]を見てください。

   It is much more important for the NSID payload data to be passed
   unambiguously from server administrator to user and back again than
   it is for the payload data to be pretty while in transit.  In
   particular, it's critical that it be straightforward for a user to
   cut and paste an exact copy of the NSID payload output by a debugging
   tool into other formats such as email messages or web forms without
   distortion.  Hexadecimal strings, while ugly, are also robust.

ペイロードデータがトランジットにはある間、きれいであることは、NSIDペイロードデータが明白にサーバアドミニストレータからユーザまでそれより行き帰り通過されるのが、ことであるはるかに重要です。 デバッグ用ツールによってひずみなしでメールメッセージかウェブフォームなどの他の形式に出力されて、切るユーザにとって簡単であり、NSIDペイロードの正確なコピーを貼るのは、特に、重要です。 醜いのですが、また、16進ストリングも強健です。

3.4.  Truncation

3.4. トランケーション

   In some cases, adding the NSID option to a response message may
   trigger message truncation.  This specification does not change the
   rules for DNS message truncation in any way, but implementors will
   need to pay attention to this issue.

いくつかの場合、NSIDオプションを応答メッセージに追加すると、メッセージトランケーションは引き金となるかもしれません。 この仕様はDNSメッセージトランケーションのために何らかの方法で規則を変えませんが、作成者は、この問題に注意を向ける必要があるでしょう。

   Including the NSID option in a response is always optional, so this
   specification never requires name servers to truncate response
   messages.

応答におけるNSIDオプションを含んでいるのがいつも任意であるので、この仕様は応答メッセージに先端を切らせるためにネームサーバを決して必要としません。

   By definition, a resolver that requests NSID responses also supports
   EDNS, so a resolver that requests NSID responses can also use the
   "sender's UDP payload size" field of the OPT pseudo-RR to signal a
   receive buffer size large enough to make truncation unlikely.

また、定義上、NSID応答を要求するレゾルバがEDNSをサポートするので、また、NSID応答を要求するレゾルバはトランケーションをありそうもなくすると十分大きい受信バッファサイズに合図するOPT疑似RRの「送付者のUDPペイロードサイズ」分野を使用できます。

4.  IANA Considerations

4. IANA問題

   IANA has allocated EDNS option code 3 for the NSID option
   (Section 2.3).

IANAはNSIDオプション(セクション2.3)のためにEDNSオプションコード3を割り当てました。

Austein                     Standards Track                     [Page 8]

RFC 5001                        DNS NSID                     August 2007

Austein規格はDNS NSID2007年8月にRFC5001を追跡します[8ページ]。

5.  Security Considerations

5. セキュリティ問題

   This document describes a channel signaling mechanism intended
   primarily for debugging.  Channel signaling mechanisms are outside
   the scope of DNSSEC, per se.  Applications that require integrity
   protection for the data being signaled will need to use a channel
   security mechanism such as TSIG [RFC2845].

このドキュメントは主としてデバッグのために意図するチャンネルシグナル伝達機構について説明します。 そういうもののDNSSECの範囲の外にチャンネルシグナル伝達機構があります。 合図されるデータのための保全保護を必要とするアプリケーションは、TSIG[RFC2845]などのチャンネルセキュリティー対策を使用する必要があるでしょう。

   Section 3.1 discusses a number of different kinds of information that
   a name server operator might choose to provide as the value of the
   NSID option.  Some of these kinds of information are security
   sensitive in some environments.  This specification deliberately
   leaves the syntax and semantics of the NSID option content up to the
   implementation and the name server operator.

セクション3.1はネームサーバオペレータが、NSIDオプションの値として提供するのを選ぶかもしれないという多くの異種の情報について論じます。 情報のこれらの数種類はいくつかの環境で敏感なセキュリティです。 この仕様は故意に実装とネームサーバオペレータにNSIDの構文と意味論をオプション内容に任せます。

   Two of the possible kinds of payload data discussed in Section 3.1
   involve a digital signature and encryption, respectively.  While this
   specification discusses some of the pitfalls that might lurk for
   careless users of these kinds of payload data, full analysis of the
   issues that would be involved in these kinds of payload data would
   require knowledge of the content to be signed or encrypted,
   algorithms to be used, and so forth, which is beyond the scope of
   this document.  Implementors should seek competent advice before
   attempting to use these kinds of NSID payloads.

セクション3.1で議論した可能な種類に関する2つのペイロードデータがそれぞれデジタル署名と暗号化にかかわります。 この仕様がこれらの種類に関するペイロードデータの不注意なユーザのために潜むかもしれない落とし穴のいくつかについて議論している間、これらの種類に関するペイロードデータにかかわる問題の完全な分析はこのドキュメントの範囲にある署名するべきであるか、または暗号化されるべき内容、使用されるべきアルゴリズムなどに関する知識を必要とするでしょう。 作成者はこれらの種類のNSIDペイロードを使用するのを試みる前に、十分なアドバイスを求めるべきです。

6.  Acknowledgements

6. 承認

   Thanks to: Joe Abley, Harald Alvestrand, Dean Anderson, Mark Andrews,
   Roy Arends, Steve Bellovin, Alex Bligh, Randy Bush, David Conrad,
   John Dickinson, Alfred Hoenes, Johan Ihren, Daniel Karrenberg, Peter
   Koch, William Leibzon, Ed Lewis, Thomas Narten, Mike Patton, Geoffrey
   Sisson, Andrew Sullivan, Mike StJohns, Tom Taylor, Paul Vixie, Sam
   Weiler, and Suzanne Woolf, none of whom are responsible for what the
   author did with their comments and suggestions.  Apologies to anyone
   inadvertently omitted from the above list.

以下のことのためにありがとうございます。 ジョーAbley、ハラルドAlvestrand、ディーン・アンダーソン、マーク・アンドリュース、ロイArends、スティーブBellovin、アレックスBligh、ランディ・ブッシュ、デヴィッド・コンラッド、ジョン・ディッキンソン、アルフレッドHoenes、ジョハンIhren、ダニエルKarrenberg、ピーター・コッホ、ウィリアムLeibzon、Ed Lewis、トーマスNarten、マイク・パットン、ジェフリー・シスン、アンドリュー・サリバン、マイクStJohns、トム・テイラー、ポールVixie、サム・ウィーラー、およびスザンヌ・ウルフ。そのいずれも作者が彼らのコメントと提案でしたことに原因となりません。 上記のリストからうっかり省略された人はだれへのも謝罪。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

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

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

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, August 1999.

[RFC2671] Vixie、P.、「DNS(EDNS0)のための拡張機能」、RFC2671、1999年8月。

Austein                     Standards Track                     [Page 9]

RFC 5001                        DNS NSID                     August 2007

Austein規格はDNS NSID2007年8月にRFC5001を追跡します[9ページ]。

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, May 2000.

[RFC2845]Vixie(P.、グドムンソン、O.、イーストレーク3番目、D.、およびB.ウェリントン、「DNS(TSIG)のための秘密鍵トランザクション認証」、RFC2845)は2000がそうするかもしれません。

7.2.  Informative References

7.2. 有益な参照

   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
              Languages", RFC 2277, BCP 18, January 1998.

[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、RFC2277、BCP18、1998年1月。

Author's Address

作者のアドレス

   Rob Austein
   ISC
   950 Charter Street
   Redwood City, CA  94063
   USA

ロブAustein ISC950憲章通りカリフォルニア94063レッドウッドシティー(米国)

   EMail: sra@isc.org

メール: sra@isc.org

Austein                     Standards Track                    [Page 10]

RFC 5001                        DNS NSID                     August 2007

Austein規格はDNS NSID2007年8月にRFC5001を追跡します[10ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

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

Acknowledgement

承認

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

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

Austein                     Standards Track                    [Page 11]

Austein標準化過程[11ページ]