RFC4697 日本語訳
4697 Observed DNS Resolution Misbehavior. M. Larson, P. Barber. October 2006. (Format: TXT=45187 bytes) (Also BCP0123) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Larson Request for Comments: 4697 P. Barber BCP: 123 VeriSign, Inc. Category: Best Current Practice October 2006
コメントを求めるワーキンググループM.ラーソンの要求をネットワークでつないでください: 4697P.バーバーBCP: 123ベリサインInc.カテゴリ: 最も良い現在の練習2006年10月
Observed DNS Resolution Misbehavior
観測されたDNS解決不正行為
Status of This Memo
このメモの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This memo describes DNS iterative resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. We offer implementation advice to iterative resolver developers to alleviate these unnecessary queries. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers.
このメモは重要な質問ボリュームにおける結果が根と最上位のドメイン(TLD)ネームサーバに送ったDNSの繰り返しのレゾルバの振舞いについて説明します。 私たちは、これらの不要な質問を軽減するために繰り返しのレゾルバ開発者に実装アドバイスを提供します。 本書ではされた推薦状は、13の根のネームサーバのうち2とすべての13のcom/ネットのTLDネームサーバで見られた観測のダイレクト副産物と異常な質問トラフィック・パターンの分析です。
Table of Contents
目次
1. Introduction ....................................................2
1.1. A Note about Terminology in this Memo ......................3
1.2. Key Words ..................................................3
2. Observed Iterative Resolver Misbehavior .........................3
2.1. Aggressive Requerying for Delegation Information ...........3
2.1.1. Recommendation ......................................5
2.2. Repeated Queries to Lame Servers ...........................6
2.2.1. Recommendation ......................................6
2.3. Inability to Follow Multiple Levels of Indirection .........7
2.3.1. Recommendation ......................................7
2.4. Aggressive Retransmission when Fetching Glue ...............8
2.4.1. Recommendation ......................................9
2.5. Aggressive Retransmission behind Firewalls .................9
2.5.1. Recommendation .....................................10
2.6. Misconfigured NS Records ..................................10
2.6.1. Recommendation .....................................11
1. 序論…2 1.1. このMemoのTerminologyの周りのNote…3 1.2. キーワード…3 2. 繰り返しのレゾルバ不正行為を観測します…3 2.1. 委譲情報のための攻撃的なRequerying…3 2.1.1. 推薦…5 2.2. サーバを不完全にするために質問を繰り返します…6 2.2.1. 推薦…6 2.3. 複数のレベルの間接指定に従うことができないこと…7 2.3.1. 推薦…7 2.4. 攻撃的なRetransmission、Fetching Glueであるときに…8 2.4.1. 推薦…9 2.5. ファイアウォールの後ろの攻撃的なRetransmission…9 2.5.1. 推薦…10 2.6. Misconfiguredナノ秒は記録します…10 2.6.1. 推薦…11
Larson & Barber Best Current Practice [Page 1] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[1ページ]RFC4697
2.7. Name Server Records with Zero TTL .........................11
2.7.1. Recommendation .....................................12
2.8. Unnecessary Dynamic Update Messages .......................12
2.8.1. Recommendation .....................................13
2.9. Queries for Domain Names Resembling IPv4 Addresses ........13
2.9.1. Recommendation .....................................14
2.10. Misdirected Recursive Queries ............................14
2.10.1. Recommendation ....................................14
2.11. Suboptimal Name Server Selection Algorithm ...............15
2.11.1. Recommendation ....................................15
3. Security Considerations ........................................16
4. Acknowledgements ...............................................16
5. Internationalization Considerations ............................16
6. References .....................................................16
6.1. Normative References ......................................16
6.2. Informative References ....................................16
2.7. ネームサーバはゼロでTTLを記録します…11 2.7.1. 推薦…12 2.8. 不要なダイナミック・アップデートメッセージ…12 2.8.1. 推薦…13 2.9. IPv4アドレスに類似しているドメイン名のための質問…13 2.9.1. 推薦…14 2.10. 的外れの反復クエリー…14 2.10.1. 推薦…14 2.11. 準最適のネームサーバ選択アルゴリズム…15 2.11.1. 推薦…15 3. セキュリティ問題…16 4. 承認…16 5. 国際化問題…16 6. 参照…16 6.1. 標準の参照…16 6.2. 有益な参照…16
1. Introduction
1. 序論
Observation of query traffic received by two root name servers and the thirteen com/net Top-Level Domain (TLD) name servers has revealed that a large proportion of the total traffic often consists of "requeries". A requery is the same question (<QNAME, QTYPE, QCLASS>) asked repeatedly at an unexpectedly high rate. We have observed requeries from both a single IP address and multiple IP addresses (i.e., the same query received simultaneously from multiple IP addresses).
2つの根のネームサーバと13com/ネットのTop-レベルDomain(TLD)ネームサーバによって受け取られた質問トラフィックの観測は、総トラフィックの大部分が"再質問"からしばしば成るのを明らかにしました。 再質問は(<QNAME、QTYPE、QCLASS>)が不意に高いレートで幾重にも頼んだという同じ問題です。 私たちはただ一つのIPアドレスと複数のIPアドレスの両方から再質問を観測しました(すなわち、同じ質問は同時に、複数のIPアドレスを受け取りました)。
By analyzing requery events, we have found that the cause of the duplicate traffic is almost always a deficient iterative resolver, stub resolver, or application implementation combined with an operational anomaly. The implementation deficiencies we have identified to date include well-intentioned recovery attempts gone awry, insufficient caching of failures, early abort when multiple levels of indirection must be followed, and aggressive retry by stub resolvers or applications. Anomalies that we have seen trigger requery events include lame delegations, unusual glue records, and anything that makes all authoritative name servers for a zone unreachable (Denial of Service (DoS) attacks, crashes, maintenance, routing failures, congestion, etc.).
再質問イベントを分析することによって、私たちは、写しトラフィックの原因が操作上の異常に結合されたほとんどいつも不十分な繰り返しのレゾルバ、スタッブレゾルバ、またはアプリケーション実装であることがわかりました。 私たちがこれまで特定した実装欠乏はスタッブレゾルバかアプリケーションでつまずいている善意の回復試み、失敗の不十分なキャッシュ、複数のレベルの間接指定に従わなければならないときの早めのアボート、および攻撃的な再試行を含んでいます。 私たちが、引き金の再質問イベントが含んでいるのを見た例外は委譲、珍しい接着剤記録、およびゾーンへのすべての正式のネームサーバを手が届かなくする何(サービス妨害(DoS)攻撃、クラッシュ、メインテナンス、ルーティング失敗、混雑など)でも不完全にします。
In the following sections, we provide a detailed explanation of the observed behavior and recommend changes that will reduce the requery rate. None of the changes recommended affects the core DNS protocol specification; instead, this document consists of guidelines to implementors of iterative resolvers.
以下のセクションで、私たちは、観測された振舞いの詳説を提供して、再質問レートを低下させる変化を推薦します。 推薦された変化のいずれもコアDNSプロトコル仕様に影響しません。 代わりに、このドキュメントは繰り返しのレゾルバの作成者にガイドラインから成ります。
Larson & Barber Best Current Practice [Page 2] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[2ページ]RFC4697
1.1. A Note about Terminology in This Memo
1.1. このメモによる用語に関する注
To recast an old saying about standards, the nice thing about DNS terms is that there are so many of them to choose from. Writing or talking about DNS can be difficult and can cause confusion resulting from a lack of agreed-upon terms for its various components. Further complicating matters are implementations that combine multiple roles into one piece of software, which makes naming the result problematic. An example is the entity that accepts recursive queries, issues iterative queries as necessary to resolve the initial recursive query, caches responses it receives, and which is also able to answer questions about certain zones authoritatively. This entity is an iterative resolver combined with an authoritative name server and is often called a "recursive name server" or a "caching name server".
規格に関して、DNSのおよそ期間の良いものがとても多いそれらがあるということであるという選ぶ古いことわざを書き直すために。 DNSに関して書くか、または話すのが、難しい場合があり、様々なコンポーネントのための同意している用語の不足から生じる混乱を引き起こす場合があります。 さらに件を複雑にするのは、結果を命名するのを問題が多くする1つのソフトウェア一本に複数の役割を結合する実装です。 例が反復クエリーを受け入れる実体であり、問題が必要に応じて初期の反復クエリーを決議する繰り返しの質問であり、キャッシュはそれが受ける応答です、そして、また、どれが厳然とある一定のゾーンに関する質問に答えることができますか? この実体は、正式のネームサーバに結合された繰り返しのレゾルバであり、しばしば「再帰的なネームサーバかキャッシュネームサーバ」と呼ばれます。
This memo is concerned principally with the behavior of iterative resolvers, which are typically found as part of a recursive name server. This memo uses the more precise term "iterative resolver", because the focus is usually on that component. In instances where the name server role of this entity requires mentioning, this memo uses the term "recursive name server". As an example of the difference, the name server component of a recursive name server receives DNS queries and the iterative resolver component sends queries.
このメモは「繰り返しのレゾルバ」というより正確な用語を使用します、焦点が通常そのコンポーネントにあるので。このメモは主に繰り返しのレゾルバの振舞いに関係があります。(そのレゾルバは、再帰的なネームサーバの一部として通常見つけられます)。 インスタンスでは、この実体のネームサーバの役割が、言及するのを必要とするところでこのメモは「再帰的なネームサーバ」という用語を使用します。 違いに関する例として、再帰的なネームサーバのネームサーバコンポーネントはDNS質問を受けます、そして、繰り返しのレゾルバコンポーネントは質問を送ります。
The advent of IPv6 requires mentioning AAAA records as well as A records when discussing glue. To avoid continuous repetition and qualification, this memo uses the general term "address record" to encompass both A and AAAA records when a particular situation is relevant to both types.
IPv6の到来は、接着剤について議論するとき、A記録と同様にAAAA記録について言及するのを必要とします。 連続した反復と資格を避けるなら、このメモは、特定の状況が両方のタイプに関連しているとき、AとAAAA記録の両方を包含するのに「アドレス記録」という一般項を使用します。
1.2. Key Words
1.2. キーワード
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 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
2. Observed Iterative Resolver Misbehavior
2. 観測された繰り返しのレゾルバ不正行為
2.1. Aggressive Requerying for Delegation Information
2.1. 委譲情報のための攻撃的なRequerying
There can be times when every name server in a zone's NS RRSet is unreachable (e.g., during a network outage), unavailable (e.g., the name server process is not running on the server host), or misconfigured (e.g., the name server is not authoritative for the given zone, also known as "lame"). Consider an iterative resolver that attempts to resolve a query for a domain name in such a zone and
ゾーンのNS RRSetのあらゆるネームサーバが手が届かなさ(例えば、ネットワーク供給停止の間の)か、入手できなさ(例えば、ネームサーバプロセスはサーバー・ホストで走っていない)か、またはmisconfiguredされている(例えば、ネームサーバも、与えられたゾーンには正式でなくて、また、「ラメ」として知られています)回があることができます。 そしてそのようなゾーンのドメイン名のための質問を決議するのを試みる繰り返しのレゾルバを考えてください。
Larson & Barber Best Current Practice [Page 3] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[3ページ]RFC4697
discovers that none of the zone's name servers can provide an answer. We have observed a recursive name server implementation whose iterative resolver then verifies the zone's NS RRSet in its cache by querying for the zone's delegation information: it sends a query for the zone's NS RRSet to one of the parent zone's name servers. (Note that queries with QTYPE=NS are not required by the standard resolution algorithm described in Section 4.3.2 of RFC 1034 [2]. These NS queries represent this implementation's addition to that algorithm.)
ゾーンのネームサーバのどれかが答えを提供できないと発見します。 私たちは、ゾーンの委譲情報のために以下について質問することによって、次に繰り返しのレゾルバがキャッシュでゾーンのNS RRSetについて確かめる再帰的なネームサーバ実装を観測しました。 それはゾーンのNS RRSetのために親ゾーンのネームサーバの1つに質問を送ります。 QTYPE=NSとの質問が.2セクション4.3RFC1034[2]で説明された標準の解決アルゴリズムによって必要とされないことに注意してください。(これらのNS質問はこの実装の追加をそのアルゴリズムに表します。)
For example, suppose that "example.com" has the following NS RRSet:
例えば、"example.com"には以下のNS RRSetがあると仮定してください:
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
example.com。 IN NS ns1.example.com example.com。 IN NS ns2.example.com。
Upon receipt of a query for "www.example.com" and assuming that neither "ns1.example.com" nor "ns2.example.com" can provide an answer, this iterative resolver implementation immediately queries a "com" zone name server for the "example.com" NS RRSet to verify that it has the proper delegation information. This implementation performs this query to a zone's parent zone for each recursive query it receives that fails because of a completely unresponsive set of name servers for the target zone. Consider the effect when a popular zone experiences a catastrophic failure of all its name servers: now every recursive query for domain names in that zone sent to this recursive name server implementation results in a query to the failed zone's parent name servers. On one occasion when several dozen popular zones became unreachable, the query load on the com/net name servers increased by 50%.
"www.example.com"のための質問とそれを仮定すること"ns1.example.com"も"ns2.example.com"も答えを提供できないを受け取り次第、"example.com"NS RRSetが、それには適切な委譲情報があることを確かめるように、この繰り返しのレゾルバ実装はすぐに、"com"ゾーンネームサーバについて質問します。 この実装はそれが受ける完全に無反応セットのネームサーバでターゲットゾーンのために失敗する各反復クエリーのためにゾーンの親ゾーンにこの質問を実行します。 ポピュラーなゾーンがすべてのネームサーバの突発故障になるときには効果を考えてください: この再帰的なネームサーバ実装に送られたそのゾーンのドメイン名のための現在の、あらゆる反復クエリーが失敗したゾーンの親ネームサーバへの質問をもたらします。 あるときいくつかのダースのポピュラーなゾーンが手が届かなくなったとき、com/ネットのネームサーバの質問負荷は50%増加しました。
We believe this verification query is not reasonable. Consider the circumstances: when an iterative resolver is resolving a query for a domain name in a zone it has not previously searched, it uses the list of name servers in the referral from the target zone's parent. If on its first attempt to search the target zone, none of the name servers in the referral is reachable, a verification query to the parent would be pointless: this query to the parent would come so quickly on the heels of the referral that it would be almost certain to contain the same list of name servers. The chance of discovering any new information is slim.
私たちは、この検証質問が合理的でないと信じています。 事情を考えてください: 繰り返しのレゾルバがそれが以前に捜していないゾーンのドメイン名のための質問を決議しているとき、それはターゲットゾーンの親から紹介にネームサーバのリストを使用します。 紹介におけるネームサーバのいずれもターゲットゾーンを捜す最初の試みのときに届かないなら、親への検証質問は無意味でしょう: 親へのこの質問は紹介のすぐ後にそれほどすばやく来るでしょう、したがって、ネームサーバの同じリストを含むのがほとんど確かでしょう。 どんな新情報も発見するという機会はスリムです。
The other possibility is that the iterative resolver successfully contacts one of the target zone's name servers and then caches the NS RRSet from the authority section of a response, the proper behavior according to Section 5.4.1 of RFC 2181 [3], because the NS RRSet from the target zone is more trustworthy than delegation information from the parent zone. If, while processing a subsequent recursive query, the iterative resolver discovers that none of the name servers
もう片方の可能性は繰り返しのレゾルバが首尾よくターゲットゾーンのネームサーバの1つに連絡して、次に、応答の権威部からNS RRSetをキャッシュするということです、.1セクション5.4RFC2181[3]に従った適切な振舞い、ターゲットゾーンからのNS RRSetが親ゾーンからの委譲情報より信頼できるので。 その後の反復クエリーを処理している間の繰り返しのレゾルバがネームサーバについてなにもにそれを発見するなら
Larson & Barber Best Current Practice [Page 4] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[4ページ]RFC4697
specified in the cached NS RRSet is available or authoritative, querying the parent would be wrong. An NS RRSet from the parent zone would now be less trustworthy than data already in the cache.
キャッシュで指定されて、NS RRSetが利用可能であるか、または正式である、親について質問するのは間違っているでしょう。 親ゾーンからのNS RRSetは現在、既にキャッシュにおけるデータほど信頼できないでしょう。
For this query of the parent zone to be useful, the target zone's entire set of name servers would have to change AND the former set of name servers would have to be deconfigured or decommissioned AND the delegation information in the parent zone would have to be updated with the new set of name servers, all within the Time to Live (TTL) of the target zone's NS RRSet. We believe this scenario is uncommon: administrative best practices dictate that changes to a zone's set of name servers happen gradually when at all possible, with servers removed from the NS RRSet left authoritative for the zone as long as possible. The scenarios that we can envision that would benefit from the parent requery behavior do not outweigh its damaging effects.
親ゾーンのこの質問が役に立つように、ターゲットゾーンの全体のセットのネームサーバが変化しなければならなくて、前のセットのネームサーバは、親ゾーンの委譲情報が新しいセットのネームサーバでアップデートするために持っているANDであると反構成されなければならないか、または使用を中止されなければならないでしょう、ターゲットゾーンのNS RRSetのLive(TTL)へのTimeの中で。 私たちは、このシナリオが珍しいと信じています: 管理最も良い習慣は、可能であるときに、ゾーンのネームサーバのセットへの変化が徐々に起こると決めます、できるだけ長い間ゾーンに正式の状態で残っているNS RRSetからサーバを取り除いていて。 私たちがそれを思い描くことができるのが親再質問の振舞いの利益を得るでしょう。シナリオ、破損効果を重しないでください。
This section should not be understood to claim that all queries to a zone's parent are bad. In some cases, such queries are not only reasonable but required. Consider the situation when required information, such as the address of a name server (i.e., the address record corresponding to the RDATA of an NS record), has timed out of an iterative resolver's cache before the corresponding NS record. If the name of the name server is below the apex of the zone, then the name server's address record is only available as glue in the parent zone. For example, consider this NS record:
ゾーンの親へのすべての質問が悪いと主張するのをこのセクションを理解するべきではありません。 いくつかの場合、そのような質問が妥当であるだけではなく、必要でもあります。 対応するNSが記録する前にネームサーバ(すなわち、NS記録のRDATAに対応するアドレス記録)のアドレスなどの必須情報は繰り返しのリゾルバのキャッシュから時間があるときには状況を考えてください。 ゾーンの頂点の下にネームサーバの名前があるなら、ネームサーバのアドレス記録は単に親ゾーンの接着剤として利用可能です。 例えば、このNS記録を考えてください:
example.com. IN NS ns.example.com.
example.com。 IN NS ns.example.com。
If a cache has this NS record but not the address record for "ns.example.com", it is unable to contact the "example.com" zone directly and must query the "com" zone to obtain the address record. Note, however, that such a query would not have QTYPE=NS according to the standard resolution algorithm.
キャッシュにアドレス記録ではなく、このNS記録が"ns.example.com"のためにあるなら、それは、"example.com"ゾーンに直接接触できないで、アドレス記録を得るために"com"ゾーンについて質問しなければなりません。 しかしながら、標準の解決アルゴリズムによると、そのような質問にはQTYPE=NSがないことに注意してください。
2.1.1. Recommendation
2.1.1. 推薦
An iterative resolver MUST NOT send a query for the NS RRSet of a non-responsive zone to any of the name servers for that zone's parent zone. For the purposes of this injunction, a non-responsive zone is defined as a zone for which every name server listed in the zone's NS RRSet:
繰り返しのレゾルバは非敏感なゾーンのNS RRSetのためにそのゾーンの親ゾーンへのネームサーバのいずれにも質問を送ってはいけません。 この命令の目的のために、非敏感なゾーンはあらゆるネームサーバがゾーンのNS RRSetに記載したゾーンと定義されます:
1. is not authoritative for the zone (i.e., lame), or
または1.、ゾーンには正式でない、(すなわち、不十分な)。
2. returns a server failure response (RCODE=2), or
または2. リターンaサーバ失敗応答(RCODE=2)。
3. is dead or unreachable according to Section 7.2 of RFC 2308 [4].
3.、RFC2308[4]のセクション7.2によると、死んでいるか、または手が届きません。
Larson & Barber Best Current Practice [Page 5] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[5ページ]RFC4697
2.2. Repeated Queries to Lame Servers
2.2. サーバを不完全にする繰り返された質問
Section 2.1 describes a catastrophic failure: when every name server for a zone is unable to provide an answer for one reason or another. A more common occurrence is when a subset of a zone's name servers is unavailable or misconfigured. Different failure modes have different expected durations. Some symptoms indicate problems that are potentially transient, for example, various types of ICMP unreachable messages because a name server process is not running or a host or network is unreachable, or a complete lack of a response to a query. Such responses could be the result of a host rebooting or temporary outages; these events do not necessarily require any human intervention and can be reasonably expected to be temporary.
セクション2.1は突発故障について説明します: ゾーンへのあらゆるネームサーバが何らかの理由に答えを提供できないとき。 より一般的な発生はゾーンのネームサーバの部分集合が入手できないかmisconfiguredされている時です。 異なった故障モードには、異なった予想された持続時間があります。 いくつかの兆候がネームサーバプロセスが稼働する予定でないか、またはホストかネットワークが手が届かないので潜在的に一時的な例えば、様々なタイプのICMPの手の届かないメッセージである問題、または質問への応答の完全な不足を示します。 そのような応答はホストリブートか一時的な供給停止の結果であるかもしれません。 これらのイベントを、必ず少しの人間の介入も必要とするというわけではなくて、一時的であると合理的に予想できます。
Other symptoms clearly indicate a condition requiring human intervention, such as lame server: if a name server is misconfigured and not authoritative for a zone delegated to it, it is reasonable to assume that this condition has potential to last longer than unreachability or unresponsiveness. Consequently, repeated queries to known lame servers are not useful. In this case of a condition with potential to persist for a long time, a better practice would be to maintain a list of known lame servers and avoid querying them repeatedly in a short interval.
他の兆候は明確に不十分なサーバなどの人間の介入を必要とする状態を示します: それへ代表として派遣されたゾーンには、ネームサーバがmisconfiguredされていて正式でないなら、「非-可到達性」か鈍感さより長い間続く可能性がこの状態にあると仮定するのが妥当です。 その結果、知られている不十分なサーバへの繰り返された質問は役に立ちません。 この場合、長い間固執する可能性がある状態では、より良い習慣は、知られている不十分なサーバのリストを主張して、短い間隔で繰り返してそれらについて質問するのを避けることになっているでしょう。
It should also be noted, however, that some authoritative name server implementations appear to be lame only for queries of certain types as described in RFC 4074 [5]. In this case, it makes sense to retry the "lame" servers for other types of queries, particularly when all known authoritative name servers appear to be "lame".
また、しかしながら、いくつかの正式のネームサーバ実装がRFC4074[5]で説明されるようにあるタイプの質問だけに不十分であるように見えることに注意されるべきです。 この場合、他のタイプの質問のための「不十分な」サーバを再試行する意味になります、特にすべての知られている正式のネームサーバが「不十分である」ように見えると。
2.2.1. Recommendation
2.2.1. 推薦
Iterative resolvers SHOULD cache name servers that they discover are not authoritative for zones delegated to them (i.e., lame servers). If this caching is performed, lame servers MUST be cached against the specific query tuple <zone name, class, server IP address>. Zone name can be derived from the owner name of the NS record that was referenced to query the name server that was discovered to be lame.
それらがゾーンには正式でないと発見する繰り返しのレゾルバSHOULDキャッシュネームサーバがそれら(すなわち、不十分なサーバ)に委任しました。 このキャッシュが実行されるなら、特定の質問tuple<ゾーン名に対して不十分なサーバをキャッシュしなければなりません、クラス、サーバIPアドレス>。 不十分であると発見されたネームサーバについて質問するために参照をつけられたNS記録の所有者名からゾーン名を得ることができます。
Implementations that perform lame server caching MUST refrain from sending queries to known lame servers for a configurable time interval after the server is discovered to be lame. A minimum interval of thirty minutes is RECOMMENDED.
不十分なサーバキャッシュを実行する実装は、サーバが不十分であると発見された後に構成可能な時間間隔の間、知られている不十分なサーバに質問を送るのを控えなければなりません。 30分の最小間隔はRECOMMENDEDです。
Larson & Barber Best Current Practice [Page 6] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[6ページ]RFC4697
An exception to this recommendation occurs if all name servers for a zone are marked lame. In that case, the iterative resolver SHOULD temporarily ignore the servers' lameness status and query one or more servers. This behavior is a workaround for the type-specific lameness issue described in the previous section.
ゾーンへのすべてのネームサーバが不十分であるとマークされるなら、この推薦への例外は起こります。 その場合、繰り返しのレゾルバSHOULDは一時サーバの不完全さ状態を無視して、1つ以上のサーバについて質問します。 この振舞いは前項で説明されたタイプ特有の不完全さ問題のための回避策です。
Implementors should take care not to make lame server avoidance logic overly broad: note that a name server could be lame for a parent zone but not a child zone, e.g., lame for "example.com" but properly authoritative for "sub.example.com". Therefore, a name server should not be automatically considered lame for subzones. In the case above, even if a name server is known to be lame for "example.com", it should be queried for QNAMEs at or below "sub.example.com" if an NS record indicates that it should be authoritative for that zone.
作成者は不十分なサーバ回避論理をひどく広くしないように注意するべきです: 例えば、ネームサーバが子供ゾーンではなく、親ゾーンに不十分であって、"example.com"に不十分ですが、"sub.example.com"には、適切に正式であるかもしれないことに注意してください。 したがって、「副-ゾーン」に不十分であると自動的にネームサーバを考えるべきではありません。 場合では、ネームサーバが"example.com"に不十分であることが知られても、NS記録が、そのゾーンに、それが正式であるべきであることを示すなら、それはQNAMEsのためにsub.example.comか"sub.example.com"の下で上では、質問されるべきです。
2.3. Inability to Follow Multiple Levels of Indirection
2.3. 複数のレベルの間接指定に従うことができないこと
Some iterative resolver implementations are unable to follow sufficient levels of indirection. For example, consider the following delegations:
いくつかの繰り返しのレゾルバ実装は十分なレベルの間接指定に従うことができません。 例えば、以下の委譲を考えてください:
foo.example. IN NS ns1.example.com.
foo.example. IN NS ns2.example.com.
foo.example。 IN NS ns1.example.com foo.example。 IN NS ns2.example.com。
example.com. IN NS ns1.test.example.net.
example.com. IN NS ns2.test.example.net.
example.com。 IN NS ns1.test.example.net example.com。 IN NS ns2.test.example.net。
test.example.net. IN NS ns1.test.example.net.
test.example.net. IN NS ns2.test.example.net.
test.example.net。 IN NS ns1.test.example.net test.example.net。 IN NS ns2.test.example.net。
An iterative resolver resolving the name "www.foo.example" must follow two levels of indirection, first obtaining address records for "ns1.test.example.net" or "ns2.test.example.net" in order to obtain address records for "ns1.example.com" or "ns2.example.com" in order to query those name servers for the address records of "www.foo.example". Although this situation may appear contrived, we have seen multiple similar occurrences and expect more as new generic top-level domains (gTLDs) become active. We anticipate many zones in new gTLDs will use name servers in existing gTLDs, increasing the number of delegations using out-of-zone name servers.
"www.foo.example"という名前を決議する繰り返しのレゾルバは2つのレベルの間接指定に従わなければなりません、最初に"www.foo.example"に関するアドレス記録のためにそれらのネームサーバについて質問するために"ns1.example.com"か"ns2.example.com"のためのアドレス記録を得るために"ns1.test.example.net"か"ns2.test.example.net"のためのアドレス記録を得て。 この状況は人為的に見えるかもしれませんが、私たちは、複数の同様の発生を見て、新しいとしてジェネリック・トップ・レベル・ドメイン(gTLDs)がアクティブになるとさらに予想します。 私たちは、新しいgTLDsの多くのゾーンが既存のgTLDsでネームサーバを使用すると予期します、ゾーンの外でネームサーバを使用することで委譲の数を増強して。
2.3.1. Recommendation
2.3.1. 推薦
Clearly constructing a delegation that relies on multiple levels of indirection is not a good administrative practice. However, the practice is widespread enough to require that iterative resolvers be able to cope with it. Iterative resolvers SHOULD be able to handle arbitrary levels of indirection resulting from out-of-zone name
明確に複数のレベルの間接指定を当てにする委譲を構成するのは、良い管理習慣ではありません。 しかしながら、習慣は繰り返しのレゾルバがそれに対処できるのが必要であるほど広範囲です。 繰り返しのレゾルバSHOULD、ゾーンの外からの任意のレベルの間接指定の結果として起こる名を扱うことができてください。
Larson & Barber Best Current Practice [Page 7] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[7ページ]RFC4697
servers. Iterative resolvers SHOULD implement a level-of-effort counter to avoid loops or otherwise performing too much work in resolving pathological cases.
サーバ。 繰り返しのレゾルバSHOULDは、輪かそうでなければ、病理学的なケースを決議する際にあまりに多くの仕事をするのを避けるために取り組みのレベルカウンタを実装します。
A best practice that avoids this entire issue of indirection is to
name one or more of a zone's name servers in the zone itself. For
example, if the zone is named "example.com", consider naming some of
the name servers "ns{1,2,...}.example.com" (or similar).
間接指定のこの全体の問題を避ける最も良い習慣はゾーン自体でゾーンのネームサーバの1つ以上を命名することになっています。 例えば、ゾーンが"example.com"と命名されるならネームサーバのいくつかを命名すると考えてください、「ナノ秒、1、2…、.example.com、」 (同様。)です。
2.4. Aggressive Retransmission when Fetching Glue
2.4. 攻撃的なRetransmission、Fetching Glueです。
When an authoritative name server responds with a referral, it includes NS records in the authority section of the response. According to the algorithm in Section 4.3.2 of RFC 1034 [2], the name server should also "put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache." Some name server implementations take this address inclusion a step further with a feature called "glue fetching". A name server that implements glue fetching attempts to include address records for every NS record in the authority section. If necessary, the name server issues multiple queries of its own to obtain any missing address records.
正式のネームサーバが紹介で応じるとき、それは応答の権威部でのNS記録を含んでいます。 .2セクション4.3RFC1034[2]におけるアルゴリズムによると、ネームサーバはまた「どんな利用可能なアドレスも追加セクションに入れてください、アドレスが信頼すべきデータかキャッシュから利用可能でないなら接着剤RRsを使用してまた」そうするべきです。 いくつかのネームサーバ実装が、より遠くに特徴が「接着剤のとって来ること」と呼ばれている状態でこのアドレス包含を前進させます。 接着剤のとって来ることを実装するネームサーバは、権威部でのあらゆるNS記録のためのアドレス記録を含んでいるのを試みます。 必要なら、ネームサーバは、どんななくなったアドレス記録も得るためにそれ自身の複数の質問を発行します。
Problems with glue fetching can arise in the context of "authoritative-only" name servers, which only serve authoritative data and ignore requests for recursion. Such an entity will not normally generate any queries of its own. Instead it answers non- recursive queries from iterative resolvers looking for information in zones it serves. With glue fetching enabled, however, an authoritative server invokes an iterative resolver to look up an unknown address record to complete the additional section of a response.
魅惑的な接着剤に関する問題は、信頼すべきデータに役立つだけである「正式に唯一」のネームサーバの文脈に起こって、再帰を求める要求を無視できます。 通常、そのような実体はそれ自身のどんな質問も生成しないでしょう。 代わりに、それはそれが役立つゾーンで情報を探している繰り返しのレゾルバから非反復クエリーに答えます。 しかしながら、接着剤のとって来ることが可能にされている状態で、正式のサーバは、応答の追加セクションを完成するために未知のアドレス記録を調べるために繰り返しのレゾルバを呼び出します。
We have observed situations where the iterative resolver of a glue- fetching name server can send queries that reach other name servers, but is apparently prevented from receiving the responses. For example, perhaps the name server is authoritative-only and therefore its administrators expect it to receive only queries and not responses. Perhaps unaware of glue fetching and presuming that the name server's iterative resolver will generate no queries, its administrators place the name server behind a network device that prevents it from receiving responses. If this is the case, all glue-fetching queries will go unanswered.
私たちは接着剤の魅惑的なネームサーバの繰り返しのレゾルバが他のネームサーバに達する質問を送ることができますが、応答を受けるのが明らかに防がれる状況を観測しました。 そして、例えば、恐らくネームサーバがそうである、正式に唯一、したがって、管理者は、応答ではなく、質問だけを受けると予想します。 恐らく接着剤のとって来るのに気づかない、そして、ネームサーバの繰り返しのレゾルバが質問を全く生成しないと推定します、管理者はそれが応答を受けるのを防ぐネットワークデバイスの後ろにネームサーバを置きます。 これがそうであるなら、すべての接着剤を魅惑的な質問が答えがなくなるでしょう。
We have observed name server implementations whose iterative resolvers retry excessively when glue-fetching queries are unanswered. A single com/net name server has received hundreds of queries per second from a single such source. Judging from the
私たちは接着剤を魅惑的な質問が答えがないときに繰り返しのレゾルバが過度に再試行するネームサーバ実装を観測しました。 単一のcom/ネットのネームサーバはシングルからそのようなソースを1秒あたり何百もの質問に受け取りました。 judging from
Larson & Barber Best Current Practice [Page 8] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[8ページ]RFC4697
specific queries received and based on additional analysis, we believe these queries result from overly aggressive glue fetching.
特定の質問は受信されました、そして、追加分析に基づいて、私たちはひどく攻撃的な接着剤のとって来るのからこれらの質問が結果であると信じています。
2.4.1. Recommendation
2.4.1. 推薦
Implementers whose name servers support glue fetching SHOULD take care to avoid sending queries at excessive rates. Implementations SHOULD support throttling logic to detect when queries are sent but no responses are received.
ネームサーバサポートが魅惑的なSHOULDをにかわで接ぐImplementersは、過度のレートで質問を送るのを避けるために注意します。 質問がいつ送られるかを検出するために論理を阻止する実装SHOULDサポートにもかかわらず、どんな応答も受け取られていません。
2.5. Aggressive Retransmission behind Firewalls
2.5. ファイアウォールの後ろの攻撃的なRetransmission
A common occurrence and one of the largest sources of repeated queries at the com/net and root name servers appears to result from resolvers behind misconfigured firewalls. In this situation, an iterative resolver is apparently allowed to send queries through a firewall to other name servers, but not receive the responses. The result is more queries than necessary because of retransmission, all of which are useless because the responses are never received. Just as with the glue-fetching scenario described in Section 2.4, the queries are sometimes sent at excessive rates. To make matters worse, sometimes the responses, sent in reply to legitimate queries, trigger an alarm on the originator's intrusion detection system. We are frequently contacted by administrators responding to such alarms who believe our name servers are attacking their systems.
一般的な発生とcom/ネットと根のネームサーバにおける繰り返された質問の最も大きい源の1つは、misconfiguredファイアウォールの後ろにレゾルバから生じるように見えます。 この状況で、ファイアウォールを通して他のネームサーバに質問を送りますが、繰り返しのレゾルバは明らかに応答を受けることができません。 結果はそれのすべてが応答を決して受けないので役に立たない「再-トランスミッション」で必要とするより多くの質問です。 ちょうどセクション2.4で説明される接着剤を魅惑的なシナリオのように、過度のレートで時々質問を送ります。 いっそう困ったことに、時々正統の質問に対して送られた応答は創始者の侵入検知システムの上のアラームの引き金となります。 私たちは頻繁にそのようなアラームにだれを反応させるかとそれらのシステムを攻撃すると私たちのネームサーバに信じられている管理者によって連絡されます。
Not only do some resolvers in this situation retransmit queries at an excessive rate, but they continue to do so for days or even weeks. This scenario could result from an organization with multiple recursive name servers, only a subset of whose iterative resolvers' traffic is improperly filtered in this manner. Stub resolvers in the organization could be configured to query multiple recursive name servers. Consider the case where a stub resolver queries a filtered recursive name server first. The iterative resolver of this recursive name server sends one or more queries whose replies are filtered, so it cannot respond to the stub resolver, which times out. Then the stub resolver retransmits to a recursive name server that is able to provide an answer. Since resolution ultimately succeeds the underlying problem might not be recognized or corrected. A popular stub resolver implementation has a very aggressive retransmission schedule, including simultaneous queries to multiple recursive name servers, which could explain how such a situation could persist without being detected.
この状況における何人かのレゾルバは過度のレートで質問を再送するだけではなく、それらが、何日も何週間もさえそうし続けています。 このシナリオは複数の再帰的なネームサーバ(繰り返しのレゾルバのトラフィックがこの様に不適切にフィルターにかけられるかに関する部分集合だけ)がある組織から生じるかもしれません。 複数の再帰的なネームサーバについて質問するために組織のスタッブレゾルバを構成できました。 スタッブレゾルバが最初にフィルターにかけることの再帰的なネームサーバについて質問するケースを考えてください。 この再帰的なネームサーバの繰り返しのレゾルバが回答がフィルターにかけられる1つ以上の質問を送るので、スタッブレゾルバに応じることができないで、どの回がアウトであるか。 そして、スタッブレゾルバは答えを提供できる再帰的なネームサーバに再送します。 解決が結局成功するので、根本的な問題は、認識しないか、修正できません。 ポピュラーなスタッブレゾルバ実装には、非常に攻撃的な「再-トランスミッション」スケジュールがあります、複数の再帰的なネームサーバ(そのような状況がどう検出されないで持続するかもしれないかがわかることができた)に同時の質問を含めて。
Larson & Barber Best Current Practice [Page 9] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[9ページ]RFC4697
2.5.1. Recommendation
2.5.1. 推薦
The most obvious recommendation is that administrators SHOULD take care not to place iterative resolvers behind a firewall that allows queries, but not the resulting replies, to pass through.
最も明白な推薦は管理者SHOULDが結果として起こる回答ではなく、質問が通り抜けるファイアウォールの後ろに繰り返しのレゾルバを置かないように注意するということです。
Iterative resolvers SHOULD take care to avoid sending queries at excessive rates. Implementations SHOULD support throttling logic to detect when queries are sent but no responses are received.
繰り返しのレゾルバSHOULDは、過度のレートで質問を送るのを避けるために注意します。 質問がいつ送られるかを検出するために論理を阻止する実装SHOULDサポートにもかかわらず、どんな応答も受け取られていません。
2.6. Misconfigured NS Records
2.6. Misconfiguredナノ秒は記録します。
Sometimes a zone administrator forgets to add the trailing dot on the domain names in the RDATA of a zone's NS records. Consider this fragment of the zone file for "example.com":
時々、ゾーンの管理者は、ゾーンのNS記録のRDATAのドメイン名で引きずっているドットを加えるのを忘れます。 "example.com"のためのゾーンファイルのこの断片を考えてください:
$ORIGIN example.com.
example.com. 3600 IN NS ns1.example.com ; Note missing
example.com. 3600 IN NS ns2.example.com ; trailing dots
ORIGIN example.com$example.com。 3600IN NS ns1.example.com。 なくなったexample.comに注意してください。 3600IN NS ns2.example.com。 引きずっているドット
The zone's authoritative servers will parse the NS RDATA as "ns1.example.com.example.com" and "ns2.example.com.example.com" and return NS records with this incorrect RDATA in responses, including typically the authority section of every response containing records from the "example.com" zone.
"ns1.example.com.example.com"、"ns2.example.com.example.com"、およびリターンNSがこの不正確なRDATAと共に応答に記録するようにゾーンの正式のサーバはNS RDATAを分析するでしょう、"example.com"ゾーンからの記録を含むあらゆる応答の権威部を通常含んでいて。
Now consider a typical sequence of queries. An iterative resolver attempting to resolve address records for "www.example.com" with no cached information for this zone will query a "com" authoritative server. The "com" server responds with a referral to the "example.com" zone, consisting of NS records with valid RDATA and associated glue records. (This example assumes that the "example.com" zone delegation information is correct in the "com" zone.) The iterative resolver caches the NS RRSet from the "com" server and follows the referral by querying one of the "example.com" authoritative servers. This server responds with the "www.example.com" address record in the answer section and, typically, the "example.com" NS records in the authority section and, if space in the message remains, glue address records in the additional section. According to Section 5.4.1 of RFC 2181 [3], NS records in the authority section of an authoritative answer are more trustworthy than NS records from the authority section of a non- authoritative answer. Thus, the "example.com" NS RRSet just received from the "example.com" authoritative server overrides the "example.com" NS RRSet received moments ago from the "com" authoritative server.
今度は、質問の典型的な系列を考えてください。 このゾーンのためのキャッシュされた情報なしで"www.example.com"のためのアドレス記録を決議するのを試みる繰り返しのレゾルバは"com"正式のサーバについて質問するでしょう。"com"サーバは紹介で"example.com"ゾーンに反応します、有効なRDATAと関連接着剤記録でNS記録から成って。 (この例は、"example.com"ゾーン委譲情報が"com"ゾーンで正しいと仮定します。) 繰り返しのレゾルバは、"com"サーバからNS RRSetをキャッシュして、"example.com"正式のサーバの1つについて質問することによって、紹介に続きます。 答え部での"www.example.com"アドレス記録と権威部での通常"example.com"NS記録、およびメッセージのスペースが残っているときの接着剤アドレス記録が追加セクションにある状態で、このサーバは反応します。 .1セクション5.4RFC2181[3]によると、正式の答えの権威部でのNS記録は非正式の答えの権威部からのNS記録より信頼できます。 したがって、"example.com"NS RRSetは"example.com"正式のサーバオーバーライドから瞬間前に"com"正式のサーバから受け取られた"example.com"NS RRSetをただ受けました。
Larson & Barber Best Current Practice [Page 10] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[10ページ]RFC4697
But the "example.com" zone contains the erroneous NS RRSet as shown in the example above. Subsequent queries for names in "example.com" will cause the iterative resolver to attempt to use the incorrect NS records and so it will try to resolve the nonexistent names "ns1.example.com.example.com" and "ns2.example.com.example.com". In this example, since all of the zone's name servers are named in the zone itself (i.e., "ns1.example.com.example.com" and "ns2.example.com.example.com" both end in "example.com") and all are bogus, the iterative resolver cannot reach any "example.com" name servers. Therefore, attempts to resolve these names result in address record queries to the "com" authoritative servers. Queries for such obviously bogus glue address records occur frequently at the com/net name servers.
しかし、"example.com"ゾーンは上記の例に示されるように誤ったNS RRSetを含んでいます。 繰り返しのレゾルバが、"example.com"の名前のためのその後の質問で不正確なNS記録を使用するのを試みるので、それは実在しない名前"ns1.example.com.example.com"と"ns2.example.com.example.com"を決議しようとするでしょう。 この例では、ゾーンのネームサーバのすべてがゾーン自体で命名されて(すなわち、"ns1.example.com.example.com"と」の「ns2.example.com.example.com両方が"example.com"に終わります)、すべてがにせであるので、繰り返しのレゾルバはどんな"example.com"ネームサーバにも達することができません。 したがって、これらの名前がアドレスをもたらすと決議する試みは"com"正式のサーバに質問を記録します。 そのような明らかににせの接着剤アドレス記録のための質問はcom/ネットのネームサーバで頻出します。
2.6.1. Recommendation
2.6.1. 推薦
An authoritative server can detect this situation. A trailing dot missing from an NS record's RDATA always results by definition in a name server name that exists somewhere under the apex of the zone that the NS record appears in. Note that further levels of delegation are possible, so a missing trailing dot could inadvertently create a name server name that actually exists in a subzone.
正式のサーバはこの状況を検出できます。 NS記録のRDATAからなくなった引きずっているドットは定義上いつもNS記録が現れるゾーンの頂点の下のどこかに存在するネームサーバ名をもたらします。 なくなった引きずっているドットがうっかり実際に「副-ゾーン」に存在するネームサーバ名を作成できるように、委譲のさらなるレベルが可能であることに注意してください。
An authoritative name server SHOULD issue a warning when one of a zone's NS records references a name server below the zone's apex when a corresponding address record does not exist in the zone AND there are no delegated subzones where the address record could exist.
SHOULDがゾーンのNSのひとりが参照を記録するとき、対応するアドレス記録であるときに、ゾーンの頂点の下のネームサーバがゾーンに存在していなくて、また代表として派遣された「副-ゾーン」が全くアドレス記録が存在できたところにないという警告を発行する正式のネームサーバ。
2.7. Name Server Records with Zero TTL
2.7. TTLがないネームサーバ記録
Sometimes a popular com/net subdomain's zone is configured with a TTL of zero on the zone's NS records, which prohibits these records from being cached and will result in a higher query volume to the zone's authoritative servers. The zone's administrator should understand the consequences of such a configuration and provision resources accordingly. A zero TTL on the zone's NS RRSet, however, carries additional consequences beyond the zone itself: if an iterative resolver cannot cache a zone's NS records because of a zero TTL, it will be forced to query that zone's parent's name servers each time it resolves a name in the zone. The com/net authoritative servers do see an increased query load when a popular com/net subdomain's zone is configured with a TTL of zero on the zone's NS records.
時々ポピュラーなcom/ネットのサブドメインのゾーンは、ゾーンのNS記録のキャッシュされるのからこれらの記録を禁じるゼロのTTLによって構成されて、ゾーンの正式のサーバへの、より高い質問量をもたらすでしょう。 ゾーンの管理者はそれに従って、そのような構成と支給リソースの結果を理解するべきです。 しかしながら、ゾーンのNS RRSetの上のどんなTTLもゾーン自体を超えて追加結果を運びません: 繰り返しのレゾルバがTTLがないことのためにゾーンのNS記録をキャッシュできないと、それはゾーンで名前を決議するたびにやむを得ずそのゾーンの親のネームサーバについて質問するでしょう。 com/ネットの正式のサーバは、ポピュラーなcom/ネットのサブドメインのゾーンがゾーンのNS記録のゼロのTTLによって構成されるとき、増強された質問がロードされるのを見ます。
A zero TTL on an RRSet expected to change frequently is extreme but permissible. A zone's NS RRSet is a special case, however, because changes to it must be coordinated with the zone's parent. In most zone parent/child relationships that we are aware of, there is
RRSetの上のTTLが変えると予想したゼロは、頻繁に極端ですが、許されています。 ゾーンの親と共にそれへの変化を調整しなければならないので、しかしながら、ゾーンのNS RRSetは特別なケースです。 私たちが意識しているほとんどのゾーン親/子供関係には、あります。
Larson & Barber Best Current Practice [Page 11] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[11ページ]RFC4697
typically some delay involved in effecting changes. Furthermore, changes to the set of a zone's authoritative name servers (and therefore to the zone's NS RRSet) are typically relatively rare: providing reliable authoritative service requires a reasonably stable set of servers. Therefore, an extremely low or zero TTL on a zone's NS RRSet rarely makes sense, except in anticipation of an upcoming change. In this case, when the zone's administrator has planned a change and does not want iterative resolvers throughout the Internet to cache the NS RRSet for a long period of time, a low TTL is reasonable.
通常作用にかかわる何らかの遅れが変化します。 その上、通常、ゾーンの正式のネームサーバ(そしてしたがって、ゾーンのNS RRSetに)のセットへの変化は比較的まれです: 信頼できる正式のサービスを提供すると、サーバは合理的に安定したセットに要求されます。 したがって、非常に、安値にもかかわらず、ゾーンのNS RRSetの上のTTLがないのはめったに理解できません、今度の変化を除いて。 ゾーンの管理者が、変化を計画して、この場合インターネット中の繰り返しのレゾルバに長い年月の間NS RRSetをキャッシュして欲しくないときに、低いTTLは妥当です。
2.7.1. Recommendation
2.7.1. 推薦
Because of the additional load placed on a zone's parent's authoritative servers resulting from a zero TTL on a zone's NS RRSet, under such circumstances authoritative name servers SHOULD issue a warning when loading a zone.
ゾーンのNS RRSetの上のTTLから全く生じないゾーンの親の正式のサーバに置かれた追加負荷のために、ゾーンをロードするとき、これでは正式のネームサーバSHOULDは警報を出します。
2.8. Unnecessary Dynamic Update Messages
2.8. 不要なダイナミック・アップデートメッセージ
The UPDATE message specified in RFC 2136 [6] allows an authorized agent to update a zone's data on an authoritative name server using a DNS message sent over the network. Consider the case of an agent desiring to add a particular resource record. Because of zone cuts, the agent does not necessarily know the proper zone to which the record should be added. The dynamic update process requires that the agent determine the appropriate zone so the UPDATE message can be sent to one of the zone's authoritative servers (typically the primary master as specified in the zone's Start of Authority (SOA) record's MNAME field).
RFC2136[6]で指定されたUPDATEメッセージで、委任代理人は、ネットワークの上に送られたDNSメッセージを使用することで正式のネームサーバに関するゾーンのデータをアップデートできます。 特定のリソース記録を加えることを望んでいるエージェントのケースを考えてください。 ゾーンカットのために、エージェントは必ず、記録が追加されるべきである適切なゾーンを知っているというわけではありません。 ダイナミックな更新処理は、エージェントがゾーンの正式のサーバ(通常指定されるとしてのAuthority(SOA)記録のMNAME分野に関するゾーンのStartのプライマリマスター)の1つにUPDATEメッセージを送ることができるように適切なゾーンを決定するのを必要とします。
The appropriate zone to update is the closest enclosing zone, which cannot be determined only by inspecting the domain name of the record to be updated, since zone cuts can occur anywhere. One way to determine the closest enclosing zone entails walking up the name space tree by sending repeated UPDATE messages until successful. For example, consider an agent attempting to add an address record with the name "foo.bar.example.com". The agent could first attempt to update the "foo.bar.example.com" zone. If the attempt failed, the update could be directed to the "bar.example.com" zone, then the "example.com" zone, then the "com" zone, and finally the root zone.
アップデートするのが適切であるゾーンがアップデートするために単に記録のドメイン名を点検することによって決定できないゾーンを囲みながら、最も近くにあります、ゾーンカットがどこでも起こることができるので。 最も近くでゾーンを囲むのが、名前スペース木を発信することによって歩くのを伴うことを決定する1つの方法がうまくいくまでUPDATEメッセージを繰り返しました。 例えば、"foo.bar.example.com"という名前でアドレス記録を加えるのを試みるエージェントを考えてください。 エージェントは、最初に、"foo.bar.example.com"ゾーンをアップデートするのを試みることができました。 試みが失敗するなら、"bar.example.com"ゾーン、次に、"example.com"ゾーン、次に、"com"ゾーン、および最終的にルートゾーンにアップデートを向けることができるでしょうに。
A popular dynamic agent follows this algorithm. The result is many UPDATE messages received by the root name servers, the com/net authoritative servers, and presumably other TLD authoritative servers. A valid question is why the algorithm proceeds to send updates all the way to TLD and root name servers. This behavior is not entirely unreasonable: in enterprise DNS architectures with an
ポピュラーなダイナミックなエージェントはこのアルゴリズムに従います。 結果は、根のネームサーバによって受け取られた、多くのUPDATEメッセージと、com/ネットの正式のサーバと、おそらく他のTLDの正式のサーバです。 妥当な疑問はアルゴリズムがアップデートをTLDと根のネームサーバまでのいっぱいに送りかける理由です。 この振舞いは完全に無理ではありません: 企業DNSアーキテクチャ
Larson & Barber Best Current Practice [Page 12] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[12ページ]RFC4697
"internal root" design, there could conceivably be private, non- public TLD or root zones that would be the appropriate targets for a dynamic update.
「内部の根」デザイン、多分、個人的で、非公共のTLDかダイナミックなアップデートのための適切な目標であるルートゾーンがあるかもしれません。
A significant deficiency with this algorithm is that knowledge of a given UPDATE message's failure is not helpful in directing future UPDATE messages to the appropriate servers. A better algorithm would be to find the closest enclosing zone by walking up the name space with queries for SOA or NS rather than "probing" with UPDATE messages. Once the appropriate zone is found, an UPDATE message can be sent. In addition, the results of these queries can be cached to aid in determining the closest enclosing zones for future updates. Once the closest enclosing zone is determined with this method, the update will either succeed or fail and there is no need to send further updates to higher-level zones. The important point is that walking up the tree with queries yields cacheable information, whereas walking up the tree by sending UPDATE messages does not.
このアルゴリズムがある重要な欠乏は与えられたUPDATEメッセージの失敗に関する知識が将来のUPDATEメッセージを適切なサーバに向けるのに有用でないということです。 より良いアルゴリズムは最も近くで同封がゾーンであることがSOAかNSのために質問と共にUPDATEメッセージで「調べる」より名前スペースをむしろ歩くことによってわかるだろうことです。 いったん適切なゾーンを見つけると、UPDATEメッセージを送ることができます。 さらに、将来のアップデートのためにゾーンを囲みながら最も近いのを決定する際に支援するためにこれらの質問の結果をキャッシュできます。 アップデートは、成功するか、またはゾーンを囲むのがいったん最も近くでこのメソッドに決定するようになると、失敗するでしょう、そして、さらなるアップデートをよりハイレベルのゾーンに送る必要は全くありません。 重要なポイントは木をメッセージをUPDATEに送ることによって歩くのがもたらしませんが、質問と共に木を歩くのが「キャッシュ-可能」情報をもたらすということです。
2.8.1. Recommendation
2.8.1. 推薦
Dynamic update agents SHOULD send SOA or NS queries to progressively higher-level names to find the closest enclosing zone for a given name to update. Only after the appropriate zone is found should the client send an UPDATE message to one of the zone's authoritative servers. Update clients SHOULD NOT "probe" using UPDATE messages by walking up the tree to progressively higher-level zones.
ダイナミックなアップデートエージェントSHOULDは名がアップデートするゾーンを囲む最も近くで見つける次第によりハイレベルの名前への質問をSOAかNSに送ります。 適切なゾーンが見つけられた後にだけクライアントはゾーンの正式のサーバの1つにUPDATEメッセージを送るべきです。 アップデートクライアントSHOULD NOTは、木を次第によりハイレベルのゾーンまで歩くことによってUPDATEメッセージを使用することで「調べます」。
2.9. Queries for Domain Names Resembling IPv4 Addresses
2.9. IPv4アドレスに類似しているドメイン名のための質問
The root name servers receive a significant number of A record queries where the QNAME looks like an IPv4 address. The source of these queries is unknown. It could be attributed to situations where a user believes that an application will accept either a domain name or an IP address in a given configuration option. The user enters an IP address, but the application assumes that any input is a domain name and attempts to resolve it, resulting in an A record lookup. There could also be applications that produce such queries in a misguided attempt to reverse map IP addresses.
根のネームサーバはQNAMEがIPv4アドレスに似ているところで多くのA記録質問を受けます。 これらの質問の源は未知です。 それをユーザが、アプリケーションが与えられた設定オプションにおけるドメイン名かIPアドレスのどちらかを受け入れると信じている状況の結果と考えることができました。 ユーザがIPアドレスを入れますが、アプリケーションは、どんな入力もドメイン名であると仮定して、それを決議するのを試みます、A記録ルックアップをもたらして。 また、地図IPアドレスを逆にする見当違いの試みにおけるそのような質問を起こす利用があるかもしれません。
These queries result in Name Error (RCODE=3) responses. An iterative resolver can negatively cache such responses, but each response requires a separate cache entry; i.e., a negative cache entry for the domain name "192.0.2.1" does not prevent a subsequent query for the domain name "192.0.2.2".
これらの質問はName Error(RCODE=3)応答をもたらします。 繰り返しのレゾルバは否定的にそのような応答をキャッシュできますが、各応答は別々のキャッシュエントリーを必要とします。 すなわち、ドメイン名のための否定的キャッシュエントリー、「192.0に、0.1インチがする.2がドメイン名のためのその後の質問を防がない、「192.0 .2 0.2インチ、」
Larson & Barber Best Current Practice [Page 13] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[13ページ]RFC4697
2.9.1. Recommendation
2.9.1. 推薦
It would be desirable for the root name servers not to have to answer these queries: they unnecessarily consume CPU resources and network bandwidth. A possible solution is to delegate these numeric TLDs from the root zone to a separate set of servers to absorb the traffic. The "black hole servers" used by the AS 112 Project (http://www.as112.net), which are currently delegated the in-addr.arpa zones corresponding to RFC 1918 [7] private use address space, would be a possible choice to receive these delegations. Of course, the proper and usual root zone change procedures would have to be followed to make such a change to the root zone.
根のネームサーバがこれらの質問に答える必要はないのは、望ましいでしょう: 彼らは不必要にCPUリソースとネットワーク回線容量を消費します。 可能なソリューションはこれらの数値ルートゾーンから別々のセットのサーバまでのTLDsがトラフィックを吸収するのを代表として派遣することです。 RFC1918[7]私用アドレス空間に対応する現在代表として派遣されるAS112Project( http://www.as112.net )によって使用された「ブラックホールサーバ」addr.arpaゾーン、これらの委譲を受ける可能な選択でしょう。 もちろん、適切で普通のルートゾーン変化手順は、ルートゾーンへのそのような変更を行うために従われなければならないでしょう。
2.10. Misdirected Recursive Queries
2.10. 的外れの反復クエリー
The root name servers receive a significant number of recursive queries (i.e., queries with the Recursion Desired (RD) bit set in the header). Since none of the root servers offers recursion, the servers' response in such a situation ignores the request for recursion and the response probably does not contain the data the querier anticipated. Some of these queries result from users configuring stub resolvers to query a root server. (This situation is not hypothetical: we have received complaints from users when this configuration does not work as hoped.) Of course, users should not direct stub resolvers to use name servers that do not offer recursion, but we are not aware of any stub resolver implementation that offers any feedback to the user when so configured, aside from simply "not working".
根のネームサーバは多くの反復クエリーを受けます(すなわち、Recursion Desired(RD)ビットによる質問はヘッダーにセットしました)。 ルートサーバーのいずれも再帰を提供しないので、そのような状況におけるサーバの応答は再帰を求める要求を無視します、そして、応答はたぶんquerierが予期したデータを含んでいません。 これらの或るものはルートサーバーについて質問するためにスタッブレゾルバを構成するユーザから結果について質問します。. (この状況は仮定していません: 私たちはこの構成が望まれているように働いていないユーザから苦情を受けました。) もちろん、ユーザは再帰を提供しないネームサーバを使用するようスタッブレゾルバに指示するべきではありませんが、私たちはそのように構成されるとどんなフィードバックもユーザに提供するどんなスタッブレゾルバ実装も意識していません、単に「働いていないこと」は別として。
2.10.1. Recommendation
2.10.1. 推薦
When the IP address of a name server that supposedly offers recursion is configured in a stub resolver using an interactive user interface, the resolver could send a test query to verify that the server indeed supports recursion (i.e., verify that the response has the RA bit set in the header). The user could be notified immediately if the server is non-recursive.
推定上再帰を提供するネームサーバのIPアドレスがスタッブレゾルバで対話的なユーザーインタフェースを使用することで構成されるとき、レゾルバは、本当に、サーバが再帰をサポートすることを確かめるためにテスト質問を送ることができました(すなわち、ヘッダーに応答でRAビットを設定することを確かめてください)。 サーバが非再帰的であるなら、ユーザはすぐに、通知されるかもしれません。
The stub resolver could also report an error, either through a user interface or in a log file, if the queried server does not support recursion. Error reporting SHOULD be throttled to avoid a notification or log message for every response from a non-recursive server.
また、スタッブレゾルバはユーザーインタフェースを通した、または、ログファイルにおける誤りを報告できました、質問されたサーバが再帰をサポートしないなら。 SHOULDが非再帰的なサーバからあらゆる応答への通知かログメッセージを避けるために阻止されると報告する誤り。
Larson & Barber Best Current Practice [Page 14] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[14ページ]RFC4697
2.11. Suboptimal Name Server Selection Algorithm
2.11. 準最適のネームサーバ選択アルゴリズム
An entire document could be devoted to the topic of problems with different implementations of the recursive resolution algorithm. The entire process of recursion is woefully under-specified, requiring each implementor to design an algorithm. Sometimes implementors make poor design choices that could be avoided if a suggested algorithm and best practices were documented, but that is a topic for another document.
再帰的な解決アルゴリズムの異なった実装に関する問題の話題に全体のドキュメントをささげることができました。 各作成者がアルゴリズムを設計するのが必要であることで、再帰の全体のプロセスは下の悲惨に指定されています。 作成者は提案されたアルゴリズムと最も良い習慣が記録されたなら時々、避けることができた不十分なデザイン選択をしますが、それは別のドキュメントのための話題です。
Some deficiencies cause significant operational impact and are therefore worth mentioning here. One of these is name server selection by an iterative resolver. When an iterative resolver wants to contact one of a zone's authoritative name servers, how does it choose from the NS records listed in the zone's NS RRSet? If the selection mechanism is suboptimal, queries are not spread evenly among a zone's authoritative servers. The details of the selection mechanism are up to the implementor, but we offer some suggestions.
いくつかの欠乏は、重要な操作上の影響を引き起こして、したがって、ここに言及する価値があります。 これらの1つは繰り返しのレゾルバによるネームサーバ選択です。繰り返しのレゾルバがゾーンの正式のネームサーバの1つに連絡したがっているとき、それはゾーンのNS RRSetにリストアップされたNS記録からどのように選ばれますか? 選択メカニズムが準最適であるなら、質問はゾーンの正式のサーバの中で均等に広げられません。 選択メカニズムの細部は作成者次第ですが、私たちはいくつかの提案を提供します。
2.11.1. Recommendation
2.11.1. 推薦
This list is not conclusive, but reflects the changes that would produce the most impact in terms of reducing disproportionate query load among a zone's authoritative servers. That is, these changes would help spread the query load evenly.
このリストは、決定的ではありませんが、ゾーンの正式のサーバの中で不均衡な質問負荷を減少させることに関して最も多くの影響を生産する変化を反映します。 すなわち、これらの変化は、均等に質問負荷を広げるのを助けるでしょう。
o Do not make assumptions based on NS RRSet order: all NS RRs SHOULD
be treated equally. (In the case of the "com" zone, for example,
most of the root servers return the NS record for
"a.gtld-servers.net" first in the authority section of referrals.
Apparently as a result, this server receives disproportionately
more traffic than the other twelve authoritative servers for
"com".)
o NS RRSetオーダーに基づく仮定をしないでください: すべてのNS RRs SHOULD、等しく扱われてください。 ("com"ゾーンの場合では、例えば、ルートサーバーの大部分は最初に、紹介の権威部で「a.gtld-servers.net」のためのNS記録を返します。 明らかにその結果、このサーバは"com"のために他の12の正式のサーバより不均衡に多くのトラフィックを受けます。)
o Use all NS records in an RRSet. (For example, we are aware of
implementations that hard-coded information for a subset of the
root servers.)
o RRSetでのすべてのNS記録を使用してください。 (例えば、私たちはルートサーバーの部分集合のためにそんなに確実なコード化された情報で実装を意識しています。)
o Maintain state and favor the best-performing of a zone's
authoritative servers. A good definition of performance is
response time. Non-responsive servers can be penalized with an
extremely high response time.
o 状態を維持してください、そして、ゾーンの正式のサーバについて最も上手に実行しているのを支持してください。 性能の良い定義は応答時間です。 非常に高い応答時間で非敏感なサーバを罰することができます。
o Do not lock onto the best-performing of a zone's name servers. An
iterative resolver SHOULD periodically check the performance of
all of a zone's name servers to adjust its determination of the
best-performing one.
o ゾーンのネームサーバについて最も上手に実行しているのを自動追跡しないでください。 繰り返しのレゾルバSHOULDは定期的にゾーンのネームサーバのすべてが最も上手に実行しているものの決断を調整する性能をチェックします。
Larson & Barber Best Current Practice [Page 15] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[15ページ]RFC4697
3. Security Considerations
3. セキュリティ問題
The iterative resolver misbehavior discussed in this document exposes the root and TLD name servers to increased risk of both intentional and unintentional Denial of Service attacks.
本書では議論した繰り返しのレゾルバ不正行為は、根とTLDがネームサーバであると意図的なものと同様に意図的でないサービス妨害攻撃の増強されたリスクに暴露します。
We believe that implementation of the recommendations offered in this document will reduce the amount of unnecessary traffic seen at root and TLD name servers, thus reducing the opportunity for an attacker to use such queries to his or her advantage.
私たちは、本書では提供された推薦の実装が根とTLDネームサーバで見られた不要なトラフィックの量を減少させると信じています、その結果、攻撃者がその人の利点にそのような質問を使用する機会を減少させます。
4. Acknowledgements
4. 承認
The authors would like to thank the following people for their comments that improved this document: Andras Salamon, Dave Meyer, Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy, Olafur Gudmundsson, Pekka Savola, Peter Koch, and Rob Austein. We apologize if we have omitted anyone; any oversight was unintentional.
作者はこのドキュメントを改良した彼らのコメントについて以下の人々に感謝したがっています: Andras Salamon、デーヴ・マイヤー、ダグ・バートン、Jaap Akkerhuis、Jinmei Tatuya、ジョン・ブレイディ、ケビン・ダーシー、Olafurグドムンソン、ペッカSavola、ピーター・コッホ、およびロブAustein。 だれでも省略したなら、私たちは謝ります。 どんな見落としも意図的ではありませんでした。
5. Internationalization Considerations
5. 国際化問題
There are no new internationalization considerations introduced by this memo.
このメモで紹介されたどんな新しい国際化問題もありません。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
6.2. Informative References
6.2. 有益な参照
[3] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
RFC 2181, July 1997.
[3]ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
[4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
2308, March 1998.
[4] アンドリュース、M.、「DNS質問(DNS NCACHE)の否定的キャッシュ」、RFC2308、1998年3月。
[5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
Queries for IPv6 Addresses", RFC 4074, May 2005.
[5] 森下、Y.、およびT.Jinmei(「IPv6アドレスのためのDNS質問に対する一般的な不正行為」、RFC4074)は2005がそうするかもしれません。
[6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
1997.
Vixie、P.、トムソン、S.、Rekhter、Y.、およびJ.が縛った[6]、「ドメインネームシステムにおけるダイナミックなアップデート(DNSアップデート)」、RFC2136(1997年4月)。
Larson & Barber Best Current Practice [Page 16] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[16ページ]RFC4697
[7] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E.
Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.
[7]Rekhter、Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
Authors' Addresses
作者のアドレス
Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
マットラーソンベリサインInc.21345屋根の頂円のヴァージニア20166-6503ダレス(米国)
EMail: mlarson@verisign.com
メール: mlarson@verisign.com
Piet Barber VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
ピートバーバーベリサインInc.21345屋根の頂円のヴァージニア20166-6503ダレス(米国)
EMail: pbarber@verisign.com
メール: pbarber@verisign.com
Larson & Barber Best Current Practice [Page 17] RFC 4697 Observed DNS Resolution Misbehavior October 2006
DNS解決不正行為2006年10月に観察されたラーソンとバーバー最も良い現在の習慣[17ページ]RFC4697
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Larson & Barber Best Current Practice [Page 18]
ラーソンと床屋の最も良い現在の習慣[18ページ]
一覧
スポンサーリンク
