[要約] RFC 6304は、AS112ネームサーバーの運用に関するガイドラインです。その目的は、プライベートIPアドレス空間に対する不要なDNSトラフィックを処理するための効果的なネームサーバーの設計と運用を提供することです。
Internet Engineering Task Force (IETF) J. Abley
Request for Comments: 6304 ICANN
Category: Informational W. Maton
ISSN: 2070-1721 NRC-CNRC
July 2011
AS112 Nameserver Operations
AS112名前サーバー操作
Abstract
概要
Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.
インターネットに接続されている多くのサイトは、グローバルに一意ではないIPv4アドレスを使用しています。例は、個々のサイト内での私的使用のためにRFC 1918で指定されたアドレスです。
Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.
このような環境のデバイスは、これらの個人用アドレスに対応するドメイン名システム（DNS）クエリ（いわゆる「逆ルックアップ」）を発生することがあります。関係するアドレスは局所的な重要性しかないため、サイト管理者がそのようなクエリがローカルで回答されるようにすることは良い習慣です。ただし、このようなクエリがサイト内で回答するのではなく、公開DNSの通常の委任パスに従うことは珍しくありません。
It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.
パブリックDNSサーバーがそのようなクエリに有用な回答をすることは不可能です。さらに、個人用住所の幅広い展開とインターネットの継続的な成長により、そのようなクエリの量は大きく成長しています。AS112プロジェクトは、ADDR.ARPAの権威あるサーバーの負荷を減らすために、このようなクエリに分散シンクを提供することを目的としています。AS112プロジェクトは、割り当てられた自律システム番号（ASN）にちなんで命名されています。
This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation.
このドキュメントでは、新しいAS112ノードをインストールするために必要な手順について説明し、そのようなノードの操作に関連するアドバイスを提供します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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）の製品です。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/rfc6304.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6304で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. AS112 DNS Service . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Nameservers . . . . . . . . . . . . . . . . . . . . . . . 4
3. Installation of a New Node . . . . . . . . . . . . . . . . . . 5
3.1. Useful Background Knowledge . . . . . . . . . . . . . . . 5
3.2. Topological Location . . . . . . . . . . . . . . . . . . . 5
3.3. Operating System and Host Considerations . . . . . . . . . 5
3.4. Routing Software . . . . . . . . . . . . . . . . . . . . . 6
3.5. DNS Software . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Testing a Newly Installed Node . . . . . . . . . . . . . . 11
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Downtime . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Statistics and Measurement . . . . . . . . . . . . . . . . 12
5. Communications . . . . . . . . . . . . . . . . . . . . . . . . 12
6. On the Future of AS112 Nodes . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. History . . . . . . . . . . . . . . . . . . . . . . . 17
Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in [RFC1918] for private use within individual sites.
インターネットに接続されている多くのサイトは、グローバルに一意ではないIPv4アドレスを使用しています。例は、個々のサイト内での私的使用のために[RFC1918]で指定されたアドレスです。
Devices in such environments may occasionally originate Domain Name System (DNS) [RFC1034] queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally [RFC6303]. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.
このような環境のデバイスは、ドメイン名システム（DNS）[RFC1034]クエリ（いわゆる「リバースルックアップ」）を発生する場合があります。関係するアドレスは局所的な重要性しかないため、サイト管理者がそのようなクエリにローカルで回答されるようにすることは良い習慣です[RFC6303]。ただし、このようなクエリがサイト内で回答するのではなく、公開DNSの通常の委任パスに従うことは珍しくありません。
It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers [RFC5855].
パブリックDNSサーバーがそのようなクエリに有用な回答をすることは不可能です。さらに、個人用住所の幅広い展開とインターネットの継続的な成長により、そのようなクエリの量は大きく成長しています。AS112プロジェクトは、ADDR.ARPAの権威あるサーバー[RFC5855]の負荷を減らすために、このようなクエリに分散シンクを提供することを目的としています。
The AS112 project encompasses a loosely coordinated collection of independently operated nameservers. Each nameserver functions as a single node in an AS112 anycast cloud [RFC4786] and is configured to answer authoritatively for a particular set of nominated zones.
AS112プロジェクトには、独立して操作された名前サーバーの大まかに調整されたコレクションが含まれます。各名前サーバーは、AS112 Anycastクラウド[RFC4786]の単一ノードとして機能し、特定のノミネートされたゾーンのセットに対して権限に応答するように構成されています。
The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.
AS112プロジェクトは、割り当てられた自律システム番号（ASN）にちなんで命名されています。
AS112 nameservers answer authoritatively for the following zones, corresponding to [RFC1918] private-use netblocks:
AS112ネームサーバーは、[RFC1918]プライベート使用ネットブロックに対応する次のゾーンに対して権限に回答します。
o 10.IN-ADDR.ARPA
o
o 16.172.IN-ADDR.ARPA, 17.172.IN-ADDR.ARPA, ..., 31.172.IN-ADDR.ARPA
o 16.172.in-addr.arpa、17.172.in-addr.arpa、...、31.172.in-addr.arpa
o 168.192.IN-ADDR.ARPA
o
and the following zone, corresponding to the "link local" netblock 169.254.0.0/16 listed in [RFC5735]:
[RFC5735]にリストされている「Link Local」NetBlock 169.254.0.0/16に対応する次のゾーン：
o 254.169.IN-ADDR.ARPA
o
To aid identification of AS112 anycast nodes, each node also answers authoritatively for the zone HOSTNAME.AS112.NET.
AS112 Anycastノードの識別を支援するために、各ノードはZone Hostname.as112.netのゾーンHostnameについても権限を持って回答します。
See Section 3.5 for the recommended contents of all these zones.
これらすべてのゾーンの推奨コンテンツについては、セクション3.5を参照してください。
It is possible that other zones corresponding to private-use infrastructure will be delegated to AS112 servers in the future. A list of zones for which AS112 servers answer authoritatively is maintained at <http://www.as112.net/>.
プライベート使用インフラストラクチャに対応する他のゾーンは、将来AS112サーバーに委任される可能性があります。AS112サーバーが権限に応答するゾーンのリストは、<http://www.as112.net/>に維持されています。
The zones listed in Section 2.1 are delegated to the two nameservers BLACKHOLE-1.IANA.ORG (192.175.48.6) and BLACKHOLE-2.IANA.ORG (192.175.48.42).
セクション2.1にリストされているゾーンは、2つの名前の名前を付けたBlackhole-1.iana.org（192.175.48.6）およびBlackhole-2.iana.org（192.175.48.42）に委任されます。
Additionally, the server PRISONER.IANA.ORG (192.175.48.1) is listed in the MNAME field of the SOA records of the IN-ADDR.ARPA zones served by AS112 nameservers. PRISONER.IANA.ORG receives mainly dynamic update queries.
さらに、サーバーPrisoner.iana.org（192.175.48.1）は、AS112名の名前サーバーが提供するIn-Addr.ArpaゾーンのSOAレコードのMNAMEフィールドにリストされています。Prisoner.iana.orgは、主に動的な更新クエリを受け取ります。
The addresses of all these nameservers are covered by the single IPv4 prefix 192.175.48.0/24.
これらすべての名前アーバーのアドレスは、単一のIPv4プレフィックス192.175.48.0/24でカバーされています。
Installation of an AS112 node is relatively straightforward. However, experience in the following general areas may prove useful:
AS112ノードのインストールは比較的簡単です。ただし、次の一般的な領域での経験は有用であることが証明される場合があります。
o inter-domain routing with BGP [RFC4271];
o BGPを使用したドメイン間ルーティング[RFC4271];
o DNS authoritative server operations; and
o DNS権威あるサーバー操作。と
o anycast [RFC4786] distribution of DNS services.
o ANYCAST [RFC4786] DNSサービスの分布。
AS112 nodes may be located anywhere on the Internet. For nodes that are intended to provide a public service to the Internet community (as opposed to private use), it may well be advantageous to choose a location that is easily (and cheaply) reachable by multiple providers, such as an Internet Exchange Point.
AS112ノードは、インターネット上のどこにでも配置できます。インターネットコミュニティに公共サービスを提供することを目的としたノードの場合（個人使用とは対照的に）、インターネット交換ポイントなどの複数のプロバイダーが簡単に（そして安価に）到達できる場所を選択することが有利かもしれません。
AS112 nodes may advertise their service prefix to BGP peers for local use (analogous to a conventional peering relationship between two providers) or for global use (analogous to a customer relationship with one or more providers).
AS112ノードは、ローカル使用（2つのプロバイダー間の従来のピアリング関係に類似）またはグローバル使用（1つ以上のプロバイダーとの顧客関係に類似）のために、BGPピアへのサービスプレフィックスを宣伝する場合があります。
It is good operational practice to notify the community of users that may fall within the reach of a new AS112 node before it is installed. At an Internet Exchange, local mailing lists usually exist to facilitate such announcements. For nodes that are intended to be globally reachable, coordination with other AS112 operators is highly recommended. See also Section 5.
インストールされる前に、新しいAS112ノードの範囲内にある可能性のあるユーザーのコミュニティに通知することは、優れた運用慣行です。インターネット交換では、このような発表を促進するために、ローカルメーリングリストが通常存在します。グローバルに到達可能なノードの場合、他のAS112演算子との調整を強くお勧めします。セクション5も参照してください。
Examples in this document are based on UNIX and UNIX-like operating systems, but other operating systems exist that are suitable for use in construction of an AS112 node.
このドキュメントの例は、UNIXおよびUNIXのようなオペレーティングシステムに基づいていますが、AS112ノードの構築に適した他のオペレーティングシステムが存在します。
The chosen platform should include either support for cloned loopback interfaces or the capability to bind multiple addresses to a single loopback interface. The addresses of the nameservers listed in Section 2.2 will be configured on these interfaces in order that the DNS software can respond to queries properly.
選択したプラットフォームには、クローン化されたループバックインターフェイスのサポートまたは単一のループバックインターフェイスに複数のアドレスをバインドする機能を含める必要があります。セクション2.2にリストされている名前サーバーのアドレスは、DNSソフトウェアがクエリに適切に応答できるように、これらのインターフェイスで構成されます。
A host that is configured to act as an AS112 anycast node should be dedicated to that purpose and should not be used to simultaneously provide other services. This guidance is provided due to the unpredictable (and occasionally high) traffic levels that AS112 nodes have been seen to attract.
AS112 Anycastノードとして機能するように構成されているホストは、その目的に専念する必要があり、同時に他のサービスを提供するために使用しないでください。このガイダンスは、AS112ノードが引き付けると見られている予測不可能な（そして時々高い）交通レベルのために提供されます。
System startup scripts should be arranged such that the various AS112-related components start automatically following a system reboot. The order in which interfaces are configured and software components started should be arranged such that routing software startup follows DNS software startup, and DNS software startup follows loopback interface configuration.
システムの再起動に従って、さまざまなAS112関連コンポーネントが自動的に開始するように、システムスタートアップスクリプトを配置する必要があります。インターフェイスが設定され、ソフトウェアコンポーネントが開始される順序は、ルーティングソフトウェアの起動がDNSソフトウェアの起動に従い、DNSソフトウェアスタートアップがループバックインターフェイス構成に従うように配置する必要があります。
Wrapper scripts or other arrangements should be employed to ensure that the anycast service prefix for AS112 is not advertised while either the anycast addresses are not configured or the DNS software is not running.
ラッパースクリプトまたはその他のアレンジメントを使用して、AS112のAnycastサービスプレフィックスが宣伝されていないことを確認する必要がありますが、Anycastアドレスが構成されていないか、DNSソフトウェアが実行されていないことを確認する必要があります。
AS112 nodes signal the availability of AS112 nameservers to the Internet using BGP [RFC4271]: each AS112 node is a BGP speaker and announces the prefix 192.175.48.0/24 to the Internet with origin AS 112 (see also Section 2.2).
AS112ノードは、BGP [RFC4271]を使用してインターネットへのAS112ネームサーバーの可用性を信号します[RFC4271]：各AS112ノードはBGPスピーカーであり、192.175.48.0/24を発表します。
The examples in this document are based on the Quagga Routing Suite [QUAGGA] running on Linux, but other software packages exist that also provide suitable BGP support for AS112 nodes.
このドキュメントの例は、Linuxで実行されているQuaggaルーティングスイート[Quagga]に基づいていますが、AS112ノードに適したBGPサポートも提供する他のソフトウェアパッケージが存在します。
The "bgpd.conf" file is used by Quagga's bgpd daemon, which provides BGP support. The router ID in this example is 203.0.113.1; the AS112 node peers with external peers 192.0.2.1 and 192.0.2.2. Note the local AS number is 112, and the service prefix originated from the AS112 node is 192.175.48.0/24.
「BGPD.CONF」ファイルは、BGPサポートを提供するQuaggaのBGPDデーモンによって使用されます。この例のルーターIDは203.0.113.1です。外部ピアを備えたAS112ノードピア192.0.2.1および192.0.2.2。メモはローカルAS番号112であり、AS112ノードから発信されるサービスプレフィックスは192.175.48.0/24です。
! bgpd.conf ! hostname as112-bgpd password <something> enable password <supersomething> ! ! Note that all AS112 nodes use the local Autonomous System ! Number 112, and originate the IPv4 prefix 192.175.48.0/24. ! All other addresses shown below are illustrative, and ! actual numbers will depend on local circumstances. ! router bgp 112 bgp router-id 203.0.113.1 network 192.175.48.0 neighbor 192.0.2.1 remote-as 64496 neighbor 192.0.2.1 next-hop-self neighbor 192.0.2.1 prefix-list AS112 out neighbor 192.0.2.1 filter-list 1 out neighbor 192.0.2.2 remote-as 64497 neighbor 192.0.2.2 next-hop-self neighbor 192.0.2.2 prefix-list AS112 out neighbor 192.0.2.2 filter-list 1 out ! ip prefix-list AS112 permit 192.175.48.0/24 ! ip as-path access-list 1 permit ^$
！bgpd.conf！ホスト名AS112-BGPDパスワード<何か>パスワードを有効にする<SuperSomething>！！すべてのAS112ノードがローカル自律システムを使用していることに注意してください！番号112、およびIPv4プレフィックス192.175.48.0/24を発信します。！以下に示されている他のすべてのアドレスは実例です！実際の数は現地の状況に依存します。！ルーターBGP 112 BGP Router-ID 203.0.113.1ネットワーク192.175.48.0近隣192.0.2.1リモートAs 64496隣人192.0.2.1 Next-Hop-Self Neighbor 192.0.2.1プレフィックスリストAS112192.0.2.2 Remote-As 64497 Neighbor 192.0.2.2 Next-Hop-Self Neighbor 192.0.2.2プレフィックスリストAS112 OUT Neighbor 192.0.2.2フィルターリスト1アウト！IPプレフィックスリストAS112許可192.175.48.0/24！IP As-Path Access-List 1 Permit ^$
The configuration above includes a double-blinded restriction on what the AS112 node shall advertise to the pair of BGP neighbors. Firstly, that prefix-list "AS112" only containing the service prefix 192.175.48.0/24 shall be advertised. Secondly, the "ip as-path access-list 1" statement contains a one-line regular expression that permits only the local AS number (112 in this case) and no other to be advertised as well. Both statements prevent the node from becoming a transit router. Equivalent restrictions using other BGP implementations should be utilised.
上記の構成には、AS112ノードがBGP近隣のペアに宣伝するものに関する二重盲検制限が含まれています。まず、サービスプレフィックス192.175.48.0/24を含むプレフィックスリスト「AS112」が宣伝されます。第二に、「IP As-Path Access-List 1」ステートメントには、ローカルAS数（この場合は112）のみを許可する1行の正規表現が含まれており、他に宣伝されていません。どちらのステートメントも、ノードがトランジットルーターになるのを防ぎます。他のBGP実装を使用した同等の制限を利用する必要があります。
The "zebra.conf" file is required to provide integration between protocol daemons (bgpd, in this case) and the kernel.
「Zebra.Conf」ファイルは、プロトコルDaemons（この場合はBGPD）とカーネル間の統合を提供するために必要です。
! zebra.conf ! hostname as112 password <something> enable password <supersomething> ! interface lo ! interface eth0 !
！Zebra.Conf！ホスト名AS112パスワード<何か>パスワードを有効にする<SuperSomething>！インターフェイスlo！インターフェイスeth0！
Although the queries received by AS112 nodes are definitively misdirected, it is important that they be answered in a manner that is accurate and consistent. For this reason, AS112 nodes operate as fully functional and standards-compliant DNS authoritative servers [RFC1034], and hence require DNS software.
AS112ノードによって受信されたクエリは明確に誤った方向に向けられていますが、正確で一貫性のある方法で回答することが重要です。このため、AS112ノードは完全に機能的および標準に準拠したDNS権威あるサーバー[RFC1034]として動作するため、DNSソフトウェアが必要です。
Examples in this document are based on ISC BIND9 [BIND], but other DNS software exists that is suitable for use in construction of an AS112 node.
このドキュメントの例はISC BIND9 [BIND]に基づいていますが、AS112ノードの構築に適した他のDNSソフトウェアが存在します。
The following is a sample BIND9 "named.conf" file for a dedicated AS112 server. Note that the nameserver is configured to act as an authoritative-only server (i.e., recursion is disabled). The nameserver is also configured to listen on the various AS112 anycast nameserver addresses, as well as its local addresses.
以下は、専用のAS112サーバーのサンプルBind9 "named.conf"ファイルです。名前サーバーは、権威のある専用サーバーとして機能するように構成されていることに注意してください（つまり、再帰は無効になっています）。NameServerは、さまざまなAS112 AnyCast AngeCherverアドレスとそのローカルアドレスでリッスンするように構成されています。
// named.conf
// named.conf
// global options
//グローバルオプション
options {
listen-on {
127.0.0.1; // localhost
// The following address is node-dependent and should be set to // something appropriate for the new AS112 node.
//次のアドレスはノード依存であり、新しいAS112ノードに適したものに設定する必要があります。
203.0.113.1; // local address (globally unique, unicast)
203.0.113.1;//ローカルアドレス（グローバルにユニーク、ユニキャスト）
// the following addresses correspond to AS112 addresses, and // are the same for all AS112 nodes
//次のアドレスはAS112アドレスに対応し、//はすべてのAS112ノードで同じです
192.175.48.1; // prisoner.iana.org (anycast)
192.175.48.6; // blackhole-1.iana.org (anycast)
192.175.48.42; // blackhole-2.iana.org (anycast)
};
directory "/var/named";
recursion no; // authoritative-only server
query-source address *;
};
// Log queries, so that when people call us about unexpected
// answers to queries they didn't realise they had sent, we
// have something to talk about. Note that activating this
// has the potential to create high CPU load and consume
// enormous amounts of disk space.
logging {
channel "querylog" {
file "/var/log/query.log" versions 2 size 500m;
print-time yes;
};
category queries { querylog; };
};
// RFC 1918
// RFC 1918
zone "10.in-addr.arpa" { type master; file "db.empty"; };
zone "16.172.in-addr.arpa" { type master; file "db.empty"; };
zone "17.172.in-addr.arpa" { type master; file "db.empty"; };
zone "18.172.in-addr.arpa" { type master; file "db.empty"; };
zone "19.172.in-addr.arpa" { type master; file "db.empty"; };
zone "20.172.in-addr.arpa" { type master; file "db.empty"; };
zone "21.172.in-addr.arpa" { type master; file "db.empty"; };
zone "22.172.in-addr.arpa" { type master; file "db.empty"; };
zone "23.172.in-addr.arpa" { type master; file "db.empty"; };
zone "24.172.in-addr.arpa" { type master; file "db.empty"; };
zone "25.172.in-addr.arpa" { type master; file "db.empty"; };
zone "26.172.in-addr.arpa" { type master; file "db.empty"; };
zone "27.172.in-addr.arpa" { type master; file "db.empty"; };
zone "28.172.in-addr.arpa" { type master; file "db.empty"; };
zone "29.172.in-addr.arpa" { type master; file "db.empty"; };
zone "30.172.in-addr.arpa" { type master; file "db.empty"; };
zone "31.172.in-addr.arpa" { type master; file "db.empty"; };
zone "168.192.in-addr.arpa" { type master; file "db.empty"; };
// RFC 5735
// RFC 5735
zone "254.169.in-addr.arpa" { type master; file "db.empty"; };
// Also answer authoritatively for the HOSTNAME.AS112.NET zone, // which contains data of operational relevance.
//また、hostname.as112.netゾーン、//運用上の関連性のデータを含むhostname.as112.netゾーンについては権限に応答します。
zone "hostname.as112.net" {
type master;
file "db.hostname.as112.net";
};
The "db.empty" file follows, below. This is the source data used to populate all the IN-ADDR.ARPA zones listed in Section 2.1. Note that the RNAME specified in the SOA record corresponds to hostmaster@root-servers.org, a suitable email address for receiving technical queries about these zones.
「DB.Empty」ファイルは次のとおりです。これは、セクション2.1にリストされているすべてのin-addr.ARPAゾーンを入力するために使用されるソースデータです。SOAレコードで指定されたRNAMEは、これらのゾーンに関する技術的なクエリを受信するための適切なメールアドレスであるhostmaster@root-servers.orgに対応することに注意してください。
; db.empty
;
; Empty zone for AS112 server.
;
$TTL 1W
@ IN SOA prisoner.iana.org. hostmaster.root-servers.org. (
1 ; serial number
1W ; refresh
1M ; retry
1W ; expire
1W ) ; negative caching TTL
;
NS blackhole-1.iana.org.
NS blackhole-2.iana.org.
;
; There should be no other resource records included in this zone.
;
; Records that relate to RFC 1918-numbered resources within the
; site hosting this AS112 node should not be hosted on this
; nameserver.
The "db.hostname.as112.net" file follows, below. This zone contains various resource records that provide operational data to users for troubleshooting or measurement purposes; the data should be edited to suit local circumstances. Note that the response to the query "HOSTNAME.AS112.NET IN TXT" should fit within a 512-octet DNS/UDP datagram: i.e., it should be available over UDP transport without requiring EDNS0 support.
「db.hostname.as112.net」ファイルは以下に続きます。このゾーンには、トラブルシューティングまたは測定目的でユーザーに運用データを提供するさまざまなリソースレコードが含まれています。データは、現地の状況に合わせて編集する必要があります。クエリ「hostname.as112.net in txt」への応答は、512-OCTET DNS/UDPデータグラム内に収まるはずであることに注意してください。つまり、EDNS0サポートを必要とせずにUDPトランスポートよりも利用できるはずです。
The optional LOC record [RFC1876] included in the zone apex provides information about the geospatial location of the node.
ゾーンApexに含まれるオプションのLOCレコード[RFC1876]は、ノードの地理空間位置に関する情報を提供します。
; db.hostname.as112.net
;
$TTL 1W
@ SOA server.example.net. admin.example.net. (
1 ; serial number
1W ; refresh
1M ; retry
1W ; expire
1W ) ; negative caching TTL
;
NS blackhole-2.iana.org.
NS blackhole-1.iana.org.
;
TXT "Name of Facility or similar" "City, Country"
TXT "See http://www.as112.net/ for more information."
;
LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m
The BIND9 tool "dig" can be used to retrieve the TXT resource records associated with the domain "HOSTNAME.AS112.NET", directed at one of the AS112 anycast nameserver addresses. Continuing the example from above, the response received should indicate the identity of the AS112 node that responded to the query. See Section 3.5 for more details about the resource records associated with "HOSTNAME.AS112.NET".
BIND9ツール「DIG」を使用して、AS112 AnyCast NameServerアドレスのいずれかに向けられたドメイン「hostname.as112.net」に関連付けられたTXTリソースレコードを取得できます。上記の例を継続すると、受け取った応答は、クエリに応答したAS112ノードのIDを示す必要があります。「HOSTNAME.AS112.NET」に関連するリソースレコードの詳細については、セクション3.5を参照してください。
% dig @prisoner.iana.org hostname.as112.net txt +short +norec "Name of Facility or similar" "City, Country" "See http://www.as112.net/ for more information." %
％dig @prisoner.iana.org hostname.as112.net txt short norec "施設の名前または同様の" "都市、国」"詳細についてはhttp://www.as112.net/を参照してください。 "％
If the response received indicates a different node is being used, then there is probably a routing problem to solve. If there is no response received at all, there might be a host or nameserver problem. Judicious use of tools such as traceroute and consultation of BGP looking glasses might be useful in troubleshooting.
受信した応答が別のノードが使用されていることを示している場合、おそらく解決すべきルーティングの問題があります。応答がまったくない場合、ホストまたは名前サーバーの問題がある可能性があります。Tracerouteなどのツールの賢明な使用やBGP見た目のグラスの相談は、トラブルシューティングに役立つ可能性があります。
Note that an appropriate set of tests for a new server will include queries sent from many different places within the expected service area of the node, using both UDP and TCP transport, and exercising all three AS112 anycast nameserver addresses.
新しいサーバーの適切なテストセットには、Nodeの予想されるサービスエリア内のさまざまな場所から送信されたクエリが含まれ、UDPトランスポートとTCPトランスポートの両方を使用し、3つのAS112 Anycast NameServerアドレスすべてを行使することに注意してください。
AS112 nodes should be monitored to ensure they are functioning correctly, just as with any other production service. An AS112 node that stops answering queries correctly can cause failures and timeouts in unexpected places and can lead to failures in dependent systems that can be difficult to troubleshoot.
AS112ノードは、他の生産サービスと同様に、正しく機能していることを確認するために監視する必要があります。クエリの応答を正しく停止するAS112ノードは、予期しない場所で障害やタイムアウトを引き起こし、トラブルシューティングが困難な依存システムの障害につながる可能性があります。
An AS112 node that needs to go off-line (e.g., for planned maintenance or as part of the diagnosis of some problem) should stop advertising the AS112 service prefix to its BGP peers. This can be done by shutting down the routing software on the node altogether or by causing the routing system to withdraw the route.
オフラインにする必要があるAS112ノード（たとえば、計画されたメンテナンスの場合、または何らかの問題の診断の一部として）は、BGPピアへのAS112サービスプレフィックスの宣伝を停止する必要があります。これは、ノード上のルーティングソフトウェアを完全にシャットダウンするか、ルーティングシステムにルートを引き出すことで実行できます。
Withdrawing the service prefix is important in order to avoid blackholing query traffic in the event that the DNS software on the node is not functioning normally.
ノード上のDNSソフトウェアが正常に機能していない場合に、ブラックホールのクエリトラフィックを避けるために、サービスプレフィックスを撤回することは重要です。
Use of the AS112 node should be measured in order to track long-term trends, identify anomalous conditions, and ensure that the configuration of the AS112 node is sufficient to handle the query load.
AS112ノードの使用は、長期的な傾向を追跡し、異常な条件を特定し、AS112ノードの構成がクエリ負荷を処理するのに十分であることを確認するために測定する必要があります。
Examples of free monitoring tools that might be useful to operators of AS112 nodes include:
AS112ノードのオペレーターに役立つ可能性のある無料の監視ツールの例は次のとおりです。
o bindgraph [BINDGRAPH]
o bindgraph [bindgraph]
o dnstop [DNSTOP]
o dnstop [dnstop]
o DSC [DSC]
o DSC [DSC]
It is good operational practice to notify the community of users that may fall within the reach of a new AS112 node before it is installed. At Internet Exchanges, local mailing lists usually exist to facilitate such announcements.
インストールされる前に、新しいAS112ノードの範囲内にある可能性のあるユーザーのコミュニティに通知することは、優れた運用慣行です。インターネット交換では、このような発表を促進するために、ローカルメーリングリストが通常存在します。
For nodes that are intended to be globally reachable, coordination with other AS112 operators is especially recommended. The mailing list <as112-ops@lists.dns-oarc.net> is operated for this purpose.
グローバルに到達可能なノードの場合、他のAS112演算子との調整を特にお勧めします。メーリングリスト<as112-ops@lists.dns-oarc.net>は、この目的のために操作されています。
Information pertinent to AS112 operations is maintained at <http://www.as112.net/>.
AS112操作に関連する情報は、<http://www.as112.net/>に維持されます。
Information about an AS112 node should also be published within the DNS, within the "HOSTNAME.AS112.NET" zone. See Section 3.5 for more details.
AS112ノードに関する情報は、「HOSTNAME.AS112.NET」ゾーン内のDNS内でも公開する必要があります。詳細については、セクション3.5を参照してください。
It is recommended practice for the operators of recursive nameservers to answer queries for zones served by AS112 nodes locally, such that queries never have an opportunity to reach AS112 servers [RFC6303]. Operational experience with AS112 nodes does not currently indicate an observable trend towards compliance with those recommendations, however.
再帰的な名前アーバーの演算子が、AS112ノードがローカルで提供するゾーンのクエリに答えることが推奨されます。ただし、AS112ノードでの運用経験は、現在、これらの推奨事項のコンプライアンスに向けた観察可能な傾向を示していません。
It is expected that some DNS software vendors will include default configuration that will implement measures such as those described in [RFC6303]. If such software is widely deployed, it is reasonable to assume that the query load received by AS112 nodes will decrease; however, it is safe to assume that the query load will not decrease to zero, and consequently that AS112 nodes will continue to provide a useful service for the foreseeable future.
一部のDNSソフトウェアベンダーには、[RFC6303]に記載されているような測定値を実装するデフォルト構成が含まれることが予想されます。そのようなソフトウェアが広く展開されている場合、AS112ノードによって受信されたクエリ負荷が減少すると仮定するのは妥当です。ただし、クエリ負荷がゼロに減少しないと仮定すると安全です。その結果、AS112ノードは近い将来に有用なサービスを提供し続けます。
There may be a requirement in the future for AS112 nodes to answer for their current set of zones over IPv6 transport. Such a requirement would necessitate the assignment of a corresponding IPv6 netblock for use as an anycast service prefix.
AS112ノードがIPv6輸送を介した現在のゾーンセットに答えるために将来的に要件があるかもしれません。このような要件では、Anycastサービスプレフィックスとして使用するために、対応するIPv6 NetBlockの割り当てが必要になります。
There may be a requirement in the future for AS112 nodes to serve additional zones or to stop serving particular zones that are currently served. Such changes would be widely announced in operational forums and published at <http://www.as112.net/>.
AS112ノードが追加のゾーンを提供するか、現在提供されている特定のゾーンの提供を停止するために、将来的には要件があるかもしれません。このような変更は、運用フォーラムで広く発表され、<http://www.as112.net/>で公開されます。
The AS112 nameservers are all named under the domain IANA.ORG (see Section 2.2). However, the anycast infrastructure itself is operated by a loosely coordinated, diverse mix of organisations across the Internet, and is not an IANA function.
AS112名の名前はすべてdomain iana.orgの下に命名されています（セクション2.2を参照）。ただし、Anycast Infrastructure自体は、インターネット上の組織の大まかに調整された多様な組み合わせによって運営されており、IANA機能ではありません。
The Autonomous System Number 112 and the IPv4 prefix 192.175.48.0/24 were assigned by ARIN.
自律システム番号112およびIPv4プレフィックス192.175.48.0/24は、ARINによって割り当てられました。
Hosts should never normally send queries to AS112 servers; queries relating to private-use addresses should be answered locally within a site. Hosts that send queries to AS112 servers may well leak information relating to private infrastructure to the public network, and this could present a security risk. This risk is orthogonal to the presence or absence of authoritative servers for these zones in the public DNS infrastructure, however.
ホストは通常、AS112サーバーにクエリを送信しないでください。個人用アドレスに関連するクエリは、サイト内でローカルに回答する必要があります。AS112サーバーにクエリを送信するホストは、パブリックネットワークへのプライベートインフラストラクチャに関連する情報をリークする可能性があり、これはセキュリティリスクをもたらす可能性があります。ただし、このリスクは、公共のDNSインフラストラクチャのこれらのゾーンの権威あるサーバーの有無に直交しています。
Queries that are answered by AS112 servers are usually unintentional; it follows that the responses from AS112 servers are usually unexpected. Unexpected inbound traffic can trigger intrusion detection systems or alerts by firewalls. Operators of AS112 servers should be prepared to be contacted by operators of remote infrastructure who believe their security has been violated. Advice to those who mistakenly believe that responses from AS112 nodes constitute an attack on their infrastructure can be found in [RFC6305].
AS112サーバーによって回答されるクエリは通常、意図的ではありません。そのため、AS112サーバーからの応答は通常予想外です。予期しないインバウンドトラフィックは、侵入検知システムまたはファイアウォールによるアラートをトリガーする可能性があります。AS112サーバーのオペレーターは、セキュリティが侵害されていると考えているリモートインフラストラクチャのオペレーターから連絡する準備をする必要があります。AS112ノードからの応答がインフラストラクチャへの攻撃を構成することを誤って信じている人々へのアドバイスは、[RFC6305]に記載されています。
The deployment of AS112 nodes is very loosely coordinated compared to other services distributed using anycast. The malicious compromise of an AS112 node and subversion of the data served by the node are hence more difficult to detect due to the lack of central management. Since it is conceivable that changing the responses to queries received by AS112 nodes might influence the behaviour of the hosts sending the queries, such a compromise might be used as an attack vector against private infrastructure.
AS112ノードの展開は、Anycastを使用して配布される他のサービスと比較して非常に緩やかに調整されています。したがって、AS112ノードの悪意のある妥協とノードが提供するデータの転覆は、中央管理が不足しているために検出するのがより困難です。AS112ノードによって受信されたクエリへの応答を変更すると、クエリの送信ホストの動作に影響を与える可能性があるため、そのような妥協はプライベートインフラストラクチャに対する攻撃ベクトルとして使用される可能性があると考えられます。
Operators of AS112 should take appropriate measures to ensure that AS112 nodes are appropriately protected from compromise, such as would normally be employed for production nameserver or network infrastructure. The guidance provided for root nameservers in [RFC2870] may be instructive.
AS112のオペレーターは、AS112ノードが妥協から適切に保護されていることを確認するために適切な対策を講じる必要があります。たとえば、通常は生産名サーバーまたはネットワークインフラストラクチャに使用されるようなものです。[RFC2870]のルートネームサーバーに提供されるガイダンスは有益です。
The zones hosted by AS112 servers are not signed with DNSSEC [RFC4033]. Given the distributed and loosely coordinated structure of the AS112 service, the zones concerned could only be signed if the private key material used was effectively public, obviating any security benefit resulting from the use of those keys.
AS112サーバーがホストするゾーンは、DNSSEC [RFC4033]で署名されていません。AS112サービスの分散および緩やかに調整された構造を考えると、関係するゾーンは、使用された秘密キー資料が効果的に公開されている場合にのみ署名でき、それらのキーの使用に起因するセキュリティ利益を除外します。
The authors wish to acknowledge the assistance of Bill Manning, John Brown, Marco D'Itri, Daniele Arena, Stephane Bortzmeyer, Frank Habicht, Chris Thompson, Peter Losher, Peter Koch, Alfred Hoenes, S. Moonesamy, and Mehmet Akcin in the preparation of this document.
著者は、ビル・マニング、ジョン・ブラウン、マルコ・ドリ、ダニエレ・アリーナ、ステファン・ボルツマイヤー、フランク・ハビヒト、クリス・トンプソン、ピーター・ロッシャー、ピーター・コッホ、アルフレッド・ホーネス、S。ムーネミー、メフメット・アクシンの準備を認めたいと考えています。このドキュメントの。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name Server Operational Requirements", BCP 40, RFC 2870, June 2000.
[RFC2870] Bush、R.、Karrenberg、D.、Kosters、M。、およびR. Plzak、「ルートネームサーバーの運用要件」、BCP 40、RFC 2870、2000年6月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティの導入と要件」、RFC 4033、2005年3月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006.
[RFC4786] Eabley、J。およびK. Lindqvist、「Anycast Servicesの運用」、BCP 126、RFC 4786、2006年12月。
[BIND] Internet Systems Consortium, "BIND", <http://www.isc.org/software/BIND/>.
[バインド]インターネットシステムコンソーシアム、「バインド」、<http://www.isc.org/software/bind/>。
[BINDGRAPH] Delaurenti, M. and M. d'Itri, "bindgraph", <http://www.linux.it/~md/software/>.
[Bindgraph] Delaurenti、M。and M. D'Itri、 "Bindgraph"、<http://www.linux.it/~md/software/>。
[DNSTOP] The Measurement Factory, "Dnstop: Stay on Top of Your DNS Traffic", <http://dns.measurement-factory.com/tools/dnstop/>.
[DNSTOP]測定工場、「DNSTOP：DNSトラフィックの上にとどまる」、<http://dns.measurementfactory.com/tools/dnstop/>。
[DSC] The Measurement Factory, "Dsc: A DNS Statistics Collector", <http://dns.measurement-factory.com/tools/dsc/>.
[DSC]測定工場、「DSC：A DNS統計コレクター」、<http://dns.measurementfactory.com/tools/dsc/>。
[QUAGGA] "Quagga Software Routing Suite", <http://www.quagga.net>.
[Quagga]「Quaggaソフトウェアルーティングスイート」、<http://www.quagga.net>。
[RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means for Expressing Location Information in the Domain Name System", RFC 1876, January 1996.
[RFC1876] Davis、C.、Vixie、P.、Goodwin、T。、およびI. Dickinson、「ドメイン名システムで位置情報を表現する手段」、RFC 1876、1996年1月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735] Cotton、M。およびL. Vegoda、「Special Use IPv4アドレス」、BCP 153、RFC 5735、2010年1月。
[RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 Reverse Zones", BCP 155, RFC 5855, May 2010.
[RFC5855] Abley、J。およびT. Manderson、「IPv4およびIPv6リバースゾーンの名前の名前」、BCP 155、RFC 5855、2010年5月。
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, July 2011.
[RFC6303]アンドリュース、M。、「地元で提供されるDNSゾーン」、BCP 163、RFC 6303、2011年7月。
[RFC6305] Abley, J. and W. Maton, "I'm Being Attacked by PRISONER.IANA.ORG!", RFC 6305, July 2011.
[RFC6305] Abley、J。およびW. Maton、「私はPrisoner.iana.org！に攻撃されています！」、RFC 6305、2011年7月。
Widespread use of the private address blocks listed in [RFC1918] followed that document's publication in 1996. At that time the IN-ADDR.ARPA zone was served by root servers.
[RFC1918]にリストされているプライベートアドレスブロックの広範な使用は、1996年にその文書の公開に続きました。その時点で、In-Addr.Arpaゾーンはルートサーバーによって提供されました。
The idea of off-loading IN-ADDR.ARPA queries relating to [RFC1918] addresses from the root nameservers was first proposed by Bill Manning and John Brown.
[RFC1918]に関連するADDR.ARPA内でオフロードするというアイデアは、ルートネームサーバーからのアドレスを最初に提案しました。
The use of anycast for distributing authoritative DNS service for [RFC1918] IN-ADDR.ARPA zones was subsequently proposed at a private meeting of root server operators.
[RFC1918] In-Addr.Arpaゾーンの権威あるDNSサービスを配布するためのAnycastの使用は、その後、ルートサーバーオペレーターの民間会議で提案されました。
ARIN provided an IPv4 prefix for the anycast service and also the autonomous system number 112 for use in originating that prefix. This assignment gave the project its name.
Arinは、AnycastサービスにIPv4プレフィックスを提供し、そのプレフィックスを発信する際に使用するための自律システム番号112も提供しました。この課題はプロジェクトに名前を与えました。
In 2002, the first AS112 anycast nodes were deployed.
2002年には、最初のAS112 Anycastノードが展開されました。
In 2011, the IN-ADDR.ARPA zone was redelegated from the root servers to a new set of servers operated independently by AfriNIC, APNIC, ARIN, ICANN, LACNIC, and the RIPE NCC and named according to [RFC5855].
2011年、In-ADDR.ARPAゾーンは、ルートサーバーからアフリニック、Apnic、Arin、ICANN、LACNIC、およびRIPE NCCによって独立して動作する新しいサーバーのセットに再接続され、[RFC5855]に従って指名されました。
The use of anycast nameservers in the AS112 project contributed to the operational experience of anycast DNS services, and it can be seen as a precursor to the anycast distribution of other authoritative DNS servers in subsequent years (e.g., various root servers).
AS112プロジェクトでのAnycast NameServersの使用は、Anycast DNSサービスの運用体験に貢献し、その後の年に他の権威あるDNSサーバーのAnycast Distributionの前兆と見なすことができます（さまざまなルートサーバーなど）。
Authors' Addresses
著者のアドレス
Joe Abley ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 US
Joeabley Icann 4676 Admiralty Way、Suite 330 Marina Del Rey、CA 90292 US
Phone: +1 519 670 9327
EMail: joe.abley@icann.org
William F. Maton Sotomayor National Research Council of Canada 1200 Montreal Road Ottawa, ON K1A 0R6 Canada
ウィリアムF.マトンソトマヨールカナダ国立研究評議会1200モントリオールロードオタワ、K1A 0R6カナダ
Phone: +1 613 993 0880
EMail: wmaton@ryouko.imsb.nrc.ca