Internet Engineering Task Force (IETF) Momoka
Request for Comments: 10001 WIDE Project
BCP: 91 T. Fiebig
Obsoletes: 3901 MPI-INF
Category: Best Current Practice August 2026
ISSN: 2070-1721
This document provides guidelines and documents best current practice for operating authoritative DNS servers, recursive resolvers, and stub resolvers in a mixed IPv4/IPv6 environment. This document recommends that both authoritative DNS servers and recursive resolvers support IPv4 and IPv6. It also provides guidance on how recursive DNS resolvers should select upstream DNS servers, including when IPv4-embedded IPv6 addresses are available.
このドキュメントでは、IPv4/IPv6 混合環境で権威 DNS サーバー、再帰リゾルバー、およびスタブリゾルバーを運用するためのガイドラインと現在のベスト プラクティスを説明します。この文書では、権威 DNS サーバーと再帰リゾルバーの両方が IPv4 と IPv6 をサポートすることを推奨します。また、IPv4 が埋め込まれた IPv6 アドレスが利用可能な場合を含め、再帰 DNS リゾルバーが上流の DNS サーバーを選択する方法についてのガイダンスも提供します。
This document obsoletes RFC 3901.
この文書は RFC 3901 を廃止します。
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベスト プラクティスを文書化したものです。
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). Further information on BCPs is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。BCP の詳細については、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/rfc10001.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10001 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。この文書から抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology
2.1. Requirements Language
3. Name Space Partitioning
3.1. Misconfigurations Causing Name Space Partitioning Due to IP
Address Family Support
3.2. Network Conditions Causing Name Space Partitioning Due to
IP Address Family Support
3.3. Reasons for Intentional Name Space Partitioning Due to IP
Address Family Support
4. Policy-Based Avoidance of Name Space Partitioning
4.1. Guidelines for Authoritative DNS Server Configuration
4.2. Guidelines for Recursive DNS Resolvers
4.3. Guidelines for DNS Stub Resolvers
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Changes Since RFC 3901
Acknowledgments
Authors' Addresses
Despite IPv6 being first discussed in the mid-1990s [RFC2460], consistent deployment throughout the whole Internet has not yet been accomplished [RFC9386]. Hence, the Internet still consists of IPv4-only, dual-stack (networks supporting both IP address families), and IPv6-only networks.
IPv6 は 1990 年代半ばに初めて議論された [RFC2460] にもかかわらず、インターネット全体への一貫した導入はまだ達成されていません [RFC9386]。したがって、インターネットは依然として IPv4 のみ、デュアル スタック (両方の IP アドレス ファミリをサポートするネットワーク)、および IPv6 のみのネットワークで構成されています。
This creates a complex landscape where authoritative DNS servers might be accessible only via specific network protocols [V6DNSRDY-23]. At the same time, DNS resolvers may only be able to access the Internet via either IPv4 or IPv6 connectivity. This poses a challenge for such resolvers because they may receive queries for names whose authoritative DNS servers do not support the same IP address family as the resolver itself.
これにより、権限のある DNS サーバーが特定のネットワーク プロトコル [V6DNSRDY-23] 経由でのみアクセスできるという複雑な状況が生じます。同時に、DNS リゾルバーは、IPv4 または IPv6 接続を介してのみインターネットにアクセスできる場合があります。これは、そのようなリゾルバーにとって、権威 DNS サーバーがリゾルバー自体と同じ IP アドレス ファミリをサポートしていない名前のクエリを受信する可能性があるため、課題となります。
[RFC3901] was written at a time when IPv6 deployment was not widespread and focuses primarily on maintaining name space continuity within the IPv4 landscape. Two decades later, IPv6 is widely deployed and is also becoming the de facto standard in many areas, such as mobile and access networks and data-center underlays. Furthermore, since 2012, IPv6 support being required for all IP-capable nodes has been established as a best current practice [RFC6540]. This document broadens the scope of [RFC3901] by recommending IPv6 connectivity for authoritative DNS servers, recursive resolvers, and stub resolvers.
[RFC3901] は、IPv6 の導入がまだ普及していない時期に書かれ、主に IPv4 環境内で名前空間の継続性を維持することに重点を置いています。20 年後、IPv6 は広く導入され、モバイル ネットワークやアクセス ネットワーク、データセンターのアンダーレイなど、多くの分野で事実上の標準になりつつあります。さらに、2012 年以降、すべての IP 対応ノードに必要な IPv6 サポートが現在のベスト プラクティスとして確立されました [RFC6540]。この文書は、権威 DNS サーバー、再帰リゾルバー、およびスタブリゾルバーの IPv6 接続を推奨することにより、[RFC3901] の範囲を拡大します。
This document provides:
このドキュメントでは次の内容が提供されます。
* Guidance on name space partitioning due to differences in IP address family support and best practices for avoiding it.
* IP アドレス ファミリのサポートの違いによる名前空間の分割に関するガイダンスと、それを回避するためのベスト プラクティス。
* Guidelines for configuring authoritative DNS servers for zones.
* ゾーンの権威 DNS サーバーを構成するためのガイドライン。
* Guidelines for operating recursive DNS resolvers.
* 再帰的 DNS リゾルバーを操作するためのガイドライン。
* Guidelines for DNS stub resolvers.
* DNS スタブリゾルバーのガイドライン。
While transition and coexistence setups may mitigate some of the DNS resolution issues in a mixed IP address family Internet, making DNS data accessible over both IPv4 and IPv6 is the most robust and flexible approach. This approach allows resolvers to retrieve the information they need without requiring intermediary translation or encapsulation services, which may introduce additional failure cases.
移行および共存の設定により、IP アドレス ファミリが混在するインターネットにおける DNS 解決の問題の一部が軽減される可能性がありますが、IPv4 と IPv6 の両方で DNS データにアクセスできるようにすることが最も堅牢で柔軟なアプローチです。このアプローチにより、リゾルバーは、追加の失敗ケースを引き起こす可能性がある中間の変換サービスやカプセル化サービスを必要とせずに、必要な情報を取得できます。
Refer to Appendix A for an overview of the main changes since [RFC3901].
[RFC3901] 以降の主な変更点の概要については、付録 A を参照してください。
This document uses DNS terminology as described in [RFC9499]. Furthermore, the following terms are used with a defined meaning:
この文書では、[RFC9499] で説明されている DNS 用語を使用します。さらに、次の用語は定義された意味で使用されます。
IPv4-reachable name server:
IPv4 で到達可能なネームサーバー:
A name server that provides either authoritative or recursive DNS services via IPv4. This does not imply anything about the DNS data served but rather indicates that the name server receives and answers queries over IPv4.
IPv4 経由で権威 DNS サービスまたは再帰 DNS サービスを提供するネーム サーバー。これは、提供される DNS データに関するものではなく、ネーム サーバーが IPv4 経由でクエリを受信し、応答することを示しています。
IPv6-reachable name server:
IPv6 で到達可能なネームサーバー:
A name server that provides either authoritative or recursive DNS services via IPv6. This does not imply anything about the DNS data served but rather indicates that the name server receives and answers queries over IPv6.
IPv6 経由で権威 DNS サービスまたは再帰 DNS サービスを提供するネーム サーバー。これは、提供される DNS データに関するものではなく、ネーム サーバーが IPv6 経由でクエリを受信し、応答することを示しています。
Dual-stack name server (or resolver):
デュアルスタックネームサーバー (またはリゾルバー):
A name server (or resolver) that is both IPv4-reachable and IPv6-reachable.
IPv4 と IPv6 の両方に到達可能なネーム サーバー (またはリゾルバー)。
Effective PMTU:
有効な PMTU:
The effective Path Maximum Transmission Unit (PMTU) is the largest IP packet size (in octets) that can successfully traverse a network path from source to destination without requiring fragmentation.
有効パス最大伝送単位 (PMTU) は、フラグメント化を必要とせずに送信元から宛先までネットワーク パスを正常に通過できる最大の IP パケット サイズ (オクテット単位) です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
When a resolver looks up a name, it starts at the root and follows referrals until it reaches a name server set that is authoritative for the name. However, if the referrals lead to a name server set that only contains name servers reachable via an IP address family not supported by the resolver, the resolver is unable to continue DNS resolution.
リゾルバーが名前を検索するときは、ルートから開始され、その名前に対して権限のあるネーム サーバー セットに到達するまで参照に従います。ただし、リゾルバーがサポートしていない IP アドレス ファミリ経由で到達可能なネーム サーバーのみを含むネーム サーバー セットに紹介が誘導された場合、リゾルバーは DNS 解決を続行できません。
If this occurs, the DNS has been effectively partitioned due to mismatching IP address family support between the recursive DNS resolver and the authoritative DNS server.
この問題が発生した場合、再帰 DNS リゾルバーと権威 DNS サーバーの間で IP アドレス ファミリのサポートが一致しないため、DNS は事実上分割されています。
With the deployment of both IPv4 and IPv6, name space partitioning can occur for different reasons. One reason is that DNS zones are consistently configured to support only either IPv4 or IPv6. Another reason is misconfigurations that make a zone unresolvable by either IPv4-only or IPv6-only resolvers. The latter is often hard to identify because the impact of misconfigurations affecting one IP address family (IPv4 or IPv6) may be hidden in a dual-stack setting. In the worst case, where both IP address families must be fully supported by a resolver, a specific name may only be resolvable via dual-stack enabled resolvers.
IPv4 と IPv6 の両方を導入すると、さまざまな理由で名前空間の分割が発生する可能性があります。理由の 1 つは、DNS ゾーンが一貫して IPv4 または IPv6 のいずれかのみをサポートするように構成されていることです。もう 1 つの理由は、構成ミスにより、IPv4 専用または IPv6 専用のリゾルバーでゾーンを解決できなくなることです。後者は、1 つの IP アドレス ファミリ (IPv4 または IPv6) に影響を及ぼす構成ミスの影響がデュアル スタック設定に隠れている可能性があるため、特定するのが困難なことがよくあります。最悪の場合、両方の IP アドレス ファミリがリゾルバによって完全にサポートされなければならない場合、特定の名前はデュアルスタック対応リゾルバを介してのみ解決できる可能性があります。
Even when an administrator assumes that they have enabled support for a specific IP address family on their authoritative DNS server, various misconfigurations may break the DNS delegation chain of a zone for that IP address family, preventing any of its records from being resolved by clients that only support that IP address family. Such misconfigurations may remain undetected if most clients can successfully fall back to the other IP address family.
管理者が、権威 DNS サーバーで特定の IP アドレス ファミリのサポートを有効にしていると想定している場合でも、さまざまな構成ミスにより、その IP アドレス ファミリのゾーンの DNS 委任チェーンが切断され、その IP アドレス ファミリのみをサポートするクライアントによるレコードの解決が妨げられる場合があります。ほとんどのクライアントが他の IP アドレス ファミリに正常にフォールバックできる場合、このような構成ミスは検出されないままになる可能性があります。
The following name-related misconfigurations can cause broken delegation for one IP address family:
次の名前関連の構成ミスにより、1 つの IP アドレス ファミリの委任が壊れる可能性があります。
No A/AAAA records for NS names:
NS 名の A/AAAA レコードがありません:
If all of the NS resource records (RRs) for a zone in their parent zone have either only A RRs or only AAAA RRs, then resolution via the other IP address family is not possible.
親ゾーン内のゾーンのすべての NS リソース レコード (RR) に A RR のみまたは AAAA RR のみがある場合、他の IP アドレス ファミリによる解決は不可能です。
Missing glue:
不足している接着剤:
If the name from an NS record for a zone is in-domain (i.e., the name is within the zone or below), a parent zone needs to contain both IPv4 and IPv6 glue records. A parent needs to serve the corresponding A and AAAA RRs in the additional section when returning the NS RRs as the referral response [RFC9471].
ゾーンの NS レコードの名前がドメイン内にある場合 (つまり、名前がゾーン内またはその下にある場合)、親ゾーンには IPv4 と IPv6 の両方のグルー レコードが含まれている必要があります。親は、紹介応答として NS RR を返すときに、追加セクションで対応する A RR および AAAA RR を提供する必要があります [RFC9471]。
No A/AAAA RR for in-domain NS:
ドメイン内 NS の A/AAAA RR なし:
If the parent provides glue records for both IP address families but the child zone itself lacks corresponding A or AAAA RRs for the names of its in-domain NS, resolution via the missing IP address family will fail during delegation revalidation (see, e.g., [NS-REVALIDATION]).
親が両方の IP アドレス ファミリのグルー レコードを提供しているが、子ゾーン自体にそのドメイン内 NS の名前に対応する A または AAAA RR が欠如している場合、欠落している IP アドレス ファミリによる解決は委任の再検証中に失敗します (例: [NS-REVALIDATION] を参照)。
Zone of sibling domain NSes not resolving:
兄弟ドメイン NS のゾーンが解決されません:
If the name from an NS RR for a zone is in a sibling domain, the corresponding zone needs to be resolvable via the IP address family in question as well. It is insufficient if the name pointed to by the NS RR has an associated A or AAAA RR.
ゾーンの NS RR からの名前が兄弟ドメインにある場合、対応するゾーンも問題の IP アドレス ファミリを介して解決可能である必要があります。NS RR が指す名前に A または AAAA RR が関連付けられている場合は不十分です。
Parent zone not resolvable via one IP address family:
親ゾーンは 1 つの IP アドレス ファミリを介して解決できません:
For a zone to be resolvable via an IP address family, the parent zones up to the root zone need to be resolvable via that IP address family as well. Any zone not resolvable via the concerned IP address family breaks the delegation chain for all its children.
ゾーンを IP アドレス ファミリ経由で解決できるようにするには、ルート ゾーンまでの親ゾーンもその IP アドレス ファミリ経由で解決できる必要があります。関連する IP アドレス ファミリ経由で解決できないゾーンは、そのすべての子の委任チェーンを壊します。
The above misconfigurations are not mutually exclusive.
上記の構成ミスは相互に排他的ではありません。
Furthermore, any of the misconfigurations above may materialize not only via a missing RR but also via an RR providing the IP address of a name server that is not configured to answer queries via that IP address family [V6DNSRDY-23].
さらに、上記の構成ミスは、RR の欠落だけでなく、その IP アドレス ファミリ [V6DNSRDY-23] を介してクエリに応答するように構成されていないネーム サーバーの IP アドレスを提供する RR によっても発生する可能性があります。
Finally, at the time of this writing, addresses (A or AAAA RRs) for a delegation's authoritative name servers are the only type of glue defined for the DNS. In the future, alternative, yet related, delegation systems may be available, where other considerations apply.
最後に、この記事の執筆時点では、委任の権威ネーム サーバーのアドレス (A または AAAA RR) が、DNS に対して定義されている唯一のタイプの接着剤です。将来的には、他の考慮事項が適用される場合、代替の、ただし関連する委任システムが利用可能になる可能性があります。
In addition to explicit misconfigurations in the served DNS zones, network conditions may also influence a resolver's ability to resolve names in a zone. The most common issue is silent MTU discards for packets that would require fragmentation to fit a reduced effective PMTU, i.e., packets being dropped on-path when they exceed the MTU of the link to the next hop without the sender being notified. This can manifest in the following ways:
サービスを提供する DNS ゾーンの明示的な構成ミスに加えて、ネットワークの状態も、ゾーン内の名前を解決するリゾルバーの能力に影響を与える可能性があります。最も一般的な問題は、減少した実効 PMTU に適合させるために断片化が必要となるパケットのサイレント MTU 廃棄です。つまり、パケットが次のホップへのリンクの MTU を超えると、送信者に通知されることなくパス上でドロップされます。これは次のような形で現れる可能性があります。
DNS-over-UDP packets requiring fragmentation:
フラグメンテーションを必要とする DNS-over-UDP パケット:
When using Extension Mechanisms for DNS (EDNS(0)) to communicate support for DNS messages larger than 512 octets [RFC6891] via conventional DNS-over-UDP transport according to [RFC1035], an IP packet carrying a DNS response may exceed the PMTU for the path to a resolver. If an authoritative DNS server does not follow [RFC9715], i.e., honors EDNS(0) sizes larger than 1232 octets, it will try to fragment the packet according to the discovered PMTU. Such packets mostly occur for DNSKEY responses with DNSSEC [RFC4034].
DNS の拡張メカニズム (EDNS(0)) を使用して、[RFC1035] に従って従来の DNS-over-UDP トランスポートを介して 512 オクテット [RFC6891] を超える DNS メッセージのサポートを通信する場合、DNS 応答を運ぶ IP パケットがリゾルバへのパスの PMTU を超える可能性があります。権威ある DNS サーバーが [RFC9715] に従わない場合、つまり 1232 オクテットを超える EDNS(0) サイズを受け入れる場合、発見された PMTU に従ってパケットを断片化しようとします。このようなパケットは主に、DNSSEC [RFC4034] による DNSKEY 応答で発生します。
In general, DNS servers SHOULD follow [RFC9715], which provides additional guidance on preventing fragmentation. [RFC9715] suggests setting an upper bound for received EDNS(0) sizes of 1400 octets to avoid the need for fragmentation. However, the DNS Flag Day 2020 initiative [DNSFlagDay2020] suggests using an upper bound EDNS(0) size of only 1232 octets, which is also adopted by most implementations. Setting the upper bound at 1232 octets ensures that generated packets do not exceed 1280 octets, i.e., the minimum MTU for IPv6 [RFC8200], which avoids IPv6 host fragmentation by the server. Hence, for clarity, the present document specifically notes that clients MAY use an EDNS(0) size of 1232 octets as well.
一般に、DNS サーバーは、断片化の防止に関する追加のガイダンスを提供する [RFC9715] に従うべきです (SHOULD)。[RFC9715] は、断片化の必要性を避けるために、受信 EDNS(0) サイズの上限を 1400 オクテットに設定することを提案しています。ただし、DNS Flag Day 2020 イニシアチブ [DNSFlagDay2020] では、わずか 1232 オクテットの EDNS(0) サイズの上限を使用することが提案されており、これはほとんどの実装でも採用されています。上限を 1232 オクテットに設定すると、生成されるパケットが 1280 オクテット、つまり IPv6 [RFC8200] の最小 MTU を超えないようになり、サーバーによる IPv6 ホストの断片化が回避されます。したがって、明確にするために、この文書では、クライアントは 1232 オクテットの EDNS(0) サイズも使用してもよい (MAY) と特に注意します。
As an additional precaution or because the DNS implementation in use does not support limiting the effective EDNS(0) size, DNS servers MAY opt to explicitly not rely on Path MTU Discovery (PMTUD) [RFC4821] or Packetization Layer Path MTU Discovery (PLPMTUD) [RFC8899]. It can do so, for example, by setting IPV6_USE_MIN_MTU=1 from [RFC3542] to avoid the need to perform PMTU discovery.
追加の予防措置として、または使用中の DNS 実装が有効な EDNS(0) サイズの制限をサポートしていないため、DNS サーバーは、Path MTU Discovery (PMTUD) [RFC4821] または Packetization Layer Path MTU Discovery (PLPMTUD) [RFC8899] に明示的に依存しないことを選択してもよい(MAY)。たとえば、[RFC3542] で IPV6_USE_MIN_MTU=1 を設定することで、PMTU 検出を実行する必要性を回避できます。
DNS-over-TCP packets requiring fragmentation:
断片化が必要な DNS-over-TCP パケット:
For various reasons, a resolver can initiate connections via TCP for resolution to an authoritative server. However, similar to the case of DNS-over-UDP, DNS-over-TCP may encounter MTU discards if PMTUD is not possible on a given path. This can occur, for example, if PMTUD-related ICMP/ICMPv6 messages are dropped (i.e., cannot be returned to the sender) or if the size communicated in these messages is incorrect (i.e., an on-path device alters the size of packets). Under these conditions, the Maximum Segment Size (MSS) honored by the authoritative DNS server leads to IP packets exceeding the effective PMTU of the path taken by responses. In that case, similar to the case of DNS-over-UDP, DNS resolution will time out when the recursive DNS resolver does not receive a response in time.
さまざまな理由により、リゾルバーは、権威サーバーへの解決のために TCP 経由で接続を開始できます。ただし、DNS-over-UDP の場合と同様に、特定のパスで PMTUD が不可能な場合、DNS-over-TCP では MTU の破棄が発生する可能性があります。これは、たとえば、PMTUD 関連の ICMP/ICMPv6 メッセージがドロップされた場合 (つまり、送信者に返せない場合)、またはこれらのメッセージで通信されたサイズが正しくない場合 (つまり、パス上のデバイスがパケットのサイズを変更した場合) に発生する可能性があります。このような状況では、権威 DNS サーバーが受け入れる最大セグメント サイズ (MSS) により、IP パケットが応答が通過するパスの実効 PMTU を超えることになります。この場合、DNS-over-UDP の場合と同様に、再帰 DNS リゾルバーが時間内に応答を受信しないと、DNS 解決がタイムアウトになります。
[RFC9715] does not provide explicit guidance on mitigating this issue.
[RFC9715] は、この問題を軽減するための明確なガイダンスを提供していません。
[RFC8200] recommends that IPv6 nodes implement Path MTU Discovery (PMTUD) in order to discover and take advantage of PMTUs greater than 1280 octets. Usually, when a transport protocol can use PMTU (or PLPMTUD [RFC8201] or Datagram PLPMTUD [RFC4821] [RFC8899]), this SHOULD be used to determine an effective PMTU.
[RFC8200] は、1280 オクテットを超える PMTU を検出して利用するために、IPv6 ノードが Path MTU Discovery (PMTUD) を実装することを推奨しています。通常、トランスポートプロトコルが PMTU (または PLPMTUD [RFC8201] または Datagram PLPMTUD [RFC4821] [RFC8899]) を使用できる場合、これを有効な PMTU を決定するために使用する必要があります (SHOULD)。
However, DNS generally benefits from low latency, and performing PMTU (or PLPMTUD [RFC8201] or Datagram PLPMTUD [RFC4821] [RFC8899]) increases the time needed to process a DNS request. This overhead could even lead to DNS requests timing out before the effective PMTU can be established by the server. Furthermore, at the time of writing, most DNS messages fit into less than 1280 octets [DNSv6MTU], which means that the benefits of being able to leverage a larger effective PMTU only affect corner cases, e.g., requests for DNSKEY RRs. Additionally, not having to rely on PMTUD benefits the time budget for DNS, as the time needed for PMTUD could already exceed the timeout budget for DNS resolution, i.e., it could prevent resolution for cases where PMTUD is needed.
ただし、DNS は一般に待ち時間が短いという利点があり、PMTU (または PLPMTUD [RFC8201] または Datagram PLPMTUD [RFC4821] [RFC8899]) を実行すると、DNS 要求の処理に必要な時間が増加します。このオーバーヘッドにより、サーバーが有効な PMTU を確立する前に DNS リクエストがタイムアウトになる可能性もあります。さらに、この記事の執筆時点では、ほとんどの DNS メッセージは 1280 オクテット [DNSv6MTU] 未満に収まります。これは、より大きな有効 PMTU を利用できる利点は、DNSKEY RR のリクエストなどの特殊なケースにのみ影響することを意味します。さらに、PMTUD に依存する必要がないことにより、DNS の時間バジェットが節約されます。これは、PMTUD に必要な時間がすでに DNS 解決のタイムアウト バジェットを超えている可能性があるためです。つまり、PMTUD が必要な場合の解決が妨げられる可能性があります。
Hence, DNS servers SHOULD configure the maximum response size to avoid fragmentation or on-path discarding of packets larger than the effective PMTU. For TCP, this can be accomplished by restricting the used MSS, either by the host limiting the MSS on its own or by rewriting the MSS field in packets during a TCP handshake.
したがって、DNS サーバーは、有効な PMTU より大きいパケットの断片化やパス上での破棄を避けるために、最大応答サイズを設定する必要があります (SHOULD)。TCP の場合、これは、ホストが独自に MSS を制限するか、TCP ハンドシェイク中にパケット内の MSS フィールドを書き換えることによって、使用される MSS を制限することによって実現できます。
Therefore, it is RECOMMENDED that DNS servers set a Sender MSS (MSS_S) of no more than 1388 octets for TCP connections. Setting this MSS ensures that packets do not exceed a size of 1448 octets, i.e., the same packet size recommended to avoid fragmentation for DNS-over-UDP packets in [RFC9715]. Furthermore, to provide additional clarity similar to the above guidance on UDP, DNS servers MAY ensure that a total packet size of 1280 octets is not exceeded by setting the MSS_S to 1220 octets, as suggested by the DNS Flag Day 2020 initiative [DNSFlagDay2020]. See Section 3.7.1 of [RFC9293].
したがって、DNS サーバーが TCP 接続に対して 1388 オクテット以下の送信者 MSS (MSS_S) を設定することが推奨されます。この MSS を設定すると、パケットが 1448 オクテットのサイズを超えないことが保証されます。これは、[RFC9715] で DNS-over-UDP パケットの断片化を回避するために推奨されているのと同じパケット サイズです。さらに、UDP に関する上記のガイダンスと同様の明確性を提供するために、DNS サーバーは、DNS Flag Day 2020 イニシアチブ [DNSFlagDay2020] が提案しているように、MSS_S を 1220 オクテットに設定することで、合計パケット サイズが 1280 オクテットを超えないことを保証してもよい(MAY)。[RFC9293] のセクション 3.7.1 を参照してください。
As an additional precaution or because the DNS implementation in use does not support limiting the effective MSS size, DNS servers MAY opt to explicitly not rely on PMTUD [RFC4821] or PLPMTUD [RFC8899]. It can do so, for example, by setting IPV6_USE_MIN_MTU=1 from [RFC3542].
追加の予防措置として、または使用中の DNS 実装が有効な MSS サイズの制限をサポートしていないため、DNS サーバーは、PMTUD [RFC4821] または PLPMTUD [RFC8899] に明示的に依存しないことを選択してもよい(MAY)。たとえば、[RFC3542] で IPV6_USE_MIN_MTU=1 を設定することでこれを行うことができます。
Broken IP connectivity at the resolver:
リゾルバーでの IP 接続の切断:
Similar to authoritative servers, stub and recursive resolvers may face broken IP connectivity for either IPv4 or IPv6.
権威サーバーと同様に、スタブおよび再帰リゾルバーは、IPv4 または IPv6 の IP 接続が切断される可能性があります。
IPv4 connectivity for a DNS resolver may experience issues, e.g., if the resolver is deployed behind a Carrier-Grade NAT (CGN) [RFC6888] that implements strict timeouts on active sessions or limits the number of available TCP and UDP ports numbers for connections below the number required by the multiple connections necessary during recursive DNS resolution. Similarly, addressing in [RFC1918] may be in use on the resolver, while address translation is not performed. Or, similar to the case for IPv6, when the DNS resolver has a global IPv4 address, but that address is not forwarded on the resolver's network.
DNS リゾルバーの IPv4 接続では、たとえばリゾルバーが、アクティブなセッションで厳密なタイムアウトを実装するキャリア グレード NAT (CGN) [RFC6888] の背後に展開されている場合、または接続に使用可能な TCP および UDP ポート番号の数が、再帰的 DNS 解決中に必要な複数の接続に必要な数よりも少ない場合に、問題が発生する可能性があります。同様に、[RFC1918] のアドレス指定がリゾルバーで使用されている場合がありますが、アドレス変換は実行されません。または、IPv6 の場合と同様に、DNS リゾルバーがグローバル IPv4 アドレスを持っているが、そのアドレスがリゾルバーのネットワーク上で転送されない場合です。
IPv6 connectivity for a DNS resolver may experience issues, if, e.g., a client has been assigned a global unicast IPv6 address but IPv6 traffic is not forwarded on the resolver's network. Also, a resolver may only have received a unique local IPv6 unicast address [RFC4193], which does not allow it to reach global addresses without translation. Similarly, IPv6 connectivity can experience issues when IPv4-IPv6 transition technologies like NAT64 [RFC6146] on IPv6-mostly networks [RFC9313] are in use, where the use of NAT64 can be, e.g., discovered through PREF64 in Router Advertisements (RAs) [RFC8781] or DNS64 [RFC7050]. There, the synthesized IPv6 addresses used in 464XLAT [RFC6877] (for example) encounter additional PMTU fluctuation due to the difference in header size between IPv4 and IPv6, possibly impacting DNS resolution.
たとえば、クライアントにグローバル ユニキャスト IPv6 アドレスが割り当てられているにもかかわらず、IPv6 トラフィックがリゾルバのネットワーク上で転送されない場合、DNS リゾルバの IPv6 接続で問題が発生する可能性があります。また、リゾルバは一意のローカル IPv6 ユニキャスト アドレス [RFC4193] のみを受信している可能性があるため、変換せずにグローバル アドレスに到達することはできません。同様に、IPv6 接続は、IPv6 がほとんどのネットワーク [RFC9313] で NAT64 [RFC6146] のような IPv4-IPv6 移行テクノロジーが使用されている場合に問題が発生する可能性があります。この場合、NAT64 の使用は、たとえば、ルーター広告 (RA) [RFC8781] の PREF64 や DNS64 [RFC7050] を通じて検出される可能性があります。そこでは、(たとえば) 464XLAT [RFC6877] で使用される合成 IPv6 アドレスは、IPv4 と IPv6 のヘッダー サイズの違いにより追加の PMTU 変動に遭遇し、DNS 解決に影響を与える可能性があります。
Note: This document only explicitly discusses DNS-over-TCP and DNS-over-UDP. However, several other transport methods between recursive and authoritative DNS servers exist, including DNS over various encrypted transports. Some of these technologies provide additional mechanisms for preventing the impact of reduced PMTU or MTU discards. Guidance in this document focuses on IP address family support and the underlying transport protocol (TCP or UDP). If DNS servers use an additional protocol layer, e.g., DNS-over-TLS [RFC7858] or DNS-over-QUIC [RFC9250], for their communication and that protocol supports additional measures to prevent issues related to fragmentation on the IP layer, these measures SHOULD be used for the connection. If the protocol is not resilient to issues related to IP layer fragmentation by default, the above guidance for TCP- and UDP-based connections SHOULD be applied analogously.
注: このドキュメントでは、DNS-over-TCP および DNS-over-UDP についてのみ明示的に説明します。ただし、再帰的 DNS サーバーと権威 DNS サーバーの間には、さまざまな暗号化されたトランスポート上の DNS など、他にもいくつかのトランスポート方法が存在します。これらのテクノロジーの一部は、PMTU または MTU 廃棄の減少による影響を防ぐための追加メカニズムを提供します。このドキュメントのガイダンスは、IP アドレス ファミリのサポートと基盤となるトランスポート プロトコル (TCP または UDP) に焦点を当てています。DNS サーバーが通信に追加のプロトコル層 (例: DNS-over-TLS [RFC7858] または DNS-over-QUIC [RFC9250]) を使用し、そのプロトコルが IP 層の断片化に関連する問題を防ぐ追加の手段をサポートしている場合、これらの手段を接続に使用する必要があります (SHOULD)。プロトコルがデフォルトで IP 層の断片化に関連する問題に耐性がない場合は、TCP ベースおよび UDP ベースの接続に関する上記のガイダンスを同様に適用する必要があります (SHOULD)。
Intentional name space partitioning due to IP address family support occurs if an operator consciously decides not to deploy IPv4 or IPv6 for a part of the resolution chain. Most commonly, this is realized by intentionally not listing A/AAAA RRs for NS names. Based on a 2023 study, the share of zones not resolvable via IPv4 is negligible, while a little less than 40% of zones are not resolvable via IPv6 [V6DNSRDY-23]. However, as IPv4 address exhaustion progresses, IPv6 adoption is expected to increase.
IP アドレス ファミリのサポートによる意図的な名前空間の分割は、オペレータが解決チェーンの一部に IPv4 または IPv6 を導入しないことを意識的に決定した場合に発生します。最も一般的には、これは NS 名の A/AAAA RR を意図的にリストしないことによって実現されます。2023 年の調査によると、IPv4 経由で解決できないゾーンの割合はごくわずかですが、ゾーンの 40% 弱が IPv6 経由で解決できません [V6DNSRDY-23]。ただし、IPv4 アドレスの枯渇が進むにつれて、IPv6 の採用が増加すると予想されます。
IPv4 and IPv6 have become comparably relevant with the final exhaustion of IPv4 address pools in Regional Internet Registries (RIRs) (see, e.g., [RIPEV4]) and the progressing deployment of IPv6. Yet, while the first zones that are exclusively IPv6 resolvable can now be observed, exclusively IPv4 resolvable zones are considerably more common [V6DNSRDY-23]. Hence, dual-stack connectivity is still instrumental to be able to resolve zones and avoid name space partitioning.
IPv4 と IPv6 は、地域インターネット レジストリ (RIR) の IPv4 アドレス プールの最終的な枯渇 ([RIPEV4] などを参照) および IPv6 の展開の進行と同様に関連するようになりました。しかし、IPv6 のみで解決可能な最初のゾーンが現在観察されていますが、IPv4 のみで解決可能なゾーンはかなり一般的です [V6DNSRDY-23]。したがって、デュアル スタック接続は、ゾーンを解決し、名前空間の分割を回避できるようにするために依然として役立ちます。
Having zones served only by name servers reachable via one IP address family would partition the DNS. Hence, a way to avoid this partitioning is needed.
1 つの IP アドレス ファミリ経由でアクセス可能なネーム サーバーのみによってゾーンが提供されると、DNS が分割されます。したがって、この分割を回避する方法が必要です。
The recommended approach to maintain name space continuity is to use administrative policies, as described in this section.
名前空間の継続性を維持するために推奨されるアプローチは、このセクションで説明するように、管理ポリシーを使用することです。
It is usually recommended that DNS zones contain at least two name servers (Section 4.1 of [RFC1034]). Typically, these servers are geographically diverse and operate under different routing policies [RFC2182], as also discussed in, e.g., the IANA requirements for Top-Level Domain (TLD) authoritative name servers [IANANS]. To prevent DNS name space partitioning, at least two IPv4-reachable and two IPv6-reachable name servers MUST be configured for a zone. A single name server that is reachable over both IPv4 and IPv6 counts once per address family.
通常、DNS ゾーンには少なくとも 2 つのネームサーバーを含めることが推奨されます ([RFC1034] のセクション 4.1)。通常、これらのサーバーは地理的に多様であり、トップレベル ドメイン (TLD) の権威ネーム サーバーに関する IANA 要件 [IANANS] などでも説明されているように、異なるルーティング ポリシー [RFC2182] の下で動作します。DNS ネームスペースの分割を防ぐには、ゾーンに対して少なくとも 2 つの IPv4 到達可能なネーム サーバーと 2 つの IPv6 到達可能なネーム サーバーを構成する必要があります。IPv4 と IPv6 の両方で到達可能な単一のネーム サーバーは、アドレス ファミリごとに 1 回カウントされます。
Please note that a name set in an NS RR that has either only an A or AAAA record may add overhead to the resolution process for resolvers only supporting the IP address family for which no corresponding A or AAAA RR is present. When selecting such an authoritative name server during DNS resolution, a query for the missing A or AAAA record would return NODATA, requiring the client to query for the A or AAAA record of another NS RR. To prevent this, it is RECOMMENDED that all names used in NS RRs have an A and AAAA record set.
A または AAAA レコードのみを持つ NS RR に設定された名前は、対応する A または AAAA RR が存在しない IP アドレス ファミリのみをサポートするリゾルバーの解決プロセスにオーバーヘッドを追加する可能性があることに注意してください。DNS 解決中にこのような権限のあるネーム サーバーを選択すると、欠落している A または AAAA レコードのクエリによって NODATA が返され、クライアントは別の NS RR の A または AAAA レコードをクエリする必要があります。これを防ぐために、NS RR で使用されるすべての名前に A および AAAA レコード セットがあることが推奨されます。
Specifically, the key requirements for a zone are:
具体的には、ゾーンの主な要件は次のとおりです。
IPv4 adoption:
IPv4の採用:
To maintain name space continuity, every DNS zone MUST be served by at least two authoritative DNS servers providing services via IPv4. Furthermore, the delegation configuration of an NS (resolution of the parent, resolution of sibling domain names, glue) MUST NOT rely on IPv6 connectivity being available.
名前空間の継続性を維持するには、IPv4 経由でサービスを提供する少なくとも 2 つの権威 DNS サーバーがすべての DNS ゾーンをサービスしなければなりません。さらに、NS の委任設定 (親の解決、兄弟ドメイン名の解決、グルー) は、利用可能な IPv6 接続に依存してはなりません (MUST NOT)。
IPv6 adoption:
IPv6の採用:
To maintain name space continuity, every DNS zone MUST be served by at least two authoritative DNS servers providing services via IPv6. To avoid reachability issues, authoritative DNS servers MUST NOT use IPv4-embedded addresses [RFC6052] (including IPv4-Mapped IPv6 addresses and deprecated IPv4-compatible addresses [RFC4291]) for receiving queries. Furthermore, the delegation configuration of an NS (resolution of the parent, resolution of sibling domain names, glue) MUST NOT rely on IPv4 connectivity being available.
名前空間の継続性を維持するには、IPv6 経由でサービスを提供する少なくとも 2 つの権威 DNS サーバーがすべての DNS ゾーンをサービスしなければなりません。到達可能性の問題を回避するために、権威 DNS サーバーは、クエリの受信に IPv4 埋め込みアドレス [RFC6052] (IPv4 マップされた IPv6 アドレスおよび非推奨の IPv4 互換アドレス [RFC4291] を含む) を使用してはなりません (MUST NOT)。さらに、NS の委任設定 (親の解決、兄弟ドメイン名の解決、グルー) は、利用可能な IPv4 接続に依存してはなりません (MUST NOT)。
Consistency:
一貫性：
Both IPv4 and IPv6 transports MUST serve equivalent DNS data to ensure a consistent resolution experience across different network types.
IPv4 と IPv6 の両方のトランスポートは、異なるネットワーク タイプ間で一貫した解決エクスペリエンスを保証するために、同等の DNS データを提供しなければなりません (MUST)。
Avoiding IP Fragmentation:
IP フラグメンテーションの回避:
IP fragmentation has been reported to be fragile [RFC8900]. Furthermore, IPv6 transition technologies can introduce unexpected reductions in the effective PMTU (e.g., when NAT64 is used (Section 7 of [RFC7269])). Therefore, IP fragmentation SHOULD be avoided by following guidance on maximum DNS payload sizes [RFC9715]. Furthermore, as per Section 5 of [RFC7766], DNS-over-TCP MUST be available as a fallback option, instead of relying on fragmented UDP packets. Similar to the guidance in [RFC9715], authoritative DNS servers MAY set an MSS of either 1388 (analogous to [RFC9715]) or 1220 (analogous to the [DNSFlagDay2020] suggestions) in TCP sessions carrying DNS responses.
IP フラグメンテーションは脆弱であると報告されています [RFC8900]。さらに、IPv6 移行テクノロジーは、実効 PMTU の予期せぬ減少を引き起こす可能性があります (たとえば、NAT64 が使用されている場合 ([RFC7269] のセクション 7))。したがって、最大 DNS ペイロード サイズ [RFC9715] に関するガイダンスに従って、IP フラグメンテーションを回避する必要があります (SHOULD)。さらに、[RFC7766] のセクション 5 に従って、断片化された UDP パケットに依存するのではなく、フォールバック オプションとして DNS-over-TCP を利用できなければなりません (MUST)。[RFC9715] のガイダンスと同様に、権威 DNS サーバーは、DNS 応答を伝送する TCP セッションで 1388 ([RFC9715] に類似) または 1220 ([DNSFlagDay2020] 提案に類似) の MSS を設定してもよい(MAY)。
To prevent name space partitioning, zone validation processes SHOULD ensure that:
名前空間の分割を防ぐために、ゾーン検証プロセスは次のことを保証する必要があります (SHOULD)。
* There are at least two IPv4 address records and two IPv6 address records available for the name servers of any child delegation within the zone.
* ゾーン内の子委任のネーム サーバーで使用できる IPv4 アドレス レコードと IPv6 アドレス レコードが少なくとも 2 つあります。
* The zone's authoritative servers follow [RFC9715] for avoiding fragmentation on DNS-over-UDP.
* ゾーンの権威サーバーは、DNS-over-UDP での断片化を回避するために [RFC9715] に従っています。
* The zone's authoritative servers support DNS-over-TCP [RFC9210].
* ゾーンの権威サーバーは DNS-over-TCP [RFC9210] をサポートします。
* The zone's authoritative servers can be reached via IPv4 and IPv6 when performing DNS resolution via IPv4-only and IPv6-only networks, respectively.
* IPv4 のみのネットワーク経由で DNS 解決を実行する場合、IPv6 のみのネットワーク経由で DNS 解決を実行する場合は、ゾーンの権威サーバーに IPv4 経由でアクセスできます。
To ensure robust DNS resolution even when facing name space partitioning, every recursive DNS resolver SHOULD be dual-stack. Exceptions apply if one of the methods to prevent name space partitioning described in this section is in place.
名前空間の分割に直面した場合でも堅牢な DNS 解決を保証するには、すべての再帰的 DNS リゾルバーをデュアルスタックにする必要があります。このセクションで説明する名前空間の分割を防止する方法のいずれかが導入されている場合は、例外が適用されます。
While the zones that IPv6-only recursive DNS resolvers can resolve are growing, they do not yet cover all zones. Hence, a recursive DNS resolver MAY be IPv6-only if it uses a transition mechanism that allows it to also query IPv4-only authoritative DNS servers or uses a configuration where it forwards queries failing IPv6-only DNS resolution to a dual-stack recursive DNS resolver (i.e., a resolver that is also able to perform DNS resolution over IPv4). If a recursive DNS resolver is aware of a PREF64 to use for NAT64 [RFC6146], either through static configuration or by discovering it (e.g., using the option described in [RFC8781]), it MAY synthesize IPv6 addresses for remote authoritative DNS servers.
IPv6 専用の再帰 DNS リゾルバーが解決できるゾーンは増加していますが、まだすべてのゾーンをカバーしているわけではありません。したがって、再帰的 DNS リゾルバは、IPv4 のみの権威 DNS サーバーへのクエリも実行できる移行メカニズムを使用する場合、または IPv6 のみの DNS 解決に失敗したクエリをデュアルスタックの再帰的 DNS リゾルバ (つまり、IPv4 経由での DNS 解決も実行できるリゾルバ) に転送する構成を使用する場合、IPv6 専用であってもよい(MAY)。再帰的 DNS リゾルバが、静的設定を通じて、またはそれを発見することによって (たとえば、[RFC8781] で説明されているオプションを使用する) ことによって、NAT64 [RFC6146] に使用する PREF64 を認識している場合、リモートの権威 DNS サーバーの IPv6 アドレスを合成してもよい(MAY)。
Similarly, a recursive DNS resolver MAY be IPv4-only if it uses a configuration where such resolvers forward queries failing IPv4-only DNS resolution to a dual-stack recursive DNS resolver (i.e., a resolver that is also able to perform DNS resolution over IPv6).
同様に、再帰的 DNS リゾルバーが、IPv4 のみの DNS 解決に失敗したクエリをデュアルスタックの再帰的 DNS リゾルバー (つまり、IPv6 経由でも DNS 解決を実行できるリゾルバー) に転送する構成を使用する場合、再帰的 DNS リゾルバーは IPv4 専用であってもよい(MAY)。
Finally, when responding to recursive queries (i.e., a query with the Recursion Desired (RD) bit set [RFC1035]), a DNS resolver SHOULD follow the above guidance on fragmentation avoidance (see Section 4.1) for communication between authoritative DNS servers and recursive DNS resolvers analogously.
最後に、再帰的クエリ (つまり、Recursion Desired (RD) ビットが設定されたクエリ [RFC1035]) に応答するとき、DNS リゾルバーは、権威 DNS サーバーと再帰的 DNS リゾルバー間の通信についても同様に、断片化回避に関する上記のガイダンス (セクション 4.1 を参照) に従うべきです (SHOULD)。
Contrary to authoritative DNS servers and recursive DNS resolvers, DNS stub resolvers are more likely to find themselves in either an IPv6-mostly or IPv4-only environment, as they are usually run on end hosts or clients. Furthermore, a DNS stub resolver has to rely on recursive DNS servers discovered for the local network, e.g., using DHCPv4 [RFC2131], DHCPv6 [RFC9915], and/or router advertisements [RFC8106]. In that case, the stub resolver may obtain multiple different IPv4 and IPv6 DNS resolver addresses to use.
権威 DNS サーバーや再帰 DNS リゾルバーとは対照的に、DNS スタブリゾルバーは通常、エンドホストまたはクライアント上で実行されるため、ほとんどが IPv6 環境または IPv4 のみの環境で動作する可能性が高くなります。さらに、DNS スタブリゾルバーは、たとえば、DHCPv4 [RFC2131]、DHCPv6 [RFC9915]、ルーター広告 [RFC8106] などを使用して、ローカル ネットワークで検出された再帰的 DNS サーバーに依存する必要があります。その場合、スタブリゾルバは、使用する複数の異なる IPv4 および IPv6 DNS リゾルバ アドレスを取得することがあります。
To prioritize different IPv4 and IPv6 DNS resolver addresses, a stub resolver SHOULD follow [RFC6724]. However, a DNS stub resolver SHOULD NOT utilize IPv4-embedded IPv6 addresses if it is able to identify them as such, e.g., by having discovered the PREF64 in use for the network [RFC8781].
異なる IPv4 および IPv6 DNS リゾルバー アドレスに優先順位を付けるには、スタブリゾルバーは [RFC6724] に従う必要があります (SHOULD)。ただし、DNS スタブリゾルバは、たとえばネットワークで使用されている PREF64 を発見することによって、IPv4 に埋め込まれた IPv6 アドレスを識別できる場合は、そのアドレスを利用すべきではありません [RFC8781]。
When providing multiple recursive DNS servers to stub resolvers, network operators have to consider that, at the time of writing, various implementations can only configure a small set of possible DNS resolver addresses, e.g., only up to three for glibc [MAN], and additional resolver addresses provided may be non-deterministically ignored by clients.
複数の再帰 DNS サーバーをスタブリゾルバに提供する場合、ネットワーク オペレータは、本書の執筆時点では、さまざまな実装で可能な DNS リゾルバ アドレスの少数のセットしか設定できず、たとえば glibc [MAN] の場合は最大 3 つしか設定できず、提供された追加のリゾルバ アドレスはクライアントによって非決定的に無視される可能性があることを考慮する必要があります。
Hence, when providing more than three recursive server addresses to stub resolvers, operators SHOULD ensure that either:
したがって、3 つを超える再帰サーバー アドレスをスタブリゾルバーに提供する場合、オペレーターは次のいずれかを確認する必要があります (SHOULD)。
1. all supplied recursive server IP addresses are from the same address family, based on knowledge as to clients being IPv4-only or IPv6-mostly; or
1. 提供されるすべての再帰的サーバー IP アドレスは、クライアントが IPv4 のみであるか、IPv6 がほとんどであるかに関する知識に基づいて、同じアドレス ファミリに属します。または
2. exactly two IP addresses are from one address family (IPv4 or IPv6) and exactly one is from the other address family.
2. ちょうど 2 つの IP アドレスが 1 つのアドレス ファミリ (IPv4 または IPv6) からのものであり、ちょうど 1 つが他のアドレス ファミリからのものです。
Furthermore, all supplied resolvers SHOULD be able to perform dual-stack DNS resolution to avoid name space partitioning due to IP address family support.
さらに、提供されるすべてのリゾルバーは、IP アドレス ファミリのサポートによる名前空間の分割を回避するために、デュアルスタック DNS 解決を実行できる必要があります (SHOULD)。
The guidelines described in this memo introduce no new security considerations into the DNS protocol itself.
このメモで説明されているガイドラインでは、DNS プロトコル自体にセキュリティに関する新たな考慮事項が導入されていません。
Nevertheless, corner cases exist where forwarding queries requiring an IP address family for resolution that is not supported by the initial resolver leads to an infinite forwarding loop under the following conditions:
ただし、次の条件下では、最初のリゾルバーでサポートされていない解決に IP アドレス ファミリを必要とするクエリの転送が無限転送ループにつながる特殊なケースが存在します。
* Two resolvers handle queries for a set of clients, each of these resolvers supports one and only one address family that is distinct from the address family supported by the other resolver;
* 2 つのリゾルバーが一連のクライアントのクエリを処理します。これらの各リゾルバーは、他のリゾルバーがサポートするアドレス ファミリとは異なる 1 つのアドレス ファミリをサポートします。
* Both resolvers are configured to forward queries requiring DNS resolution via the IP address family they do not support to the other; and
* どちらのリゾルバーも、サポートしていない IP アドレス ファミリを介して DNS 解決を必要とするクエリをもう一方のリゾルバーに転送するように構成されています。そして
* A query for a zone that is not resolvable via IPv4 and not resolvable via IPv6 is received.
* IPv4 経由でも IPv6 経由でも解決できないゾーンのクエリを受信しました。
In such cases, a query for the non-resolvable zone would be endlessly forwarded between these resolvers.
このような場合、解決不可能なゾーンに対するクエリは、これらのリゾルバー間で際限なく転送されます。
To prevent such cases, single-stack recursive DNS resolvers SHOULD be configured to forward queries they cannot resolve due to lacking support for one address family to dual-stack recursive DNS resolvers. Furthermore, recursive DNS resolvers MUST NOT be configured to forward queries to DNS resolvers that are configured to forward queries to them in the first place.
このようなケースを防ぐために、単一スタックの再帰的 DNS リゾルバーは、1 つのアドレス ファミリのサポートがないために解決できないクエリをデュアルスタックの再帰的 DNS リゾルバーに転送するように構成すべきです (SHOULD)。さらに、再帰的 DNS リゾルバーは、そもそもクエリを転送するように設定されている DNS リゾルバーにクエリを転送するように設定してはなりません (MUST NOT)。
Recommendations for recursive and stub resolvers rely on a correctly discovered PREF64. Security issues may materialize if an incorrect PREF64 is used. Hence, guidance from [RFC9872] on securely discovering PREF64 SHOULD be followed.
再帰リゾルバーとスタブ リゾルバーの推奨事項は、正しく検出された PREF64 に依存します。不適切な PREF64 が使用されると、セキュリティの問題が発生する可能性があります。したがって、PREF64 の安全な検出に関する [RFC9872] のガイダンスに従う必要があります (SHOULD)。
Preventing fragmentation according to the guidance in this document may increase load on DNS servers, as more TCP fallbacks might be required. While measurements have shown this to be (at the time of writing) in the range of 3-5% of connections [DNSv6MTU], operators SHOULD monitor the actual impact on their servers when implementing guidance from this document to detect unexpected load increases early on.
このドキュメントのガイダンスに従って断片化を防止すると、より多くの TCP フォールバックが必要になる可能性があるため、DNS サーバーの負荷が増加する可能性があります。測定によると、これは (執筆時点で) 接続の 3 ～ 5% の範囲 [DNSv6MTU] であることが示されていますが、オペレータは、この文書のガイダンスを実装する際に、サーバーへの実際の影響を監視して、予期せぬ負荷の増加を早期に検出する必要があります。
This document has no IANA actions.
この文書には IANA のアクションはありません。
However, IANA should consider updating its technical requirements for authoritative DNS servers to require both IPv4 and IPv6 addresses for each authoritative server [IANANS], in accordance with the processes for reviewing and revising these procedures.
ただし、IANA は、これらの手順を検討および改訂するプロセスに従って、各権威サーバーに IPv4 と IPv6 の両方のアドレスを要求するように権威 DNS サーバーの技術要件を更新することを検討する必要があります [IANANS]。
[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>.
[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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<https://www.rfc-editor.org/info/rfc6052>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<https://www.rfc-editor.org/info/rfc7766>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC9210] Kristoff, J. and D. Wessels, "DNS Transport over TCP -
Operational Requirements", BCP 235, RFC 9210,
DOI 10.17487/RFC9210, March 2022,
<https://www.rfc-editor.org/info/rfc9210>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[RFC9471] Andrews, M., Huque, S., Wouters, P., and D. Wessels, "DNS
Glue Requirements in Referral Responses", RFC 9471,
DOI 10.17487/RFC9471, September 2023,
<https://www.rfc-editor.org/info/rfc9471>.
[RFC9715] Fujiwara, K. and P. Vixie, "IP Fragmentation Avoidance in
DNS over UDP", RFC 9715, DOI 10.17487/RFC9715, January
2025, <https://www.rfc-editor.org/info/rfc9715>.
[DNSFlagDay2020]
"DNS flag day 2020", <https://dnsflagday.net/2020/>.
[DNSv6MTU] Fiebig, T. and A. Feldmann, "'How I learned to stop
worrying and love IPv6': Measuring the Internet's
Readiness for DNS over IPv6", IMC '25: Proceedings of the
2025 ACM Internet Measurement Conference, pp. 359-380,
DOI 10.1145/3730567.3764439, October 2025,
<https://doi.org/10.1145/3730567.3764439>.
[IANANS] IANA, "Technical requirements for authoritative name
servers",
<https://www.iana.org/help/nameserver-requirements>.
[MAN] "resolv.conf(5) - Linux manual page", 2025,
<https://man7.org/linux/man-pages/man5/
resolv.conf.5.html>.
[NS-REVALIDATION]
Huque, S., Vixie, P. A., and W. Toorop, "Delegation
Revalidation by DNS Resolvers", Work in Progress,
Internet-Draft, draft-ietf-dnsop-ns-revalidation-13, 6
July 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-dnsop-ns-revalidation-13>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
DOI 10.17487/RFC2182, July 1997,
<https://www.rfc-editor.org/info/rfc2182>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for
IPv6", RFC 3542, DOI 10.17487/RFC3542, June 2003,
<https://www.rfc-editor.org/info/rfc3542>.
[RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
Guidelines", BCP 91, RFC 3901, DOI 10.17487/RFC3901,
September 2004, <https://www.rfc-editor.org/info/rfc3901>.
[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>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard,
"IPv6 Support Required for All IP-Capable Nodes", BCP 177,
RFC 6540, DOI 10.17487/RFC6540, April 2012,
<https://www.rfc-editor.org/info/rfc6540>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., and H. Ashida, "Common Requirements for Carrier-Grade
NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
April 2013, <https://www.rfc-editor.org/info/rfc6888>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013,
<https://www.rfc-editor.org/info/rfc7050>.
[RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64
Deployment Options and Experience", RFC 7269,
DOI 10.17487/RFC7269, June 2014,
<https://www.rfc-editor.org/info/rfc7269>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[RFC8781] Colitti, L. and J. Linkova, "Discovering PREF64 in Router
Advertisements", RFC 8781, DOI 10.17487/RFC8781, April
2020, <https://www.rfc-editor.org/info/rfc8781>.
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile",
BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
<https://www.rfc-editor.org/info/rfc8900>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>.
[RFC9313] Lencse, G., Palet Martinez, J., Howard, L., Patterson, R.,
and I. Farrer, "Pros and Cons of IPv6 Transition
Technologies for IPv4-as-a-Service (IPv4aaS)", RFC 9313,
DOI 10.17487/RFC9313, October 2022,
<https://www.rfc-editor.org/info/rfc9313>.
[RFC9386] Fioccola, G., Volpato, P., Palet Martinez, J., Mishra, G.,
and C. Xie, "IPv6 Deployment Status", RFC 9386,
DOI 10.17487/RFC9386, April 2023,
<https://www.rfc-editor.org/info/rfc9386>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[RFC9872] Buraglio, N., Jensen, T., and J. Linkova, "Recommendations
for Discovering IPv6 Prefix Used for IPv6 Address
Synthesis", RFC 9872, DOI 10.17487/RFC9872, September
2025, <https://www.rfc-editor.org/info/rfc9872>.
[RFC9915] Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T.
Winters, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", STD 102, RFC 9915, DOI 10.17487/RFC9915,
January 2026, <https://www.rfc-editor.org/info/rfc9915>.
[RIPEV4] RIPE NCC, "The RIPE NCC has run out of IPv4 Addresses",
November 2019, <https://www.ripe.net/publications/news/
about-ripe-ncc-and-ripe/the-ripe-ncc-has-run-out-of-
ipv4-addresses>.
[V6DNSRDY-23]
Streibelt, F., Sattler, P., Lichtblau, F., Hernandez-
Gañán, C., Feldmann, A., Gasser, O., and T. Fiebig, "How
Ready is DNS for an IPv6-Only World?", Passive and Active
Measurement (PAM 2023), Lecture Notes in Computer Science,
vol. 13882, pp. 525-549, DOI 10.1007/978-3-031-28486-1_22,
March 2023, <https://link.springer.com/
chapter/10.1007/978-3-031-28486-1_22>.
The following changes have been made to the guidance published in [RFC3901]:
[RFC3901] で公開されたガイダンスに次の変更が加えられました。
* Expanded the terminology section, also taking considerations from [RFC9499] into account.
* [RFC9499] の考慮事項も考慮して、用語セクションを拡張しました。
* Expanded name space partitioning, independently discussing intentional choices, misconfigurations, and network conditions, which lead to name space partitioning due to differences in IP address family support.
* 名前空間の分割を拡張し、IP アドレス ファミリのサポートの違いにより名前空間の分割につながる、意図的な選択、構成ミス、およびネットワークの状態について個別に議論します。
* Now recommends the use of IPv4 and IPv6 for authoritative DNS servers instead of leaving IPv6 optional.
* IPv6 をオプションのままにするのではなく、権威 DNS サーバーに IPv4 と IPv6 の使用を推奨するようになりました。
* Now recommends testing IPv4 and IPv6 resolvability when delegating zones instead of only testing IPv4 resolvability.
* ゾーンを委任するときに、IPv4 の解決可能性のみをテストするのではなく、IPv4 および IPv6 の解決可能性をテストすることを推奨するようになりました。
* Added guidance on handling IP layer fragmentation.
* IP 層の断片化の処理に関するガイダンスを追加しました。
* Added guidance for IP address family handling for recursive and stub resolvers.
* 再帰リゾルバーおよびスタブリリゾルバーの IP アドレス ファミリの処理に関するガイダンスを追加しました。
Valuable input for this document was provided by the following individuals: Bob Harold, Andreas Schulze, Tommy Jensen, Nick Buraglio, Jen Linkova, Tim Chown, Brian E. Carpenter, Tom Petch, Philipp S. Tiesel, Mark Andrews, Stefan Ubbink, Joe Abley, Gorry Fairhurst, Paul Vixie, Lorenzo Colitti, David Farmer, Pieter Lexis, Ralf Weber, Philip Homburg, Marco Davids, Mohamed Boucadair, Thomas Fossati, Aihua Guo, Bernie Volz, David Dong, Roman Danyliw, Éric Vyncke, and Erik Nygren.
この文書に対する貴重な意見は次の方々から提供されました: Bob Harold、Andreas Schulze、Tommy Jensen、Nick Buragilo、Jen Linkova、Tim Cown、Brian E. Carpenter、Tom Petch、Philipp S. Tiesel、Mark Andrews、Stefan Ubbink、Joe Abley、Gorry Fairhurst、Paul Vixie、Lorenzo Colitti、David Farmer、Pieter Lexis、Ralf Weber、Philipホンブルグ、マルコ・ダービッツ、モハメド・ブーカデール、トーマス・フォッサティ、アイフア・グオ、バーニー・ヴォルツ、デイビッド・ドン、ローマン・ダニリュー、エリック・ヴィンケ、エリック・ニグレン。
Furthermore, the authors express their thanks to the authors of [RFC3901], Alain Durand and Johan Ihren, and provide their original acknowledgements verbatim below:
さらに、著者らは、[RFC3901] の著者である Alain Durand 氏と Johan Ihren 氏に感謝の意を表し、彼らの元の謝辞をそのまま以下に記載します。
This document is the result of many conversations that happened in the DNS community at IETF and elsewhere since 2001. During that period of time, a number of Internet drafts have been published to clarify various aspects of the issues at stake. This document focuses on the conclusion of those discussions.
この文書は、2001 年以来 IETF などの DNS コミュニティで行われた多くの会話の結果です。この期間中、問題となっている問題のさまざまな側面を明確にするために、多数のインターネット草案が公開されました。この文書は、それらの議論の結論に焦点を当てています。
The authors would like to acknowledge the role of Pekka Savola in his thorough review of the document.
著者らは、文書の徹底的なレビューにおける Pekka Savola の役割を認めたいと思います。
Momoka Yamamoto
WIDE Project
Email: momoka.my6@gmail.com
Tobias Fiebig
Max-Planck-Institut fuer Informatik
Campus E14
66123 Saarbruecken
Germany
Phone: +49 681 9325 3527
Email: tfiebig@mpi-inf.mpg.de