[要約] RFC 9199は、大規模な権威DNSサーバー運用者が直面する考慮事項について述べています。この文書の目的は、インターネットの安定性と信頼性を高めるための運用上のベストプラクティスを提供することです。主に、大規模なDNSインフラを管理・運用する技術者や組織が利用する場面が想定されます。
Independent Submission G. Moura
Request for Comments: 9199 SIDN Labs/TU Delft
Category: Informational W. Hardaker
ISSN: 2070-1721 J. Heidemann
USC/Information Sciences Institute
M. Davids
SIDN Labs
March 2022
Considerations for Large Authoritative DNS Server Operators
大規模な権限DNSサーバー事業者に関する考慮事項
Abstract
概要
Recent research work has explored the deployment characteristics and configuration of the Domain Name System (DNS). This document summarizes the conclusions from these research efforts and offers specific, tangible considerations or advice to authoritative DNS server operators. Authoritative server operators may wish to follow these considerations to improve their DNS services.
最近の研究作業は、ドメインネームシステム（DNS）の展開特性と構成を検討しました。この文書は、これらの研究努力からの結論を要約し、信頼できるDNSサーバー事業者に特定の有形の考慮事項またはアドバイスを提供しています。権限サーバーオペレーターは、DNSサービスを向上させるためにこれらの考慮事項に従うことを望むかもしれません。
It is possible that the results presented in this document could be applicable in a wider context than just the DNS protocol, as some of the results may generically apply to any stateless/short-duration anycasted service.
この文書に提示された結果は、いくつかの結果が、どのようなステートレス/短期間のAnycastサービスにも一般的に適用される可能性があるため、DNSプロトコルだけでは、より広い文脈に適用できます。
This document is not an IETF consensus document: it is published for informational purposes.
この文書はIETFコンセンサス文書ではありません。情報提供のために公開されています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。それは情報提供のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディタは、この文書をその判断で公開することを選択し、実装または展開の値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9199.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9199で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF信頼と文書の著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。
Table of Contents
目次
1. Introduction
2. Background
3. Considerations
3.1. C1: Deploy Anycast in Every Authoritative Server to Enhance
Distribution and Latency
3.1.1. Research Background
3.1.2. Resulting Considerations
3.2. C2: Optimizing Routing is More Important than Location
Count and Diversity
3.2.1. Research Background
3.2.2. Resulting Considerations
3.3. C3: Collect Anycast Catchment Maps to Improve Design
3.3.1. Research Background
3.3.2. Resulting Considerations
3.4. C4: Employ Two Strategies When under Stress
3.4.1. Research Background
3.4.2. Resulting Considerations
3.5. C5: Consider Longer Time-to-Live Values Whenever Possible
3.5.1. Research Background
3.5.2. Resulting Considerations
3.6. C6: Consider the Difference in Parent and Children's TTL
Values
3.6.1. Research Background
3.6.2. Resulting Considerations
4. Security Considerations
5. Privacy Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
This document summarizes recent research that explored the deployed DNS configurations and offers derived, specific, tangible advice to DNS authoritative server operators (referred to as "DNS operators" hereafter). The considerations (C1-C6) presented in this document are backed by peer-reviewed research, which used wide-scale Internet measurements to draw their conclusions. This document summarizes the research results and describes the resulting key engineering options. In each section, readers are pointed to the pertinent publications where additional details are presented.
この文書は、展開されたDNS構成を探求した最近の研究を要約し、DNS権限のサーバー演算子（以下、「DNS演算子」と呼ばれる）を提供します。この文書に記載されている考慮事項（C1~C6）は、査読付き研究によって支えられており、これは幅広いインターネット測定を使用して結論を引き出す。この文書は研究結果をまとめ、結果として得られる重要なエンジニアリングオプションについて説明します。各セクションでは、読者は追加の詳細が提示されている適切な出版物に指摘されています。
These considerations are designed for operators of "large" authoritative DNS servers, which, in this context, are servers with a significant global user population, like top-level domain (TLD) operators, run by either a single operator or multiple operators. Typically, these networks are deployed on wide anycast networks [RFC1546] [AnyBest]. These considerations may not be appropriate for smaller domains, such as those used by an organization with users in one unicast network or in a single city or region, where operational goals such as uniform, global low latency are less required.
これらの考慮事項は、この文脈では、最上位のドメイン（TLD）演算子など、一つのオペレータまたは複数の演算子によって実行される、グローバルなユーザ人口を有するサーバである「大」権限DNSサーバの演算子向けに設計されています。通常、これらのネットワークはワイドエニーキャストネットワークで展開されています[RFC1546] [ANARBEST]。これらの考慮事項は、1つのユニキャストネットワーク内のユーザーが使用されているもの、または一様な世界的な低遅延などの運用上の目標が必要でない単一の都市または地域で使用されるものなど、小さいドメインには適切ではないかもしれません。
It is possible that the results presented in this document could be applicable in a wider context than just the DNS protocol, as some of the results may generically apply to any stateless/short-duration anycasted service. Because the conclusions of the reviewed studies don't measure smaller networks, the wording in this document concentrates solely on discussing large-scale DNS authoritative services.
この文書に提示された結果は、いくつかの結果が、どのようなステートレス/短期間のAnycastサービスにも一般的に適用される可能性があるため、DNSプロトコルだけでは、より広い文脈に適用できます。レビューされた研究の結論は小さいネットワークを測定しないため、この文書の文言は大規模なDNS権限サービスについてのみ議論するだけです。
This document is not an IETF consensus document: it is published for informational purposes.
この文書はIETFコンセンサス文書ではありません。情報提供のために公開されています。
The DNS has two main types of DNS servers: authoritative servers and recursive resolvers, shown by a representational deployment model in Figure 1. An authoritative server (shown as AT1-AT4 in Figure 1) knows the content of a DNS zone and is responsible for answering queries about that zone. It runs using local (possibly automatically updated) copies of the zone and does not need to query other servers [RFC2181] in order to answer requests. A recursive resolver (Re1-Re3) is a server that iteratively queries authoritative and other servers to answer queries received from client requests [RFC1034]. A client typically employs a software library called a "stub resolver" ("stub" in Figure 1) to issue its query to the upstream recursive resolvers [RFC1034].
DNSには、2つの主要なタイプのDNSサーバーがあります。そのゾーンに関するクエリに答える。それはゾーンのローカル（自動更新）コピーを使用して実行され、要求に応答するために他のサーバー[RFC2181]を照会する必要はありません。再帰リゾルバ（RE1-RE3）は、信頼できるサーバーと他のサーバーをクライアント要求から受信したクエリに回答するサーバーです[RFC1034]。クライアントは通常、「スタブリゾルバ」と呼ばれるソフトウェアライブラリ（図1の「スタブ」）を使用して、アップストリーム再帰リゾルバ[RFC1034]にクエリを発行します。
+-----+ +-----+ +-----+ +-----+
| AT1 | | AT2 | | AT3 | | AT4 |
+-----+ +-----+ +-----+ +-----+
^ ^ ^ ^
| | | |
| +-----+ | |
+------| Re1 |----+| |
| +-----+ |
| ^ |
| | |
| +----+ +----+ |
+------|Re2 | |Re3 |------+
+----+ +----+
^ ^
| |
| +------+ |
+-| stub |-+
+------+
Figure 1: Relationship between Recursive Resolvers (Re) and Authoritative Name Servers (ATn)
図1：再帰リゾルバ（RE）と権威あるネームサーバ（ATN）の関係
DNS queries issued by a client contribute to a user's perceived latency and affect the user experience [Singla2014] depending on how long it takes for responses to be returned. The DNS system has been subject to repeated Denial-of-Service (DoS) attacks (for example, in November 2015 [Moura16b]) in order to specifically degrade the user experience.
クライアントによって発行されたDNSクエリは、ユーザーの認識された待ち時間に貢献し、返信を返すのにかかる時間に応じてユーザーエクスペリエンス[SingLA2014]に影響を与えます。DNSシステムは、ユーザーエクスペリエンスを特に劣化させるために、繰り返しサービス拒否（DOS）攻撃（例えば、2015年11月の[Moura16B]）の対象となっています。
To reduce latency and improve resiliency against DoS attacks, the DNS uses several types of service replication. Replication at the authoritative server level can be achieved with the following:
待ち時間を減らし、DOS攻撃に対する回復力を向上させるために、DNSはいくつかの種類のサービス複製を使用します。信頼できるサーバーレベルでのレプリケーションは、次のようにして実現できます。
i. the deployment of multiple servers for the same zone [RFC1035] (AT1-AT4 in Figure 1);
i. 同じゾーン[RFC1035]の複数のサーバーの展開（図1のAT1-AT4）。
ii. the use of IP anycast [RFC1546] [RFC4786] [RFC7094] that allows the same IP address to be announced from multiple locations (each of referred to as an "anycast instance" [RFC8499]); and
ii。IP Anycast [RFC1546] [RFC4786] [RFC7094] [RFC7094]を使用すると、同じIPアドレスを複数の場所から発表できます（「Anycastインスタンス」[RFC8499]）。と
iii. the use of load balancers to support multiple servers inside a single (potentially anycasted) instance. As a consequence, there are many possible ways an authoritative DNS provider can engineer its production authoritative server network with multiple viable choices, and there is not necessarily a single optimal design.
III。単一の（潜在的にAnycasted）インスタンス内の複数のサーバーをサポートするためのロードバランサの使用。その結果、信頼できるDNSプロバイダーが複数の実行可能な選択肢を持つ生産権限サーバーネットワークをエンジニアリングできる可能な方法がたくさんあり、必ずしも単一の最適な設計はありません。
In the next sections, we cover the specific considerations (C1-C6) for conclusions drawn within academic papers about large authoritative DNS server operators. These considerations are conclusions reached from academic work that authoritative server operators may wish to consider in order to improve their DNS service. Each consideration offers different improvements that may impact service latency, routing, anycast deployment, and defensive strategies, for example.
次のセクションでは、大規模な信頼できるDNSサーバー事業者についての学術論文内に描かれた結論のための具体的な考慮事項（C1-C6）をカバーしています。これらの考慮事項は、信頼できるサーバー事業者がDNSサービスを改善するために検討を希望することがあると学術作業から到達した結論です。各考察は、例えば、サービスの待ち時間、ルーティング、エネルギー展開、および防御戦略に影響を与える可能性があるさまざまな改善を提供します。
3.1. C1: Deploy Anycast in Every Authoritative Server to Enhance Distribution and Latency
3.1. C1：配布と待ち時間を強化するために、すべての権限サーバーでエネルギーを展開する
Authoritative DNS server operators announce their service using NS records [RFC1034]. Different authoritative servers for a given zone should return the same content; typically, they stay synchronized using DNS zone transfers (authoritative transfer (AXFR) [RFC5936] and incremental zone transfer (IXFR) [RFC1995]), coordinating the zone data they all return to their clients.
権限のあるDNSサーバー事業者は、NSレコード[RFC1034]を使用してサービスを発表します。特定のゾーン用のさまざまな権限サーバーは同じコンテンツを返すはずです。通常、それらはDNSゾーン転送（権限転送（AXFR）[RFC5936]および[IXFR）[RFC1995]）を使用して同期しています。すべてのクライアントに戻るゾーンデータを調整します。
As discussed above, the DNS heavily relies upon replication to support high reliability, ensure capacity, and reduce latency [Moura16b]. The DNS has two complementary mechanisms for service replication: name server replication (multiple NS records) and anycast (multiple physical locations). Name server replication is strongly recommended for all zones (multiple NS records), and IP anycast is used by many larger zones such as the DNS root [AnyFRoot], most top-level domains [Moura16b], and many large commercial enterprises, governments, and other organizations.
上述したように、DNSは高い信頼性をサポートするために複製に大きく依存し、容量を確保し、待ち時間[Moura16B]を減らす。DNSには、サービスレプリケーションの2つの補完メカニズムがあります。ネームサーバーのレプリケーション（複数のNSレコード）とAnycast（複数の物理的位置）。ネームサーバーのレプリケーションはすべてのゾーン（複数のNSレコード）に強く推奨され、IP AnercastはDNSルート[Anyfroot]、ほとんどの最上位ドメイン[Moura16B]、および多くの大規模な商業企業、政府などの多くの大規模ゾーンで使用されています。そして他の組織。
Most DNS operators strive to reduce service latency for users, which is greatly affected by both of these replication techniques. However, because operators only have control over their authoritative servers and not over the client's recursive resolvers, it is difficult to ensure that recursives will be served by the closest authoritative server. Server selection is ultimately up to the recursive resolver's software implementation, and different vendors and even different releases employ different criteria to choose the authoritative servers with which to communicate.
ほとんどのDNS演算子は、ユーザーのサービス待ち時間を減らすように努めます。これは、これらの複製手法の両方の影響を大きく影響します。ただし、オペレータはクライアントの再帰的なリゾルバを越えていないと、信頼できるサーバーを制御しかないため、再帰が最も近い信頼できるサーバーによって提供されることを保証することは困難です。サーバーの選択は最終的には再帰的リゾルバのソフトウェアの実装まで、さまざまなベンダーや異なるリリースでさえ異なる基準を採用して、通信する権限のあるサーバーを選択します。
Understanding how recursive resolvers choose authoritative servers is a key step in improving the effectiveness of authoritative server deployments. To measure and evaluate server deployments, [Mueller17b] describes the deployment of seven unicast authoritative name servers in different global locations and then queried them from more than 9000 Reseaux IP Europeens (RIPE) authoritative server operators and their respective recursive resolvers.
再帰的なリゾルバがどのように選択するかを確認する権限サーバーの選択方法は、信頼できるサーバーの展開の有効性を向上させるための重要なステップです。サーバーの展開を測定して評価するには、[MUELRER17B]は、さまざまなグローバル・ロケーションにある7つのユニキャスト権限ネームサーバーの展開を説明してから、9000以上のReseaux IP Europeens（RIPE）権限サーバー演算子とそれぞれの再帰リゾルバーから照会しました。
It was found in [Mueller17b] that recursive resolvers in the wild query all available authoritative servers, regardless of the observed latency. But the distribution of queries tends to be skewed towards authoritatives with lower latency: the lower the latency between a recursive resolver and an authoritative server, the more often the recursive will send queries to that server. These results were obtained by aggregating results from all of the vantage points, and they were not specific to any vendor or version.
観測された待ち時間にかかわらず、野生の再帰的なリゾルバーが依然として利用可能なすべての権威あるサーバーをクエリすることは、[Mueller17b]で見つかりました。しかし、クエリの分布は待ち時間が遅くなる権限に向かって歪められる傾向があります。再帰的レゾルバと信頼できるサーバーの間の待ち時間が低いほど、再帰がそのサーバーにクエリを送信します。これらの結果は、すべての視点からの結果を集約することによって得られ、それらは任意のベンダーまたはバージョンに固有のものではなかった。
The authors believe this behavior is a consequence of combining the two main criteria employed by resolvers when selecting authoritative servers: resolvers regularly check all listed authoritative servers in an NS set to determine which is closer (the least latent), and when one isn't available, it selects one of the alternatives.
著者らは、この動作は、信頼できるサーバーの選択時にリゾルバによって採用されている2つの主要な基準を組み合わせることの結果であると考えています。リゾルバは、NSセット内のすべてのリストされた信頼できるサーバーをNSセットで定期的にチェックして、どちらが狭い（最小の潜在的）、そうでないかを判断する利用可能で、それは代替案の1つを選択します。
For an authoritative DNS operator, this result means that the latency of all authoritative servers (NS records) matter, so they all must be similarly capable -- all available authoritatives will be queried by most recursive resolvers. Unicasted services, unfortunately, cannot deliver good latency worldwide (a unicast authoritative server in Europe will always have high latency to resolvers in California and Australia, for example, given its geographical distance).
信頼できるDNS演算子の場合、この結果は、すべての権威あるサーバー（NSレコード）の待ち時間が問題であるため、すべて同様に可能な限りが必要です。不幸なサービスは、世界中で良好な待ち時間を提供することはできません（ヨーロッパのユニキャスト権限サーバーは常にカリフォルニア州およびオーストラリアのリゾルベースには常に高い待ち時間、例えばその地理的距離を考える）です。
[Mueller17b] recommends that DNS operators deploy equally strong IP anycast instances for every authoritative server (i.e., for each NS record). Each large authoritative DNS server provider should phase out its usage of unicast and deploy a number of well-engineered anycast instances with good peering strategies so they can provide good latency to their global clients.
[MUELRER17B]は、DNS演算子がすべての権限サーバー（すなわち、各NSレコードについて）に対して等しく強力なIP Anycastインスタンスを展開することをお勧めします。各大規模な権限DNSサーバープロバイダーは、ユニキャストの使用を段階的に排除し、それらがグローバルな顧客に良い待ち時間を提供できるように、優れたピアリング戦略を持つ多数の適切なエニーキャストインスタンスを展開する必要があります。
As a case study, the ".nl" TLD zone was originally served on seven authoritative servers with a mixed unicast/anycast setup. In early 2018, .nl moved to a setup with 4 anycast authoritative servers.
ケーススタディとして、「.nl」TLDゾーンはもともと混在のユニキャスト/エニーキャスト設定を備えた7つの権限のあるサーバーで提供されました。2018年初頭に、.nlは4つのエニーキャスト権限サーバーでセットアップに移動しました。
The contribution of [Mueller17b] to DNS service engineering shows that because unicast cannot deliver good latency worldwide, anycast needs to be used to provide a low-latency service worldwide.
DNSサービスエンジニアリングへの[Mueller17b]の貢献は、ユニキャストが世界中で良好な待ち時間を提供できないため、世界中の低遅延サービスを提供する必要があることを示しています。
3.2. C2: Optimizing Routing is More Important than Location Count and Diversity
3.2. C2：最適化ルーティングは、位置数と多様性よりも重要です
When selecting an anycast DNS provider or setting up an anycast service, choosing the best number of anycast instances [RFC4786] [RFC7094] to deploy is a challenging problem. Selecting the right quantity and set of global locations that should send BGP announcements is tricky. Intuitively, one could naively think that more instances are better and that simply "more" will always lead to shorter response times.
Anycast DNSプロバイダを選択するか、またはエニーキャストサービスの設定を選択するときは、展開するための[RFC4786] [RFC7094]の最良の数を選択することは困難な問題です。BGPアナウンスメントを送信する必要がある正しい数量と一連のグローバルな場所を選択することは難しいです。直感的には、より多くのインスタンスが優れており、単に「もっと」は常に応答時間が短くなると考えることができます。
This is not necessarily true, however. In fact, proper route engineering can matter more than the total number of locations, as found in [Schmidt17a]. To study the relationship between the number of anycast instances and the associated service performance, the authors measured the round-trip time (RTT) latency of four DNS root servers. The root DNS servers are implemented by 12 separate organizations serving the DNS root zone at 13 different IPv4/IPv6 address pairs.
しかし、これは必ずしも真実ではありません。実際、[SCHMIDT17A]で見つかったように、適切なルートエンジニアリングは場所の総数以上のものです。Anycastインスタンスの数と関連サービスパフォーマンスの関係を調べるには、著者らは4つのDNSルートサーバーの往復時間（RTT）待ち時間を測定しました。ルートDNSサーバーは、13の異なるIPv4 / IPv6アドレスペアでDNSルートゾーンを提供する12個の別々の組織によって実装されています。
The results documented in [Schmidt17a] measured the performance of the {c,f,k,l}.root-servers.net (referred to as "C", "F", "K", and "L" hereafter) servers from more than 7,900 RIPE Atlas probes. RIPE Atlas is an Internet measurement platform with more than 12,000 global vantage points called "Atlas probes", and it is used regularly by both researchers and operators [RipeAtlas15a] [RipeAtlas19a].
[SCHMIDT17A]で文書化された結果は、{C、F、K、L}。root-servers.net（ "c"、 "f"、 "k"、および "L"という）の性能を測定しました。7,900以上の熟したアトラスプローブから。RIPE ATLASは、「Atlas Probes」と呼ばれる12,000を超えるグローバルな点を持つインターネット測定プラットフォームで、研究者とオペレータの両方で定期的に使用されています[RipeAtlas15a] [RipeAtlas19a]。
In [Schmidt17a], the authors found that the C server, a smaller anycast deployment consisting of only 8 instances, provided very similar overall performance in comparison to the much larger deployments of K and L, with 33 and 144 instances, respectively. The median RTTs for the C, K, and L root servers were all between 30-32 ms.
[SCHMIDT17A]では、Cサーバーは、33および144インスタンスのKとLのはるかに大きな展開と比較して、非常に類似の全体的なパフォーマンスを比較して、8個のインスタンスのみで構成されたすべてのエニーキャスト展開であることがわかりました。C、K、およびLのルートサーバーのためのRTTの中央値はすべて30~32ミリ秒の間でした。
Because RIPE Atlas is known to have better coverage in Europe than other regions, the authors specifically analyzed the results per region and per country (Figure 5 in [Schmidt17a]) and show that known Atlas bias toward Europe does not change the conclusion that properly selected anycast locations are more important to latency than the number of sites.
RIPE ATLASは他の地域よりもヨーロッパでより良い報道を持つことが知られているので、著者は地域ごとの結果を特に分析し、国ごと（[Schmidt17a]）で、ヨーロッパへの既知のATLASバイアスが適切に選択された結論を変更しないことを示しました。エニーキャストの場所は、サイト数よりも待ち時間に重要です。
The important conclusion from [Schmidt17a] is that when engineering anycast services for performance, factors other than just the number of instances (such as local routing connectivity) must be considered. Specifically, optimizing routing policies is more important than simply adding new instances. The authors showed that 12 instances can provide reasonable latency, assuming they are globally distributed and have good local interconnectivity. However, additional instances can still be useful for other reasons, such as when handling DoS attacks [Moura16b].
[SCHMIDT17A]からの重要な結論は、パフォーマンスのためにエンジニアリングサービスをエンジニアリングするとき（ローカルルーティング接続など）を考慮する必要があります。具体的には、ルーティングポリシーの最適化は、新しいインスタンスを追加するだけではより重要です。著者らは、12個のインスタンスがグローバルに分散され、優れたローカル相互接続性を持つと仮定して、合理的な待ち時間を提供できることを示しました。ただし、DOS攻撃を取り扱うときなど、追加のインスタンスは他の理由で有用であり得る[Moura16B]。
An anycast DNS service may be deployed from anywhere and from several locations to hundreds of locations (for example, l.root-servers.net has over 150 anycast instances at the time this was written). Anycast leverages Internet routing to distribute incoming queries to a service's nearest distributed anycast locations measured by the number of routing hops. However, queries are usually not evenly distributed across all anycast locations, as found in the case of L-Root when analyzed using Hedgehog [IcannHedgehog].
Anycast DNSサービスは、どこからでもいくつかの場所から数百の場所へ展開されてもよい（たとえば、これはこれが書き込まれた時点で150以上のAnycastインスタンスを持ちます）。Anycastインターネットルーティングを利用して、着信クエリをルーティングホップの数によって測定されたサービスの最も近い分散エニーキャスト場所に配布します。ただし、HERGEHOG [ICANNHERGESHOG]を使用して分析されたときにL-ROOTの場合には、クエリは通常、すべてのエニーキャストの場所にわたって均等に分散されていません。
Adding locations to or removing locations from a deployed anycast network changes the load distribution across all of its locations. When a new location is announced by BGP, locations may receive more or less traffic than it was engineered for, leading to suboptimal service performance or even stressing some locations while leaving others underutilized. Operators constantly face this scenario when expanding an anycast service. Operators cannot easily directly estimate future query distributions based on proposed anycast network engineering decisions.
展開されたエニーキャストネットワークからの場所への場所を追加または削除すると、そのすべての場所にわたる負荷分散を変更します。新しい場所がBGPによって発表されると、場所が設計されていたよりも多かれ少なかれトラフィックを受信することができ、最適なサービスパフォーマンスにつながるか、または他の人が過小化されたままにしている間にいくつかの場所を強調することさえあります。オペレータは、エニーキャストサービスを拡張するときに常にこのシナリオに直面します。オペレータは、提案されたエニーキャストネットワーク工学の決定に基づいて将来のクエリ分布を簡単に推定することはできません。
To address this need and estimate the query loads of an anycast service undergoing changes (in particular expanding), [Vries17b] describes the development of a new technique enabling operators to carry out active measurements using an open-source tool called Verfploeter (available at [VerfSrc]). The results allow the creation of detailed anycast maps and catchment estimates. By running Verfploeter combined with a published IPv4 "hit list", the DNS can precisely calculate which remote prefixes will be matched to each anycast instance in a network. At the time of this writing, Verfploeter still does not support IPv6 as the IPv4 hit lists used are generated via frequent large-scale ICMP echo scans, which is not possible using IPv6.
このニーズに対処し、変更を受ける（特に拡張されている）エニーキャストサービスのクエリ負荷を推定するために、[VRIES17B]は、オペレータがVerfploeterと呼ばれるオープンソースツールを使用してアクティブな測定を実行するための新しい技術の開発を説明しています（[at [verfsrc]）結果は、詳細なエニーキャストマップと集水域推定値を作成できます。verfploeterを発行したIPv4 "Hit List"と組み合わせることで、DNSはネットワーク内の各エニーキャストインスタンスにどのリモートプレフィックスが一致するかを正確に計算できます。この書き込み時に、Verfploeterは依然として使用されるIPv4のヒットリストが頻繁な大規模ICMPエコースキャンを介して生成されるため、IPv6をサポートしていません。これはIPv6を使用して不可能です。
As proof of concept, [Vries17b] documents how Verfploeter was used to predict both the catchment and query load distribution for a new anycast instance deployed for b.root-servers.net. Using two anycast test instances in Miami (MIA) and Los Angeles (LAX), an ICMP echo query was sent from an IP anycast address to each IPv4 /24 network routing block on the Internet.
コンセプトの証明として、[VRIES17B]は、B.ROOT-Servers.netにデプロイされた新しいAnycastインスタンスの集水集計とクエリの負荷分散の両方を予測するためにVerfploeterを使用した方法を文書化します。MIAMI（MIA）およびLOS ANGERES（LAX）の2つのエニーキャストテストインスタンスを使用して、ICMPエコークエリがIPエニーキャストアドレスからインターネット上の各IPv4 / 24ネットワークルーティングブロックに送信されました。
The ICMP echo responses were recorded at both sites and analyzed and overlaid onto a graphical world map, resulting in an Internet-scale catchment map. To calculate expected load once the production network was enabled, the quantity of traffic received by b.root-servers.net's single site at LAX was recorded based on a single day's traffic (2017-04-12, "day in the life" (DITL) datasets [Ditl17]). In [Vries17b], it was predicted that 81.6% of the traffic load would remain at the LAX site. This Verfploeter estimate turned out to be very accurate; the actual measured traffic volume when production service at MIA was enabled was 81.4%.
ICMPエコー応答は両方のサイトで記録され、グラフィックワールドマップ上に分析されオーバーレイされ、インターネットスケールの集中地図が得られました。生産ネットワークが有効になったら、予想される負荷を計算するには、B.Root-Servers.NetのLAXで受信されたトラフィックの数量は、1日のトラフィック（2017-04-12、ライフの日 "日"（ "）に基づいて記録されました（DITL）データセット[DITL17]）。[VRIES17B]では、トラフィック負荷の81.6％がLAXサイトに残ると予測されました。このverfploeter推定値は非常に正確であることがわかりました。MIAでの製造サービスが有効になっているときの実際の測定されたトラフィック量は81.4％でした。
Verfploeter can also be used to estimate traffic shifts based on other BGP route engineering techniques (for example, Autonomous System (AS) path prepending or BGP community use) in advance of operational deployment. This was studied in [Vries17b] using prepending with 1-3 hops at each instance, and the results were compared against real operational changes to validate the accuracy of the techniques.
VerfPloeterは、運用展開の前に、他のBGPルート工学技術（例えば、自律システム（AS）経路の前またはBGPコミュニティの使用）に基づいてトラフィックシフトを推定するためにも使用できます。これを各インスタンスで1~3ホップで前方に予備することを使用して、[VRIES17B]で検討し、その結果を実際の動作変更と比較して技術の精度を検証した。
An important operational takeaway [Vries17b] provides is how DNS operators can make informed engineering choices when changing DNS anycast network deployments by using Verfploeter in advance. Operators can identify suboptimal routing situations in advance with significantly better coverage rather than using other active measurement platforms such as RIPE Atlas. To date, Verfploeter has been deployed on an operational testbed (anycast testbed) [AnyTest] on a large unnamed operator and is run daily at b.root-servers.net [Vries17b].
重要なオペレーショナルテイクアウト[VRIES17B]は、DNSオペレータがVerfPloeterを使用してDNS Anycastネットワーク展開を変更するときにDNSオペレータが情報に基づいてエンジニアリングの選択を行うことができます。オペレータは、熟したATLAなどの他のアクティブな測定プラットフォームを使用するのではなく、大幅に優れたカバレッジを備えた最適なルーティング状況を識別できます。今日まで、Verfploeterは、大規模な名前のオペレータのオペレーショナルテストベッド（Anycast TestBed）[anytest]にデプロイされており、B.Root-Servers.net [Vries17b]で毎日実行されています。
Operators should use active measurement techniques like Verfploeter in advance of potential anycast network changes to accurately measure the benefits and potential issues ahead of time.
オペレータは、潜在的なエニーキャストネットワークの変更が前もって、潜在的なエニーキャストネットワークの変化のような積極的な測定技術を使用する必要があります。
DDoS attacks are becoming bigger, cheaper, and more frequent [Moura16b]. The most powerful recorded DDoS attack against DNS servers to date reached 1.2 Tbps by using Internet of Things (IoT) devices [Perlroth16]. How should a DNS operator engineer its anycast authoritative DNS server to react to such a DDoS attack? [Moura16b] investigates this question using empirical observations grounded with theoretical option evaluations.
DDOS攻撃は、より大きく、より安く、そしてより頻繁になっています[Moura16B]。DNSサーバーに対する最も強力な録音されたDDOS攻撃は、The Mothing（IoT）デバイスのインターネット（Perlroth16]を使用して1.2 Tbpsに達しました。DNSオペレータエンジニアは、そのようなDDOS攻撃に反応するためにそのAnycast権限のDNSサーバーをどのようにエンジニアリングするか？[Moura16B]理論的オプション評価で接地された経験的観測を用いてこの質問を調査する。
An authoritative DNS server deployed using anycast will have many server instances distributed over many networks. Ultimately, the relationship between the DNS provider's network and a client's ISP will determine which anycast instance will answer queries for a given client, given that the BGP protocol maps clients to specific anycast instances using routing information. As a consequence, when an anycast authoritative server is under attack, the load that each anycast instance receives is likely to be unevenly distributed (a function of the source of the attacks); thus, some instances may be more overloaded than others, which is what was observed when analyzing the root DNS events of November 2015 [Moura16b]. Given the fact that different instances may have different capacities (bandwidth, CPU, etc.), making a decision about how to react to stress becomes even more difficult.
Anycastを使用してデプロイされた権限のあるDNSサーバーには、多くのネットワークにわたって配布されている多くのサーバーインスタンスがあります。最終的には、DNSプロバイダのネットワークとクライアントのISPとの間の関係は、BGPプロトコルがルーティング情報を使用してクライアントを特定のAnycastインスタンスにマッピングすることを考えると、どのようなクライアントのクエリに応答するかを決定します。その結果、任意のAnycast権限サーバーが攻撃中の場合、各エニーキャストインスタンスが受信する負荷は不均一に分散されている可能性があります（攻撃の送信元の関数）。したがって、いくつかのインスタンスは他のインスタンスよりもオーバーロードされている可能性があります。これは、2015年11月のルートDNSイベントを分析するときに観察されたものです[Moura16B]。異なるインスタンスが異なる能力（帯域幅、CPUなど）を持つことができるという事実を考えると、ストレスへの反応方法についての決定を下すことがさらに困難になります。
In practice, when an anycast instance is overloaded with incoming traffic, operators have two options:
実際には、エニーキャストインスタンスが着信トラフィックでオーバーロードされている場合、演算子には2つのオプションがあります。
* They can withdraw its routes, pre-prepend its AS route to some or all of its neighbors, perform other traffic-shifting tricks (such as reducing route announcement propagation using BGP communities [RFC1997]), or communicate with its upstream network providers to apply filtering (potentially using FlowSpec [RFC8955] or the DDoS Open Threat Signaling (DOTS) protocol [RFC8811] [RFC9132] [RFC8783]). These techniques shift both legitimate and attack traffic to other anycast instances (with hopefully greater capacity) or block traffic entirely.
* 彼らはそのルートを引き出すことができ、その隣人の一部または全部へのルートを事前に説明し、他のトラフィックシフトのトリック（BGPコミュニティを使用したルートアナウンス伝播の低減（RFC1997]を使ったルートアナウンス伝播の削減など）を実行するか、またはその上流のネットワークプロバイダと通信することができます。フィルタリング（Flowspec [RFC8955]またはDDOS Open Threatシグナリング（DOTS）プロトコル[RFC8811] [RFC9132] [RFC8783]）。これらの手法は、正当なトラフィックと攻撃トラフィックの両方を他のエニーキャストインスタンスにシフトします（うまくいけば、容量が大きい）、またはトラフィックを完全にブロックします。
* Alternatively, operators can become degraded absorbers by continuing to operate, knowing dropping incoming legitimate requests due to queue overflow. However, this approach will also absorb attack traffic directed toward its catchment, hopefully protecting the other anycast instances.
* あるいは、キューオーバーフローによる着信正当な要求を低下させることを知って動作を続けることによって、オペレータが吸収剤を劣化させることができる。しかしながら、このアプローチはまたその集水域に向けられた攻撃トラフィックを吸収することが、他のエニーキャストのインスタンスを保護していることを願っています。
[Moura16b] describes seeing both of these behaviors deployed in practice when studying instance reachability and RTTs in the DNS root events. When withdraw strategies were deployed, the stress of increased query loads were displaced from one instance to multiple other sites. In other observed events, one site was left to absorb the brunt of an attack, leaving the other sites to remain relatively less affected.
[Moura16b] DNSルートイベントのインスタンス到達可能性とRTTSの検討時に、実際に展開されたこれらの動作の両方の両方が表示されています。撤回戦略が展開されたとき、増加したクエリ負荷の応力は1つのインスタンスから他の複数のサイトに移動されました。他の観察された出来事では、他の部位が比較的少ないままであることを比較的罹患したままにするために、ある部位が攻撃の鈍さを吸収するために残された。
Operators should consider having both an anycast site withdraw strategy and an absorption strategy ready to be used before a network overload occurs. Operators should be able to deploy one or both of these strategies rapidly. Ideally, these should be encoded into operating playbooks with defined site measurement guidelines for which strategy to employ based on measured data from past events.
オペレータは、ネットワークの過負荷が発生する前に、Anycastサイト撤回戦略と吸収戦略の両方を使用することを検討する必要があります。オペレータは、これらの戦略の一方または両方を迅速に展開できるはずです。理想的には、これらは、過去のイベントからの測定データに基づいて採用した戦略が定義されたサイト測定ガイドラインを持つ操作プレイブックにエンコードされるべきです。
[Moura16b] speculates that careful, explicit, and automated management policies may provide stronger defenses to overload events. DNS operators should be ready to employ both common filtering approaches and other routing load-balancing techniques (such as withdrawing routes, prepending Autonomous Systems (ASes), adding communities, or isolating instances), where the best choice depends on the specifics of the attack.
[Moura16B]注意深くて明示的、および自動管理ポリシーをオーバーロードするためのより強い防御を提供するかもしれないことを投機化します。DNS演算子は、一般的なフィルタリングアプローチとその他のルーティング負荷分散技術（ルートの撤回、自律システム（ASES）の追加、コミュニティの追加、またはインスタンスの分離など）を採用する準備ができておく必要があります。ここで、最良の選択は攻撃の詳細によって異なります。。
Note that this consideration refers to the operation of just one anycast service point, i.e., just one anycasted IP address block covering one NS record. However, DNS zones with multiple authoritative anycast servers may also expect loads to shift from one anycasted server to another, as resolvers switch from one authoritative service point to another when attempting to resolve a name [Mueller17b].
この考慮事項は、1つのNSレコードをカバーする1つのエニーキャストサービスポイント、すなわち1つの非キャスティングIPアドレスブロックのみの動作を指すことに留意されたい。ただし、複数の権限のあるAnycastサーバーを持つDNSゾーンは、名前[MULER17B]の名前を解決しようとすると、1つの権限サービスポイントから別の権限サービスポイントへのスイッチを切り替えるときに、1つのAnycastサーバーから別のキャスチャーサーバーへの移行を期待できます。
Caching is the cornerstone of good DNS performance and reliability. A 50 ms response to a new DNS query may be considered fast, but a response of less than 1 ms to a cached entry is far faster. In [Moura18b], it was shown that caching also protects users from short outages and even significant DDoS attacks.
キャッシングは、DNSの性能と信頼性の礎石です。新しいDNSクエリへの50msの応答は速く考慮され得るが、キャッシュされたエントリから1ms未満の応答ははるかに速い。[Moura18B]では、キャッシングも短期間の停止や重要なDDOS攻撃からさえもユーザーを保護することが示されました。
Time-to-live (TTL) values [RFC1034] [RFC1035] for DNS records directly control cache durations and affect latency, resilience, and the role of DNS in Content Delivery Network (CDN) server selection. Some early work modeled caches as a function of their TTLs [Jung03a], and recent work has examined cache interactions with DNS [Moura18b], but until [Moura19b], no research had provided considerations about the benefits of various TTL value choices. To study this, Moura et al. [Moura19b] carried out a measurement study investigating TTL choices and their impact on user experiences in the wild. They performed this study independent of specific resolvers (and their caching architectures), vendors, or setups.
DNSレコードの場合は、Cache Delivery Network（CDN）サーバーの選択内のレイテンシング、弾力、およびDNSの役割に直接制御し、レイテンシ、回復力、およびDNSの役割に影響を与えます。TTLS [JUNG03A]の関数としてのいくつかの初期の作業モデルであり、最近の作業はDNS [Moura18B]とのキャッシュ相互作用を調べましたが、[Moura19B]まで、さまざまなTTL値の選択の利点についての考慮事項はありませんでした。これを研究するために、Moura et al。[Moura19B] TTLの選択を調査する測定研究と野生のユーザー経験への影響を実施した。彼らは、特定のリゾルバ（およびキャッシングアーキテクチャ）、ベンダー、またはセットアップとは無関係にこの研究を行いました。
First, they identified several reasons why operators and zone owners may want to choose longer or shorter TTLs:
まず、オペレータとゾーンの所有者がより長いまたは短いTTLを選択したい理由のいくつかの理由を特定しました。
* Longer TTLs, as discussed, lead to a longer cache life, resulting in faster responses. In [Moura19b], this was measured this in the wild, and it showed that by increasing the TTL for the .uy TLD from 5 minutes (300 s) to 1 day (86,400 s), the latency measured from 15,000 Atlas vantage points changed significantly: the median RTT decreased from 28.7 ms to 8 ms, and the 75th percentile decreased from 183 ms to 21 ms.
* 議論されたように、より長いTTLは、より長いキャッシュ寿命をもたらし、その結果応答が高速化されます。[Moura19b]では、これを野生で測定したところ、5分（300秒）から1日（86,400秒）のTTLを増やすことで、15,000のATLAS VANTACTON点から測定されたレイテンシが変化した。有意に：RTT中央値は28.7ミリ秒から8ミリ秒に減少し、75分のパーセンタイルは183ミリ秒から21ミリ秒に減少した。
* Longer caching times also result in lower DNS traffic: authoritative servers will experience less traffic with extended TTLs, as repeated queries are answered by resolver caches.
* より長いキャッシング時間もDNSトラフィックの低さをもたらします。
* Longer caching consequently results in a lower overall cost if the DNS is metered: some providers that offer DNS as a Service charge a per-query (metered) cost (often in addition to a fixed monthly cost).
* その結果、DNSが計算された場合、キャッシングが長くなると、DNSをサービス料として提供するプロバイダ（Metered）コストが、クエリごとのコスト（毎月の費用に加えて）を提供します。
* Longer caching is more robust to DDoS attacks on DNS infrastructure. DNS caching was also measured in [Moura18b], and it showed that the effects of a DDoS on DNS can be greatly reduced, provided that the caches last longer than the attack.
* より長いキャッシングは、DNSインフラストラクチャに対するDDOS攻撃に対してより堅牢です。DNSキャッシングも[Moura18B]で測定したところ、キャッシュが攻撃より長く続くとし、DNSに対するDDOの影響を大幅に減らすことができることを示した。
* Shorter caching, however, supports deployments that may require rapid operational changes: an easy way to transition from an old server to a new one is to simply change the DNS records. Since there is no method to remotely remove cached DNS records, the TTL duration represents a necessary transition delay to fully shift from one server to another. Thus, low TTLs allow for more rapid transitions. However, when deployments are planned in advance (that is, longer than the TTL), it is possible to lower the TTLs just before a major operational change and raise them again afterward.
* ただし、キャッシュが短くなると、迅速な運用変更が必要な展開をサポートします。古いサーバーから新しいサーバーに移行する簡単な方法は、単にDNSレコードを変更することです。キャッシュされたDNSレコードをリモートで削除する方法はありませんので、TTL期間は1つのサーバーから別のサーバーに完全にシフトするために必要な遷移遅延を表します。したがって、低いTTLはより迅速な遷移を可能にする。ただし、展開が事前に予定されている場合（つまりTTLより長い）、主な運用上の変化の直前にTTLを下げることができ、その後も再び上げます。
* Shorter caching can also help with a DNS-based response to DDoS attacks. Specifically, some DDoS-scrubbing services use the DNS to redirect traffic during an attack. Since DDoS attacks arrive unannounced, DNS-based traffic redirection requires that the TTL be kept quite low at all times to allow operators to suddenly have their zone served by a DDoS-scrubbing service.
* より短いキャッシングは、DDOS攻撃に対するDNSベースの応答を支援することもできます。具体的には、DDOSスクラビングサービスの中には、攻撃中にトラフィックをリダイレクトするためにDNSを使用します。DDOS攻撃はアンネットで到着しないので、DNSベースのトラフィックリダイレクトでは、常にTTLが非常に低く、オペレータが突然DDOSスクラビングサービスによってゾーンを提供できるようにする必要があります。
* Shorter caching helps DNS-based load balancing. Many large services are known to rotate traffic among their servers using DNS-based load balancing. Each arriving DNS request provides an opportunity to adjust the service load by rotating IP address records (A and AAAA) to the lowest unused server. Shorter TTLs may be desired in these architectures to react more quickly to traffic dynamics. Many recursive resolvers, however, have minimum caching times of tens of seconds, placing a limit on this form of agility.
* より短いキャッシングは、DNSベースの負荷分散を支援します。多くの大規模サービスは、DNSベースの負荷分散を使用してサーバー間のトラフィックを回転させることが知られています。到着した各DNS要求は、IPアドレスレコード（AとAAAA）を最も低い未使用のサーバーに回転させることによってサービス負荷を調整する機会を提供します。トラフィックダイナミクスにより迅速に反応するために、これらのアーキテクチャに短いTTLが望ましい場合があります。ただし、多くの再帰的リゾルバは、この形式の敏捷性に限界を配置して、数十秒のキャッシング時間を持ちます。
Given these considerations, the proper choice for a TTL depends in part on multiple external factors -- no single recommendation is appropriate for all scenarios. Organizations must weigh these trade-offs and find a good balance for their situation. Still, some guidelines can be reached when choosing TTLs:
これらの考慮事項を考慮すると、TTLの適切な選択は複数の外部要因に部分的に依存します - すべてのシナリオには単一の推奨は適切です。組織はこれらのトレードオフを量り、彼らの状況のための良いバランスを見つけなければなりません。それでも、TTLを選択するときにいくつかのガイドラインに到達することができます。
* For general DNS zone owners, [Moura19b] recommends a longer TTL of at least one hour and ideally 4, 8, or 24 hours. Assuming planned maintenance can be scheduled at least a day in advance, long TTLs have little cost and may even literally provide cost savings.
* 一般的なDNSゾーンの所有者の場合、[Moura19B]は少なくとも1時間以上4,8、または24時間のTTLが長くなることをお勧めします。計画されたメンテナンスを少なくとも1日前までにスケジュールすることができると仮定すると、長いTTLはコストがほとんどありません。文字通りコスト削減を提供します。
* For TLD and other public registration operators (for example, most ccTLDs and .com, .net, and .org) that host many delegations (NS records, DS records, and "glue" records), [Moura19b] demonstrates that most resolvers will use the TTL values provided by the child delegations while some others will choose the TTL provided by the parent's copy of the record. As such, [Moura19b] recommends longer TTLs (at least an hour or more) for registry operators as well for child NS and other records.
* 多くの代表団（NSレコード、DSレコード、および「接着剤」レコード）をホストするTLDおよびその他の公開登録演算子（例えば、NSレコード、DSレコード、および「Glue」レコード）では、ほとんどのリゾルベースがあることを示しています。他の人が親のレコードのコピーによって提供されるTTLを選択する間、子の代表団によって提供されるTTL値を使用します。そのように、[Moura19b]は、レジストリ演算子およびその他のレコードのためのレジストリ事業者のためのより長いTTL（少なくとも1時間以上）を推奨しています。
* Users of DNS-based load balancing or DDoS-prevention services may require shorter TTLs: TTLs may even need to be as short as 5 minutes, although 15 minutes may provide sufficient agility for many operators. There is always a tussle between using shorter TTLs that provide more agility and using longer TTLs that include all the benefits listed above.
* DNSベースの負荷分散またはDDOS防止サービスのユーザは、より短いTTLを必要とする可能性がある.TTLは5分ほど短くなる必要があるが、15分は多くの演算子に対して十分な敏捷性を提供する可能性がある。より敏捷性を高め、上記のすべての利点を含むより長いTTLを使用するより短いTTLを使用することの間には常に努力があります。
* Regarding the use of A/AAAA and NS records, the TTLs for A/AAAA records should be shorter than or equal to the TTL for the corresponding NS records for in-bailiwick authoritative DNS servers, since [Moura19b] finds that once an NS record expires, their associated A/AAAA will also be requeried when glue is required to be sent by the parents. For out-of-bailiwick servers, A, AAAA, and NS records are usually all cached independently, so different TTLs can be used effectively if desired. In either case, short A and AAAA records may still be desired if DDoS mitigation services are required.
* / AAAAおよびNSレコードの使用に関しては、/ AAAAレコードのTTLは、NSレコードを1回見つけることを検索するため、In-BailiWick信頼性DNSサーバーの対応するNSレコードのTTL以下にする必要があります。有効期限が切れると、接着剤が両親によって送られる必要があるときにも関連付けられているでしょう。BailiOwickサーバー、A、AAAA、およびNSレコードは通常独立してキャッシュされているため、必要に応じて異なるTTLを効果的に使用できます。どちらの場合も、DDOSの軽減サービスが必要な場合は、短いAおよびAAAAレコードが依然として望ましい場合があります。
Multiple record types exist or are related between the parent of a zone and the child. At a minimum, NS records are supposed to be identical in the parent (but often are not), as are corresponding IP addresses in "glue" A/AAAA records that must exist for in-bailiwick authoritative servers. Additionally, if DNSSEC [RFC4033] [RFC4034] [RFC4035] [RFC4509] is deployed for a zone, the parent's DS record must cryptographically refer to a child's DNSKEY record.
複数のレコードタイプが存在するか、ゾーンの親と子の親の間に関連しています。最低限、NSレコードは、In-BailiWick信任状サーバーに存在している必要がある「Glue」A / AAAAレコードの対応するIPアドレスがあるように、親（ただし、しばしばそうではありません）で同一であるとされています。また、DNSSEC [RFC4033] [RFC4034] [RFC4035] [RFC4509]がゾーンにデプロイされている場合、親のDSレコードは子のDNSKEYレコードを暗号化する必要があります。
Because some information exists in both the parent and a child, it is possible for the TTL values to differ between the parent's copy and the child's. [Moura19b] examines resolver behaviors when these values differed in the wild, as they frequently do -- often, parent zones have de facto TTL values that a child has no control over. For example, NS records for TLDs in the root zone are all set to 2 days (48 hours), but some TLDs have lower values within their published records (the TTLs for .cl's NS records from their authoritative servers is 1 hour). [Moura19b] also examines the differences in the TTLs between the NS records and the corresponding A/AAAA records for the addresses of a name server. RIPE Atlas nodes are used to determine what resolvers in the wild do with different information and whether the parent's TTL is used for cache lifetimes ("parent-centric") or the child's ("child-centric").
親と子の両方にいくつかの情報が存在するため、親のコピーと子の間でTTL値が異なる可能性があります。[Moura19B]は、リゾルバの動作を調べて、これらの値が野生の中で異なる場合、親ゾーンには、子供がコントロールしないという事実TTL値があります。たとえば、ルートゾーン内のTLDのNSレコードはすべて2日（48時間）に設定されていますが、いくつかのTLDは公開されているレコード内の値が小さい（.CLのNSレコードのためのTTLは1時間です）。[Moura19b] NSレコード間のTTLの違いと、ネームサーバのアドレスの対応するA / AAAAレコードとの間の違いを調べます。RIPE ATLASノードは、野生のDOのどのリゾルベースを異なる情報で決定し、親のTTLがキャッシュ寿命（「親中心」）または子（「子セン色」）に使用されるかを判断するために使用されます。
[Moura19b] found that roughly 90% of resolvers follow the child's view of the TTL, while 10% appear parent-centric. Additionally, it found that resolvers behave differently for cache lifetimes for in-bailiwick vs. out-of-bailiwick NS/A/AAAA TTL combinations. Specifically, when NS TTLs are shorter than the corresponding address records, most resolvers will requery for A/AAAA records for the in-bailiwick resolvers and switch to new address records even if the cache indicates the original A/AAAA records could be kept longer. On the other hand, the inverse is true for out-of-bailiwick resolvers: if the NS record expires first, resolvers will honor the original cache time of the name server's address.
[Moura19B]リゾルバの約90％がTTLの子供の見解に従うことを発見したが、10％は親中心に見えます。さらに、リゾルバイは、インベイリックVS. un-bailiwick ns / a / aaaa TTLの組み合わせのためのキャッシュ寿命に対して異なる動作をしていることがわかりました。具体的には、NS TTLSが対応するアドレスレコードより短い場合、ほとんどのリゾルバはインベイリックウィックリゾルバの/ AAAAレコードに対してクエリを受信し、キャッシュが元のA / AAAAレコードを表示しても新しいアドレスレコードに切り替えます。一方、逆は、BailioWickリゾルバに当てはまります.NSレコードが最初に有効期限が切れている場合、リゾルバはネームサーバのアドレスの元のキャッシュタイムを称えます。
The important conclusion from this study is that operators cannot depend on their published TTL values alone -- the parent's values are also used for timing cache entries in the wild. Operators that are planning on infrastructure changes should assume that an older infrastructure must be left on and operational for at least the maximum of both the parent and child's TTLs.
この研究からの重要な結論は、演算子が公開されたTTL値だけに依存できないことです。親の値は、ワイルド内のタイミングキャッシュエントリにも使用されます。インフラストラクチャの変更を計画している演算子は、古いインフラストラクチャを少なくとも親と子のTTLの両方に少なくとも最大限に運用する必要があります。
This document discusses applying measured research results to operational deployments. Most of the considerations affect mostly operational practice, though a few do have security-related impacts.
この文書では、測定された研究結果を運用展開に適用することについて説明します。ほとんどの考慮事項は主に運用慣行に影響しますが、セキュリティ関連の影響があります。
Specifically, C4 discusses a couple of strategies to employ when a service is under stress from DDoS attacks and offers operators additional guidance when handling excess traffic.
具体的には、C4は、サービスがDDOS攻撃からストレスを受けているときに採用するための戦略をいくつか議論し、オペレータが過剰なトラフィックを処理するときに追加のガイダンスを提供します。
Similarly, C5 identifies the trade-offs with respect to the operational and security benefits of using longer TTL values.
同様に、C5は、より長いTTL値を使用する操作上の利点およびセキュリティ上の利点に関するトレードオフを識別します。
This document does not add any new, practical privacy issues, aside from possible benefits in deploying longer TTLs as suggested in C5. Longer TTLs may help preserve a user's privacy by reducing the number of requests that get transmitted in both client-to-resolver and resolver-to-authoritative cases.
この文書は、C5で提案されているように、より長いTTLを展開する際の可能な利点を除いて、新しい実用的なプライバシーの問題を追加していません。より長いTTLは、クライアントからリゾルバとリゾルバに送信される場合に送信される要求の数を減らすことによって、ユーザーのプライバシーを保持するのに役立ちます。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P.、「ドメイン名 - コンセプトと施設」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https：//www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P.、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https：//www.rfc-editor.org/info/rfc1035>。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, DOI 10.17487/RFC1546, November 1993, <https://www.rfc-editor.org/info/rfc1546>.
[RFC1546]パートリッジ、C、Mendez、T.、およびW.ミリケン、「ホストAnycasting Service」、RFC 1546、DOI 10.17487 / RFC1546、1993年11月、<https：//www.rfc-editor.org/info/RFC1546>。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, DOI 10.17487/RFC1995, August 1996, <https://www.rfc-editor.org/info/rfc1995>.
[RFC1995] ohta、M。、「DNSのインクリメンタルゾーン転送」、RFC 1995、DOI 10.17487 / RFC1995、1996年8月、<https://www.rfc-editor.org/info/rfc1995>。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <https://www.rfc-editor.org/info/rfc1997>.
[RFC1997] Chandra、R.、Traina、P.、T. Li、 "BGPコミュニティ属性"、RFC 1997、DOI 10.17487 / RFC1997、1996年8月、<https：//www.rfc-editor.org/info/RFC1997>。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>.
[RFC2181] ELZ、R.およびR. BUSH、「DNS仕様への説明」、RFC 2181、DOI 10.17487 / RFC2181、1997年7月、<https：//www.rfc-editor.org/info/rfc2181>。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC4786]能力、J.およびK.Lindqvist、「Anycastサービスの操作」、BCP 126、RFC 4786、DOI 10.17487 / RFC4786、2006年12月、<https：//www.rfc-editor.org/info/rfc4786>。
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, <https://www.rfc-editor.org/info/rfc5936>.
[RFC5936] Lewis、E、A.ホエン、「DNSゾーン転送プロトコル（AXFR）」、RFC 5936、DOI 10.17487 / RFC5936、2010年6月、<https：//www.rfc-editor.org/info/ RFC5936>。
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, January 2014, <https://www.rfc-editor.org/info/rfc7094>.
[RFC7094] McPherson、D.、Oran、D.、Thaler、D.、およびE. Osterweil、「IP Anercastの建築検討」、RFC 7094、DOI 10.17487 / RFC7094、2014年1月、<https：//www.rfc-editor.org/info/rfc7094>。
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8499] Hoffman、P.、Sullivan、A.、K. Fujiwara、「DNS用語」、BCP 219、RFC 8499、DOI 10.17487 / RFC8499、2019年1月、<https：//www.rfc-editor.org/情報/ RFC8499>。
[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", RFC 8783, DOI 10.17487/RFC8783, May 2020, <https://www.rfc-editor.org/info/rfc8783>.
[RFC8783] Boucadair、M.、ED。T.Reddy.k、ed。、「分散サービス拒否オープン脅威シグナリング（ドット）データチャネル仕様」、RFC 8783、DOI 10.17487 / RFC8783、2020年5月、<https：//www.rfc-編集者。ORG / INFO / RFC8783>。
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/info/rfc8955>.
[RFC8955] LOIBL、C.、HARES、S.、Raszuk、R.、McPherson、D.、およびM. Bacher、「フロー仕様規則の普及」、RFC 8955、DOI 10.17487 / RFC8955、2020年12月、<https：//www.rfc-editor.org/info/rfc8955>。
[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 9132, DOI 10.17487/RFC9132, September 2021, <https://www.rfc-editor.org/info/rfc9132>.
[RFC9132] Boucadair、M.、Ed。、浅い、J.、およびT.Reddy.k、「分散サービス拒否オープン脅威シグナリング（ドット）信号チャネル仕様」、RFC 9132、DOI 10.17487 / RFC9132、9月2021、<https://www.rfc-editor.org/info/rfc9132>。
[AnyBest] Woodcock, B., "Best Practices in DNS Service-Provision Architecture", Version 1.2, March 2016, <https://meetings.icann.org/en/marrakech55/schedule/mon-tech/presentation-dns-service-provision-07mar16-en.pdf>.
[アネバスト]ウッドコック、B.、「DNSサービス提供アーキテクチャのベストプラクティス」、バージョン1.2、2016年3月、<https：//meetings.icann.org/en/marrakech55/schedule/mon-tech/presentation-dns-Service-Provision-07mar16-en.pdf>。
[AnyFRoot] Woolf, S., "Anycasting f.root-servers.net", January 2003, <https://archive.nanog.org/meetings/nanog27/presentations/ suzanne.pdf>.
[Anyfroot] Woolf、S.、 "Anycasting F.Root-Servers.net"、2003年1月、<https：//artive.nanog.org/meetings/nanog27/presentations/ suzanne.pdf>。
[AnyTest] Tangled, "Tangled Anycast Testbed", <http://www.anycast-testbed.com/>.
[ANYTEST]タングル、「Anycast TestBed」、<http://www.anycast-testbed.com/>。
[Ditl17] DNS-OARC, "2017 DITL Data", April 2017, <https://www.dns-oarc.net/oarc/data/ditl/2017>.
[DITL17] DNS-OARC、「2017 DITLデータ」、2017年4月、<https://www.dns-oarc.net/oarc/data/ditl/2017>。
[IcannHedgehog] "hedgehog", commit b136eb0, May 2021, <https://github.com/dns-stats/hedgehog>.
[ICANNHERGESHOG]「HERGEHOG」、COMMIT B136EB0、2021年5月、<https：//github.com/dns-stats/hedgehog>。
[Jung03a] Jung, J., Berger, A., and H. Balakrishnan, "Modeling TTL-based Internet Caches", ACM 2003 IEEE INFOCOM, DOI 10.1109/INFCOM.2003.1208693, July 2003, <http://www.ieee-infocom.org/2003/papers/11_01.PDF>.
[Jung03a] Jung、J.、Berger、A。、およびH.Balakrishnan、「TTLベースのインターネットキャッシュのモデリング」、ACM 2003 IEEE Infocom、DOI 10.1109 / infcom.1109 / 2003年7月、<http：//www.ieee-infocom.org/2003/papers/11_01.pdf>。
[Moura16b] Moura, G.C.M., Schmidt, R. de O., Heidemann, J., de Vries, W., Müller, M., Wei, L., and C. Hesselman, "Anycast vs. DDoS: Evaluating the November 2015 Root DNS Event", ACM 2016 Internet Measurement Conference, DOI 10.1145/2987443.2987446, November 2016, <https://www.isi.edu/~johnh/PAPERS/Moura16b.pdf>.
[Moura16B] Moura、GCM、Schmidt、R. De O.、Heidemann、J.、De Vries、W.、Müller、M.、Wei、L.、およびC.Hesselman、「Anycast対DDos：11月の評価2015 Root DNSイベント "、ACM 2016インターネット測定会議、DOI 10.1145 / 2987443.2987446、2016年11月、<https：//www.isi.edu/~johnh/papers/moura16b.pdf>。
[Moura18b] Moura, G.C.M., Heidemann, J., Müller, M., Schmidt, R. de O., and M. Davids, "When the Dike Breaks: Dissecting DNS Defenses During DDoS", ACM 2018 Internet Measurement Conference, DOI 10.1145/3278532.3278534, October 2018, <https://www.isi.edu/~johnh/PAPERS/Moura18b.pdf>.
[Moura18B] Moura、GCM、Heidemann、J.、Müller、M.、Schmidt、R. De O.、およびM. Davids、「DIKEが破断した場合：DDOのDNS防御の解剖「DNS防御」、ACM 2018インターネット測定会議、DOI201145/3278532.3278534、2018年10月、<https：//www.isi.edu/~johnh/papers/moura18b.pdf>。
[Moura19b] Moura, G.C.M., Hardaker, W., Heidemann, J., and R. de O. Schmidt, "Cache Me If You Can: Effects of DNS Time-to-Live", ACM 2019 Internet Measurement Conference, DOI 10.1145/3355369.3355568, October 2019, <https://www.isi.edu/~hardaker/papers/2019-10-cache-me-ttls.pdf>.
[Moura19B] Moura、GCM、ハーメン、W.、Heidemann、J.、およびR. De O.Schmidt、「キャッシュMe Me Me Me Me Me Me Time-To-Liveの効果」、ACM 2019インターネット測定会議、DOI 10.11452019年10月、<https://www.isi.edu/~hardaker/papers/2019-10-cache-me-ttls.pdf>。
[Mueller17b] Müller, M., Moura, G.C.M., Schmidt, R. de O., and J. Heidemann, "Recursives in the Wild: Engineering Authoritative DNS Servers", ACM 2017 Internet Measurement Conference, DOI 10.1145/3131365.3131366, November 2017, <https://www.isi.edu/%7ejohnh/PAPERS/Mueller17b.pdf>.
[Mueller17B]ミュラー、M.、Moura、GCM、Schmidt、R. De O.、J.Heidemann、「野生の再帰：工学的権威あるDNSサーバー」、ACM 2017インターネット測定会議、DOI 10.1145 / 3131365.3131366、2017年11月、<https://www.isi.edu/%7ejohnh/papers/mueller17b.pdf>。
[Perlroth16] Perlroth, N., "Hackers Used New Weapons to Disrupt Major Websites Across U.S.", October 2016, <https://www.nytimes.com/2016/10/22/business/internet-problems-attack.html>.
[Perlroth16] Perlooth、N.、「ハッカーは、2016年10月に大手Webサイトを混乱させるために新しい武器を使用しました」、<https：//www.nytimes.com/2016/10/22/business/internet-problems-attack.html>。
[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, <https://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月、<https：//www.rfc-editor.org/info/rfc4033>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Mssey、D.、およびS. Rose、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、<https://www.rfc-editor.org/info/rfc4034>。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/info/rfc4035>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、<https://www.rfc-editor.org/info/rfc4035>。
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, DOI 10.17487/RFC4509, May 2006, <https://www.rfc-editor.org/info/rfc4509>.
[RFC4509]「DNSSEC代理標識署名者（DSSEC委任署名者（DS）リソースレコード（RRS）」、RFC 4509、DOI 10.17487 / RFC4509、<https：///www.rfc-編集者のSHA-256の使用ORG / INFO / RFC4509>。
[RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., Teague, N., and R. Compton, "DDoS Open Threat Signaling (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, August 2020, <https://www.rfc-editor.org/info/rfc8811>.
[RFC8811] Mortensen、A.、ED。、Reddy.k、T.、Ed。、Andreasen、F.、Teague、N.、R. Compton、「DDOSオープン脅威シグナル伝達（ドット）アーキテクチャ」、RFC 8811、DOI 10.17487 / RFC8811、2020年8月、<https://www.rfc-editor.org/info/rfc8811>。
[RipeAtlas15a] RIPE Network Coordination Centre (RIPE NCC), "RIPE Atlas: A Global Internet Measurement Network", October 2015, <http://ipj.dreamhosters.com/wp-content/uploads/issues/2015/ipj18-3.pdf>.
[RipeAtlas15A]熟したネットワークコーディネーションセンター（熟したNCC）、「熟したアトラス：グローバルインターネット測定ネットワーク」、2015年10月、<http://ipj.dreamhosters.com/wp-content/uploads/issues/2015/ipj18-3.pdf>。
[RipeAtlas19a] RIPE Network Coordination Centre (RIPE NCC), "RIPE Atlas", <https://atlas.ripe.net>.
[RipeAtlas19a]熟したネットワーク調整センター（熟したNCC）、「熟したAtlas」、<https://atlas.ripe.net>。
[Schmidt17a] Schmidt, R. de O., Heidemann, J., and J. Kuipers, "Anycast Latency: How Many Sites Are Enough?", PAM 2017 Passive and Active Measurement Conference, DOI 10.1007/978-3-319-54328-4_14, March 2017, <https://www.isi.edu/%7ejohnh/PAPERS/Schmidt17a.pdf>.
[SCHMIDT17A] Schmidt、R. De O.、Heidemann、J.、J. Kuipers、「Anycast Laitency：サイト数は十分なのですか」、PAM 2017のパッシブおよびアクティブ測定会議、DOI 10.1007 / 978-3-319-54328-4_14、2017年3月、<https：//www.isi.edu/%7ejohnh/papers/schmidt17a.pdf>。
[Singla2014] Singla, A., Chandrasekaran, B., Godfrey, P., and B. Maggs, "The Internet at the Speed of Light", 13th ACM Workshop on Hot Topics in Networks, DOI 10.1145/2670518.2673876, October 2014, <http://speedierweb.web.engr.illinois.edu/cspeed/papers/ hotnets14.pdf>.
[Singla2014] Singla、A.、Chandrasekaran、B.、Godfrey、P.、およびB. Maggs、「光のスピードでインターネット」、ネットワークのホットトピックに関する13番目のACMワークショップ、DOI 10.1145 / 2670518.2673876、2014年10月、<http://speedierweb.web.engr.illinois.edu/cspeed/papers/hotnets14.pdf>。
[VerfSrc] "Verfploeter Source Code", commit f4792dc, May 2019, <https://github.com/Woutifier/verfploeter>.
[verfsrc] "Verfploeterのソースコード"、2019年5月、<https://github.com/woutifier/verfploeter>をコミットするF4792DC。
[Vries17b] de Vries, W., Schmidt, R. de O., Hardaker, W., Heidemann, J., de Boer, P-T., and A. Pras, "Broad and Load-Aware Anycast Mapping with Verfploeter", ACM 2017 Internet Measurement Conference, DOI 10.1145/3131365.3131371, November 2017, <https://www.isi.edu/%7ejohnh/PAPERS/Vries17b.pdf>.
[VRIES17B] De Vries、W.、Schmidt、R. De O.、W.、W.、HeideMann、J.、De Boer、Pt。、およびA. PRA、「冒険率との幅広およびロードアウェイマッピング」、ACM 2017インターネット測定会議、DOI 10.1145 / 3131365.3131371、2017年11月、<https：//www.isi.edu/%7ejohnh/papers/vries17b.pdf>。
Acknowledgements
謝辞
We would like to thank the reviewers of this document who offered valuable suggestions as well as comments at the IETF DNSOP session (IETF 104): Duane Wessels, Joe Abley, Toema Gavrichenkov, John Levine, Michael StJohns, Kristof Tuyteleers, Stefan Ubbink, Klaus Darilion, and Samir Jafferali.
私たちは、貴重な提案を提供したこの文書のレビューとIETF DNSOPセッション（IETF 104）にあります。（IETF 104）：Duane Wessels、Joe Cormy、Toema Gavrichenkov、John Levine、Michael Stjohns、Kristof Tuyteleres、Stefan Ubbink、KlausDarilion、およびSamir Jafferali。
Additionally, we would like thank those acknowledged in the papers this document summarizes for helping produce the results: RIPE NCC and DNS OARC for their tools and datasets used in this research, as well as the funding agencies sponsoring the individual research.
さらに、この文書を承認してくれてありがとうございました。
Contributors
貢献者
This document is a summary of the main considerations of six research papers written by the authors and the following people who contributed substantially to the content and should be considered coauthors; this document would not have been possible without their hard work:
この文書は、作者によって書かれた6つの研究論文の主な考慮事項の主な考慮事項の概要と、その内容に実質的に貢献し、CoAuthorsと見なされるべきです。この文書は彼らのハードワークなしでは不可能だったでしょう：
* Ricardo de O. Schmidt
* Ricardo de O. Schmidt
* Wouter B. de Vries
* ヴォーチB.デブリ
* Moritz Mueller
* モリッツミュラー
* Lan Wei
* LAN Wei
* Cristian Hesselman
* クリスチャンヘッセルマン
* Jan Harm Kuipers
* Jan害Kuipers.
* Pieter-Tjerk de Boer
* Pieter-Tjerk de Boer
* Aiko Pras
* エイコプラス
Authors' Addresses
著者の住所
Giovane C. M. Moura SIDN Labs/TU Delft Meander 501 6825 MD Arnhem Netherlands Phone: +31 26 352 5500 Email: giovane.moura@sidn.nl
Giovane C. M. Moura Sidn Labs / TU Delft Meelder 501 6825 MD Arnhemオランダ電話：31 26 352 5500 Eメール：giovane.moura@sidn.nl
Wes Hardaker USC/Information Sciences Institute PO Box 382 Davis, CA 95617-0382 United States of America Phone: +1 (530) 404-0099 Email: ietf@hardakers.net
Wes Hardaker USC / Information Sciences Institute Po Box 382 Davis、CA 95617-0382アメリカ合衆国電話：1（530）404-0099 Eメール：IETF@Hardakers.net
John Heidemann USC/Information Sciences Institute 4676 Admiralty Way Marina Del Rey, CA 90292-6695 United States of America Phone: +1 (310) 448-8708 Email: johnh@isi.edu
John Heidemann USC / Information Sciences Institute 4676 Admigulalty Way Marinaly Del Rey、CA 90292-6695アメリカ合衆国電話：1（310）448-8708 Eメール：johnh@isi.edu
Marco Davids SIDN Labs Meander 501 6825 MD Arnhem Netherlands Phone: +31 26 352 5500 Email: marco.davids@sidn.nl
Marco Davids Sidn Labs蛇行501 6825 MD Arnhem Netherlands電話：31 26 352 5500 Eメール：Marco.davids@sidn.nl