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
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プロジェクトはIN-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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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プロジェクトはIN-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エニーキャスト雲[RFC4786]の1つのノードとして機能し、指名区域の特定のセットのために正式に回答するように構成されています。
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 16.172.IN-ADDR.ARPA, 17.172.IN-ADDR.ARPA, ..., 31.172.IN-ADDR.ARPA
お １６。１７２。いんーあっｄＲ。あＲぱ、 １７。１７２。いんーあっｄＲ。あＲぱ、 。。。、 ３１。１７２。いんーあっｄＲ。あＲぱ
o 168.192.IN-ADDR.ARPA
お １６８。１９２。いんーあっｄＲ。あＲぱ
and the following zone, corresponding to the "link local" netblock 169.254.0.0/16 listed in [RFC5735]:
[RFC5735]に記載されている「リンクローカル」ネットブロック169.254.0.0/16に対応し、次のゾーン：
o 254.169.IN-ADDR.ARPA
お ２５４。１６９。いんーあっｄＲ。あＲぱ
To aid identification of AS112 anycast nodes, each node also answers authoritatively for the zone HOSTNAME.AS112.NET.
AS112のエニーキャスト・ノードの識別を助けるために、各ノードはまた、ゾーンHOSTNAME.AS112.NETための正式回答します。
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に記載されているゾーンは、二つのネームサーバ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];
BGP [RFC4271]とOドメイン間ルーティング。
o DNS authoritative server operations; and
OのDNS権威サーバ操作;そして
o anycast [RFC4786] distribution of DNS services.
DNSサービスのOエニーキャスト[RFC4786]配布。
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のノードは、（1つのまたは複数のプロバイダと顧客との関係に類似）ローカルで使用するために（2つのプロバイダ間の従来のピアリング関係に類似）、またはグローバルに使用するために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のエニーキャスト・ノードとして動作するように構成されているホストは、その目的に専用されるべきであり、同時に他のサービスを提供するために使用すべきではありません。このガイダンスは、原因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.
ラッパースクリプトまたは他の構成は、エニーキャストアドレスが設定されていないか、DNSソフトウェアが実行されていないのどちらか一方でAS112のためのエニーキャストサービスプレフィクスがアドバタイズされていないことを確実にするために用いられるべきです。
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ネームサーバの可用性を知らせる：各AS112ノードは、BGPスピーカであり、（セクション2.2を参照）112と原点とインターネットにプレフィックス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.
このドキュメントの例は、Quaggaのルーティングスイート[クアッガ]に基づいており、Linux上で実行されているが、他のソフトウェアパッケージも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です。外部ピアの192.0.2.1と192.0.2.2とAS112ノードピア。ローカル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を発信。 ！以下に示す他のすべてのアドレスは例示であり、そして！実際の数値は、地域の状況に依存します。 ！リモートとして隣接アウト64496ネイバー192.0.2.1次ホップ自己ネイバー192.0.2.1プレフィックスリストAS112アウトネイバー192.0.2.1フィルタリスト1 112のBGPルータID 203.0.113.1ネットワーク192.175.48.0ネイバー192.0.2.1 BGPルータ192.0.2.2リモート-として64497隣人192.0.2.2ネクストホップ自己ネイバー192.0.2.2のプレフィクスリストのAS112アウト隣人192.0.2.2フィルタリスト1アウト！ IPプレフィクスリストのAS112許可192.175.48.0/24！ IPなどのパスアクセスリスト1つの許可^ $
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などのパスアクセスリスト1」の文も同様にアドバタイズされるだけ（この場合は112）AS番号、ローカルおよびなし他を許可する1行の正規表現が含まれています。どちらのステートメントは、トランジットルータになってからノードを防ぎます。他のBGPの実装を使用して同等の制限は利用すべきです。
The "zebra.conf" file is required to provide integration between protocol daemons (bgpd, in this case) and the kernel.
「zebra.conf」ファイルは、プロトコルデーモン（この場合はbgpd、）とカーネルの間の統合を提供するために必要とされます。
! zebra.conf ! hostname as112 password <something> enable password <supersomething> ! interface lo ! interface eth0 !
！ zebra.conf！ホスト名AS112パスワード<何か>パスワードを有効にするには、<supersomething>！インタフェース見よ！インターフェイス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]に基づいて、他のDNSソフトウェアは、それがAS112ノードの構成での使用に適して存在しています。
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」ファイルです。ネームサーバは、権限の専用サーバとして動作するように構成されている（すなわち、再帰が無効になっています）。ネームサーバはまた、様々なAS112エニーキャストネームサーバのアドレスだけでなく、そのローカルアドレスをリッスンするように設定されています。
// named.conf
// named.confの
// global options
//グローバルオプション
options { listen-on { 127.0.0.1; // localhost
オプション{聞くオン{127.0.0.1; // localhostを
// The following address is node-dependent and should be set to // something appropriate for the new AS112 node.
//次のアドレスは、ノードに依存しており、新しいAS112ノードの適切な何かを//に設定する必要があります。
// 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)
192.175.48.1; // prisoner.iana.org（エニー）192.175.48.6; // blackhole-1.iana.org（エニー）192.175.48.42。 // blackhole-2.iana.org（エニーキャスト）
};
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.
人々がクエリに//予想外の答えについての私達を呼び出すとき、彼らが送信されていたことに気づかなかった、我々はについて話をする何かを持っている// //よう、クエリをログに記録します。この//を活性化することは、高いCPUの負荷を作成し、ディスクスペースの//膨大な量を消費する可能性があることに注意してください。
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"; };
ゾーン「254.169.in-addr.arpa」{タイプマスター;ファイル「db.empty」。 }。
// Also answer authoritatively for the HOSTNAME.AS112.NET zone, // which contains data of operational relevance.
//また、業務関連のデータが含まれている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」ファイルは、以下の、次の。このゾーンは、トラブルシューティングや測定の目的のためにユーザーに運用データを提供する様々なリソースレコードが含まれています。データは、地域の実情に合うように編集する必要があります。すなわち、それはEDNS0のサポートを必要とせずにUDPトランスポートを介して利用可能であるべきである：「TXT、IN HOSTNAME.AS112.NET」クエリに対する応答が512オクテットDNS / UDPデータグラム内に収まらなければならないことに注意してください。
The optional LOC record [RFC1876] included in the zone apex provides information about the geospatial location of the node.
任意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ツールは、AS112のエニーキャストネームサーバのアドレスのいずれかに向けドメイン「HOSTNAME.AS112.NET」、に関連したTXTリソースレコードを取得するために使用することができ、「DIG」。上から例を続けると、受信した応答は、クエリに応答した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."
%
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.
応答が受信された場合、別のノードが使用されていることを示し、次に解決するルーティング問題は、おそらくあります。全く受信応答がない場合は、ホストまたはネームサーバに問題がある可能性があります。メガネを探して、そのような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.
新しいサーバーのテストの適切なセットがUDPとTCPトランスポート、および3つのすべてのAS112のエニーキャストネームサーバのアドレスを行使両方を使用して、ノードの予想されるサービスエリア内のさまざまな場所から送信されたクエリが含まれることに注意してください。
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]
マイクロBindgraf [Bindgraf]
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サーバ[RFC6303]を到達する機会を持つことはありませんように、お勧めです。 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トランスポート上のゾーンの彼らの現在のセットのために答えるの将来の要件があるかもしれません。そのような要件は、エニーキャストサービス接頭辞として使用するための対応のIPv6ネットブロックの割り当てを必要とします。
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のネームサーバは、すべてのドメインIANA.ORG（2.2節を参照）の下に名前が付けられます。しかし、エニーキャストインフラ自体がインターネットを経由し、組織の緩く調整し、多様なミックスによって運営され、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ノードの展開は非常に緩く、エニーキャストを使用して分散する他のサービスに比べて調整されています。ノードがサービスを提供データの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.
著者は、準備にビル・マニング、ジョン・ブラウン、マルコD'Itriさん、ダニエル・アリーナ、ステファンBortzmeyer、フランクHabicht、クリス・トンプソン、ピーターLosher、ピーター・コッホ、アルフレッドHoenes、S. Moonesamy、およびメフメットAkcinの支援を認めることを望みますこのドキュメントの。
[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.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、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]ブッシュ、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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006.
[RFC4786] Abley、J.およびK. Lindqvist、 "エニーキャストサービスの運用"、BCP 126、RFC 4786、2006年12月。
[BIND] Internet Systems Consortium, "BIND", <http://www.isc.org/software/BIND/>.
[BIND]インターネットシステムコンソーシアム、 "BIND"、<http://www.isc.org/software/BIND/>。
[BINDGRAPH] Delaurenti, M. and M. d'Itri, "bindgraph", <http://www.linux.it/~md/software/>.
【BINDGRAPH] Delaurenti、M.および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.measurement-factory.com/tools/dnstop/>。
[DSC] The Measurement Factory, "Dsc: A DNS Statistics Collector", <http://dns.measurement-factory.com/tools/dsc/>.
[DSC]測定ファクトリー、 "DSC：DNS統計情報収集"、<http://dns.measurement-factory.com/tools/dsc/>。
[QUAGGA] "Quagga Software Routing Suite", <http://www.quagga.net>.
[クアッガ] "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]デイビス、C.、いるVixie、P.、グッドウィン、T.、およびI.ディキンソン、RFC 1876 "ドメインネームシステムに位置情報を表現するための手段"、1996年1月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]コットン、M.およびL. Vegoda、 "特別の使用の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月。
Appendix A. History
付録A.歴史
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]に記載されているプライベートアドレスブロックの普及は、IN-ADDR.ARPAゾーンはルートサーバによって提供された当時は1996年にその文書の公表を行いました。
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]のアドレスに関連するオフロードのIN-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サービスを配信するためのエニーキャストの使用は、その後、ルートサーバ運営者の私的会合で提案されました。
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は、エニーキャストサービスともその接頭辞を発信に使用するための自律システム番号112のIPv4のプレフィックスを提供しました。この割り当ては、プロジェクトにその名前を与えました。
In 2002, the first AS112 anycast nodes were deployed.
2002年には、最初のAS112のエニーキャストノードが展開されました。
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ゾーンは、[RFC5855]によるとAfriNIC、APNIC、ARIN、ICANN、LACNIC、RIPE NCCとで独立して動作のサーバーの新しいセットにルートサーバからredelegatedと命名されました。
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プロジェクトにおけるエニーキャストネームサーバを使用すると、エニーキャストDNSサービスの運用経験に貢献し、それがその後の数年間で、他の権威DNSサーバのエニーキャスト配信への前駆体（例えば、様々なルートサーバ）として見ることができます。
Authors' Addresses
著者のアドレス
Joe Abley ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 US
ジョーAbley ICANN 4676アドミラルティ・ウェイ、スイート330マリナ・デル・レイ、CA 90292米国
Phone: +1 519 670 9327 EMail: joe.abley@icann.org
電話：+1 519 670 9327 Eメール：joe.abley@icann.org
William F. Maton Sotomayor National Research Council of Canada 1200 Montreal Road Ottawa, ON K1A 0R6 Canada
K1A 0R6カナダONカナダ1200年モントリオール道路オタワのウィリアム・F. Matonソトマイヨール国立研究評議会、
Phone: +1 613 993 0880 EMail: wmaton@ryouko.imsb.nrc.ca
電話：+1 613 993 0880 Eメール：wmaton@ryouko.imsb.nrc.ca