[要約] RFC 5001は、DNSのNSIDオプションに関する仕様であり、DNSサーバーの識別子を提供するためのものです。目的は、DNSサーバーの特定と追跡を容易にすることです。
Network Working Group R. Austein
Request for Comments: 5001 ISC
Category: Standards Track August 2007
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
DNS Anycast、ロードバランシング、およびその他のメカニズムの使用が増加し、複数のDNS Name Serverが単一のIPアドレスを共有できるようにするため、名前サーバーのプールが特定のクエリに応答したものを伝えるのが難しい場合があります。既存のアドホックメカニズムにより、オペレーターはそのような構成をデバッグする必要がある場合にフォローアップクエリを送信できますが、応答した名前サーバーのアイデンティティを取得するための完全に信頼できる唯一の方法は、この情報をこの情報に含めることです。応答自体。このメモは、この機能をサポートするプロトコル拡張機能を定義しています。
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
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.
DNS Anycast、ロードバランシング、およびその他のメカニズムの使用が増加し、複数のDNS Name Serverが単一のIPアドレスを共有できるようにするため、名前サーバーのプールが特定のクエリに応答したものを伝えるのが難しい場合があります。
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.
既存のアドホックメカニズムにより、オペレーターはそのような構成をデバッグする必要がある場合にフォローアップクエリを送信できますが、これは完全に満足のいくソリューションではない状況があります。質問は、ある種の非常に動的な負荷分散ハードウェアの背後にあるかもしれません。したがって、これらのアドホックメカニズムは確かに何もないよりも優れていますが（すでに展開されているという利点があります）、より良いソリューションが望ましいと思われます。
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クエリが保持された状態のないiDempotent操作であることを考えると、特定のクエリに応答した名前サーバーのIDを取得する唯一の完全に信頼できる方法は、その名前サーバーに応答自体の識別情報を含めることです。このメモは、これを達成するためのプロトコルの強化を定義しています。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
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]オプションを使用して、名前サーバーを識別する情報に対するリゾルバーの欲求を知らせ、名前サーバーの応答を保持します。
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.
Resolverは、クエリメッセージのEDNS Opt Pseudo-RRに空のNSIDオプション（セクション2.3）を送信することにより、名前サーバーを識別する情報に対する要望を示しています。
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リクエストを無料で追加できますが、それは別の問題です。
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 Pseudo-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オプションの存在または不在に影響しません。
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で述べたように、このメカニズムは権威ある名前サーバーに限定されていません。セマンティクスは、再帰的な名前サーバーに等しく適用できることを目的としています。
The OPTION-CODE for the NSID option is 3.
NSIDオプションのオプションコードは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オプションのオプションデータは不透明なバイト文字列で、そのセマンティクスは意図的にプロトコルの外側に残されています。ディスカッションについては、セクション3.1を参照してください。
User interfaces MUST read and write the contents of the NSID option as a sequence of hexadecimal digits, two digits per payload octet.
ユーザーインターフェイスは、NSIDオプションのコンテンツを16進数桁、ペイロードオクテットごとに2桁として読み書きする必要があります。
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を参照してください。
This section discusses certain aspects of the protocol and explains considerations that led to the chosen design.
このセクションでは、プロトコルの特定の側面について説明し、選択したデザインにつながった考慮事項について説明します。
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で単純な不透明なバイト文字列を指定する理由を説明します。
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 それは、最初に何らかの乱数ジェネレーターから派生したある種の確率的に一意の識別子であり、その後、名前サーバーの再起動全体に保存されている可能性があります。
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
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つの非アニカストIPアドレスがありますが、名前サーバーのオペレーターは、非アニカストアドレスを漏らすことをいとわない場合があります。
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 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.
o ハッシュまたは擬似ランダム番号を使用すると、リゾルバーが「本当に」のいずれかがどこにあるかを必ずしも通知することなく、2つの名前サーバーを際立たせるために使用できる固定された長さの値を提供できますが、たまたま偶然にデバッグを難しくすることができます。フレンドリーなオープン環境になりましょう。さらに、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 確率的に一意の識別子には、ハッシュされた識別子と同様のプロパティがありますが、（十分に良好な乱数ジェネレーターが与えられている場合）は、検索スペースの問題に免疫があります。ただし、このアプローチの強さもその弱点です。サーバーオペレーターでさえ、デバッグ中にサーバーインスタンスを識別子と関連付けることができるアルゴリズム変換はありません。また、このアプローチでは、再起動全体で確率的に一意の識別子を保持するためにName Serverインスタンスを必要としますが、権威ある名前サーバーには何らかの形の不揮発性ストレージがあるため、これは深刻な制限ではないようです。そのような識別子を保存する方法がない名前サーバーのまれなケースでは、再起動するたびに名前サーバーが新しい識別子を生成する場合、ひどいことは何も起こりません。
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 任意のOctet文字列を使用すると、名前サーバーオペレーターがさらに別の設定を提供し、構成を構成するか、構成を忘れます。Anycast Name Server Constellationのすべてのノードを「My Name Server」と識別することは、特に役立ちません。
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 署名されたBLOBは、署名されたデータが動的であり、タイムスタンプやリクエスターを識別する何らかのデータなどの何らかのリプレイ保護を含む場合を除き、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 静的暗号化されたBLOBは、攻撃を再生する可能性があり、実際には、復号化キーを所有していない当事者にとっては乱数であるため、特に有用ではありません。動的暗号化されたブロブは、おそらく状況によっては有用である可能性がありますが、署名されたブロブと同様に、動的暗号化されたブロブには、このドキュメントの範囲を超えて詳細なセキュリティ分析が必要になります。
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ペイロードが不透明なバイト文字列であると定義し、ペイロードの選択を実装者と名前サーバーオペレーターに任せます。
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 ユニキャストアドレスを漏らしているオペレーターは、確率的に一意の乱数の生のバイナリ表現を使用する可能性があります。これはおそらくデフォルトの実装動作である必要があります。
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 ユニキャストアドレスを漏らしているオペレーターは、単純さのためにユニキャストアドレスの生のバイナリ表現を使用するだけで問題ではありません。これは、オペレーターによる明示的な構成選択を介してのみ行う必要があります。
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 NameサーバーのメンテナンスアドレスをNogoodniksに漏らすことなく、有用なデバッグに十分な情報を提供すると同時に、そのような漏れが自分の裁量でより多くの情報を提供すると脅迫しているという名前のサーバーオペレーターを見つけることができるようになります。
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オプションは推移的ではありません。これは厳密にホップバイホップメカニズムです。
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 Name Serverの最もよく知られているケースはルートゾーンの名前サーバーのサブセットであるため、これまでの名前サーバー識別の議論のほとんどは、権威ある名前サーバーの識別に焦点を当てています。ただし、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.
このメカニズムの推移的なバリアントを持っていることには何らかのユーティリティがあるかもしれませんが（たとえば、スタブリゾルバーは再帰サーバーにどの権威ある名前サーバーが再帰名サーバーに特定の回答を提供したかを伝えるように依頼することができます）、のセマンティクスはこのようなバリアントはより複雑であり、将来の仕事のために残されます。
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, 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.
セクション3.1で説明されている可能性のあるペイロードコンテンツの範囲を考えると、効率的で、便利で、明確で、審美的に心地よいNSIDペイロードの単一のプレゼンテーション形式を定義することはできません。特に、何らかの形のテキスト文字列を使用するプレゼンテーション形式を使用することは魅力的ですが、これをサポートしようとすると、非常にシンプルなデバッグメカニズムを意図しているものが大幅に複雑になります。
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ペイロードを導出する場合、US-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ペイロード出力の正確なコピーをカットして貼り付けて、歪みのない電子メールメッセージやWebフォームなどの他の形式に貼り付けることが簡単です。16進列の弦は、醜いですが、堅牢です。
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応答を要求するリゾルバーはEDNをサポートするため、NSID応答を要求するリゾルバーは、「送信者のUDPペイロードサイズ」を使用して、OPT擬似RRのフィールドを使用して、トランケーションを不可能にするのに十分な大きさのバッファーサイズを信号することもできます。
IANA has allocated EDNS option code 3 for the NSID option (Section 2.3).
IANAは、NSIDオプションにEDNSオプションコード3を割り当てました（セクション2.3）。
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ペイロードを使用しようとする前に、有能なアドバイスを求める必要があります。
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.
感謝：ジョー・イーブリー、ハラルド・アルベスランド、ディーン・アンダーソン、マーク・アンドリュース、ロイ・アレンズ、スティーブ・ベロヴィン、アレックス・ブライ、ランディ・ブッシュ、デビッド・コンラッド、ジョン・ディキンソン、アルフレッド・ホーネス、ヨハン・イーレン、ダニエル・カーレンバーグ、ピーター・コッホ、ウィリアム・ライブゾン、エド・ルイスン、トーマス・ナルテン、マイク・パットン、ジェフリー・シッソン、アンドリュー・サリバン、マイク・セントジョンズ、トム・テイラー、ポール・ビクシー、サム・ワイラー、スザンヌ・ウルフは、著者が彼らのコメントと提案で何をしたかについて責任を負いません。上記のリストから不注意に省略された人に謝罪します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、BCP 14、1997年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[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.、Gudmundsson、O.、Eastlake 3rd、D。、およびB. Wellington、「DNSのシークレットキートランザクション認証」、2000年5月、RFC 2845。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 2277, BCP 18, January 1998.
[RFC2277] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、RFC 2277、BCP 18、1998年1月。
Author's Address
著者の連絡先
Rob Austein ISC 950 Charter Street Redwood City, CA 94063 USA
ロブオーストインISC 950チャーターストリートレッドウッドシティ、カリフォルニア94063 USA
EMail: sra@isc.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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エディター機能の資金は現在、インターネット協会によって提供されています。