[要約] RFC 7646は、DNSSECネガティブトラストアンカーの定義と使用に関するものであり、DNSSECのセキュリティ拡張機能を活用するためのガイドラインを提供しています。このRFCの目的は、DNSSECのネガティブトラストアンカーの概念を明確にし、その使用方法を説明することです。
Internet Engineering Task Force (IETF) P. Ebersman
Request for Comments: 7646 Comcast
Category: Informational W. Kumari
ISSN: 2070-1721 Google
C. Griffiths
Nominet
J. Livingood
Comcast
R. Weber
Nominum
September 2015
Definition and Use of DNSSEC Negative Trust Anchors
DNSSECネガティブトラストアンカーの定義と使用
Abstract
概要
DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes. This document defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains.
DNS Security Extensions（DNSSEC）は現在、広範囲に展開されています。ただし、ドメイン署名ツールとプロセスは、DNSSECに関連しないドメイン管理ツールとプロセスほどには成熟しておらず、信頼性が高くありません。このドキュメントでは、指定されたドメインでDNSSEC検証を無効にすることでDNSSEC検証エラーを軽減するために使用できるネガティブトラストアンカー（NTA）を定義しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7646.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7646で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction and Motivation .....................................3
1.1. Definition of a Negative Trust Anchor ......................3
1.2. Motivations for Negative Trust Anchors .....................4
1.2.1. Mitigating Domain Validation Failures ...............4
1.2.2. Improving End-User Experience .......................4
1.2.3. Avoiding Switching to a Non-validating Resolver .....5
2. Use of a Negative Trust Anchor ..................................5
2.1. Applicability of Negative Trust Anchors ....................6
3. Managing Negative Trust Anchors .................................7
3.1. Alerting Users to Negative Trust Anchor Use ................7
4. Removal of a Negative Trust Anchor ..............................7
5. Comparison to Other DNS Misconfigurations .......................8
6. Intentionally Broken Domains ....................................8
7. Discovering Broken Domains ......................................9
8. Security Considerations ........................................11
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................12
Appendix A. Configuration Examples ...............................13
A.1. NLnet Labs Unbound ........................................13
A.2. Internet System Consortium (ISC) BIND .....................14
A.3. Nominum Vantio ............................................14
Acknowledgements ..................................................15
Authors' Addresses ................................................15
DNSSEC has now entered widespread deployment. However, the DNSSEC signing tools and processes are less mature and reliable than those for non-DNSSEC-related administration. As a result, operators of DNS recursive resolvers, such as Internet Service Providers (ISPs), occasionally observe domains incorrectly managing DNSSEC-related resource records. This mismanagement triggers DNSSEC validation failures and then causes large numbers of end users to be unable to reach a domain. Many end users tend to interpret this as a failure of their ISP or resolver operator, and they may switch to a non-validating resolver or contact their ISP to complain, rather than seeing this as a failure on the part of the domain they wanted to reach. Without the techniques in this document, this pressure may cause the resolver operator to disable (or simply not deploy) DNSSEC validation.
DNSSECは今や広範囲に及ぶ展開に入りました。ただし、DNSSEC署名ツールとプロセスは、非DNSSEC関連の管理用のものよりも成熟度が低く、信頼性が低いです。その結果、インターネットサービスプロバイダー（ISP）などのDNS再帰リゾルバーのオペレーターは、DNSSEC関連のリソースレコードを誤って管理しているドメインを観察することがあります。この誤った管理によりDNSSEC検証エラーがトリガーされ、多数のエンドユーザーがドメインにアクセスできなくなります。多くのエンドユーザーは、これをISPまたはリゾルバーオペレーターの障害として解釈する傾向があり、ドメインの一部の障害としてこれを見るのではなく、非検証リゾルバーに切り替えるか、ISPに連絡して不満を言う場合があります。リーチ。このドキュメントの手法がないと、このプレッシャーにより、リゾルバーオペレーターがDNSSEC検証を無効にする（または単に展開しない）可能性があります。
This document defines Negative Trust Anchors (NTAs), which can be used during the transition to ubiquitous DNSSEC deployment. NTAs are configured locally on a validating DNS recursive resolver to shield end users from DNSSEC-related authoritative name server operational errors. NTAs are intended to be temporary and only implemented by the organization requiring an NTA (and not distributed by any organizations outside of the administrative boundary). Finally, NTAs pertain only to DNSSEC and not to Public Key Infrastructures (PKIs) such as X.509.
このドキュメントでは、ユビキタスDNSSEC展開への移行中に使用できるネガティブトラストアンカー（NTA）を定義しています。 NTAは、検証中のDNS再帰リゾルバでローカルに構成され、エンドユーザーをDNSSEC関連の信頼できるネームサーバーの操作エラーから保護します。 NTAは一時的なものであり、NTAを必要とする組織によってのみ実装されることを意図しています（管理境界外の組織によって配布されることはありません）。最後に、NTAはDNSSECにのみ関係し、X.509などの公開キー基盤（PKI）には関係しません。
Use of an NTA to temporarily disable DNSSEC validation for a specific misconfigured domain name immediately restores access for end users. This allows the domain's administrators to fix their misconfiguration while also allowing the organization using the NTA to keep DNSSEC validation enabled and still reach the misconfigured domain.
NTAを使用して、特定の誤って構成されたドメイン名のDNSSEC検証を一時的に無効にすると、エンドユーザーのアクセスが直ちに復元されます。これにより、ドメインの管理者は、構成の誤りを修正すると同時に、NTAを使用する組織がDNSSEC検証を有効にしたまま、構成の誤ったドメインに到達できるようにすることができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
Trust anchors are defined in [RFC5914]. A trust anchor is used by a validating caching resolver as a starting point for building the authentication chain for a signed DNS response. By way of analogy, NTAs stop validation of the authentication chain. Instead, the validator treats any upstream responses as if the zone is unsigned and does not set the Authentic Data (AD) bit in responses it sends to clients. Note that this is a behavior and not a separate resource record. This NTA can potentially be implemented at any level within the chain of trust and would stop validation from that point in the chain down. Validation starts again if there is a positive trust anchor further down in the chain. For example, if there is an NTA at example.com and a positive trust anchor at foo.bar.example.com, then validation resumes for foo.bar.example.com and anything below it.
トラストアンカーは[RFC5914]で定義されています。トラストアンカーは、署名済みDNS応答の認証チェーンを構築するための開始点として、検証キャッシングリゾルバーによって使用されます。類推として、NTAは認証チェーンの検証を停止します。代わりに、検証ツールは上流の応答をゾーンが署名されていないものとして処理し、クライアントに送信する応答に認証データ（AD）ビットを設定しません。これは動作であり、個別のリソースレコードではないことに注意してください。このNTAは、信頼の連鎖内の任意のレベルで実装できる可能性があり、連鎖のその時点から検証を停止します。チェーンのさらに下にポジティブトラストアンカーがある場合、検証が再び開始されます。たとえば、example.comにNTAがあり、foo.bar.example.comに正のトラストアンカーがある場合、foo.bar.example.comとその下のすべての検証が再開されます。
A domain name can fail validation for two general reasons: a legitimate security failure (e.g., due to an attack or compromise of some sort) or as a result of misconfiguration on the part of a zone administrator. As domains transition to DNSSEC, the most common reason for a validation failure has been misconfiguration. Thus, domain administrators should be sure to read [RFC6781] in full. They should pay special attention to Section 4.2 of [RFC6781], which pertains to key rollovers, as these appear to be the cause of many recent validation failures.
ドメイン名は、2つの一般的な理由で検証に失敗する可能性があります。正当なセキュリティ障害（たとえば、何らかの攻撃や侵害によるもの）か、ゾーン管理者側の設定ミスの結果です。ドメインがDNSSECに移行する際、検証が失敗する最も一般的な理由は、構成の誤りです。したがって、ドメイン管理者は必ず[RFC6781]を完全に読んでください。主要なロールオーバーに関連する[RFC6781]のセクション4.2に特に注意を払う必要があります。これは、最近の多くの検証失敗の原因であると思われるためです。
It is also possible that some DNSSEC validation failures could arise due to differences in how different software developers interpret DNSSEC standards and/or how those developers choose to implement support for DNSSEC. For example, it is conceivable that a domain may be DNSSEC-signed properly, and one vendor's DNS recursive resolvers will validate the domain but other vendors' software may fail to validate the domain.
また、ソフトウェア開発者がDNSSEC標準をどのように解釈するか、または開発者がDNSSECのサポートの実装を選択する方法が異なるために、DNSSEC検証の失敗が発生する可能性もあります。たとえば、ドメインがDNSSECで適切に署名されている可能性があり、あるベンダーのDNS再帰リゾルバーがドメインを検証しますが、他のベンダーのソフトウェアはドメインの検証に失敗する場合があります。
End users generally do not know of, understand, or care about the resolution process that causes connections to happen. This is by design: the point of the DNS is to insulate users from having to remember IP addresses through a friendlier way of naming systems. It follows from this that end users do not, and should not, be expected to know about DNSSEC, validation, or anything of the sort. As a result, end users may misinterpret the failure to reach a domain due to DNSSEC-related misconfiguration. They may (incorrectly) assume that their ISP is purposely blocking access to the domain or that it is a performance failure on the part of their ISP (especially of the ISP's DNS servers). They may contact their ISP to complain, which will incur cost for their ISP. In addition, they may use online tools and sites to complain about this problem, such as via a blog, web forum, or social media site, which may lead to dissatisfaction on the part of other end users or general criticism of an ISP or operator of a DNS recursive resolver.
エンドユーザーは、通常、接続を発生させる解決プロセスを知らない、理解しない、または気にしません。これは設計によるものです。DNSの目的は、より使いやすいネーミングシステムを使用して、ユーザーがIPアドレスを覚えておく必要がないようにすることです。このことから、エンドユーザーはDNSSEC、検証、またはそのようなものについて知っていることを期待されていないはずです。その結果、エンドユーザーはDNSSEC関連の設定ミスが原因で、ドメインに到達できないことを誤って解釈する可能性があります。 ISPが故意にドメインへのアクセスをブロックしている、またはISP（特にISPのDNSサーバー）のパフォーマンス障害であると（誤って）想定している場合があります。彼らは不満を言うために彼らのISPに連絡するかもしれません、そしてそれは彼らのISPに費用がかかるでしょう。さらに、オンラインツールやサイトを使用して、ブログ、ウェブフォーラム、ソーシャルメディアサイトなどを通じてこの問題について不満を言う可能性があり、他のエンドユーザーの不満やISPやオペレーターに対する一般的な批判につながる可能性があります。 DNS再帰リゾルバの。
As end users publicize these failures, others may recommend they switch from security-aware DNS resolvers to resolvers not performing DNSSEC validation. This is a shame since the ISP or other DNS recursive resolver operator is actually doing exactly what they are supposed to do in failing to resolve a domain name; this is the expected result when a domain can no longer be validated, and it protects end users from a potential security threat. Use of an NTA would allow the ISP to specifically remedy the failure to reach that domain, without compromising security for other sites. This would result in a satisfied end user, with minimal impact to the ISP, while maintaining the security of DNSSEC for correctly maintained domains.
エンドユーザーがこれらの障害を公表するときに、セキュリティ対応DNSリゾルバーからDNSSEC検証を実行しないリゾルバーに切り替えることを推奨するユーザーもいます。 ISPや他のDNS再帰リゾルバーオペレーターが実際にドメイン名の解決に失敗した場合に行うべきことを正確に実行しているので、これは残念です。これは、ドメインを検証できなくなった場合に予想される結果であり、潜在的なセキュリティ脅威からエンドユーザーを保護します。 NTAを使用すると、ISPは、他のサイトのセキュリティを損なうことなく、そのドメインへの到達の失敗を明確に解決できます。これにより、ISPへの影響を最小限に抑えながら、エンドユーザーを満足させると同時に、正しく維持されたドメインのDNSSECのセキュリティを維持できます。
The following text from [RFC4033] is worth noting: "In the final analysis, however, authenticating both DNS keys and data is a matter of local policy, which may extend or even override the protocol extensions defined in this document set." A responsibility (one of many) of a caching server operator is to protect the integrity of the cache.
[RFC4033]の次のテキストは注目に値します：「しかし、最終的な分析では、DNSキーとデータの両方の認証はローカルポリシーの問題であり、このドキュメントセットで定義されたプロトコル拡張を拡張またはオーバーライドする場合さえあります。」キャッシングサーバーオペレーターの責任（多くの1つ）は、キャッシュの整合性を保護することです。
As noted in Section 1.2.2, some people may consider switching to an alternative, non-validating resolver themselves, or may recommend that others do so. But if a domain fails DNSSEC validation and is inaccessible, this could very well be due to a security-related issue. In order to be as safe and secure as possible, end users should not change to DNS servers that do not perform DNSSEC validation as a workaround, and people should not recommend that others do so either. Domains that fail DNSSEC for legitimate reasons (versus misconfiguration) may be in control of hackers, or there could be other significant security issues with the domain.
セクション1.2.2で述べたように、一部の人々は、代替の検証されていないリゾルバへの切り替えを自分で検討するか、他の人にそうすることを勧めることがあります。しかし、ドメインがDNSSEC検証に失敗し、アクセスできない場合は、セキュリティ関連の問題が原因である可能性が非常に高いです。エンドユーザーは、できる限り安全で安全なものにするために、回避策としてDNSSEC検証を実行しないDNSサーバーに変更しないでください。また、他のユーザーもそうすることを推奨しないでください。正当な理由（構成の誤り）でDNSSECに失敗したドメインは、ハッカーの制御下にあるか、ドメインに他の重大なセキュリティ問題がある可能性があります。
Thus, switching to a non-validating resolver to restore access to a domain that fails DNSSEC validation is not a recommended practice, is bad advice to others, and is potentially harmful to end-user security.
したがって、DNSSEC検証に失敗したドメインへのアクセスを復元するために非検証リゾルバーに切り替えることは推奨される方法ではなく、他のユーザーに悪いアドバイスであり、エンドユーザーのセキュリティに潜在的に有害です。
Technical personnel trained in the operation of DNS servers must confirm that a DNSSEC validation failure is due to misconfiguration, as a similar breakage could have occurred if an attacker gained access to a domain's authoritative servers and modified those records or had the domain pointed to their own rogue authoritative servers. They should also confirm that the domain is not intentionally broken, such as for testing purposes as noted in Section 6. Finally, they should make a reasonable attempt to contact the domain owner of the misconfigured zone, preferably prior to implementing the NTA.
攻撃者がドメインの権限のあるサーバーにアクセスし、それらのレコードを変更したり、ドメインを自分のものに指定したりすると、同様の破損が発生する可能性があるため、DNSサーバーの操作に関するトレーニングを受けた技術担当者は、DNSSEC検証の失敗が設定ミスによるものであることを確認する必要があります。不正な権威サーバー。また、セクション6に記載されているテストの目的などで、ドメインが意図的に破壊されていないことも確認する必要があります。最後に、できればNTAを実装する前に、誤構成されたゾーンのドメイン所有者に連絡するための合理的な試みを行う必要があります。
Involving trained technical personnel is costly, but operational experience suggests that this is a very rare event, usually on the order of once per quarter (or even less).
訓練を受けた技術担当者の関与は費用がかかりますが、運用上の経験から、これは非常にまれなイベントであり、通常は四半期に1回程度（またはそれ以下）です。
It is important for the resolver operator to confirm that the domain is still under the ownership/control of the legitimate owner of the domain in order to ensure that disabling validation for a specific domain does not direct users to an address under an attacker's control. Contacting the domain owner and telling them the DNSSEC records that the resolver operator is seeing allows the resolver operator to determine if the issue is a DNSSEC misconfiguration or an attack.
特定のドメインの検証を無効にしてもユーザーが攻撃者の制御下にあるアドレスに誘導されないようにするには、リゾルバーオペレーターがドメインがドメインの正当な所有者の所有権/管理下にあることを確認することが重要です。ドメイン所有者に連絡して、リゾルバーオペレーターが確認しているDNSSECレコードを通知すると、リゾルバーオペレーターは、問題がDNSSECの構成ミスか攻撃かを判断できます。
In the case of a validation failure due to misconfiguration of a Top-Level Domain (TLD) or popular domain name (such as a top 100 website), content or services in the affected TLD or domain could be inaccessible for a large number of users. In such cases, it may be appropriate to use an NTA as soon as the misconfiguration is confirmed. An example of a list of "top N" websites is the Alexa "Top 500 Sites on the Web" [Alexa] or a list of the of the most-accessed names in the resolver's cache.
トップレベルドメイン（TLD）または人気のあるドメイン名（トップ100のWebサイトなど）の設定ミスによる検証エラーの場合、影響を受けるTLDまたはドメインのコンテンツまたはサービスに多数のユーザーがアクセスできなくなる可能性があります。このような場合、設定ミスが確認されたらすぐにNTAを使用するのが適切な場合があります。 「上位N」のWebサイトのリストの例は、Alexaの「Web上の上位500サイト」[Alexa]またはリゾルバーのキャッシュで最もアクセスされている名前のリストです。
Once a domain has been confirmed to fail DNSSEC validation due to a DNSSEC-related misconfiguration, an ISP or other DNS recursive resolver operator may elect to use an NTA for that domain or sub-domain. This instructs their DNS recursive resolver to temporarily NOT perform DNSSEC validation at or in the misconfigured domain. This immediately restores access to the domain for end users while the domain's administrator corrects the misconfiguration(s). It does not and should not involve turning off validation more broadly.
DNSSEC関連の設定ミスによりドメインがDNSSEC検証に失敗したことが確認されると、ISPまたはその他のDNS再帰リゾルバーオペレーターは、そのドメインまたはサブドメインにNTAを使用することを選択できます。これは、DNS再帰リゾルバに、誤って構成されたドメインまたはそのドメインでDNSSEC検証を一時的に実行しないように指示します。これにより、ドメインの管理者が構成の誤りを修正する一方で、エンドユーザーのドメインへのアクセスが直ちに復元されます。検証をより広範囲にオフにすることは含まれません。
An NTA MUST only be used for a limited duration. Implementors SHOULD allow the operator using the NTA to set an end time and date associated with any NTA. Optimally, this time and date is set in a DNS recursive resolver's configuration, though in the short term, this may also be achieved via other systems or supporting processes. Use of an NTA MUST NOT be automatic.
NTAは、限られた期間のみ使用する必要があります。実装者は、NTAを使用するオペレーターがNTAに関連付けられた終了日時を設定できるようにする必要があります（SHOULD）。理想的には、この日時はDNS再帰リゾルバーの構成で設定されますが、短期的には、これは他のシステムまたはサポートプロセスを介して実現することもできます。 NTAの使用は自動であってはなりません。
Finally, an NTA SHOULD be used only in a specific domain or sub-domain and MUST NOT affect validation of other names up the authentication chain. For example, an NTA for zone1.example.com would affect only names at or below zone1.example.com, and validation would still be performed on example.com, .com, and the root ("."). This NTA also SHOULD NOT affect names in another branch of the tree (such as example.net). In another example, an NTA for example.com would affect only names within example.com, and validation would still be performed on .com and the root ("."). In this scenario, if there is a (probably manually configured) trust anchor for zone1.example.com, validation would be performed for zone1.example.com and subdomains of zone1.example.com.
最後に、NTAは特定のドメインまたはサブドメインでのみ使用する必要があり（SHOULD）、認証チェーンの他の名前の検証に影響を与えてはなりません（MUST NOT）。たとえば、zone1.example.comのNTAは、zone1.example.com以下の名前にのみ影響し、example.com、.com、およびルート（ "。"）でも検証が実行されます。このNTAは、ツリーの別のブランチ（example.netなど）の名前にも影響を与えないでください。別の例では、example.comのNTAはexample.com内の名前にのみ影響し、検証は引き続き.comおよびルート（ "。"）で実行されます。このシナリオでは、zone1.example.comに（おそらく手動で設定された）トラストアンカーがある場合、zone1.example.comとzone1.example.comのサブドメインに対して検証が実行されます。
While NTAs have proven useful during the early stages of DNSSEC adoption, domain owners are ultimately responsible for managing and ensuring that their DNS records are configured correctly.
NTAはDNSSEC採用の初期段階で有用であることが証明されていますが、ドメイン所有者は最終的にDNSレコードが正しく構成されていることを管理および保証する責任があります。
Most current implementations of DNS validating resolvers currently follow [RFC4033] on configuring a trust anchor using either a public key as in a DNSKEY resource record (RR) or a hash of a public key as in a DS RR.
DNS検証リゾルバーの最新の実装は、現在[RFC4033]に従い、DNSKEYリソースレコード（RR）のような公開鍵またはDS RRのような公開鍵のハッシュを使用して、トラストアンカーを構成しています。
Different DNS validators may have different configuration names for an NTA. For examples, see Appendix A.
異なるDNSバリデーターでは、NTAの構成名が異なる場合があります。例については、付録Aを参照してください。
An NTA placed at a node where there is a configured positive trust anchor MUST take precedence over that trust anchor, effectively disabling it. Implementations MAY issue a warning or informational message when this occurs, so that operators are not surprised when this happens.
構成された正のトラストアンカーがあるノードに配置されたNTAは、そのトラストアンカーよりも優先され、事実上それを無効にする必要があります。実装は、これが発生したときに警告または情報メッセージを発行することができるので、これが発生してもオペレーターは驚かないでしょう。
End users of a DNS recursive resolver or other people may wonder why a domain that fails DNSSEC validation resolves with a supposedly validating resolver. Therefore, implementors should consider transparently disclosing NTAs that are currently in place or were in place in the past, such as on a website [Disclosure-Example].
DNS再帰リゾルバのエンドユーザーまたは他の人々は、DNSSEC検証に失敗したドメインが、おそらく検証を行うリゾルバで解決するのか疑問に思うかもしれません。したがって、実装者は、現在実施されている、または過去に実施されたNTAを、Webサイト[開示例]などで透過的に開示することを検討する必要があります。
This is particularly important since there is currently no special DNS query response code that could indicate to end users or applications that an NTA is in place. Such disclosures should optimally include both the data and time that the NTA was put in place and when it was removed.
NTAが設定されていることをエンドユーザーまたはアプリケーションに示すことができる特別なDNSクエリ応答コードは現在ないため、これは特に重要です。そのような開示には、国税庁が設置された日時とそれがいつ削除されたかを、最適に含める必要があります。
As explored in Section 8, using an NTA once the zone correctly validates can have security considerations. It is therefore RECOMMENDED that NTA implementors should periodically attempt to validate the domain in question, for the period of time that the NTA is in place, until such validation is again successful. NTAs MUST expire automatically when their configured lifetime ends. The lifetime SHOULD NOT exceed a week. There is limited experience with what this value should be, but at least one large vendor has documented customer feedback suggesting that a week is reasonable based on expectations of how long failures take to fix or to be forgotten. Operational experience may further refine these expectations.
セクション8で説明したように、ゾーンが正しく検証されたらNTAを使用すると、セキュリティ上の考慮事項が生じる可能性があります。したがって、NTAの実装者は、NTAが実施されている期間、問題のあるドメインの検証が定期的に試行され、検証が再び成功するまで推奨されることをお勧めします。 NTAは、構成された有効期間が終了すると自動的に期限切れになる必要があります。存続期間は1週間を超えてはなりません。この値がどうあるべきかについての経験は限られていますが、少なくとも1つの大手ベンダーが顧客のフィードバックを文書化しており、障害が修正または忘れられるまでにかかる時間の予想に基づいて1週間が妥当であると示唆しています。運用経験は、これらの期待をさらに改善する可能性があります。
Before removing the NTA, all authoritative resolvers listed in the zone should be checked (due to anycast and load balancers, it may not be possible to check all instances).
NTAを削除する前に、ゾーンにリストされているすべての信頼できるリゾルバーを確認する必要があります（エニーキャストおよびロードバランサーのため、すべてのインスタンスを確認できない場合があります）。
Once all testing succeeds, an NTA should be removed as soon as is reasonably possible. One possible method to automatically determine when the NTA can be removed is to send a periodic query for type Start of Authority (SOA) at the NTA node; if it gets a response that it can validate (whether the response was an actual SOA answer or a NOERROR/NODATA with appropriate NSEC/NSEC3 records), the NTA is presumed no longer to be necessary and is removed. Implementations SHOULD, by default, perform this operation. Note that under some circumstances, this is undesirable behavior (for example, if www.example.com has a bad signature, but example.com/SOA is fine), so implementations may wish to allow the operator to override this spot-check/behavior.
すべてのテストが成功したら、合理的に可能な限り早くNTAを削除する必要があります。 NTAをいつ削除できるかを自動的に判断する1つの可能な方法は、NTAノードでStart of Authority（SOA）タイプの定期的なクエリを送信することです。検証できる応答を受け取った場合（応答が実際のSOA応答であるか、適切なNSEC / NSEC3レコードを含むNOERROR / NODATAであるかに関係なく）、NTAは不要であると見なされて削除されます。実装では、デフォルトでこの操作を実行する必要があります。一部の状況下では、これは望ましくない動作です（たとえば、www.example.comの署名が悪いが、example.com / SOAは問題ない場合）。そのため、実装では、オペレーターがこのスポットチェックをオーバーライドできるようにする場合があります。動作。
When removing the NTA, the implementation SHOULD remove all cached entries at and below the NTA node.
NTAを削除する場合、実装はNTAノード以下のキャッシュされたエントリをすべて削除する必要があります（SHOULD）。
Domain administrators are ultimately responsible for managing and ensuring their DNS records are configured correctly. ISPs or other DNS recursive resolver operators cannot and should not correct misconfigured A, CNAME, MX, or other resource records of domains for which they are not authoritative. Expecting non-authoritative entities to protect domain administrators from any misconfiguration of resource records is therefore unrealistic and unreasonable and, in the long term, is harmful to the delegated design of the DNS and could lead to extensive operational instability and/or variation.
ドメイン管理者は、最終的にDNSレコードが正しく構成され、管理されていることを確認する責任があります。 ISPまたは他のDNS再帰リゾルバーオペレーターは、権限のないドメインの誤って構成されたA、CNAME、MX、または他のリソースレコードを修正することはできません。したがって、権限のないエンティティがリソースレコードの誤設定からドメイン管理者を保護することを期待することは、非現実的で不合理であり、長期的には、DNSの委任された設計に有害であり、広範な運用の不安定性や変動につながる可能性があります。
With DNSSEC breakage, it is often possible to tell that there is a misconfiguration by looking at the data and not needing to guess what it should have been.
DNSSECが破損していると、データを調べて、本来あるべきものを推測する必要がないため、構成に誤りがあることがしばしばわかります。
Some domains, such as dnssec-failed.org, have been intentionally broken for testing purposes [Website-Visitors] [Netalyzr]. For example, dnssec-failed.org is a DNSSEC-signed domain that is broken. If an end user is querying a validating DNS recursive resolver, then this or other similarly intentionally broken domains should fail to resolve and should result in a "Server Failure" error (RCODE 2, also known as 'SERVFAIL'). If such a domain resolved successfully, then it is a sign that the DNS recursive resolver is not fully validating.
dnssec-failed.orgなどの一部のドメインは、テスト目的で意図的に破壊されています[Website-Visitors] [Netalyzr]。たとえば、dnssec-failed.orgは、壊れているDNSSEC署名ドメインです。エンドユーザーが有効なDNS再帰リゾルバにクエリを実行している場合、これまたは同様に意図的に壊れたドメインは解決に失敗し、「サーバー障害」エラー（RCODE 2、「SERVFAIL」とも呼ばれます）になるはずです。このようなドメインが正常に解決された場合、DNS再帰リゾルバーが完全に検証していないことを示しています。
Organizations that utilize NTAs should not add an NTA for any intentionally broken domain. Such additions are prevented by the requirement that the operator attempt to contact the administrators for the zone that has broken DNSSEC.
NTAを利用する組織は、意図的に破損したドメインにNTAを追加しないでください。このような追加は、オペレーターがDNSSECを破ったゾーンの管理者に連絡することを試みるという要件によって防止されます。
Organizations operating an intentionally broken domain may wish to consider adding a TXT record for the domain to the effect of "This domain is purposely DNSSEC broken for testing purposes".
意図的に破損したドメインを運用している組織は、「このドメインは意図的にDNSSECがテスト目的で破損している」という影響のために、ドメインのTXTレコードを追加することを検討する場合があります。
Discovering that a domain is DNSSEC broken as a result of an operator error instead of an attack is not trivial, and the examples here should be vetted by an experienced professional before making the decision to implement an NTA.
攻撃ではなくオペレーターエラーの結果としてドメインがDNSSECで壊れていることを発見することは簡単ではありません。NTAの実装を決定する前に、経験豊富な専門家がこの例を精査する必要があります。
One of the key things to look for when looking at a DNSSEC broken domain is consistency and history. Therefore, it is good if you have the ability to look at the server's DNS traffic over a long period of time or have a database that stores DNS names and associated answers (this is often referred to as a "passive DNS database"). Another invaluable tool is DNSViz (http://dnsviz.net), which also stores DNSSEC-related data historically. The drawback here is that you need for it to have tested the domain before the incident occurs.
DNSSECの壊れたドメインを調べるときに探すべき重要なことの1つは、一貫性と履歴です。したがって、サーバーのDNSトラフィックを長期間にわたって確認できる機能があるか、DNS名と関連する回答を格納するデータベース（これは「パッシブDNSデータベース」と呼ばれることが多い）がある場合に適しています。もう1つの貴重なツールはDNSViz（http://dnsviz.net）で、これはDNSSEC関連のデータも履歴に保存します。ここでの欠点は、インシデントが発生する前にドメインをテストする必要があることです。
The first and easiest thing to check is if the failure of the domain is consistent across different software implementations. If not, you want to inform the vendor where it fails so that the vendor can look more deeply into the issue.
最初に確認する最も簡単なことは、ドメインの障害がさまざまなソフトウェア実装間で一貫しているかどうかです。そうでない場合は、ベンダーに問題の詳細を調査できるように、障害が発生した場所をベンダーに通知する必要があります。
The next thing is to figure out what the actual failure mode is. At the time of this writing, several tools that do this are available, including:
次のことは、実際の故障モードが何であるかを理解することです。これを書いている時点で、これを行ういくつかのツールが利用可能です。
o DNSViz (http://dnsviz.net)
o DNSViz（http://dnsviz.net）
o Verisign DNSSEC debugger (http://dnssec-debugger.verisignlabs.com)
o Verisign DNSSECデバッガー（http://dnssec-debugger.verisignlabs.com）
o Zonemaster (http://www.zonemaster.fr, https://github.com/dotse/ zonemaster)
o Zonemaster（http：//www.zonemaster.fr、https：//github.com/dotse/ zonemaster）
Most of these tools are open source and can be installed locally. However, using the tools over the Internet has the advantage of providing visibility from a different point. This is an incomplete list, and it is expected that additional tools will be developed over time to aid in troubleshooting DNSSEC issues.
これらのツールのほとんどはオープンソースであり、ローカルにインストールできます。ただし、インターネット経由でツールを使用すると、別の場所からの可視性を提供できるという利点があります。これは不完全なリストであり、DNSSECの問題のトラブルシューティングに役立つ追加のツールが今後開発されることが予想されます。
Once you figure out what the error is, you need to check if it shows consistently around the world and from all authoritative servers. Use DNS Tools (dig) or DNS looking glasses to verify this. An error that is consistently the same is more likely to be caused by an operator rather than by an attack. Also, if the output from the authoritative server is consistently different from the resolvers' output, this hints to an attack rather then an error, unless EDNS0 client subnet [CLIENT-SUBNET] is applied to the domain.
エラーが何であるかがわかったら、それが世界中で一貫して、すべての信頼できるサーバーから表示されるかどうかを確認する必要があります。これを確認するには、DNSツール（掘る）またはDNS鏡を使用します。一貫して同じエラーは、攻撃ではなくオペレーターによって引き起こされる可能性が高くなります。また、権限のあるサーバーからの出力がリゾルバーの出力と一貫して異なる場合、これはEDNS0クライアントサブネット[CLIENT-SUBNET]がドメインに適用されていない限り、エラーではなく攻撃を示唆します。
A last check is to look at the actual DNS data. Is the result of the query still the same or has it changed? While a lot of DNSSEC errors occur on events that change DNSSEC data, the actual record someone wants to go to often stays the same. If the data is the same, this is an indication (not a guarantee) that the error is operator caused. Keep in mind that with DNS being used to globally balance traffic, the data associated to a name might be different in different parts of the Internet.
最後のチェックは、実際のDNSデータを確認することです。クエリの結果は同じですか、それとも変更されていますか？多くのDNSSECエラーはDNSSECデータを変更するイベントで発生しますが、誰かが行きたい実際のレコードはしばしば同じままです。データが同じである場合、これはエラーがオペレーターによって引き起こされたことを示す（保証ではありません）。 DNSを使用してグローバルにトラフィックのバランスをとっている場合、名前に関連付けられたデータはインターネットのさまざまな部分で異なる可能性があることに注意してください。
Here are some examples of common DNSSEC failures that have been seen as operator signing errors on the Internet:
以下は、インターネットでオペレーター署名エラーと見なされている一般的なDNSSEC障害の例です。
o RRSIG timing issue. Each signature has an inception time and expiry time between which it is valid. Letting this time expire without creating a new signature is one of the most common DNSSEC errors. To a lesser extent, this also occurs if signatures were made active before the inception time. For all of these errors, your primary check is to check on the data. Signature expiration is also about the only error we see on actual data (like www.example.com). All other errors are more or less related to dealing with the chain of trust established by DS records in the parent zone and DNSKEYs in the child zones. These mostly occur during key rollovers but are not limited to that.
o RRSIGのタイミングの問題。各シグネチャには、有効な開始時刻と有効期限があります。新しい署名を作成せずにこの時間を満了させることは、最も一般的なDNSSECエラーの1つです。それほどではありませんが、これは開始時刻より前に署名がアクティブになった場合にも発生します。これらすべてのエラーについて、主なチェックはデータをチェックすることです。署名の有効期限は、実際のデータ（www.example.comなど）で発生する唯一のエラーに関するものでもあります。他のすべてのエラーは、親ゾーンのDSレコードと子ゾーンのDNSKEYによって確立された信頼チェーンの処理に関連しています。これらは主にキーのロールオーバー中に発生しますが、それに限定されません。
o DNSKEYs in a child zone don't match the DS record in the parent zone. There is a big variation of this that can happen at any point in the key lifecycle. DNSViz is the best tool to show problems in the chain. If you debug it yourself, use dig +multiline so that you can see the key id of a DNSKEY. Common variations of this can be:
o 子ゾーンのDNSKEYが親ゾーンのDSレコードと一致しません。これには、キーライフサイクルの任意の時点で発生する可能性のある大きなバリエーションがあります。 DNSVizは、チェーン内の問題を示すのに最適なツールです。自分でデバッグする場合は、dig + multilineを使用して、DNSKEYのキーIDを確認できます。これの一般的なバリエーションは次のとおりです。
* DS pointing to a non-existent key in the child zone. Questions for consideration here include the following. Has there ever been a key (and, if so, was it used)? Has there been a recent change in the DNSKEY RRSet (indicating a key rollover)? Has the actual data in the zone changed? Is the zone DNSSEC signed at all and has it been in the past?
* 子ゾーンに存在しないキーを指すDS。ここで検討すべき質問は次のとおりです。鍵があったことはありますか（ある場合、それが使用されていましたか）？ DNSKEY RRSet（キーのロールオーバーを示す）に最近変更がありましたか？ゾーンの実際のデータは変更されましたか？ゾーンDNSSECはまったく署名されていますか？それは過去のものですか？
* DS pointing to an existent key, but no signatures are made with the key. The checks above should be done, with the addition of checking if another key in the DNSKEY RRSet is now used to sign the records.
* DSは既存のキーを指していますが、そのキーで署名は行われていません。上記のチェックを実行する必要があります。さらに、DNSKEY RRSetの別のキーがレコードの署名に使用されているかどうかもチェックします。
* Data in DS or DNSKEY doesn't match the other. This is more common in initial setup when there was a copy-and-paste error. Again, checking history on data is the best you can do there.
* DSまたはDNSKEYのデータが他のデータと一致しません。これは、コピーアンドペーストエラーが発生したときの初期セットアップでより一般的です。繰り返しますが、データの履歴を確認することは、そこで実行できる最善の方法です。
All of the above is just a starting point for consideration when deciding whether or not to deploy a trust anchor. It is not possible to provide a simple checklist to run through to determine whether a domain is broken because of an attack or an operator error.
上記のすべては、トラストアンカーを展開するかどうかを決定する際の検討の開始点にすぎません。攻撃またはオペレーターのエラーが原因でドメインが壊れているかどうかを判断するための簡単なチェックリストを提供することはできません。
End-to-end DNSSEC validation will be disabled during the time that an NTA is used. In addition, the NTA may be in place after the time when the DNS misconfiguration that caused validation to break has been fixed. Thus, there may be a gap between when a domain has been re-secured and when an NTA is removed. In addition, an NTA may be put in place by DNS recursive resolver operators without the knowledge of the authoritative domain administrator for a given domain name. However, attempts SHOULD be made to contact and inform the domain administrator prior to putting the NTA in place.
NTAが使用されている間、エンドツーエンドのDNSSEC検証は無効になります。さらに、検証が失敗する原因となったDNSの誤った構成が修正された後、NTAが設置される場合があります。したがって、ドメインが再保護されたときとNTAが削除されたときの間にギャップが生じる可能性があります。さらに、NTAは、特定のドメイン名の権限のあるドメイン管理者の知識がなくても、DNS再帰リゾルバーオペレーターによって配置される場合があります。ただし、NTAを導入する前に、ドメイン管理者に連絡して通知する試みを行う必要があります。
One side effect of implementing an NTA is that it may break client applications that assume that a domain is signed and expect an AD bit in the response. It is expected that many applications that require DNSSEC for a domain will perform their own validation, so this should not be a major issue.
NTAを実装することの副作用の1つは、ドメインが署名されていると想定し、応答でADビットを期待するクライアントアプリケーションを破壊する可能性があることです。ドメインにDNSSECを必要とする多くのアプリケーションが独自の検証を実行することが予想されるため、これは大きな問題ではありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<http： //www.rfc-editor.org/info/rfc4033>。
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, DOI 10.17487/RFC5914, June 2010, <http://www.rfc-editor.org/info/rfc5914>.
[RFC5914] Housley、R.、Ashmore、S。、およびC. Wallace、「Trust Anchor Format」、RFC 5914、DOI 10.17487 / RFC5914、2010年6月、<http://www.rfc-editor.org/info/ rfc5914>。
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, <http://www.rfc-editor.org/info/rfc6781>.
[RFC6781] Kolkman、O.、Mekking、W.、and R. Gieben、 "DNSSEC Operational Practices、Version 2"、RFC 6781、DOI 10.17487 / RFC6781、December 2012、<http://www.rfc-editor.org / info / rfc6781>。
[Alexa] Alexa, "The top 500 sites on the web", <http://www.alexa.com/topsites>.
[アレクサ]アレクサ、「ウェブ上の上位500サイト」、<http://www.alexa.com/topsites>。
[CLIENT-SUBNET] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", Work in Progress, draft-ietf-dnsop-edns-client-subnet-03, August 2015.
[CLIENT-SUBNET] Contavalli、C.、van der Gaast、W.、Lawrence、D。、およびW. Kumari、「DNSクエリのクライアントサブネット」、作業中、draft-ietf-dnsop-edns-client-subnet 2015年8月3日。
[Disclosure-Example] Comcast, "faa.gov Failing DNSSEC Validation (Fixed)", February 2013, <http://dns.comcast.net/index.php/entry/ faa-gov-failing-dnssec-validation-fixed>.
[開示例] Comcast、「faa.gov Failing DNSSEC Validation（Fixed）」、2013年2月、<http://dns.comcast.net/index.php/entry/ faa-gov-failing-dnssec-validation-fixed >。
[Netalyzr] Weaver, N., Kreibich, C., Nechaev, B., and V. Paxson, "Implications of Netalyzr's DNS Measurements", Securing and Trusting Internet Names (SATIN), April 2011, <http://conferences.npl.co.uk/satin/presentations/ satin2011slides-Weaver.pdf>.
[Netalyzr] Weaver、N.、Kreibich、C.、Nechaev、B。、およびV. Paxson、「Impplications of Netalyzr's DNS Measurements」、Securing and Trusting Internet Names（SATIN）、2011年4月、<http：// conferences。 npl.co.uk/satin/presentations/ satin2011slides-Weaver.pdf>。
[Unbound-Config] Wijngaards, W., "Unbound: How to Turn Off DNSSEC", June 2010, <http://unbound.net/documentation/ howto_turnoff_dnssec.html>.
[Unbound-Config] Wijngaards、W。、「Unbound：How to Turn Off DNSSEC」、2010年6月、<http://unbound.net/documentation/howto_turnoff_dnssec.html>。
[Website-Visitors] Mens, J., "Is my Web site being used via a DNSSEC-validator?", July 2012, <http://jpmens.net/2012/07/30/ is-my-web-site-being-used-via-dnssec-validator/>.
[Website-Visitors] Mens、J.、「私のWebサイトはDNSSEC-validatorを介して使用されていますか？」、2012年7月、<http://jpmens.net/2012/07/30/ is-my-web-site -being-used-via-dnssec-validator />。
The section contains example configurations to achieve NTA functionality for the zone foo.example.com.
このセクションには、ゾーンfoo.example.comのNTA機能を実現するための設定例が含まれています。
Note: These are simply examples -- name server operators are expected to test and understand the implications of these operations. Note also that some of available implementations may not implement all recommended functionality in this document. In that case, it is advisable to request the developer or vendor of the implementation to support the missing feature rather than start using the incomplete implementation.
注：これらは単なる例です。ネームサーバーのオペレーターは、これらの操作の影響をテストして理解する必要があります。また、利用可能な実装の一部は、このドキュメントで推奨されているすべての機能を実装していない場合があります。その場合、不完全な実装の使用を開始するのではなく、実装の開発者またはベンダーに不足している機能をサポートするように依頼することをお勧めします。
Unbound [Unbound-Config] lets us simply disable validation checking for a specific zone by adding configuration statements to unbound.conf:
Unbound [Unbound-Config]では、unbound.confに構成ステートメントを追加することにより、特定のゾーンの検証チェックを無効にするだけです。
server: domain-insecure: "foo.example.com"
サーバー：domain-insecure： "foo.example.com"
Using the 'unbound-control' command, one can add and remove NTAs without restarting the name server.
「unbound-control」コマンドを使用すると、ネームサーバーを再起動せずにNTAを追加および削除できます。
Using the "unbound-control" command: list_insecure list domain-insecure zones insecure_add zone add domain-insecure zone insecure_remove zone remove domain-insecure zone
「unbound-control」コマンドを使用：list_insecure list domain-insecure zone insecure_add zone add domain-insecure zone insecure_remove zone remove domain-insecure zone
Items added with the "unbound-control" command are added to the running server and are lost when the server is restarted. Items from unbound.conf stay after restart.
「unbound-control」コマンドで追加されたアイテムは実行中のサーバーに追加され、サーバーを再起動すると失われます。再起動後、unbound.confのアイテムが残ります。
For additional information, see [Unbound-Config].
追加情報については、[Unbound-Config]を参照してください。
Use the "rndc" command:
「rndc」コマンドを使用します。
nta -dump List all negative trust anchors. nta [-lifetime duration] [-force] domain [view] Set a negative trust anchor, disabling DNSSEC validation for the given domain. Using -lifetime specifies the duration of the NTA, up to one week. The default is one hour. Using -force prevents the NTA from expiring before its full lifetime, even if the domain can validate sooner. nta -remove domain [view] Remove a negative trust anchor, re-enabling validation for the given domain.
nta -dumpすべての負のトラストアンカーを一覧表示します。 nta [-lifetime duration] [-force] domain [view]負のトラストアンカーを設定し、指定されたドメインのDNSSEC検証を無効にします。 -lifetimeを使用すると、NTAの期間を最大1週間まで指定できます。デフォルトは1時間です。 -forceを使用すると、ドメインがより早く検証できる場合でも、NTAが完全に有効になる前に期限切れになるのを防ぎます。 nta -remove domain [view]否定のトラストアンカーを削除し、指定されたドメインの検証を再度有効にします。
**
＊＊
*negative-trust-anchors*
*ネガティブトラストアンカー*
_Format_: name
_形式_：名前
_Command Channel_: view.update name=world negative-trust-anchors=(foo.example.com)
_コマンドチャネル_：view.update name = world negative-trust-anchors =（foo.example.com）
_Command Channel_: resolver.update name=res1 negative-trust-anchors=(foo.example.com)
_コマンドチャネル_：resolver.update name = res1 negative-trust-anchors =（foo.example.com）
*Description*: Disables DNSSEC validation for a domain, even if the domain is under an existing security root.
*説明*：ドメインが既存のセキュリティルートの下にある場合でも、ドメインのDNSSEC検証を無効にします。
Acknowledgements
謝辞
Several people made contributions to this document and/or played an important role in the development and evolution of it. In some cases, this included performing a detailed review and then providing feedback and constructive criticism for future revisions, or engaging in a healthy debate over the subject of the document. All of this was helpful, and therefore, the following individuals merit acknowledgement: Joe Abley, John Barnitz, Tom Creighton, Marco Davids, Brian Dickson, Patrik Falstrom, Tony Finch, Chris Ganster, Olafur Gudmundsson, Peter Hagopian, Wes Hardaker, Paul Hoffman, Christer Holmberg, Shane Kerr, Murray Kucherawy, Rick Lamb, Marc Lampo, Ted Lemon, Scott Rose, A. Schulze, Wendy Seltzer, Antoin Verschuren, Paul Vixie, Patrik Wallstrom, Nick Weaver, W.C.A. Wijngaards, and Suzanne Woolf.
何人かの人々がこの文書に貢献し、そして/またはそれの開発と進化において重要な役割を果たしました。場合によっては、詳細なレビューを行ってから、フィードバックや建設的な批評を将来の改訂に提供したり、ドキュメントの主題について健全な議論をしたりすることも含まれていました。これはすべて役に立ちました。したがって、次の個人は承認に値します：ジョーアブリー、ジョンバルニッツ、トムクレイトン、マルコデイビッド、ブライアンディクソン、パトリックファルストロム、トニーフィンチ、クリスガンスター、オラファーグドムンドソン、ピーターハゴピアン、ウェスハーダーカー、ポールホフマン、Christer Holmberg、Shane Kerr、Murray Kucherawy、Rick Lamb、Marc Lampo、Ted Lemon、Scott Rose、A。Schulze、Wendy Seltzer、Antoin Verschuren、Paul Vixie、Patrik Wallstrom、Nick Weaver、WCA Wijngaards、およびSuzanne Woolf。
Edward Lewis, Evan Hunt, Andrew Sullivan, and Tatuya Jinmei provided especially large amounts of text and/or detailed review.
Edward Lewis、Evan Hunt、Andrew Sullivan、およびTatuya Jinmeiは、特に大量のテキストや詳細なレビューを提供しました。
Authors' Addresses
著者のアドレス
Paul Ebersman Comcast One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 United States
Paul Ebersman Comcast One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia、PA 19103アメリカ合衆国
Email: ebersman-ietf@dragon.net
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: warren@kumari.net
URI: http://www.google.com
Chris Griffiths Nominet Minerva House Edmund Halley Road Oxford Science Park Oxford OX4 4DQ United Kingdom
クリスグリフィスノミネットミネルバハウスエドマンドハリーロードオックスフォードサイエンスパークオックスフォードOX4 4DQイギリス
Email: cgriffiths@gmail.com
URI: http://www.nominet.org.uk/
Jason Livingood Comcast One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 United States
Jason Livingood Comcast One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia、PA 19103アメリカ合衆国
Email: jason_livingood@cable.comcast.com
URI: http://www.comcast.com
Ralf Weber Nominum
名前の半分ウェーバー
Email: Ralf.Weber@nominum.com
URI: http://www.nominum.com