[要約] 要約：RFC 7706は、ループバック上でルートサーバを実行することによってアクセス時間を短縮する方法について説明しています。 目的：このRFCの目的は、インターネットのルートサーバへのアクセス時間を短縮するための新しいアプローチを提案することです。
Internet Engineering Task Force (IETF) W. Kumari
Request for Comments: 7706 Google
Category: Informational P. Hoffman
ISSN: 2070-1721 ICANN
November 2015
Decreasing Access Time to Root Servers by Running One on Loopback
ループバックでルートサーバーを実行することによるルートサーバーへのアクセス時間の短縮
Abstract
概要
Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1). This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator.
一部のDNS再帰リゾルバーは、最も近いDNSルートサーバーへのラウンドトリップ時間が望ましいよりも長くなっています。一部のDNS再帰リゾルバーオペレーターは、サードパーティによってDNSルートサーバーに送信された要求のスヌーピングを防ぎたいと考えています。このようなリゾルバーは、ループバックアドレス（127.0.0.1など）でフルルートゾーンのコピーを実行することにより、ラウンドトリップ時間を大幅に短縮し、要求の監視を防止できます。このドキュメントでは、DNSの他のユーザーに脅威を与えないルートゾーンのコピーを開始および維持する方法を示しますが、オペレーターに運用上の脆弱性を追加します。
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/rfc7706.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7706で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operation of the Root Zone on the Loopback Address . . . . . 5
4. Using the Root Zone Server on the Loopback Address . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8
Appendix B. Example Configurations of Common Implementations . . 8
B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 9
B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10
B.3. Example Configuration: Microsoft Windows Server 2012 . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
DNS recursive resolvers have to provide answers to all queries from their customers, even those for domain names that do not exist. For each queried name that has a top-level domain (TLD) that is not in the recursive resolver's cache, the resolver must send a query to a root server to get the information for that TLD, or to find out that the TLD does not exist. Typically, the vast majority of queries going to the root are for names that do not exist in the root zone, and the negative answers are cached for a much shorter period of time. A slow path between the recursive resolver and the closest root server has a negative effect on the resolver's customers.
DNS再帰リゾルバは、存在しないドメイン名のクエリも含め、顧客からのすべてのクエリに回答を提供する必要があります。再帰リゾルバのキャッシュにないトップレベルドメイン（TLD）を持つクエリされた名前ごとに、リゾルバはルートサーバーにクエリを送信して、そのTLDの情報を取得するか、TLDがそうでないことを確認する必要があります存在します。通常、ルートに送信されるクエリの大部分はルートゾーンに存在しない名前に対するものであり、否定的な回答ははるかに短い期間キャッシュされます。再帰リゾルバと最も近いルートサーバー間のパスが遅いと、リゾルバの顧客に悪影響を及ぼします。
Recursive resolvers currently send queries for all TLDs that are not in their caches to root servers, even though most of those queries get answers that are referrals to other servers. Malicious third parties might be able to observe that traffic on the network between the recursive resolver and one or more of the DNS roots.
現在、再帰リゾルバは、キャッシュにないすべてのTLDのクエリをルートサーバーに送信しますが、これらのクエリのほとんどは、他のサーバーへの参照である回答を取得します。悪意のある第三者が、再帰リゾルバと1つ以上のDNSルートの間のネットワーク上のトラフィックを監視できる可能性があります。
This document describes a method for the operator of a recursive resolver to greatly speed these queries and to hide them from outsiders. The basic idea is to create an up-to-date root zone server on a loopback address on the same host as the recursive server, and use that server when the recursive resolver looks up root information. The recursive resolver validates all responses from the root server on the loopback address, just as it would all responses from a remote root server.
このドキュメントでは、再帰リゾルバーのオペレーターがこれらのクエリを大幅に高速化し、それらを部外者から隠す方法について説明します。基本的な考え方は、再帰サーバーと同じホストのループバックアドレスに最新のルートゾーンサーバーを作成し、再帰リゾルバーがルート情報を検索するときにそのサーバーを使用することです。再帰リゾルバは、リモートルートサーバーからのすべての応答と同様に、ループバックアドレスでルートサーバーからのすべての応答を検証します。
The primary goals of this design are to provide faster negative responses to stub resolver queries that contain junk queries, and to prevent queries and responses from being visible on the network. This design will probably have little effect on getting faster positive responses to stub resolver for good queries on TLDs, because the data for those zones is usually long-lived and already in the cache of the recursive resolver; thus, getting faster positive responses is a non-goal of this design.
この設計の主な目的は、ジャンククエリを含むスタブリゾルバクエリに対する否定的な応答を高速化し、クエリと応答がネットワーク上に表示されないようにすることです。これらのゾーンのデータは通常、存続期間が長く、再帰リゾルバーのキャッシュに既にあるため、この設計は、TLDの適切なクエリに対してスタブリゾルバーへのより迅速な肯定応答を取得することにほとんど影響を与えません。したがって、より早い肯定的な応答を得ることは、この設計の目標ではありません。
This design explicitly only allows the new root zone server to be run on a loopback address, in order to prevent the server from serving authoritative answers to any system other than the recursive resolver.
この設計では、サーバーが再帰リゾルバー以外のシステムに対して信頼できる応答を提供できないようにするために、新しいルートゾーンサーバーをループバックアドレスでのみ実行することを明示的に許可しています。
It is important to note that the design being described here is not considered a "best practice". In fact, many people feel that it is an excessively risky practice because it introduces a new operational piece to local DNS operations where there was not one before. The advantages listed above do not come free: if this new system does not work correctly, users can get bad data, or the entire recursive resolution system might fail in ways that are hard to diagnose.
ここで説明する設計は「ベストプラクティス」とは見なされないことに注意してください。実際、多くの人々は、これまでになかったローカルのDNS運用に新しい運用上の要素を導入するため、これは非常に危険な慣行であると感じています。上記の利点は無料ではありません。この新しいシステムが正しく機能しない場合、ユーザーは不正なデータを取得したり、再帰解決システム全体が診断が困難な方法で失敗したりする可能性があります。
This design requires the addition of authoritative name server software running on the same machine as the recursive resolver. Thus, recursive resolver software such as BIND will not need to add much new functionality, but recursive resolver software such as Unbound will need to be able to talk to an authoritative server (such as NSD) running on the same host.
この設計では、再帰リゾルバと同じマシンで実行されている信頼できるネームサーバーソフトウェアを追加する必要があります。したがって、BINDなどの再帰リゾルバソフトウェアは、多くの新しい機能を追加する必要はありませんが、Unboundなどの再帰リゾルバソフトウェアは、同じホストで実行されている信頼できるサーバー（NSDなど）と通信できる必要があります。
Because of the significant operational risks described in this document, distributions of recursive DNS servers MUST NOT include configuration for the design described here. It is acceptable to point to this document, but not to indicate that this configuration is something that should be considered without reading the entire document.
このドキュメントで説明されている重大な運用上のリスクがあるため、再帰DNSサーバーの配布には、ここで説明されている設計の構成を含めることはできません。このドキュメントを指すことは許容されますが、この構成がドキュメント全体を読まずに検討する必要があるものであることを示すことはできません。
A different approach to solving the problems discussed in this document is described in [AggressiveNSEC].
このドキュメントで説明されている問題を解決するための別のアプローチは、[AggressiveNSEC]で説明されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
In order to implement the mechanism described in this document:
このドキュメントで説明されているメカニズムを実装するために：
o The system MUST be able to validate a zone with DNSSEC [RFC4033].
o システムはDNSSEC [RFC4033]でゾーンを検証できなければなりません。
o The system MUST have an up-to-date copy of the DNS root key.
o システムには、DNSルートキーの最新のコピーが必要です。
o The system MUST be able to retrieve a copy of the entire root zone (including all DNSSEC-related records).
o システムは、ルートゾーン全体（DNSSEC関連のすべてのレコードを含む）のコピーを取得できる必要があります。
o The system MUST be able to run an authoritative server on one of the IPv4 loopback addresses (that is, an address in the range 127/8 for IPv4 or ::1 in IPv6).
o システムは、IPv4ループバックアドレスの1つ（つまり、IPv4の場合は127/8のアドレス、IPv6の場合は:: 1）で信頼できるサーバーを実行できる必要があります。
A corollary of the above list is that authoritative data in the root zone used on the local authoritative server MUST be identical to the same data in the root zone for the DNS. It is possible to change the unsigned data (the glue records) in the copy of the root zone, but such changes could cause problems for the recursive server that accesses the local root zone, and therefore any changes to the glue records SHOULD NOT be made.
上記のリストの帰結として、ローカルの権威サーバーで使用されるルートゾーンの権威データは、DNSのルートゾーンの同じデータと同一でなければなりません。ルートゾーンのコピーで署名されていないデータ（グルーレコード）を変更することは可能ですが、そのような変更はローカルルートゾーンにアクセスする再帰サーバーに問題を引き起こす可能性があるため、グルーレコードへの変更は行わないでください。 。
The operation of an authoritative server for the root in the system described here can be done separately from the operation of the recursive resolver.
ここで説明するシステムのルートに対する権限のあるサーバーの操作は、再帰リゾルバーの操作とは別に実行できます。
The steps to set up the root zone are:
ルートゾーンを設定する手順は次のとおりです。
1. Retrieve a copy of the root zone. (See Appendix A for some current locations of sources.)
1. ルートゾーンのコピーを取得します。 （現在の出典の場所については、付録Aを参照してください。）
2. Start the authoritative server with the root zone on a loopback address that is not in use. For IPv4, this would typically be 127.0.0.1, but if that address is in use, any address in 127/8 is acceptable. For IPv6, this would be ::1.
2. 使用されていないループバックアドレスのルートゾーンで権限のあるサーバーを起動します。 IPv4の場合、これは通常127.0.0.1ですが、そのアドレスが使用されている場合は、127/8の任意のアドレスが受け入れられます。 IPv6の場合、これは:: 1になります。
The contents of the root zone MUST be refreshed using the timers from the SOA record in the root zone, as described in [RFC1035]. This inherently means that the contents of the local root zone will likely be a little behind those of the global root servers because those servers are updated when triggered by NOTIFY messages. If the contents of the zone cannot be refreshed before the expire time, the server MUST return a SERVFAIL error response for all queries until the zone can be successfully be set up again.
[RFC1035]で説明されているように、ルートゾーンの内容は、ルートゾーンのSOAレコードのタイマーを使用して更新する必要があります。これは本質的に、ローカルルートゾーンのコンテンツがグローバルルートサーバーのコンテンツよりも少し遅れる可能性があることを意味します。これらのサーバーはNOTIFYメッセージによってトリガーされたときに更新されるためです。有効期限が切れる前にゾーンのコンテンツを更新できない場合、サーバーは、ゾーンを再び正常に設定できるようになるまで、すべてのクエリに対してSERVFAILエラー応答を返さなければなりません（MUST）。
In the event that refreshing the contents of the root zone fails, the results can be disastrous. For example, sometimes all the NS records for a TLD are changed in a short period of time (such as 2 days); if the refreshing of the local root zone is broken during that time, the recursive resolver will have bad data for the entire TLD zone.
ルートゾーンのコンテンツの更新に失敗した場合、結果は悲惨なものになる可能性があります。たとえば、TLDのすべてのNSレコードが短期間に（2日など）変更されることがあります。その間にローカルルートゾーンの更新が中断された場合、再帰リゾルバにはTLDゾーン全体の不良データが含まれます。
An administrator using the procedure in this document SHOULD have an automated method to check that the contents of the local root zone are being refreshed. One way to do this is to have a separate process that periodically checks the SOA of the root zone from the local root zone and makes sure that it is changing. At the time that this document is published, the SOA for the root zone is the digital representation of the current date with a two-digit counter appended, and the SOA is changed every day even if the contents of the root zone are unchanged. For example, the SOA of the root zone on January 2, 2015 was 2015010201. A process can use this fact to create a check for the contents of the local root zone (using a program not specified in this document).
このドキュメントの手順を使用する管理者は、ローカルルートゾーンの内容が更新されていることを確認する自動化された方法を使用する必要があります（SHOULD）。これを行う1つの方法は、ローカルゾーンからルートゾーンのSOAを定期的にチェックし、変更されていることを確認する別のプロセスを用意することです。このドキュメントが公開された時点では、ルートゾーンのSOAは2桁のカウンターが追加された現在の日付のデジタル表現であり、ルートゾーンの内容が変更されていなくても、SOAは毎日変更されます。たとえば、2015年1月2日のルートゾーンのSOAは2015010201でした。プロセスはこのファクトを使用して、ローカルルートゾーンの内容のチェックを作成できます（このドキュメントで指定されていないプログラムを使用）。
A recursive resolver that wants to use a root zone server operating as described in Section 3 simply specifies the local address as the place to look when it is looking for information from the root. All responses from the root server must be validated using DNSSEC.
セクション3で説明されているように動作するルートゾーンサーバーを使用したい再帰リゾルバは、ルートから情報を探すときに探す場所としてローカルアドレスを指定するだけです。ルートサーバーからのすべての応答は、DNSSECを使用して検証する必要があります。
Note that using this configuration will cause the recursive resolver to fail if the local root zone server fails. See Appendix B for more discussion of this for specific software.
この構成を使用すると、ローカルルートゾーンサーバーに障害が発生した場合に再帰リゾルバーが失敗することに注意してください。特定のソフトウェアの詳細については、付録Bを参照してください。
To test the proper operation of the recursive resolver with the local root server, use a DNS client to send a query for the SOA of the root to the recursive server. Make sure the response that comes back has the AA bit in the message header set to 0.
ローカルルートサーバーを使用した再帰リゾルバの適切な動作をテストするには、DNSクライアントを使用して、ルートのSOAのクエリを再帰サーバーに送信します。返される応答のメッセージヘッダーのAAビットが0に設定されていることを確認してください。
A system that does not follow the DNSSEC-related requirements given in Section 2 can be fooled into giving bad responses in the same way as any recursive resolver that does not do DNSSEC validation on responses from a remote root server. Anyone deploying the method described in this document should be familiar with the operational benefits and costs of deploying DNSSEC [RFC4033].
セクション2に記載されているDNSSEC関連の要件に準拠していないシステムは、リモートルートサーバーからの応答でDNSSEC検証を行わない再帰リゾルバと同じ方法で、不正な応答をする可能性があります。このドキュメントで説明されている方法を導入する人は、DNSSEC [RFC4033]を導入することの運用上の利点とコストに精通している必要があります。
As stated in Section 1, this design explicitly only allows the new root zone server to be run on a loopback address, in order to prevent the server from serving authoritative answers to any system other than the recursive resolver. This has the security property of limiting damage to any other system that might try to rely on an altered copy of the root.
セクション1で述べたように、この設計では、サーバーが再帰リゾルバー以外のシステムに対して信頼できる応答を提供できないようにするために、新しいルートゾーンサーバーをループバックアドレスでのみ実行することを明示的に許可しています。これには、変更されたルートのコピーに依存しようとする可能性のある他のシステムへの損傷を制限するというセキュリティ特性があります。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[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>。
[AggressiveNSEC] Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3", Work in Progress, draft-fujiwara-dnsop-nsec-aggressiveuse-02, October 2015.
[AggressiveNSEC]藤原健一郎、加藤明夫、「NSEC / NSEC3の積極的な使用」、作業中、draft-fujiwara-dnsop-nsec-aggressiveuse-02、2015年10月。
[Manning2013] Manning, W., "Client Based Naming", 2013, <http://www.sfc.wide.ad.jp/dissertation/bill_e.html>.
[Manning2013] Manning、W。、「Client Based Naming」、2013、<http://www.sfc.wide.ad.jp/dissertation/bill_e.html>。
The root zone can be retrieved from anywhere as long as it comes with all the DNSSEC records needed for validation. Currently, one can get the root zone from ICANN by zone transfer (AXFR) over TCP from DNS servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org.
ルートゾーンは、検証に必要なすべてのDNSSECレコードが付属している限り、どこからでも取得できます。現在、xfr.lax.dns.icann.orgおよびxfr.cjr.dns.icann.orgにあるDNSサーバーからTCPを介したゾーン転送（AXFR）によってICANNからルートゾーンを取得できます。
Currently, the root can also be retrieved by AXFR over TCP from the following root server operators:
現在、ルートはAXFR over TCPによって次のルートサーバーオペレーターから取得することもできます。
o b.root-servers.net
o ｂ。ろおｔーせｒゔぇｒｓ。ねｔ
o c.root-servers.net
o ｃ。ろおｔーせｒゔぇｒｓ。ねｔ
o f.root-servers.net
o ｆ。ろおｔーせｒゔぇｒｓ。ねｔ
o g.root-servers.net
o ｇ。ろおｔーせｒゔぇｒｓ。ねｔ
o k.root-servers.net
o ｋ。ろおｔーせｒゔぇｒｓ。ねｔ
It is crucial to note that none of the above services are guaranteed to be available. It is possible that ICANN or some of the root server operators will turn off the AXFR capability on the servers listed above. Using AXFR over TCP to addresses that are likely to be anycast (as the ones above are) may conceivably have transfer problems due to anycast, but current practice shows that to be unlikely.
上記のサービスのいずれも利用可能であることが保証されていないことに注意することが重要です。 ICANNまたは一部のルートサーバーオペレーターが、上記のサーバーでAXFR機能をオフにする可能性があります。 （上記のように）エニーキャストである可能性が高いアドレスにAXFR over TCPを使用すると、エニーキャストが原因で転送の問題が発生する可能性がありますが、現在の慣例では、その可能性は低いと示されています。
To repeat the requirement from earlier in this document: if the contents of the zone cannot be refreshed before the expire time, the server MUST return a SERVFAIL error response for all queries until the zone can be successfully be set up again.
このドキュメントの前半の要件を繰り返すには、有効期限が切れる前にゾーンのコンテンツを更新できない場合、サーバーは、ゾーンを再び正常に設定できるようになるまで、すべてのクエリに対してSERVFAILエラー応答を返さなければなりません。
This section shows fragments of configurations for some popular recursive server software that is believed to correctly implement the requirements given in this document.
このセクションでは、このドキュメントに記載されている要件を正しく実装していると考えられる一般的な再帰サーバーソフトウェアの構成の一部を示します。
The IPv4 and IPv6 addresses in this section were checked recently by testing for AXFR over TCP from each address for the known single-letter names in the root-servers.net zone.
このセクションのIPv4およびIPv6アドレスは、root-servers.netゾーン内の既知の1文字の名前について、各アドレスからAXFR over TCPをテストすることにより最近チェックされました。
The examples here use a loopback address of 127.12.12.12, but typical installations will use 127.0.0.1. The different address is used in order to emphasize that the root server does not need to be on the device at "localhost".
ここの例では127.12.12.12のループバックアドレスを使用していますが、通常のインストールでは127.0.0.1を使用します。ルートサーバーが "localhost"のデバイス上にある必要がないことを強調するために、異なるアドレスが使用されます。
BIND acts both as a recursive resolver and an authoritative server. Because of this, there is "fate-sharing" between the two servers in the following configuration. That is, if the root server dies, it is likely that all of BIND is dead.
BINDは、再帰リゾルバと権威サーバーの両方として機能します。このため、次の構成では、2つのサーバー間で「運命共有」が行われます。つまり、ルートサーバーが停止した場合、すべてのBINDが停止している可能性があります。
Using this configuration, queries for information in the root zone are returned with the AA bit not set.
この構成を使用すると、ルートゾーンの情報に対するクエリは、AAビットが設定されていない状態で返されます。
When slaving a zone, BIND will treat zone data differently if the zone is slaved into a separate view (or a separate instance of the software) versus slaved into the same view or instance that is also performing the recursion.
ゾーンをスレーブ化するとき、ゾーンが別のビュー（またはソフトウェアの別のインスタンス）にスレーブ化されている場合と、再帰を実行している同じビューまたはインスタンスにスレーブ化されている場合、BINDはゾーンデータを異なる方法で扱います。
Validation: When using separate views or separate instances, the DS records in the slaved zone will be validated as the zone data is accessed by the recursive server. When using the same view, this validation does not occur for the slaved zone.
検証：別のビューまたは別のインスタンスを使用する場合、再帰サーバーがゾーンデータにアクセスすると、スレーブゾーンのDSレコードが検証されます。同じビューを使用する場合、この検証はスレーブゾーンでは発生しません。
Caching: When using separate views or instances, the recursive server will cache all of the queries for the slaved zone, just as it would using the traditional "root hints" method. Thus, as the zone in the other view or instance is refreshed or updated, changed information will not appear in the recursive server until the TTL of the old record times out. Currently, the TTL for DS and delegation NS records is two days. When using the same view, all zone data in the recursive server will be updated as soon as it receives its copy of the zone.
キャッシュ：個別のビューまたはインスタンスを使用する場合、再帰サーバーは、従来の「ルートヒント」メソッドを使用する場合と同様に、スレーブゾーンのすべてのクエリをキャッシュします。したがって、他のビューまたはインスタンスのゾーンが更新または更新されると、古いレコードのTTLがタイムアウトするまで、変更された情報は再帰サーバーに表示されません。現在、DSおよび委任NSレコードのTTLは2日です。同じビューを使用する場合、再帰サーバーがゾーンのコピーを受信するとすぐに、再帰サーバーのすべてのゾーンデータが更新されます。
view root {
match-destinations { 127.12.12.12; };
zone "." {
type slave;
file "rootzone.db";
notify no;
masters {
192.228.79.201; # b.root-servers.net
192.33.4.12; # c.root-servers.net
192.5.5.241; # f.root-servers.net
192.112.36.4; # g.root-servers.net
193.0.14.129; # k.root-servers.net
192.0.47.132; # xfr.cjr.dns.icann.org
192.0.32.132; # xfr.lax.dns.icann.org
2001:500:84::b; # b.root-servers.net
2001:500:2f::f; # f.root-servers.net
2001:7fd::1; # k.root-servers.net
2620:0:2830:202::132; # xfr.cjr.dns.icann.org
2620:0:2d0:202::132; # xfr.lax.dns.icann.org
};
};
};
view recursive {
dnssec-validation auto;
allow-recursion { any; };
recursion yes;
zone "." {
type static-stub;
server-addresses { 127.12.12.12; };
};
};
Unbound and NSD are separate software packages. Because of this, there is no "fate-sharing" between the two servers in the following configurations. That is, if the root server instance (NSD) dies, the recursive resolver instance (Unbound) will probably keep running but will not be able to resolve any queries for the root zone. Therefore, the administrator of this configuration might want to carefully monitor the NSD instance and restart it immediately if it dies.
UnboundとNSDは別々のソフトウェアパッケージです。このため、次の構成では、2つのサーバー間で「運命共有」は行われません。つまり、ルートサーバーインスタンス（NSD）が停止した場合、再帰リゾルバーインスタンス（アンバインド）はおそらく実行を継続しますが、ルートゾーンのクエリを解決できなくなります。したがって、この構成の管理者は、NSDインスタンスを注意深く監視し、停止した場合はすぐに再起動する必要があります。
Using this configuration, queries for information in the root zone are returned with the AA bit not set.
この構成を使用すると、ルートゾーンの情報に対するクエリは、AAビットが設定されていない状態で返されます。
# Configuration for Unbound server: do-not-query-localhost: no stub-zone: name: "." stub-prime: no stub-addr: 127.12.12.12
＃アンバインドサーバーの構成：do-not-query-localhost：no stub-zone：name： "。" stub-prime：no stub-addr：127.12.12.12
# Configuration for NSD
server:
ip-address: 127.12.12.12
zone:
name: "."
request-xfr: 192.228.79.201 NOKEY # b.root-servers.net
request-xfr: 192.33.4.12 NOKEY # c.root-servers.net
request-xfr: 192.5.5.241 NOKEY # f.root-servers.net
request-xfr: 192.112.36.4 NOKEY # g.root-servers.net
request-xfr: 193.0.14.129 NOKEY # k.root-servers.net
request-xfr: 192.0.47.132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 192.0.32.132 NOKEY # xfr.lax.dns.icann.org
request-xfr: 2001:500:84::b NOKEY # b.root-servers.net
request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net
request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net
request-xfr: 2620:0:2830:202::132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 2620:0:2d0:202::132 NOKEY # xfr.lax.dns.icann.org
Windows Server 2012 contains a DNS server in the "DNS Manager" component. When activated, that component acts as a recursive server. DNS Manager can also act as an authoritative server.
Windows Server 2012では、「DNSマネージャー」コンポーネントにDNSサーバーが含まれています。アクティブにすると、そのコンポーネントは再帰サーバーとして機能します。 DNSマネージャーは、権限のあるサーバーとしても機能します。
Using this configuration, queries for information in the root zone are returned with the AA bit set.
この構成を使用すると、ルートゾーンの情報に対するクエリは、AAビットセットで返されます。
The steps to configure DNS Manager to implement the requirements in this document are:
このドキュメントの要件を実装するようにDNSマネージャーを構成する手順は次のとおりです。
1. Launch the DNS Manager GUI. This can be done from the command line ("dnsmgmt.msc") or from the Service Manager (the "DNS" command in the "Tools" menu).
1. DNSマネージャGUIを起動します。これは、コマンドライン（「dnsmgmt.msc」）またはサービスマネージャ（「ツール」メニューの「DNS」コマンド）から実行できます。
2. In the hierarchy under the server on which the service is running, right-click on the "Forward Lookup Zones", and select "New Zone". This brings up a succession of dialog boxes.
2. サービスが実行されているサーバーの下の階層で、[前方参照ゾーン]を右クリックし、[新しいゾーン]を選択します。これにより、一連のダイアログボックスが表示されます。
3. In the "Zone Type" dialog box, select "Secondary zone".
3. [ゾーンの種類]ダイアログボックスで、[セカンダリゾーン]を選択します。
4. In the "Zone Name" dialog box, enter ".".
4. 「ゾーン名」ダイアログボックスに「。」を入力します。
5. In the "Master DNS Servers" dialog box, enter "b.root-servers.net". The system validates that it can do a zone transfer from that server. (After this configuration is completed, the DNS Manager will attempt to transfer from all of the root zone servers.)
5. [マスターDNSサーバー]ダイアログボックスで、「b.root-servers.net」と入力します。システムは、そのサーバーからゾーン転送を実行できることを検証します。 （この構成が完了すると、DNSマネージャーはすべてのルートゾーンサーバーからの転送を試みます。）
6. In the "Completing the New Zone Wizard" dialog box, click "Finish".
6. [新しいゾーンウィザードの完了]ダイアログボックスで、[完了]をクリックします。
7. Verify that the DNS Manager is acting as a recursive resolver. Right-click on the server name in the hierarchy, choosing the "Advanced" tab in the dialog box. See that "Disable recursion (also disables forwarders)" is not selected, and that "Enable DNSSEC validation for remote responses" is selected.
7. DNSマネージャーが再帰リゾルバーとして機能していることを確認します。階層内のサーバー名を右クリックし、ダイアログボックスの[詳細]タブを選択します。 「再帰を無効にする（フォワーダーも無効にする）」が選択されていないこと、および「リモート応答のDNSSEC検証を有効にする」が選択されていることを確認します。
Acknowledgements
謝辞
The authors fully acknowledge that running a copy of the root zone on the loopback address is not a new concept, and that we have chatted with many people about that idea over time. For example, Bill Manning described a similar solution but to a very different problem (intermittent connectivity, instead of constant but slow connectivity) in his doctoral dissertation in 2013 [Manning2013].
著者は、ループバックアドレスでルートゾーンのコピーを実行することは新しい概念ではなく、その考えについて多くの人と時間をかけて話し合ったことを完全に認めます。たとえば、Bill Manningは同様のソリューションを説明しましたが、2013年の博士論文[Manning2013]で非常に異なる問題（一定ではあるが低速の接続ではなく、断続的な接続）について説明しました。
Evan Hunt contributed greatly to the logic in the requirements. Other significant contributors include Wouter Wijngaards, Tony Hain, Doug Barton, Greg Lindsay, and Akira Kato. The authors also received many offline comments about making the document clear that this is just a description of a way to operate a root zone on localhost, and not a recommendation to do so.
Evan Huntは、要件のロジックに大きく貢献しました。他の重要な貢献者には、Wouter Wijngaards、Tony Hain、Doug Barton、Greg Lindsay、およびAkira Katoが含まれます。著者はまた、これがlocalhostでルートゾーンを操作する方法の単なる説明であり、推奨するものではないことをドキュメントに明確にすることについて、多くのオフラインコメントを受け取りました。
Authors' Addresses
著者のアドレス
Warren Kumari Google
ウォーレンクマリグーグル
Email: Warren@kumari.net
Paul Hoffman ICANN
ポール・ホフマンICANN
Email: paul.hoffman@icann.org