[要約] RFC 9103は、DNSゾーン転送をTLSで安全に行うためのプロトコルです。この目的は、DNSデータのプライバシーと完全性を保護することにあります。主に、信頼できるサーバ間でのゾーン転送時に利用されます。
Internet Engineering Task Force (IETF) W. Toorop
Request for Comments: 9103 NLnet Labs
Updates: 1995, 5936, 7766 S. Dickinson
Category: Standards Track Sinodun IT
ISSN: 2070-1721 S. Sahib
Brave Software
P. Aras
A. Mankin
Salesforce
August 2021
DNS Zone Transfer over TLS
DNSゾーンはTLSを介して転送されます
Abstract
概要
DNS zone transfers are transmitted in cleartext, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies the use of TLS, rather than cleartext, to prevent zone content collection via passive monitoring of zone transfers: XFR over TLS (XoT). Additionally, this specification updates RFC 1995 and RFC 5936 with respect to efficient use of TCP connections and RFC 7766 with respect to the recommended number of connections between a client and server for each transport.
DNSゾーン転送はクリアテキストで送信され、攻撃者はネットワーク接続を盗聴することによってゾーンの内容を収集する機会を与えます。DNSトランザクション署名（TSIG）メカニズムは、直接ゾーン転送を許可されたクライアントにのみ制限するために指定されていますが、機密性を追加しません。このドキュメントでは、ゾーン転送のパッシブモニタリングによるゾーンコンテンツのコレクションを防ぐために、ClearTextではなくTLSの使用を指定します。XFR TLS（XOT）。さらに、この仕様は、各トランスポートのためのクライアントとサーバー間の推奨される接続数に関して、TCP接続とRFC 7766の効率的な使用に関してRFC 1995とRFC 5936を更新します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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 Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、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/rfc9103.
この文書の現在のステータス、任意のエラータ、およびフィードバックの提供方法は、https://www.rfc-editor.org/info/rfc9103で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Threat Model
4. Design Considerations for XoT
5. Connection and Data Flows in Existing XFR Mechanisms
5.1. AXFR Mechanism
5.2. IXFR Mechanism
5.3. Data Leakage of NOTIFY and SOA Message Exchanges
5.3.1. NOTIFY
5.3.2. SOA
6. Updates to Existing Specifications
6.1. Update to RFC 1995 for IXFR over TCP
6.2. Update to RFC 5936 for AXFR over TCP
6.3. Updates to RFCs 1995 and 5936 for XFR over TCP
6.3.1. Connection Reuse
6.3.2. AXFRs and IXFRs on the Same Connection
6.3.3. XFR Limits
6.3.4. The edns-tcp-keepalive EDNS(0) Option
6.3.5. Backwards Compatibility
6.4. Update to RFC 7766
7. XoT Specification
7.1. Connection Establishment
7.2. TLS Versions
7.3. Port Selection
7.4. High-Level XoT Descriptions
7.5. XoT Transfers
7.6. XoT Connections
7.7. XoT vs. ADoT
7.8. Response RCODES
7.9. AXoT Specifics
7.9.1. Padding AXoT Responses
7.10. IXoT Specifics
7.10.1. Condensation of Responses
7.10.2. Fallback to AXFR
7.10.3. Padding of IXoT Responses
7.11. Name Compression and Maximum Payload Sizes
8. Multi-primary Configurations
9. Authentication Mechanisms
9.1. TSIG
9.2. SIG(0)
9.3. TLS
9.3.1. Opportunistic TLS
9.3.2. Strict TLS
9.3.3. Mutual TLS
9.4. IP-Based ACL on the Primary
9.5. ZONEMD
10. XoT Authentication
11. Policies for Both AXoT and IXoT
12. Implementation Considerations
13. Operational Considerations
14. IANA Considerations
15. Security Considerations
16. References
16.1. Normative References
16.2. Informative References
Appendix A. XoT Server Connection Handling
A.1. Listening Only on a Specific IP Address for TLS
A.2. Client-Specific TLS Acceptance
A.3. SNI-Based TLS Acceptance
A.4. Transport-Specific Response Policies
A.4.1. SNI-Based Response Policies
Acknowledgements
Contributors
Authors' Addresses
DNS has a number of privacy vulnerabilities, as discussed in detail in [RFC9076]. Query privacy between stub resolvers and recursive resolvers has received the most attention to date, with Standards Track documents for both DNS over TLS (DoT) [RFC7858] and DNS over HTTPS (DoH) [RFC8484] and a proposal for DNS over QUIC [DPRIVE-DNSOQUIC]. There is ongoing work on DNS privacy requirements for exchanges between recursive resolvers and authoritative servers and some suggestions for how signaling of DoT support by authoritative name servers might work. However, there is currently no RFC that specifically defines recursive-to-authoritative DNS over TLS (ADoT).
DNSには、[RFC9076]で詳しく説明したように、いくつかのプライバシーの脆弱性があります。スタブリゾルバと再帰的なリゾルバのクエリのプライバシーは、日付に最も注目を集めており、標準はTLS（DOT）[RFC7858]とHTTPS（DOH）[RFC8484]を介したDNS（DOH）[RFC8484]とQUIC上のDNSの提案を追跡しています。-dnsoquic]再帰的なリゾルガーと権威あるサーバーとの間の交換のためのDNSプライバシー要件および信頼できるネームサーバーによるドットサポートのシグナリングがどのように機能するかについてのいくつかの提案については、継続的な取り組みがあります。ただし、現在、TLS（ADOT）を介して再帰的に信頼できるDNSを定義するRFCは現在ありません。
[RFC9076] establishes that a stub resolver's DNS query transactions are not public and that they need protection, but, on zone transfer [RFC1995] [RFC5936], it says only:
[RFC9076]スタブリゾルバのDNSクエリ取引が公開されておらず、保護が必要であることを確立しますが、ゾーン転送[RFC1995] [RFC5936]、それは次のとおりです。
| Privacy risks for the holder of a zone (the risk that someone gets | the data) are discussed in [RFC5155] and [RFC5936].
| ..ゾーンのホルダーのためのプライバシーリスク（誰かがデータを取得するリスク）は[RFC5155]および[RFC5936]で説明されています。
In what way is exposing the full contents of a zone a privacy risk? The contents of the zone could include information such as names of persons used in names of hosts. Best practice is not to use personal information for domain names, but many such domain names exist. The contents of the zone could also include references to locations that allow inference about location information of the individuals associated with the zone's organization. It could also include references to other organizations. Examples of this could be:
ゾーンの全内容をどのように公開しているのは、プライバシーリスクをかけていますか？ゾーンの内容には、ホスト名で使用されている人の名前などの情報が含まれています。ベストプラクティスは、ドメイン名に個人情報を使用することではありませんが、そのようなドメイン名が多くあります。ゾーンの内容はまた、ゾーンの組織に関連する個人の位置情報に関する推論を可能にする場所への参照を含み得る。他の組織への参照も含まれます。この例は次のとおりです。
* Person-laptop.example.org
*
* MX-for-Location.example.org
*
* Service-tenant-from-another-org.example.org
*
Additionally, the full zone contents expose all the IP addresses of endpoints held in the DNS records, which can make reconnaissance and attack targeting easier, particularly for IPv6 addresses or private networks. There may also be regulatory, policy, or other reasons why the zone contents in full must be treated as private.
さらに、フルゾーンの内容は、DNSレコードに保持されているエンドポイントのすべてのIPアドレスを公開します。これにより、IPv6アドレスやプライベートネットワークでは、偵察と攻撃のターゲティングを容易にすることができます。ゾーンの内容が完全にプライベートとして扱われなければならないのは、規制、政策、またはその他の理由もあります。
Neither of the RFCs mentioned in [RFC9076] contemplate the risk that someone gets the data through eavesdropping on network connections, only via enumeration or unauthorized transfer, as described in the following paragraphs.
[RFC9076]に記載されているRFCのいずれも、次の段落で説明されているように、ネットワーク接続を盗聴することによって、誰かがネットワーク接続を盗聴することによってデータを取得するリスクを考えています。
Zone enumeration is trivially possible for DNSSEC zones that use NSEC, i.e., queries for the authenticated denial-of-existence records allow a client to walk through the entire zone contents. [RFC5155] specifies NSEC3, a mechanism to provide measures against zone enumeration for DNSSEC-signed zones (a goal was to make it as hard to enumerate a DNSSEC-signed zone as an unsigned zone). Whilst this is widely used, it has been demonstrated that zone walking is possible for precomputed NSEC3 using attacks, such as those described in [NSEC3-attacks]. This prompted further work on an alternative mechanism for DNSSEC-authenticated denial of existence (NSEC5 [NSEC5]); however, questions remain over the practicality of this mechanism.
ゾーン列挙は、NSEC、すなわち認証された存在拒否レコードのクエリを使用するDNSSECゾーンでは、クライアントがゾーンの内容全体を歩くことを可能にするDNSSECゾーンが可能です。[RFC5155] NSEC3、DNSSEC署名ゾーンのゾーン列挙体に対するメカニズムを提供するメカニズムである（目標は、DNSSEC符号ゾーンを符号なしゾーンとして列挙するのは難しくすることでした）。これは広く使用されているが、[NSEC3 - 攻撃]で説明されているものなどの攻撃を使用した事前計算NSEC3のゾーンウォーキングが可能であることが実証されている。これにより、DNSSEC認証済み存在拒否（NSEC5 [NSEC5]）の代替メカニズムについてさらに取り組んだ。しかし、質問はこのメカニズムの実用性に依存しません。
[RFC5155] does not address data obtained outside zone enumeration (nor does [NSEC5]). Preventing eavesdropping of zone transfers (as described in this document) is orthogonal to preventing zone enumeration, though they aim to protect the same information.
[RFC5155]ゾーンの列挙体の外部に取得されたデータをアドレス指定していません（NORD [NSEC5]）。ゾーン転送の盗聴を防ぐ（この文書に記載されているように）ゾーンの列挙を防ぐことは直交していますが、同じ情報を保護することを目的としています。
[RFC5936] specifies using TSIG [RFC8945] for authorization of the clients of a zone transfer and for data integrity but does not express any need for confidentiality, and TSIG does not offer encryption.
[RFC5936]ゾーン転送のクライアントの承認とデータの整合性のためのTSIG [RFC8945]を使用して、機密性の必要性を表明し、TSIGは暗号化を提供しません。
Section 8 of the NIST document "Secure Domain Name System (DNS) Deployment Guide" [NIST-GUIDE] discusses restricting access for zone transfers using Access Control Lists (ACLs) and TSIG in more detail. It also discusses the possibility that specific deployments might choose to use a lower-level network layer to protect zone transfers, e.g., IPsec.
NIST文書の第8章「セキュアドメイン名システム（DNS）展開ガイド」[NISTガイド]は、アクセス制御リスト（ACL）とTSIGをより詳細に使用したゾーン転送のアクセス制限を説明しています。また、特定の展開は、ゾーン転送、例えばIPsecを保護するために下位レベルのネットワーク層を使用することを選択できる可能性についても説明します。
It is noted that in all the common open-source implementations such ACLs are applied on a per-query basis (at the time of writing). Since requests typically occur on TCP connections, authoritative servers must therefore accept any TCP connection and then handle the authentication of each zone transfer (XFR) request individually.
すべての共通のオープンソースの実装では、そのようなACLがクエリごとに適用されます（書き込み時点）。要求は通常TCP接続で発生しているため、権威あるサーバーはTCP接続を受け入れてから、各ゾーン転送（XFR）要求の認証を個別に処理する必要があります。
Because both AXFR (authoritative transfer) and IXFR (incremental zone transfer) are typically carried out over TCP from authoritative DNS protocol implementations, encrypting zone transfers using TLS [RFC8499] -- based closely on DoT [RFC7858] -- seems like a simple step forward. This document specifies how to use TLS (1.3 or later) as a transport to prevent zone collection from zone transfers.
axfr（univertivative transfer）とixfr（incremital zone転送）の両方が、通常、信頼できるDNSプロトコル実装からTCPを介して実行されているため、TLS [RFC8499]を使用した暗号化ゾーン転送 - DOT [RFC7858] - 簡単なステップのようです前方。このドキュメントでは、ゾーン転送からのゾーン収集を防ぐためのトランスポートとしてTLS（1.3以降）を使用する方法を指定します。
This document also updates the previous specifications for zone transfers to clarify and extend them, mainly with respect to TCP usage:
この文書はまた、主にTCP使用法に関して、それらを明確にし拡張するためのゾーン転送のための前の仕様を更新します。
* [RFC1995] (IXFR) and [RFC5936] (AXFR) are both updated to add further specification on efficient use of TCP connections.
* [RFC1995]（IXFR）と[RFC5936]（AXFR）は、TCP接続の効率的な使用に関するさらなる仕様を追加するように更新されます。
* Section 6.2.2 of [RFC7766] ("DNS Transport over TCP - Implementation Requirements") is updated with a new recommendation about the number of connections between a client and server for each transport.
* [RFC7766]のセクション6.2.2（ "DNSトランスポート - 実装要件"）は、トランスポートごとにクライアントとサーバー間の接続数に関する新しい推奨事項で更新されます。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Privacy terminology is as described in Section 3 of [RFC6973].
プライバシーの用語は[RFC6973]のセクション3に記載されているとおりです。
DNS terminology is as described in [RFC8499]. Note that, as in [RFC8499], the terms 'primary' and 'secondary' are used for two servers engaged in zone transfers.
DNS用語は[RFC8499]に記載されているとおりです。[RFC8499]と同様に、ゾーン転送に従事する2つのサーバーに「Primary」と 'Secondary'という用語が使用されます。
DoT: DNS over TLS, as specified in [RFC7858]
DOT：[RFC7858]で指定されているように、TLS上のDNS
XFR over TCP: Used to mean both IXFR over TCP [RFC1995] and AXFR over TCP [RFC5936]
XFR over TCP：TCP [RFC1995]とAXFRの両方を意味するTCP [RFC5936]
XoT: XFR-over-TLS mechanisms, as specified in this document, which apply to both AXFR over TLS and IXFR over TLS (XoT is pronounced 'zot' since X here stands for 'zone transfer')
XOT：TLSを介してTLSとIXFRを介してAXFRに適用されるこのドキュメントで指定されているXFR-OVER-TLSメカニズムは、TLSを介してTLSとIXFRを介して適用されます（XOTは「ZOT」は「ゾーン転送」を表します）。
AXoT: AXFR over TLS
Axot：TLS上のAXFR
IXoT: IXFR over TLS
IXOT：TLS以上のIXFR
The threat model considered here is one where the current contents and size of the zone are considered sensitive and should be protected during transfer.
ここで考慮されている脅威モデルは、ゾーンの現在の内容とサイズが敏感であると見なされ、転送中に保護されるべきです。
The threat model does not, however, consider the existence of a zone, the act of zone transfer between two entities, nor the identities of the name servers hosting a zone (including both those acting as hidden primaries/secondaries or directly serving the zone) as sensitive information. The proposed mechanism does not attempt to obscure such information. The reasons for this include:
しかし、脅威モデルは、ゾーンの存在、2つのエンティティ間のゾーン転送の行為、ゾーンをホストするネームサーバの識別情報（隠された原色/第二区分としてのゾーンを直接処理する）の識別情報を考慮していません。機密情報として。提案されたメカニズムはそのような情報を不明瞭にしようとしません。その理由は次のとおりです。
* much of this information can be obtained by various methods, including active scanning of the DNS, and
* この情報の多くは、DNSのアクティブスキャンを含むさまざまな方法で入手できます。
* an attacker who can monitor network traffic can rather easily infer relations between name servers simply from traffic patterns, even when some or all of the traffic is encrypted (in terms of current deployments).
* ネットワークトラフィックを監視できる攻撃者は、トラフィックの一部または全部が暗号化されていても（現在の展開に関して）、単にトラフィックパターンからの関係を簡単に簡単に推測できます。
The model does not consider attacks on the mechanisms that trigger a zone transfer, e.g., NOTIFY messages.
モデルは、ゾーン転送を引き起こすメカニズムに対する攻撃を考慮していません。
It is noted that simply using XoT will indicate a desire by the zone owner that the contents of the zone remain confidential and so could be subject to blocking (e.g., via blocking of port 853) if an attacker had such capabilities. However, this threat is likely true of any such mechanism that attempts to encrypt data passed between name servers, e.g., IPsec.
XOTを使用するだけでは、ゾーンの内容が機密のままであり、攻撃者がそのような機能を持っていた場合（例えば、ポート853のブロッキングを介して）ブロッキングの影響を受ける可能性があることが単にゾーン所有者による要望を示すことに留意されたい。ただし、この脅威は、ネームサーバー、例えばIPsecの間で渡されたデータを暗号化しようとするそのようなメカニズムのどんなメカニズムにも当てはまります。
The following principles were considered in the design for XoT:
次の原則がXOTの設計で検討されました。
Confidentiality: Clearly using an encrypted transport for zone transfers will defeat zone content leakage that can occur via passive surveillance.
機密性：ゾーン転送のための暗号化されたトランスポートをはっきりと使用すると、パッシブサーベイランスによって発生する可能性があるゾーンのコンテンツの漏洩が軽減されます。
Authentication: Use of single or mutual TLS (mTLS) authentication (in combination with ACLs) can complement and potentially be an alternative to TSIG.
認証：単一または相互TLS（MTLS）認証（ACLと組み合わせて）の使用は、TSIGに代わるものとなる可能性があります。
Performance: * Existing AXFR and IXFR mechanisms have the burden of backwards compatibility with older implementations based on the original specifications in [RFC1034] and [RFC1035]. For example, some older AXFR servers don't support using a TCP connection for multiple AXFR sessions or XFRs of different zones because they have not been updated to follow the guidance in [RFC5936]. Any implementation of XoT would obviously be required to implement optimized and interoperable transfers, as described in [RFC5936], e.g., transfer of multiple zones over one connection.
パフォーマンス：*既存のAXFRおよびIXFRメカニズムは、[RFC1034]の元の仕様と[RFC1035]に基づいて、古い実装との後方互換性の負担を持っています。たとえば、いくつかの古いAXFRサーバーは、[RFC5936]のガイダンスに従って更新されていないため、さまざまなゾーンの複数のAXFRセッションまたはXFRのTCP接続を使用していません。XOTの任意の実装は、[RFC5936]、例えば1つの接続にわたる複数のゾーンの転送で説明されているように、最適化された相互運用可能な転送を実装することが明らかに必要とされるでしょう。
* Current usage of TCP for IXFR is suboptimal in some cases, i.e., connections are frequently closed after a single IXFR.
* IXFRのためのTCPの電流使用は、場合によっては、すなわち接続が単一のIXFRの後に頻繁に閉じられる。
The original specification for zone transfers in [RFC1034] and [RFC1035] was based on a polling mechanism: a secondary performed a periodic query for the SOA (start of zone authority) record (based on the refresh timer) to determine if an AXFR was required.
[RFC1034]と[RFC1035]のゾーン転送の元の仕様はポーリングメカニズムに基づいていました。次のものは、axfrがあったかどうかを判断するためにSOA（ゾーン局の開始）レコード（リフレッシュタイマに基づく）レコードの周期的なクエリを実行しました。必要。
[RFC1995] and [RFC1996] introduced the concepts of IXFR and NOTIFY, respectively, to provide for prompt propagation of zone updates. This has largely replaced AXFR where possible, particularly for dynamically updated zones.
[RFC1995]および[RFC1996]は、IXFRの概念を導入し、それぞれゾーンアップデートのプロンプト伝播を提供します。これは、可能な限り、特に動的に更新されたゾーンに対して、可能な限りAXFRを大部分置き換えました。
[RFC5936] subsequently redefined the specification of AXFR to improve performance and interoperability.
[RFC5936]続いてAXFRの仕様を再定義して、性能と相互運用性を向上させました。
In this document, the term 'XFR mechanism' is used to describe the entire set of message exchanges between a secondary and a primary that concludes with a successful AXFR or IXFR request/response. This set may or may not include:
この文書では、「XFRメカニズム」という用語は、成功したaxfrまたはixfr要求/応答で終わるセカンダリとプライマリとの間のメッセージ交換の全セットを記述するために使用される。このセットは次のように設定されている場合があります。
* NOTIFY messages
* メッセージを通知します
* SOA queries
* SOAクエリ
* Fallback from IXFR to AXFR
* IXFRからAXFRへのフォールバック
* Fallback from IXFR over UDP to IXFR over TCP
* TCP上のUDPからIXFRへのIXFRからのフォールバック
The term is used to encompass the range of permutations that are possible and is useful to distinguish the 'XFR mechanism' from a single XFR request/response exchange.
この用語は、可能な順列の範囲を網羅するために使用され、「XFRメカニズム」を単一のXFR要求/応答交換から区別するのに役立ちます。
The figure below provides an outline of an AXFR mechanism including NOTIFYs.
以下の図は、Notifysを含むAXFR機構の概要を示しています。
Secondary Primary
二次初代
| NOTIFY |
| <-------------------------------- | UDP
| --------------------------------> |
| NOTIFY Response |
| |
| |
| SOA Request |
| --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP session)
| SOA Response |
| |
| |
| |
| AXFR Request | ---
| --------------------------------> | |
| <-------------------------------- | |
| AXFR Response 1 | |
| (Zone data) | |
| | |
| <-------------------------------- | | TCP
| AXFR Response 2 | | Session
| (Zone data) | |
| | |
| <-------------------------------- | |
| AXFR Response 3 | |
| (Zone data) | ---
| |
Figure 1: AXFR Mechanism
図1：AXFR機構
1. An AXFR is often (but not always) preceded by a NOTIFY (over UDP) from the primary to the secondary. A secondary may also initiate an AXFR based on a refresh timer or scheduled/triggered zone maintenance.
1. AXFRは、（常にUDP over UDP）の前に、プライマリからセカンダリまでの前に（常に常にはありません）。二次は、リフレッシュタイマまたはスケジュール/トリガゾーンのメンテナンスに基づいてAXFRを開始することができる。
2. The secondary will normally (but not always) make an SOA query to the primary to obtain the serial number of the zone held by the primary.
2. 二次は正常に（常にそうではありません）プライマリに保持されているゾーンのシリアル番号を取得するために、プライマリへのSOAクエリを作成します。
3. If the primary serial is higher than the secondary's serial (using Serial Number Arithmetic [RFC1982]), the secondary makes an AXFR request (over TCP) to the primary, after which the AXFR data flows in one or more AXFR responses on the TCP connection. [RFC5936] defines this specific step as an 'AXFR session', i.e., as an AXFR query message and the sequence of AXFR response messages returned for it.
3. プライマリシリアルがセカンダリのシリアル（シリアル番号算術演算[RFC1982]を使用）より高い場合、2次はPRIMATEにAXFR要求（TCPを介して）をプライマリにします。その後、AXFRデータはTCP接続で1つ以上のAXFR応答に流れます。。[RFC5936]この特定のステップを 'axfrセッション'、すなわちAXFRクエリメッセージとして、それに返されたAXFR応答メッセージのシーケンスとして定義します。
[RFC5936] re-specified AXFR, providing additional guidance beyond that provided in [RFC1034] and [RFC1035] and importantly specified that AXFR must use TCP as the transport protocol.
[RFC5936] AXFRを再指定し、[RFC1034]と[RFC1035]で提供されている追加のガイダンスを提供し、AXFRがTCPをトランスポートプロトコルとして使用しなければならないことをお知らせします。
Additionally, Sections 4.1, 4.1.1, and 4.1.2 of [RFC5936] provide improved guidance for AXFR clients and servers with regard to reuse of TCP connections for multiple AXFRs and AXFRs of different zones. However, [RFC5936] was constrained by having to be backwards compatible with some very early basic implementations of AXFR. For example, it outlines that the SOA query can also happen on this connection. However, this can cause interoperability problems with older implementations that support only the trivial case of one AXFR per connection.
さらに、[RFC5936]のセクション4.1,4.1.1、および4.1.2は、AXFRクライアントおよびサーバーのためのガイダンスを提供し、異なるゾーンの複数のAXFRとAXFRのTCP接続の再利用に関して。しかしながら、[RFC5936]は、AXFRのいくつかの非常に早期の基本的な実装と逆方向に互換性がある必要がある必要があることによって制約されました。たとえば、SOAクエリもこの接続で発生する可能性があることを概説します。ただし、これにより、接続ごとに1つのAXFRの些細な場合のみをサポートする古い実装に関する相互運用性の問題が発生する可能性があります。
The figure below provides an outline of the IXFR mechanism including NOTIFYs.
以下の図は、Notifysを含むIXFRメカニズムの概要を示しています。
Secondary Primary
二次初代
| NOTIFY |
| <-------------------------------- | UDP
| --------------------------------> |
| NOTIFY Response |
| |
| |
| SOA Request |
| --------------------------------> | UDP or TCP
| <-------------------------------- |
| SOA Response |
| |
| |
| |
| IXFR Request |
| --------------------------------> | UDP or TCP
| <-------------------------------- |
| IXFR Response |
| (Zone data) |
| |
| | ---
| IXFR Request | |
| --------------------------------> | | Retry over
| <-------------------------------- | | TCP if
| IXFR Response | | required
| (Zone data) | ---
Figure 2: IXFR Mechanism
図2：IXFRメカニズム
1. An IXFR is normally (but not always) preceded by a NOTIFY (over UDP) from the primary to the secondary. A secondary may also initiate an IXFR based on a refresh timer or scheduled/triggered zone maintenance.
1. IXFRは通常、1次からセカンダリへの通知（UDP over UDP）が先行しています。二次は、リフレッシュタイマまたはスケジュール/トリガゾーンのメンテナンスに基づいてIXFRを開始することができる。
2. The secondary will normally (but not always) make an SOA query to the primary to obtain the serial number of the zone held by the primary.
2. 二次は正常に（常にそうではありません）プライマリに保持されているゾーンのシリアル番号を取得するために、プライマリへのSOAクエリを作成します。
3. If the primary serial is higher than the secondary's serial (using Serial Number Arithmetic [RFC1982]), the secondary makes an IXFR request to the primary, after which the primary sends an IXFR response.
3. プライマリシリアルがセカンダリのシリアル（シリアル番号算術演算[RFC1982]を使用）より高い場合、2次はプライマリへのIXFR要求を行います。その後、プライマリはIXFR応答を送信します。
[RFC1995] specifies that IXFR may use UDP if the entire IXFR response can be contained in a single DNS packet, otherwise, TCP is used. In fact, it says:
[RFC1995] IXFRの応答全体を単一のDNSパケットに含めることができる場合、IXFRがUDPを使用できるように指定します。それ以外の場合は、TCPが使用されます。実際、それは言う：
| Thus, a client should first make an IXFR query using UDP.
| ..したがって、クライアントは最初にUDPを使用してIXFRクエリを作成する必要があります。
So there may be a fourth step above where the client falls back to IXFR over TCP. There may also be an additional step where the secondary must fall back to AXFR because, e.g., the primary does not support IXFR.
そのため、TCPの上でクライアントがIXFRに戻る4番目のステップがあります。例えば、1次がIXFRをサポートしていないので、二次がAXFRに立ち返らなければならない追加のステップもあり得る。
However, it is noted that most of the widely used open-source implementations of authoritative name servers (including both [BIND] and [NSD]) do IXFR using TCP by default in their latest releases. For BIND, TCP connections are sometimes used for SOA queries, but, in general, they are not used persistently and are closed after an IXFR is completed.
ただし、正式なネームサーバーの広く使用されているオープンソースの実装の大部分（BIND]と[NSD]の両方を含む）は、最新のリリースではTCPを使用してIXFRを使用します。バインドの場合、TCP接続はSOAクエリに使用されることがありますが、一般に、それらは永続的に使用されず、IXFRが完了した後に閉じられます。
This section presents a rationale for considering the encryption of the other messages in the XFR mechanism.
このセクションでは、XFRメカニズム内の他のメッセージの暗号化を考慮するための根拠を示します。
Since the SOA of the published zone can be trivially discovered by simply querying the publicly available authoritative servers, leakage of this resource record (RR) via such a direct query is not discussed in the following sections.
公開されたゾーンのSOAは、公的に利用可能な権限サーバーを単純に照会することによって、このような直接問合せを介したこのリソース・レコードの漏洩については、次のセクションで説明されていません。
Unencrypted NOTIFY messages identify configured secondaries on the primary.
暗号化されていない通知メッセージは、プライマリ上の設定された2次元を識別します。
[RFC1996] also states:
[RFC1996]も次のとおりです。
| If ANCOUNT>0, then the answer section represents an unsecure hint | at the new RRset for this <QNAME,QCLASS,QTYPE>.
| ..Angount> 0の場合、回答セクションは安全でないヒントを表します。この<qname、qclass、qtype>の新しいRRセットで。
But since the only query type (QTYPE) for NOTIFY defined at the time of this writing is SOA, this does not pose a potential leak.
しかし、この書き込み時に定義された通知のための唯一のクエリタイプ（QType）はSOAであるため、これは潜在的なリークを引き起こさない。
For hidden XFR servers (either primaries or secondaries), an SOA response directly from that server only additionally leaks the degree of SOA serial number lag of any downstream secondary of that server.
隠しXFRサーバー（原原則または2番目の）の場合、そのサーバーから直接SOAレスポンスはそのサーバーの下流の任意の下流のSOAシリアル番号遅れの程度をさらにリークします。
For convenience, the term 'XFR over TCP' is used in this document to mean both IXFR over TCP and AXFR over TCP; therefore, statements that use that term update both [RFC1995] and [RFC5936] and implicitly also apply to XoT. Differences in behavior specific to XoT are discussed in Section 7.
便宜上、この文書では「XFR over TCP」という用語がこの文書では、TCP上でのIXFRとTCPを介してAXFRの両方を意味します。したがって、その用語を更新するステートメントは、[RFC1995]と[RFC5936]の両方を使用し、暗黙的にもXOTに適用されます。XOTに固有の動作の違いは、セクション7で説明されています。
Both [RFC1995] and [RFC5936] were published sometime before TCP became a widely supported transport for DNS. [RFC1995], in fact, says nothing with respect to optimizing IXFRs over TCP or reusing already open TCP connections to perform IXFRs or other queries. Therefore, there arguably is an implicit assumption that a TCP connection is used for one and only one IXFR request. Indeed, many major open-source implementations take this approach (at the time of this writing). And whilst [RFC5936] gives guidance on connection reuse for AXFR, it predates more recent specifications describing persistent TCP connections (e.g., [RFC7766], [RFC7828]), and AXFR implementations again often make less-than-optimal use of open connections.
TCPがDNSのための広くサポートされている輸送になった前に、[RFC1995]と[RFC5936]の両方がいつか公開されました。[RFC1995]は、実際には、TCPを介したIXFRSを最適化すること、またはIXFRまたは他のクエリを実行するためにすでに開いているTCP接続を再利用することに関して何も言いません。したがって、間違いなく、TCP接続が1つのIXFR要求のみに使用されることを暗黙的に仮定することです。実際、多くの主要なオープンソースの実装はこのアプローチを取ります（この書き込み時に）。そして、[RFC5936]がAXFRの接続再利用に関するガイダンスを与えますが、永続的なTCP接続（例えば、[RFC7766]、[RFC7828]）を記述するより最近の仕様、およびAXFRの実装を再び開放接続の最適な使用を頻繁に使用することを述べています。
Given this, new implementations of XoT will clearly benefit from specific guidance on TCP/TLS connection usage for XFR, because this will:
これを考えると、XOTの新しい実装は、これはXFRのTCP / TLS接続使用法に関する特定のガイダンスから明らかに利益を得るでしょう。
* result in more consistent XoT implementations with better interoperability and
* 相互運用性が向上したより一貫したXOT実装をもたらします。
* remove any need for XoT implementations to support legacy behavior for XoT connections that XFR-over-TCP implementations have historically often supported.
* XOTの実装の必要性をすべて削除して、XOT接続のレガシー動作をサポートし、XFFR-over-TCP実装が歴史的にサポートされていることがよくあります。
Therefore, this document updates both the previous specifications for XFR over TCP ([RFC1995] and [RFC5936]) to clarify that:
したがって、この文書は、TCP over TCP（[RFC1995]および[RFC5936]）の前の仕様の両方を更新して、次のことを明確にします。
* Implementations MUST use [RFC7766] ("DNS Transport over TCP - Implementation Requirements") to optimize the use of TCP connections.
* TCP接続の使用を最適化するために、実装は[RFC7766]（「DNSトランスポート - 実装要件」）を使用する必要があります。
* Whilst [RFC7766] states that "DNS clients SHOULD pipeline their queries" on TCP connections, it did not distinguish between XFRs and other queries for this behavior. It is now recognized that XFRs are not as latency sensitive as other queries and can be significantly more complex for clients to handle, both because of the large amount of state that must be kept and because there may be multiple messages in the responses. For these reasons, it is clarified here that a valid reason for not pipelining queries is when they are all XFR queries, i.e., clients sending multiple XFRs MAY choose not to pipeline those queries. Clients that do not pipeline XFR queries therefore have no additional requirements to handle out-of-order or intermingled responses (as described later), since they will never receive them.
* [RFC7766]は、TCP接続で「DNSクライアントは自分のクエリをパイプラインする必要がある」と述べているため、この動作のXFRと他のクエリを区別しませんでした。これは、XFRSが他のクエリほど待ち時間に敏感ではなく、保持されなければならない大量の状態のために、クライアントが扱うために依然として扱われるのにかなり複雑であることが認識されています。これらの理由から、クエリをパイプライン化されていないという有効な理由は、それらがすべてXFRクエリ、すなわち複数のXFRを送信するクライアントがそれらのクエリをパイプラインにしないように選択することができることが明確にされている。したがって、パイプラインXFRクエリを照会しないクライアントは、それらが決して受信することは決してないので、順序外または混在している応答を処理するための追加の要件はありません。
* Implementations SHOULD use the edns-tcp-keepalive EDNS(0) option [RFC7828] to manage persistent connections. This is more flexible than the alternative of simply using fixed timeouts.
* 実装は、永続的な接続を管理するためにEDNS-TCP-KeepAlive EDNS（0）オプション[RFC7828]を使用する必要があります。これは、単に固定タイムアウトを使用する代わりの代替手段よりも柔軟です。
The following sections include detailed clarifications on the updates to XFR behavior implied in [RFC7766] and how the use of [RFC7828] applies specifically to XFR exchanges. They also discuss how IXFR and AXFR can reuse the same TCP connection.
次のセクションでは、[RFC7766]で暗示されたXFR動作の更新に関する詳細な説明と、[RFC7828]の使用方法がXFR交換に特に適用されています。また、ixfrとaxfrが同じTCP接続を再利用できる方法についても説明します。
For completeness, the recent specification of extended DNS error (EDE) codes [RFC8914] is also mentioned here. For zone transfers, when returning REFUSED to a zone transfer request from an 'unauthorized' client (e.g., where the client is not listed in an ACL for zone transfers or does not sign the request with a valid TSIG key), the extended DNS error code 18 - Prohibited can also be sent.
完全性のために、最近の拡張DNSエラー（EDE）コード[RFC8914]の仕様もここに記載されています。ゾーン転送の場合、ゾーン転送の場合は、「不正な」クライアントからのゾーン転送要求を拒否した場合（たとえば、クライアントがゾーン転送のACLに表示されていないか、有効なTSIGキーを使用して要求に署名しない場合）、拡張DNSエラーコード18 - 禁止されています。
For clarity, an IXFR-over-TCP server compliant with this specification MUST be able to handle multiple concurrent IXoT requests on a single TCP connection (for the same and different zones) and SHOULD send the responses as soon as they are available, which might be out of order compared to the requests.
明確にするために、この仕様に準拠したIXFR-over TCPサーバーは、単一のTCP接続（同じゾーン用の）で複数の同時IXOT要求を処理できなければなりません（同じ、異なるゾーン用）、使用可能な限りすぐに応答を送信する必要があります。要求と比較して故障してください。
For clarity, an AXFR-over-TCP server compliant with this specification MUST be able to handle multiple concurrent AXoT sessions on a single TCP connection (for the same and different zones). The response streams for concurrent AXFRs MAY be intermingled, and AXFR-over-TCP clients compliant with this specification, which pipeline AXFR requests, MUST be able to handle this.
明確にするために、この仕様に準拠したAXFR-over TCPサーバーは、単一のTCP接続（同じゾーン用の）で複数の同時アクションセッションを処理できる必要があります。並行AXFRの応答ストリームは、この仕様に準拠したAXFR-over TCPクライアントがこの仕様に準拠している可能性があります。この仕様は、これを処理できる必要があります。
As specified, XFR-over-TCP clients SHOULD reuse any existing open TCP connection when starting any new XFR request to the same primary, and for issuing SOA queries, instead of opening a new connection. The number of TCP connections between a secondary and primary SHOULD be minimized (also see Section 6.4).
指定されているように、XFR-over-TCPクライアントは、新しいXFR要求を同じプライマリに開始するとき、および新しい接続を開くのではなく、SOAクエリを発行するときに、既存のオープンTCP接続を再利用する必要があります。セカンダリとプライマリ間のTCP接続の数を最小限に抑える必要があります（6.4項も参照）。
Valid reasons for not reusing existing connections might include:
既存の接続を再利用しない有効な理由は次のとおりです。
* As already noted in [RFC7766], separate connections for different zones might be preferred for operational reasons. In this case, the number of concurrent connections for zone transfers SHOULD be limited to the total number of zones transferred between the client and server.
* [RFC7766]で既に述べたように、異なるゾーンに対する個別の接続が操作上の理由から推奨される可能性があります。この場合、ゾーン転送の同時接続の数は、クライアントとサーバー間で転送されたゾーンの総数に制限されるべきです。
* A configured limit for the number of outstanding queries or XFR requests allowed on a single TCP connection has been reached.
* 単一のTCP接続で許可されている未処理クエリまたはXFR要求の数に設定された制限が達成されました。
* The message ID pool has already been exhausted on an open connection.
* メッセージIDプールはすでにオープン接続で使い果たされています。
* A large number of timeouts or slow responses have occurred on an open connection.
* 開いている接続で多数のタイムアウトまたは遅い応答が発生しました。
* An edns-tcp-keepalive EDNS(0) option with a timeout of 0 has been received from the server, and the client is in the process of closing the connection (see Section 6.3.4).
* 0のタイムアウトを持つEDNS-TCP-KeepAlive EDNS（0）オプションがサーバーから受信され、クライアントは接続を閉じるプロセスにあります（6.3.4項を参照）。
If no TCP connections are currently open, XFR clients MAY send SOA queries over UDP or a new TCP connection.
TCP接続が現在開いていない場合、XFRクライアントはUDPまたは新しいTCP接続を介してSOAクエリを送信することができます。
Neither [RFC1995] nor [RFC5936] explicitly discuss the use of a single TCP connection for both IXFR and AXFR requests. [RFC5936] does make the general statement:
[RFC1995] NOR [RFC5936]も、IXFR要求とAXFR要求の両方に対する単一のTCP接続の使用について明示的に説明しません。[RFC5936]一般的な文を作成します。
| Non-AXFR session traffic can also use an open connection.
| ..AXFR以外のセッショントラフィックは、オープン接続も使用できます。
In this document, the above is clarified to indicate that implementations capable of both AXFR and IXFR and compliant with this specification SHOULD:
この文書では、AXFRとIXFRの両方が可能で、この仕様に準拠している実装ができることを示すために上記を明確にしています。
* use the same TCP connection for both AXFR and IXFR requests to the same primary,
* AXFR要求とIXFR要求の両方に同じTCP接続を使用します。
* pipeline such requests (if they pipeline XFR requests in general) and MAY intermingle them, and
* そのようなリクエスト（彼らが一般的にXFRをリクエストする場合）とそれらを混乱させる可能性がある場合、
* send the response(s) for each request as soon as they are available, i.e., responses MAY be sent intermingled.
* それらが利用可能になるとすぐに各要求の応答を送信する、すなわち、回答が混在していることがある。
For some current implementations, adding all the above functionality would introduce significant code complexity. In such a case, there will need to be an assessment of the trade-off between that and the performance benefits of the above for XFR.
現在の実装では、上記のすべての機能を追加すると、大きなコードの複雑さが導入されます。そのような場合、XFRについて上記のものとの間のトレードオフの評価となる必要があります。
The server MAY limit the number of concurrent IXFRs, AXFRs, or total XFR transfers in progress (or from a given secondary) to protect server resources. Servers SHOULD return SERVFAIL if this limit is hit, since it is a transient error and a retry at a later time might succeed (there is no previous specification for this behavior).
サーバーは、サーバーリソースを保護するために、並行IXFR、AXFR、または合計XFR転送中（または特定のセカンダリから）の数を制限することがあります。この制限がヒットされている場合、サーバーはSERVFAILを返し、後で再試行が成功する可能性があります（この動作には以前の仕様はありません）。
XFR clients that send the edns-tcp-keepalive EDNS(0) option on every XFR request provide the server with maximum opportunity to update the edns-tcp-keepalive timeout. The XFR server may use the frequency of recent XFRs to calculate an average update rate as input to the decision of what edns-tcp-keepalive timeout to use. If the server does not support edns-tcp-keepalive, the client MAY keep the connection open for a few seconds ([RFC7766] recommends that servers use timeouts of at least a few seconds).
EDNS-TCP-KeepAlive EDNS（0）オプションをすべてのXFR要求に送信するXFRクライアントは、EDNS-TCP-KeepAliveタイムアウトを更新するために最大の機会を提供します。XFRサーバーは最近のXFRの周波数を使用して、使用するEDNS-TCP-KeepAliveタイムアウトの決定への平均更新レートを計算することができます。サーバーがEDNS-TCP-KeepAliveをサポートしていない場合、クライアントは数秒間接続を開くことがあります（[RFC7766]は、サーバーが少なくとも数秒のタイムアウトを使用することをお勧めします）。
Whilst the specification for EDNS(0) [RFC6891] does not specifically mention AXFRs, it does say:
EDNS（0）の仕様（RFC6891]は特にAXFRに言及していないが、それは言う：
| If an OPT record is present in a received request, compliant
| responders MUST include an OPT record in their respective
| responses.
In this document, the above is clarified to indicate that if an OPT record is present in a received AXFR request, compliant responders MUST include an OPT record in each of the subsequent AXFR responses. Note that this requirement, combined with the use of edns-tcp-keepalive, enables AXFR servers to signal the desire to close a connection (when existing transactions have competed) due to low resources by sending an edns-tcp-keepalive EDNS(0) option with a timeout of 0 on any AXFR response. This does not signal that the AXFR is aborted, just that the server wishes to close the connection as soon as possible.
この文書では、OPTレコードが受信されたAXFR要求に存在する場合、準拠した応答者は、後続のAXFR応答のそれぞれにOPTレコードを含める必要があることを明確にしています。この要件は、EDNS-TCP-KeepAliveの使用と組み合わされて、AXFRサーバーが接続を閉じるという希望をシグナリングしたい（既存のトランザクションが競合した場合）EDNS-TCP-KeepAlive EDN（0）を送信することによって低いリソースの影響を受けることができます。AXFRレスポンスでは0のタイムアウトのオプション。これは、AXFRが中止されていることは、できるだけ早く接続を閉じたいというわけではない。
Certain legacy behaviors were noted in [RFC5936], with provisions that implementations may want to offer options to fallback to legacy behavior when interoperating with servers known to not support [RFC5936]. For purposes of interoperability, IXFR and AXFR implementations may want to continue offering such configuration options, as well as supporting some behaviors that were underspecified prior to this work (e.g., performing IXFR and AXFRs on separate connections). However, XoT connections should have no need to do so.
特定の従来の動作は[RFC5936]に記載されていましたが、実装では、サポートされていないサーバーと相互運用したときにレガシーの動作にフォールバックするオプションを提供することができます[RFC5936]。相互運用性の目的のために、IXFRおよびAXFRの実装は、そのような構成オプションを提供し続けることができ、およびこの作業の前には不明のいくつかの動作をサポートすることを望み、（例えば、別々の接続でIXFRおよびAXFRを実行する）。ただし、XOT接続はそうする必要はありません。
[RFC7766] made general implementation recommendations with regard to TCP/TLS connection handling:
[RFC7766] TCP / TLS接続処理に関して一般的な実装の推奨事項を作成しました。
| To mitigate the risk of unintentional server overload, DNS clients
| MUST take care to minimize the number of concurrent TCP
| connections made to any individual server. It is RECOMMENDED that
| for any given client/server interaction there SHOULD be no more
| than one connection for regular queries, one for zone transfers,
| and one for each protocol that is being used on top of TCP (for
| example, if the resolver was using TLS). However, it is noted
| that certain primary/ secondary configurations with many busy
| zones might need to use more than one TCP connection for zone
| transfers for operational reasons (for example, to support
| concurrent transfers of multiple zones).
Whilst this recommends a particular behavior for the clients using TCP, it does not relax the requirement for servers to handle 'mixed' traffic (regular queries and zone transfers) on any open TCP/TLS connection. It also overlooks the potential that other transports might want to take the same approach with regard to using separate connections for different purposes.
これは、TCPを使用しているクライアントの特定の動作をお勧めしますが、開いているTCP / TLS接続では、「混在」トラフィック（通常のクエリとゾーン転送）を処理するための要件を緩和することはできません。それはまた、他の輸送が異なる目的のための別々の接続を使用することに関して同じアプローチを取りたいと思う可能性がある可能性もあります。
This specification updates the above general guidance in [RFC7766] to provide the same separation of connection purpose (regular queries and zone transfers) for all transports being used on top of TCP.
この仕様は、TCPの上で使用されているすべてのトランスポートの接続目的（通常のクエリとゾーン転送）の分離を提供するために、[RFC7766]の上記の一般的なガイダンスを更新します。
Therefore, it is RECOMMENDED that for each protocol used on top of TCP in any given client/server interaction there SHOULD be no more than one connection for regular queries and one for zone transfers.
したがって、特定のクライアント/サーバーの対話でTCPの上で使用されている各プロトコルの場合、通常のクエリとゾーン転送用に1つずつ接続されている必要があります。
As an illustration, it could be imagined that in the future such an interaction could hypothetically include one or all of the following:
図として、将来的にはそのような対話が次のうちの1つまたはすべてを含むことができると想像された。
* one TCP connection for regular queries
* 通常のクエリのための1つのTCP接続
* one TCP connection for zone transfers
* ゾーン転送のための1つのTCP接続
* one TLS connection for regular queries
* 通常のクエリのための1つのTLS接続
* one TLS connection for zone transfers
* ゾーン転送のための1つのTLS接続
* one DoH connection for regular queries
* 定期的なクエリに対する1つのDOH接続
* one DoH connection for zone transfers
* ゾーン転送のための1つのDOH接続
Section 6.3.1 provides specific details of the reasons why more than one connection for a given transport might be required for zone transfers from a particular client.
セクション6.3.1は、特定のクライアントからのゾーン転送に特定のトランスポートに対する複数の接続が必要になる可能性がある理由の具体的な詳細を示しています。
During connection establishment, the Application-Layer Protocol Negotiation (ALPN) token "dot" [DoT-ALPN] MUST be selected in the TLS handshake.
接続確立中に、アプリケーション層プロトコルネゴシエーション（ALPN）トークン「ドット」[DOT-ALPN]をTLSハンドシェイクで選択する必要があります。
All implementations of this specification MUST use only TLS 1.3 [RFC8446] or later.
この仕様のすべての実装はTLS 1.3 [RFC8446]以降だけを使用する必要があります。
The connection for XoT SHOULD be established using port 853, as specified in [RFC7858], unless there is mutual agreement between the primary and secondary to use a port other than port 853 for XoT. There MAY be agreement to use different ports for AXoT and IXoT or for different zones.
XOTのポート853以外のポートを使用するためにプライマリとセカンダリの間に相互合意がない限り、[RFC7858]で指定されているように、XOTの接続は、ポート853を使用して確立されます。AxotやIxotや異なるゾーンにさまざまなポートを使用するための合意があるかもしれません。
It is useful to note that in XoT it is the secondary that initiates the TLS connection to the primary for an XFR request so that, in terms of connectivity, the secondary is the TLS client and the primary is the TLS server.
XOTでは、XFR要求に対してプライマリへのTLS接続を開始するセカンダリであることに注意して、接続性の観点から、セカンダリはTLSクライアントであり、プライマリがTLSサーバーです。
The figure below provides an outline of the AXoT mechanism including NOTIFYs.
以下の図は、Notifysを含むアクションメカニズムの概要を示しています。
Secondary Primary
二次初代
| NOTIFY |
| <-------------------------------- | UDP
| --------------------------------> |
| NOTIFY Response |
| |
| |
| SOA Request |
| --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP/TLS session)
| SOA Response |
| |
| |
| |
| AXFR Request | ---
| --------------------------------> | |
| <-------------------------------- | |
| AXFR Response 1 | |
| (Zone data) | |
| | |
| <-------------------------------- | | TLS
| AXFR Response 2 | | Session
| (Zone data) | |
| | |
| <-------------------------------- | |
| AXFR Response 3 | |
| (Zone data) | ---
| |
Figure 3: AXoT Mechanism
図3：アクソット機構
The figure below provides an outline of the IXoT mechanism including NOTIFYs.
以下の図は、Notifysを含むIXOTメカニズムの概要を示しています。
Secondary Primary
二次初代
| NOTIFY |
| <-------------------------------- | UDP
| --------------------------------> |
| NOTIFY Response |
| |
| |
| SOA Request |
| --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP/TLS session)
| SOA Response |
| |
| |
| |
| IXFR Request | ---
| --------------------------------> | |
| <-------------------------------- | |
| IXFR Response | |
| (Zone data) | |
| | | TLS
| | | session
| IXFR Request | |
| --------------------------------> | |
| <-------------------------------- | |
| IXFR Response | |
| (Zone data) | ---
Figure 4: IXoT Mechanism
図4：IXOTメカニズム
For a zone transfer between two endpoints to be considered protected with XoT, all XFR requests and responses for that zone MUST be sent over TLS connections, where at a minimum:
XOTで保護される2つのエンドポイント間のゾーン転送の場合、そのゾーンに対するすべてのXFR要求と応答は、最小限にあります。
* The client MUST authenticate the server by use of an authentication domain name using a Strict Privacy profile, as described in [RFC8310].
* [RFC8310]で説明されているように、クライアントは、厳密なプライバシープロファイルを使用して認証ドメイン名を使用してサーバーを認証する必要があります。
* The server MUST validate the client is authorized to request or proxy a zone transfer by using one or both of the following methods:
* サーバーは、クライアントを検証する必要があります。次の方法の一方または両方を使用して、ゾーン転送を要求またはプロキシを実行することができます。
- mutual TLS (mTLS)
- 相互TLS（MTLS）
- an IP-based ACL (which can be either per message or per connection) combined with a valid TSIG/SIG(0) signature on the XFR request
- XFRリクエストの有効なTSIG / SIG（0）署名と組み合わせたIPベースのACL（メッセージごとまたは1接続にすることができます）
If only one method is selected, then mTLS is preferred because it provides strong cryptographic protection at both endpoints.
1つのメソッドのみが選択されている場合は、両方のエンドポイントで強力な暗号保護を提供するため、MTLSが優先されます。
Authentication mechanisms are discussed in full in Section 9, and the rationale for the above requirement is discussed in Section 10. Transfer group policies are discussed in Section 11.
認証メカニズムについてはセクション9で全文で説明し、上記の要件の根拠はセクション10で説明されています。転送グループポリシーについては、11章で説明します。
The details in Section 6 about, e.g., persistent connections and XFR message handling, are fully applicable to XoT connections as well. However, any behavior specified here takes precedence for XoT.
例えば、永続的な接続およびXFRメッセージ処理について、セクション6の詳細は、XOT接続にも完全に適用可能である。ただし、ここで指定された動作はXOTに優先されます。
If no TLS connections are currently open, XoT clients MAY send SOA queries over UDP, TCP, or TLS.
現在開いているTLS接続がない場合、XOTクライアントはUDP、TCP、またはTLSを介してSOAクエリを送信することがあります。
As noted earlier, there is currently no specification for encryption of connections from recursive resolvers to authoritative servers. Some authoritative servers are experimenting with ADoT, and opportunistic encryption has also been raised as a possibility; therefore, it is highly likely that use of encryption by authoritative servers will evolve in the coming years.
前述のように、再帰リゾルバから権威あるサーバーへの接続の暗号化の仕様はありません。一部の権限のあるサーバーがADOTを試しているもの、および日和見論的暗号化も可能性として発生しました。したがって、信頼できるサーバーによる暗号化の使用は今後数年間で進化する可能性が高いです。
This raises questions in the short term with regard to TLS connection and message handling for authoritative servers. In particular, there is likely to be a class of authoritative servers that wish to use XoT in the near future with a small number of configured secondaries but that do not wish to support DoT for regular queries from recursives in that same time frame. These servers have to potentially cope with probing and direct queries from recursives and from test servers and also potential attacks that might wish to make use of TLS to overload the server.
これにより、信頼できるサーバーのTLS接続とメッセージ処理に関して、短期間で質問が発生します。特に、近い将来XOTを使用する希望の信頼できるサーバーのクラスが、小数の設定された二次的なもので、同じ時間枠内の再帰からの定期的なクエリのドットをサポートしたくない可能性があります。これらのサーバーは、再帰やテストサーバーからのプロービングと直接のクエリに対処し、テストサーバーから、サーバーを過負荷にするためにTLSを使用したいと思う可能性がある潜在的な攻撃に対処する必要があります。
[RFC5936] clearly states that non-AXFR session traffic can use an open connection; however, this requirement needs to be reevaluated when considering the application of the same model to XoT. Proposing that a server should also start responding to all queries received over TLS just because it has enabled XoT would be equivalent to defining a form of authoritative DoT. This specification does not propose that, but it also does not prohibit servers from answering queries unrelated to XFR exchanges over TLS. Rather, this specification simply outlines in later sections:
[RFC5936]非AXFRセッショントラフィックがオープン接続を使用できることを明確に述べています。ただし、XOTと同じモデルの適用を検討するときにこの要件を再評価する必要があります。サーバーがTLSを介して受信されたすべてのクエリへの応答を開始することも、XOTが正式なドットの形式を定義することと同じであろうということを提案します。この仕様はそれを提案していませんが、サーバーはTLSを介してXFRの交換とは無関係のクエリに応答することを禁止しません。むしろ、この仕様は後述のセクションで概説しています。
* the utilization of EDE codes by XoT servers in response to queries on TLS connections that they are not willing to answer (see Section 7.8)
* 答えが望まないTLS接続のクエリに応答してXOTサーバによるEDEコードの利用（7.8項参照）
* the operational and policy options that an operator of a XoT server has with regard to managing TLS connections and messages (see Appendix A)
* XOTサーバーのオペレーターがTLS接続とメッセージの管理に関して使用される運用およびポリシーのオプション（付録Aを参照）
XoT clients and servers MUST implement EDE codes. If a XoT server receives non-XoT traffic it is not willing to answer on a TLS connection, it SHOULD respond with REFUSED and the extended DNS error code 21 - Not Supported [RFC8914]. XoT clients should not send any further queries of this type to the server for a reasonable period of time (for example, one hour), i.e., long enough that the server configuration or policy might be updated.
XOTクライアントとサーバーはEDEコードを実装する必要があります。XOTサーバーがTLS接続で回答しても構わないXOTトラフィックを受信した場合は、拒否され、拡張DNSエラーコード21 - サポートされていない[RFC8914]で応答する必要があります。XOTクライアントは、このタイプのさらなるクエリを妥当な期間（たとえば、1時間）、すなわちサーバ構成またはポリシーが更新される可能性があるほど長い間サーバーに送信しないでください。
Historically, servers have used the REFUSED RCODE for many situations; therefore, clients often had no detailed information on which to base an error or fallback path when queries were refused. As a result, the client behavior could vary significantly. XoT servers that refuse queries must cater to the fact that client behavior might vary from continually retrying queries regardless of receiving REFUSED to every query or, at the other extreme, clients may decide to stop using the server over any transport. This might be because those clients are either non-XoT clients or do not implement EDE codes.
歴史的に、サーバーは多くの状況に対して拒否されたRCODEを使用しています。したがって、クライアントは、クエリが拒否されたときにエラーまたはフォールバックパスをベースにするための詳細な情報はしばしばありませんでした。その結果、クライアントの動作は大幅に異なる可能性があります。クエリを拒否するXOTサーバーは、クライアントの動作がすべてのクエリを拒否したことに関係なく、クライアントの動作が継続的に再試行クエリによって異なる可能性があるため、または他の極端なクライアントがあらゆるトランスポートを介してサーバーの使用を中止することを決定することができます。これは、これらのクライアントが非XOTクライアントであるか、EDEコードを実装していないためです。
The goal of padding AXoT responses is two fold:
Padding Axot Responsesの目標は2倍です。
* to obfuscate the actual size of the transferred zone to minimize information leakage about the entire contents of the zone
* ゾーンの内容全体についての情報漏洩を最小限に抑えるために転送ゾーンの実際のサイズを難読化する
* to obfuscate the incremental changes to the zone between SOA updates to minimize information leakage about zone update activity and growth
* ゾーン更新活動と成長についての情報漏洩を最小限に抑えるためにSOAアップデート間のゾーンへの増分変更を難読化するには
Note that the reuse of XoT connections for transfers of multiple different zones slightly complicates any attempt to analyze the traffic size and timing to extract information. Also, effective padding may require the state to be kept because zones may grow and/ or shrink over time.
複数の異なるゾーンの転送のためのXOT接続の再利用は、トラフィックのサイズを分析し、情報を抽出するタイミングをわずかに複雑にすることに注意してください。また、ゾーンが経時的に成長および/または縮小することができるので、効果的なパディングは状態を維持することを必要とし得る。
It is noted here that, depending on the padding policies eventually developed for XoT, the requirement to obfuscate the total zone size might require a server to create 'empty' AXoT responses, that is, AXoT responses that contain no RRs apart from an OPT RR containing the EDNS(0) option for padding. For example, without this capability, the maximum size that a tiny zone could be padded to would theoretically be limited if there had to be a minimum of 1 RR per packet.
ここで、XOTのために最終的に開発されたパディングポリシーに応じて、総ゾーンサイズを難読化するための要件は、「空」のアクション応答、すなわちオプトRRとは別にRRを含むアクション応答をサーバにする必要があることに留意されたい。パディングのためのEDNS（0）オプションを含む。たとえば、この機能なしでは、パケットごとに最低1 RRがなければならない場合、小さなゾーンが理論的には理論的に制限されるようにすることができる最大サイズを表します。
However, as with existing AXFR, the last AXoT response message sent MUST contain the same SOA that was in the first message of the AXoT response series in order to signal the conclusion of the zone transfer.
ただし、既存のAXFRと同様に、送信された最後のAxot Responseメッセージは、ゾーン転送の終了を通知するために、AxOT応答シリーズの最初のメッセージにあるのと同じSOAを含める必要があります。
[RFC5936] says:
[RFC5936]言う：
| Each AXFR response message SHOULD contain a sufficient number of
| RRs to reasonably amortize the per-message overhead, up to the
| largest number that will fit within a DNS message (taking the
| required content of the other sections into account, as described
| below).
'Empty' AXoT responses generated in order to meet a padding requirement will be exceptions to the above statement. For flexibility, for future proofing, and in order to guarantee support for future padding policies, it is stated here that secondary implementations MUST be resilient to receiving padded AXoT responses, including 'empty' AXoT responses that contain only an OPT RR containing the EDNS(0) option for padding.
パディング要件を満たすために生成された '空の'アクション応答は、上記のステートメントの例外になります。将来の校正のために、そして将来の校正のための柔軟性のために、そして将来のパディングポリシーのための支援を保証するために、ここでは、EDNを含むOpt RRのみを含む「空の」アクション応答を含む、二次実装を受信するように弾力的でなければならないことがここで述べられている（0）パディングのオプション。
Recommendations of specific policies for padding AXoT responses are out of scope for this specification. Detailed considerations of such policies and the trade-offs involved are expected to be the subject of future work.
PDING AxOT応答のための特定のポリシーの推奨事項は、本明細書の範囲外です。そのような方針と関与するトレードオフの詳細な考慮事項は、将来の仕事の主題であると予想されます。
[RFC1995] says that condensation of responses is optional and MAY be done. Whilst it does add complexity to generating responses, it can significantly reduce the size of responses. However, any such reduction might be offset by increased message size due to padding. This specification does not update the optionality of condensation for XoT responses.
[RFC1995]は、応答の凝縮が任意であり、行われてもよいと述べています。応答を生成するための複雑さを追加すると、それは応答の大きさを大幅に減らすことができます。しかしながら、パディングによるメッセージサイズの増大により、そのような減少はオフセットされ得る。この仕様はXOT応答の結露のオプション性を更新しません。
Fallback to AXFR can happen, for example, if the server is not able to provide an IXFR for the requested SOA. Implementations differ in how long they store zone deltas and how many may be stored at any one time.
axfrへのフォールバックは、例えば、サーバが要求されたSOAに対してIXFRを提供することができない場合に起こり得る。実装は、ゾーンのデルタを保存する期間、および一度にどのように保存されるかが異なります。
Just as with IXFR over TCP, after a failed IXFR, an IXoT client SHOULD request the AXFR on the already open XoT connection.
IXFR over TCPでのIXFRと同じように、IXTクライアントは既に開いているXOT接続でAXFRを要求する必要があります。
The goal of padding IXoT responses is to obfuscate the incremental changes to the zone between SOA updates to minimize information leakage about zone update activity and growth. Both the size and timing of the IXoT responses could reveal information.
IXOT応答をパディングするという目的は、ゾーン更新活動と成長についての情報漏洩を最小限に抑えるために、SOAの更新間のゾーンへの増分変更を難読化することです。IXOT応答のサイズとタイミングの両方が情報を明らかにする可能性があります。
IXFR responses can vary greatly in size from the order of 100 bytes for one or two record updates to tens of thousands of bytes for large, dynamic DNSSEC-signed zones. The frequency of IXFR responses can also depend greatly on if and how the zone is DNSSEC signed.
IXFRの応答は、大規模なダイナミックなDNSEC署名ゾーンには、1,000バイトの1,000バイトの数十万バイトの場合は100バイトの順序から大きく異なります。IXFR応答の頻度は、ゾーンがDNSSECの署名された場合にも大きく依存できます。
In order to guarantee support for future padding policies, it is stated here that secondary implementations MUST be resilient to receiving padded IXoT responses.
将来のパディングポリシーのためのサポートを保証するために、二次実装は埋め込まれたIXOT応答を受信するように弾力的でなければならないことが明らかにされる。
Recommendation of specific policies for padding IXoT responses are out of scope for this specification. Detailed considerations of such padding policies, the use of traffic obfuscation techniques (such as generating fake XFR traffic), and the trade-offs involved are expected to be the subject of future work.
IXOT応答をパディングするための具体的なポリシーの推奨は、この仕様の範囲外です。そのようなパディング方針の詳細な考慮事項、交通難読化技術（偽のXFRトラフィックの生成など）の使用、および関連するトレードオフは将来の作業の主題であると予想されます。
It is noted here that name compression [RFC1035] can be used in XFR responses to reduce the size of the payload; however, the maximum value of the offset that can be used in the name compression pointer structure is 16384. For some DNS implementations, this limits the size of an individual XFR response used in practice to something around the order of 16 KB. In principle, larger payload sizes can be supported for some responses with more sophisticated approaches (e.g., by precalculating the maximum offset required).
ここでは、Payloadのサイズを縮小するために、名前圧縮[RFC1035]をXFR応答で使用することができます。ただし、名前圧縮ポインタ構造の名前で使用できるオフセットの最大値は16384です。いくつかのDNS実装では、実際に使用されている個々のXFRレスポンスのサイズを16 KBのオーダーの周囲に制限します。原則として、より高いペイロードサイズをより洗練されたアプローチ（例えば、必要な最大オフセットを予備縮小することによって）を有するいくつかの応答についてサポートすることができる。
Implementations may wish to offer options to disable name compression for XoT responses to enable larger payloads. This might be particularly helpful when padding is used, since minimizing the payload size is not necessarily a useful optimization in this case and disabling name compression will reduce the resources required to construct the payload.
実装は、より大きなペイロードを有効にするためにXOT応答の名前圧縮を無効にするためのオプションを提供したいと思うかもしれません。ペイロードサイズを最小限に抑えるため、ペイロードサイズを最小限に抑えることは必ずしも有用な最適化であるため、パディングが使用され、名前圧縮を無効にすると、ペイロードを構成するために必要なリソースが減少するため、これは特に役立ちます。
This model can provide flexibility and redundancy, particularly for IXFR. A secondary will receive one or more NOTIFY messages and can send an SOA to all of the configured primaries. It can then choose to send an XFR request to the primary with the highest SOA (or based on other criteria, e.g., RTT).
このモデルは、特にIXFRのための柔軟性と冗長性を提供することができます。二次は1つ以上の通知メッセージを受信し、構成されたすべての原本にSOAを送信することができます。その後、最高SOAを使用して（または他の基準、例えばRTTに基づいて）プライマリにXFR要求を送信することを選択できます。
When using persistent connections, the secondary may have a XoT connection already open to one or more primaries. Should a secondary preferentially request an XFR from a primary to which it already has an open XoT connection or the one with the highest SOA (assuming it doesn't have a connection open to it already)?
永続的な接続を使用する場合、二次はXOT接続を既に1つ以上の原本に開くことができる。セカンダリが、すでにオープンXOT接続を既に持っているプライマリからXFRをリクエストする場合、またはSOAが最も高いSOAを持つものを既に要求する必要がありますか？
Two extremes can be envisaged here. The first one can be considered a 'preferred primary connection' model. In this case, the secondary continues to use one persistent connection to a single primary until it has reason not to. Reasons not to might include the primary repeatedly closing the connection, long query/response RTTs on transfers, or the SOA of the primary being an unacceptable lag behind the SOA of an alternative primary.
ここでは2つの極値を想定することができます。最初のものは「優先するプライマリ接続」モデルと見なすことができます。この場合、二次は、理由がない理由があるまで、1つのプライマリに1つの永続的接続を使用し続けています。接続を繰り返し閉じることができないような理由で、転送上の長いクエリ/レスポンスRTTS、またはプライマリのSOAのSOAは、代替のプライマリのSOAの背後にある許容できないラグです。
The other extreme can be considered a 'parallel primary connection' model. Here, a secondary could keep multiple persistent connections open to all available primaries and only request XFRs from the primary with the highest serial number. Since normally the number of secondaries and primaries in direct contact in a transfer group is reasonably low, this might be feasible if latency is the most significant concern.
もう一方の極端なものは、「並列主な接続」モデルと見なすことができます。ここで、二次的な接続がすべての利用可能なプライマリに複数の永続接続を開くことができ、一次元から最も高いシリアル番号でXFRを要求するだけです。通常、転送グループ内の直接接触の2番目の数の数は合理的に低いので、待ち時間が最も重要な場合は実現可能です。
Recommendation of a particular scheme is out of scope of this document, but implementations are encouraged to provide configuration options that allow operators to make choices about this behavior.
特定のスキームの推奨はこの文書の範囲外ですが、実装は、オペレータがこの動作について選択をすることを可能にする構成オプションを提供することをお勧めします。
To provide context to the requirements in Section 7.5, this section provides a brief summary of some of the existing authentication and validation mechanisms (both transport independent and TLS specific) that are available when performing zone transfers. Section 10 then discusses in more detail specifically how a combination of TLS authentication, TSIG, and IP-based ACLs interact for XoT.
セクション7.5の要件にコンテキストを提供するために、このセクションでは、ゾーン転送を実行するときに使用可能な既存の認証および検証メカニズム（トランスポート独立およびTLS固有の両方）の簡単な要約を提供します。次に、セクション10は、TLS認証、TSIG、およびIPベースのACLの組み合わせがXOTに対話する方法を具体的に詳しく説明します。
In this document, the mechanisms are classified based on the following properties:
この文書では、メカニズムは次のプロパティに基づいて分類されます。
Data Origin Authentication (DO): Authentication 1) of the fact that the DNS message originated from the party with whom credentials were shared and 2) of the data integrity of the message contents (the originating party may or may not be the party operating the far end of a TCP/TLS connection in a 'proxy' scenario).
データの原点認証（DO）：認証情報が共有された当事者から発信されたDNSメッセージが、メッセージ内容のデータ整合性（発信側では、当事者が操作している場合、または存在しない可能性があります）の事実の認証1）「プロキシ」シナリオでのTCP / TLS接続の遠端）。
Channel Confidentiality (CC): Confidentiality of the communication channel between the client and server (i.e., the two endpoints of a TCP/TLS connection) from passive surveillance.
チャネル機密保持（CC）：パッシブサーベイランスからのクライアントとサーバ間の通信チャネルの機密性（すなわち、TCP / TLS接続の2つのエンドポイント）。
Channel Authentication (CA): Authentication of the identity of the party to whom a TCP/TLS connection is made (this might not be a direct connection between the primary and secondary in a proxy scenario).
チャネル認証（CA）：TCP / TLS接続が行われている当事者のIDの認証（これは、プロキシシナリオでのプライマリとセカンダリの間の直接接続ではない可能性があります）。
TSIG [RFC8945] provides a mechanism for two or more parties to use shared secret keys that can then be used to create a message digest to protect individual DNS messages. This allows each party to authenticate that a request or response (and the data in it) came from the other party, even if it was transmitted over an unsecured channel or via a proxy.
TSIG [RFC8945]は、個々のDNSメッセージを保護するためにメッセージダイジェストを作成するために使用できる共有秘密鍵を使用するための2つ以上のパーティーのメカニズムを提供します。これにより、各パーティは、無担保チャネルを介してまたはプロキシを介して送信されても、要求または応答（およびITのデータ）が相手方から来たことを認証することができます。
Properties: Data origin authentication.
プロパティ：データ発信認証。
SIG(0) [RFC2931] similarly provides a mechanism to digitally sign a DNS message but uses public key authentication, where the public keys are stored in DNS as KEY RRs and a private key is stored at the signer.
SIG（0）[RFC2931]も同様にDNSメッセージにデジタル署名するメカニズムを提供しますが、公開鍵認証を使用します。ここで、公開鍵はDNSにキーRRSとして保存され、秘密鍵が署名者に保存されます。
Properties: Data origin authentication.
プロパティ：データ発信認証。
Opportunistic TLS for DoT is defined in [RFC8310] and can provide a defense against passive surveillance, providing on-the-wire confidentiality. Essentially:
ドットの日和見的TLSは[RFC8310]で定義されており、パッシブサーベイランスに対する防御を提供し、電線上の機密保持を提供することができます。本質的に：
* if clients know authentication information for a server, they SHOULD try to authenticate the server,
* クライアントがサーバーの認証情報を知っている場合、それらはサーバーの認証を試みるべきです。
* if this fails or clients do not know the information, they MAY fallback to using TLS without authentication, or
* これが失敗したかクライアントが情報を知らない場合、それらは認証なしでTLSを使用することにフォールバックすることがあります。
* clients MAY fallback to using cleartext if TLS is not available.
* TLSが使用できない場合、クライアントはClearTextを使用するようにフォールバックすることがあります。
As such, it does not offer a defense against active attacks (e.g., an on-path active attacker on the connection from client to server) and is not considered as useful for XoT.
そのため、アクティブな攻撃に対する防御（例えば、クライアントからサーバーへの接続上のオンパスアクティブな攻撃者）に対する防御は提供されておらず、XOTに有用ではありません。
Properties: None guaranteed.
プロパティ：何も保証されていません。
Strict TLS for DoT [RFC8310] requires that a client is configured with an authentication domain name (and/or Subject Public Key Info (SPKI) pin set) that MUST be used to authenticate the TLS handshake with the server. If authentication of the server fails, the client will not proceed with the connection. This provides a defense for the client against active surveillance, providing client-to-server authentication and end-to-end channel confidentiality.
DOTの厳密なTLS [RFC8310]サーバーとのTLSハンドシェイクを認証するために使用する必要がある認証ドメイン名（および/またはサブジェクト公開鍵情報（SPKI）ピンセット）でクライアントが構成されている必要があります。サーバーの認証が失敗した場合、クライアントは接続を続行しません。これにより、クライアント監視に対するクライアントの防衛があり、クライアントからサーバーへの認証とエンドツーエンドのチャネルの機密性を提供します。
Properties: Channel confidentiality and channel authentication (of the server).
プロパティ：チャネル機密性とチャネル認証（サーバーの）
This is an extension to Strict TLS [RFC8310] that requires that a client is configured with an authentication domain name (and/or SPKI pin set) and a client certificate. The client offers the certificate for authentication by the server, and the client can authenticate the server the same way as in Strict TLS. This provides a defense for both parties against active surveillance, providing bidirectional authentication and end-to-end channel confidentiality.
これは、クライアントが認証ドメイン名（および/またはSPKI PIN SET）とクライアント証明書で構成されていることを要求する厳密なTLS [RFC8310]の拡張です。クライアントはサーバーによる認証の証明書を提供し、クライアントは厳密なTLSと同じ方法でサーバーを認証できます。これにより、双方向認証とエンドツーエンドのチャネル機密性を提供する能動監視に対する両当事者の防衛があります。
Properties: Channel confidentiality and mutual channel authentication.
プロパティ：チャネル機密性と相互チャネル認証
Most DNS server implementations offer an option to configure an IP-based ACL, which is often used in combination with TSIG-based ACLs to restrict access to zone transfers on primary servers on a per-query basis.
ほとんどのDNSサーバー実装では、IPベースのACLを設定するオプションを提供します。これは、TSIGベースのACLと組み合わせて使用して、クエリごとにプライマリサーバー上のゾーン転送へのアクセスを制限します。
This is also possible with XoT, but it must be noted that, as with TCP, the implementation of such an ACL cannot be enforced on the primary until an XFR request is received on an established connection.
これはXOTでも可能ですが、TCPと同様に、そのようなACLの実装は、確立された接続でXFR要求が受信されるまでプライマリ上で強制されないことに注意してください。
As discussed in Appendix A, an IP-based per-connection ACL could also be implemented where only TLS connections from recognized secondaries are accepted.
付録Aで説明されているように、認識された第二次数からのTLS接続のみが受け入れられる場合に、IPベースの接続ごとのACLも実装され得る。
Properties: Channel authentication of the client.
プロパティ：クライアントのチャネル認証。
For completeness, ZONEMD [RFC8976] ("Message Digest for DNS Zones") is described here. The ZONEMD message digest is a mechanism that can be used to verify the content of a standalone zone. It is designed to be independent of the transmission channel or mechanism, allowing a general consumer of a zone to do origin authentication of the entire zone contents. Note that the current version of [RFC8976] states:
完全性のために、ZoneMD [RFC8976]（「DNSゾーンのメッセージダイジェスト」）について説明します。ZoneMDメッセージダイジェストは、スタンドアロンゾーンの内容を検証するために使用できるメカニズムです。ゾーンの一般的な消費者がゾーン内容全体の原点認証を行うことを可能にする送信チャネルまたはメカニズムから独立しているように設計されています。現在のバージョンの[RFC8976]は次のように状態を示していることに注意してください。
| As specified herein, ZONEMD is impractical for large, dynamic
| zones due to the time and resources required for digest
| calculation. However, the ZONEMD record is extensible so that new
| digest schemes may be added in the future to support large,
| dynamic zones.
It is complementary but orthogonal to the above mechanisms and can be used in conjunction with XoT but is not considered further here.
それは補完的であるが上記のメカニズムに直交しており、XOTと共に使用することができるが、ここではさらに考慮されていない。
It is noted that zone transfer scenarios can vary from a simple single primary/secondary relationship where both servers are under the control of a single operator to a complex hierarchical structure that includes proxies and multiple operators. Each deployment scenario will require specific analysis to determine which combination of authentication methods are best suited to the deployment model in question.
ゾーン転送シナリオは、両方のサーバが単一の演算子の制御下にある単純な単一のプライマリ/セカンダリ関係とは異なる場合があり、プロキシと複数の演算子を含む複雑な階層構造に配置されていることに留意されたい。各デプロイメントシナリオは、問題の展開モデルに最も適している認証方法のどの組み合わせが最も適しているかを決定するために特定の分析が必要になります。
The XoT authentication requirement specified in Section 7.5 addresses the issue of ensuring that the transfers are encrypted between the two endpoints directly involved in the current transfers. The following table summarizes the properties of a selection of the mechanisms discussed in Section 9. The two-letter abbreviations for the properties are used below: (S) indicates the secondary and (P) indicates the primary.
セクション7.5に規定されているXOT認証要件は、転送が現在の転送に直接関わる2つのエンドポイント間で暗号化されることを保証するという問題を解決します。次の表は、セクション9で説明されているメカニズムの選択のプロパティをまとめたものです。プロパティの2文字の省略形は以下のとおりです。（s）セカンダリを示し、（p）は一次を示します。
+================+=======+=======+=======+=======+=======+=======+
| Method | DO(S) | CC(S) | CA(S) | DO(P) | CC(P) | CA(P) |
+================+=======+=======+=======+=======+=======+=======+
| Strict TLS | | Y | Y | | Y | |
+----------------+-------+-------+-------+-------+-------+-------+
| Mutual TLS | | Y | Y | | Y | Y |
+----------------+-------+-------+-------+-------+-------+-------+
| ACL on primary | | | | | | Y |
+----------------+-------+-------+-------+-------+-------+-------+
| TSIG | Y | | | Y | | |
+----------------+-------+-------+-------+-------+-------+-------+
Table 1: Properties of Authentication Methods for XoT
表1：XOTの認証方法のプロパティ
Based on this analysis, it can be seen that:
この分析に基づいて、それは見ることができます：
* Using just mutual TLS can be considered a standalone solution since both endpoints are cryptographically authenticated.
* 両方のエンドポイントが暗号的に認証されているため、単なる相互TLSを使用すると、スタンドアロンのソリューションと見なすことができます。
* Using secondary-side Strict TLS with a primary-side IP-based ACL and TSIG/SIG(0) combination provides sufficient protection to be acceptable.
* 一次側IPベースのACLおよびTSIG / SIG（0）の組み合わせを有する二次側厳密なTLSを使用することは、許容できる十分な保護を提供する。
Using just an IP-based ACL could be susceptible to attacks that can spoof TCP IP addresses; using TSIG/SIG(0) alone could be susceptible to attacks that were able to capture such messages should they be accidentally sent in cleartext by any server with the key.
IPベースのACLだけを使用すると、TCP IPアドレスを偽装できる攻撃の影響を受けやすくなる可能性があります。TSIG / SIG（0）を使用すると、そのようなメッセージをキャプチャすることができた攻撃の影響を受けやすくなりました。
Whilst the protection of the zone contents in a transfer between two endpoints can be provided by the XoT protocol, the protection of all the transfers of a given zone requires operational administration and policy management.
2つのエンドポイント間の転送におけるゾーン内容の保護は、XOTプロトコルによって提供され得るが、特定のゾーンのすべての転送の保護には、運用管理およびポリシー管理が必要である。
The entire group of servers involved in XFR for a particular set of zones (all the primaries and all the secondaries) is called the 'transfer group'.
特定のゾーンのセット（すべての原色およびすべての後続）についてXFRに関与するサーバーのグループ全体は '転送グループ'と呼ばれます。
In order to assure the confidentiality of the zone information, the entire transfer group MUST have a consistent policy of using XoT. If any do not, this is a weak link for attackers to exploit. For clarification, this means that within any transfer group both AXFRs and IXFRs for a zone MUST all use XoT.
ゾーン情報の機密性を保証するためには、転送グループ全体にXOTを使用する一貫したポリシーが必要です。そうでない場合、これは攻撃者が悪用するための弱いリンクです。明確化のために、これは任意の転送グループ内でゾーンのaxfrsとixfrの両方がすべてxotを使用しなければならないことを意味します。
An individual zone transfer is not considered protected by XoT unless both the client and server are configured to use only XoT, and the overall zone transfer is not considered protected until all members of the transfer group are configured to use only XoT with all other transfers servers (see Section 12).
クライアントとサーバーの両方がXOTのみを使用するように構成されていない限り、個々のゾーン転送はXOTによって保護されず、転送グループのすべてのメンバーが他のすべての転送サーバーとのXOTのみを使用するように構成されているまで、全体のゾーン転送は保護されないと見なされません。（12を参照）。
A XoT policy MUST specify if:
次の場合にXOTポリシーを指定する必要があります。
* mutual TLS is used and/or
* 相互TLSが使用されています
* an IP-based ACL and TSIG/SIG(0) combination is used.
* IPベースのACLとTSIG / SIG（0）の組み合わせが使用されます。
Since this may require configuration of a number of servers who may be under the control of different operators, the desired consistency could be hard to enforce and audit in practice.
これはさまざまな演算子の管理下にあるかもしれない多くのサーバーの構成を必要とするかもしれないので、望ましい一貫性は実際に執行し監査するのが難しいかもしれません。
Certain aspects of the policies can be relatively easy to test independently, e.g., by requesting zone transfers without TSIG, from unauthorized IP addresses or over cleartext DNS. Other aspects, such as if a secondary will accept data without a TSIG digest or if secondaries are using Strict as opposed to Opportunistic TLS, are more challenging.
ポリシーの特定の態様は、例えば、TSIGなしのゾーン転送を、不正なIPアドレスまたは明確なIPアドレスからのゾーン転送を要求することによって、比較的容易にテストすることができます。二次がTSIGダイジェストなしでデータを受け入れるか、または日和見主義的TLSとは対照的に厳密な場合などの他の態様は、より困難である。
The mechanics of coordinating or enforcing such policies are out of the scope of this document but may be the subject of future operational guidance.
そのようなポリシーを調整または強制する力学はこの文書の範囲外であるが、将来の運用ガイダンスの対象となる可能性がある。
Server implementations may want to also offer options that allow ACLs on a zone to specify that a specific client can use either XoT or TCP. This would allow for flexibility while clients are migrating to XoT.
サーバーの実装には、ゾーン上のACLが特定のクライアントがXOTまたはTCPを使用できるように指定できるオプションも提供することがあります。これにより、クライアントがXOTに移行している間は、柔軟性が可能になります。
Client implementations may similarly want to offer options to cater to the multi-primary case where the primaries are migrating to XoT.
クライアントの実装は、原本がXOTに移行している多主体的なケースに対応するためのオプションを同様に提供することができます。
If the options described in Section 12 are available, such configuration options MUST only be used in a 'migration mode' and therefore should be used with great care.
セクション12で説明されているオプションが利用可能な場合は、そのような設定オプションは「移行モード」でのみ使用されている必要があります。したがって、細心の注意を払って使用する必要があります。
It is noted that use of a TLS proxy in front of the primary server is a simple deployment solution that can enable server-side XoT.
プライマリサーバの前にTLSプロキシを使用することは、サーバ側XOTを有効にすることができる単純な展開ソリューションであることに留意されたい。
This document has no IANA actions.
この文書にはIANAの行動がありません。
This document specifies a security measure against a DNS risk: the risk that an attacker collects entire DNS zones through eavesdropping on cleartext DNS zone transfers.
このドキュメントはDNSリスクに対するセキュリティ対策を指定します。攻撃者がClearText DNSゾーン転送を盗聴することでDNSゾーン全体を収集するリスク。
This does not mitigate:
これは軽減されません。
* the risk that some level of zone activity might be inferred by observing zone transfer sizes and timing on encrypted connections (even with padding applied), in combination with obtaining SOA records by directly querying authoritative servers,
* ゾーンの転送サイズと暗号化された接続でのタイミング（適用されたパディングでも）ゾーンの転送サイズとタイミングが推測される可能性があるため、正式なサーバーを直接問い合わせることでSOAレコードを取得することで、
* the risk that hidden primaries might be inferred or identified via observation of encrypted connections, or
* 隠された原色が暗号化された接続の観察によって推測または識別される可能性があるリスク
* the risk of zone contents being obtained via zone enumeration techniques.
* ゾーン内容のリスクはゾーン列挙技術を介して取得されます。
Security concerns of DoT are outlined in [RFC7858] and [RFC8310].
DOTのセキュリティ上の懸念は[RFC7858]と[RFC8310]に概説されています。
[DoT-ALPN] IANA, "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs", <https://www.iana.org/assignments/tls-extensiontype-values/>.
[DOT-ALPN] IANA、「TLSアプリケーション層プロトコルネゴシエーション（ALPN）プロトコルID」、<https：//www.iana.org/assignments/tls-extensiontype-values/>。
[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>。
[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>。
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC1996] Vixie、P.、「ゾーン変更の迅速な通知（DNS Notify）」、RFC 1996、DOI 10.17487 / RFC1996、1996年8月、<https://www.rfc-editor.org/info/rfc1996>。
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC2931]イーストレイク3RD、D.、DNSリクエストおよびトランザクションシグニチャ（SIG（0）S） "、RFC 2931、DOI 10.17487 / RFC2931、2000年9月、<https：//www.rfc-editor.org/info/RFC2931>。
[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ゾーン転送プロトコル（AXFゾーン転送プロトコル（AXFR）」、RFC 5936、DOI 10.17487 / RFC5936、2010年6月、<https://www.rfc-editor.org/info/ RFC5936>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973]クーパー、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M.、R. Smith、「インターネットプロトコルのプライバシーに関する考察」、RFC 6973、DOI2017487 / RFC6973、2013年7月、<https：//www.rfc-editor.org/info/rfc6973>。
[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>.
[RFC7766]ディッキンソン、J.、Dickinson、S.、Bellis、R.、Mankin、A.、D.ウェース、「TCPの輸送 - 実施要件」、RFC 7766、DOI 10.17487 / RFC7766、2016年3月、<https://www.rfc-editor.org/info/rfc7766>。
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/RFC7828, April 2016, <https://www.rfc-editor.org/info/rfc7828>.
[RFC7828] Wouters、P.、Cormy、J.、Dickinson、S.、およびR. Bellis、「EDNS-TCP-Keepalive EDNS0オプション」、RFC 7828、DOI 10.17487 / RFC7828、2016年4月、<https：//www.rfc-editor.org/info/rfc7828>。
[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>.
[RFC7858] HU、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D.、およびP.HOFFMAN、「トランスポート層セキュリティ（TLS）のDNSの仕様（TLS）」、RFC 7858、DOI10.17487 / RFC7858、2016年5月、<https://www.rfc-editor.org/info/rfc7858>。
[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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles for DNS over TLS and DNS over DTLS", RFC 8310, DOI 10.17487/RFC8310, March 2018, <https://www.rfc-editor.org/info/rfc8310>.
[RFC8310]ディッキンソン、S.、Gillmor、D.、DNDY、「DNS上のDNSのための使用プロフィール」、RFC 8310、DOI 10.17487 / RFC8310、2018年3月、<https：//www.rfc-editor.org/info/rfc8310>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[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>。
[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, "Extended DNS Errors", RFC 8914, DOI 10.17487/RFC8914, October 2020, <https://www.rfc-editor.org/info/rfc8914>.
[RFC8914] Kumari、W.、Hunt、E.、Arends、R.、Hardaker、W.、D. Lawrence、「拡張DNSエラー」、RFC 8914、DOI 10.17487 / RFC8914、<https：//www.rfc-editor.org/info/rfc8914>。
[RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., Gudmundsson, O., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", STD 93, RFC 8945, DOI 10.17487/RFC8945, November 2020, <https://www.rfc-editor.org/info/rfc8945>.
[RFC8945] DuPont、F.、Morris、S.、Vixie、P.、Eastleake 3RD、D.、Gudmundsson、O.、およびB.Welientton、「DNSの秘密鍵取引認証」、STD 93、RFC8945、DOI 10.17487 / RFC8945、2020年11月、<https：//www.rfc-editor.org/info/rfc8945>。
[BIND] ISC, "BIND 9.16.16", <https://www.isc.org/bind/>.
[BIND] ISC、「BIND 9.16.16」、<https://www.isc.org/bind/>。
[DPRIVE-DNSOQUIC] Huitema, C., Dickinson, S., and A. Mankin, "Specification of DNS over Dedicated QUIC Connections", Work in Progress, Internet-Draft, draft-ietf-dprive-dnsoquic-03, 12 July 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-dprive-dnsoquic-03>.
[DPrive-DNSOQUIC] Huitema、C、Dickinson、S.、A. Mankin、「専用のQUIC接続を介したDNSの仕様」、進行中の作業、インターネットドラフト、ドラフト-IETF-DPRIVE-DNSOQUIC-03,12月12日2021、<https://datatracker.ietf.org/doc/html/draft-ietf-dprive-dnsoquic-03>。
[NIST-GUIDE] Chandramouli, R. and S. Rose, "Secure Domain Name System (DNS) Deployment Guide", September 2013, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-81-2.pdf>.
[NISTガイド] Chandramouli、R.およびS. Rose、2013年9月、<https://nvlpubs.nist.gov/nistpubs/specialPublications / Nist.Sp.800-81-2.pdf>。
[NSD] NLnet Labs, "NSD 4.3.6", <https://www.nlnetlabs.nl/projects/nsd/about/>.
[NSD] NLNET Labs、 "NSD 4.3.6"、<https：//www.nlnetlabs.nl/projects/nsd/about/>。
[NSEC3-attacks] Goldberg, S., Naor, N., Papadopoulos, D., Reyzin, L., Vasant, S., and A. Ziv, "Stretching NSEC3 to the Limit: Efficient Zone Enumeration Attacks on NSEC3 Variants", February 2015, <https://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf>.
[NSEC3-攻撃] Goldberg、S.、Naor、N.、Papadopoulos、D.、Reyzin、L.、Vasant、S、およびA. ZIV、「NSEC3の限界へのストレッチ：NSEC3亜種に関する効率的なゾーン列挙型攻撃」、2015年2月、<https://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf>。
[NSEC5] Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of Existence", Work in Progress, Internet-Draft, draft-vcelak-nsec5-08, 29 December 2018, <https://datatracker.ietf.org/doc/html/draft-vcelak-nsec5-08>.
[NSEC5] vCelak、J.、Goldberg、S.、Papadopoulos、D.、Huque、S.、D.ローレンス、「NSEC5、DNSSEC認証済み存在拒否」、進行中の作業、インターネットドラフト、ドラフト - vcelak-2018年12月29日、<https://datatracker.ietf.org/doc/html/draft-vcelak-nsec5-08>。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>.
[RFC1982] ELZ、R.およびR.ブッシュ、「シリアル番号算術」、RFC 1982、DOI 10.17487 / RFC1982、1996年8月、<https：//www.rfc-editor.org/info/rfc1982>。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <https://www.rfc-editor.org/info/rfc5155>.
[RFC5155] Laurie、B.、Sisson、G.、Arends、R.、およびD. Blocka、 "DNSセキュリティ（DNSSEC）ハッシュ化認証済み存在拒否"、RFC 5155、DOI 10.17487 / RFC5155、2008年3月、<https：//www.rfc-editor.org/info/rfc5155>。
[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>.
[RFC6891] Damas、J.、Graff、M.、およびP.Vixie、「DNSの拡張メカニズム（EDNS（0））」、STD 75、RFC 6891、DOI 10.17487 / RFC6891、2013年4月、<https：//www.rfc-editor.org/info/rfc6891>。
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.
[RFC8484] HOFFMAN、P.およびP.Mcmanus、「HTTPS経由のDNSクエリ（DOH）」、RFC 8484、DOI 10.17487 / RFC8484、2018年10月、<https：//www.rfc-editor.org/info/rfc8484>。
[RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. Hardaker, "Message Digest for DNS Zones", RFC 8976, DOI 10.17487/RFC8976, February 2021, <https://www.rfc-editor.org/info/rfc8976>.
[RFC8976]ウェース、D.、Barber、P.、Weinberg、M.、Kumari、W.およびW.Sharker、「DNSゾーンのメッセージダイジェスト」、RFC 8976、DOI 10.17487 / RFC8976、2021年2月、<https：//www.rfc-editor.org/info/rfc8976>。
[RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076, DOI 10.17487/RFC9076, July 2021, <https://www.rfc-editor.org/info/rfc9076>.
[RFC9076] WicinSki、T.、ED。、「DNSプライバシーに関する考慮事項」、RFC 9076、DOI 10.17487 / RFC9076、2021年7月、<https：//www.rfc-editor.org/info/rfc9076>。
[TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", Work in Progress, Internet-Draft, draft-ietf-tls-esni-13, 12 August 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-13>.
[TLS-ESNI] Rescorla、E.、OKU、K.、Sullivan、N.、およびCA Wood、「TLS暗号化クライアントHello」、進行中の作業、インターネットドラフト、草案-IETF-TLS-ESNI-13,122021年8月、<https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-13>。
This appendix provides a non-normative outline of the pros and cons of XoT server connection-handling options.
この付録では、XOTサーバー接続処理オプションの長所と短所の非規範的な概要を提供します。
For completeness, it is noted that an earlier draft version of this document suggested using a XoT-specific ALPN to negotiate TLS connections that supported only a limited set of queries (SOA, XFRs); however, this did not gain support. Reasons given included additional code complexity and the fact that XoT and ADoT are both DNS wire format and so should share the "dot" ALPN.
完全性のために、この文書の以前のドラフト版は、限られたクエリのセット（SOA、XFR）のみをサポートしているTLS接続をネゴシエートするためにXOT固有のALPNを使用して示唆されていることに注意してください。しかし、これはサポートを受けることはありませんでした。与えられた理由には追加のコードの複雑さとXOTとADOTが両方ともDNSワイヤフォーマットで、「ドット」ALPNを共有する必要があります。
Obviously, a name server that hosts a zone and services queries for the zone on an IP address published in an NS record may wish to use a separate IP address for XoT to listen for TLS, only publishing that address to its secondaries.
明らかに、NSレコードで公開されているIPアドレスのゾーンのゾーンとサービスクエリをホストするネームサーバは、XOTに別々のIPアドレスを使用してTLSをリッスンし、そのアドレスを1次元に公開したいと思うかもしれません。
Pros: Probing of the public IP address will show no support for TLS. ACLs will prevent zone transfer on all transports on a per-query basis.
Pros：パブリックIPアドレスのプロービングはTLSをサポートしていません。ACLは、クエリごとにすべてのトランスポートでゾーン転送を防ぎます。
Cons: Attackers passively observing traffic will still be able to observe TLS connections to the separate address.
短所：トラフィックを受動的に観察する攻撃者は、TLS接続を別々のアドレスに観察することができます。
Primaries that include IP-based ACLs and/or mutual TLS in their authentication models have the option of only accepting TLS connections from authorized clients. This could be implemented either using a proxy or directly in the DNS implementation.
認証モデル内のIPベースのACLおよび/または相互TLSを含む原本には、許可されたクライアントからのTLS接続のみを受け付けることのみがあります。これは、プロキシを使用するか、DNS実装で直接実装できます。
Pros: Connection management happens at setup time. The maximum number of TLS connections a server will have to support can be easily assessed. Once the connection is accepted, the server might well be willing to answer any query on that connection since it is coming from a configured secondary, and a specific response policy on the connection may not be needed (see below).
長所：接続管理はセットアップ時に起こります。サーバーがサポートする必要があるTLS接続の最大数を簡単に評価できます。接続が受け入れられると、サーバーは設定されたセカンダリから来ているので、その接続に対するクエリに答えても構わないと思われる可能性があり、接続上の特定の応答ポリシーは必要ない場合があります（下記参照）。
Cons: Currently, none of the major open-source implementations of a DNS authoritative server support such an option.
短所：現在、DNS権限サーバーの主要なオープンソースの実装のどれもそのようなオプションをサポートしていません。
Primaries could also choose to only accept TLS connections based on a Server Name Indication (SNI) that was published only to their secondaries.
原本は、サーバー名表示（SNI）に基づいてTLS接続を受け入れることも選択できます。
Pros: Reduces the number of accepted connections.
長所：受け入れられた接続の数を減らします。
Cons: As above. Also, this is not a recommended use of SNI. For SNIs sent in the clear, this would still allow attackers passively observing traffic to potentially abuse this mechanism. The use of Encrypted Client Hello [TLS-ESNI] may be of use here.
短所：上記のように。また、これはSNIの推奨使用ではありません。CLEARで送信されたSNIの場合、これは攻撃者がこのメカニズムを潜在的に悪用するために受動的にトラフィックを観察することを可能にするでしょう。暗号化されたクライアントhello [TLS-ESNI]の使用はここで使用することができます。
Some primaries might rely on TSIG/SIG(0) combined with per-query, IP-based ACLs to authenticate secondaries. In this case, the primary must accept all incoming TLS/TCP connections and then apply a transport-specific response policy on a per-query basis.
いくつかの原本は、照会ごとのIPベースのACLと組み合わせて、2次元を認証するためのTSIG / SIG（0）に依存している可能性があります。この場合、プライマリはすべての着信TLS / TCP接続を受け入れてから、クエリごとにトランスポート固有の応答ポリシーを適用する必要があります。
As an aside, whilst [RFC7766] makes a general purpose distinction in the advice to clients about their usage of connections (between regular queries and zone transfers), this is not strict, and nothing in the DNS protocol prevents using the same connection for both types of traffic. Hence, a server cannot know the intention of any client that connects to it; it can only inspect the messages it receives on such a connection and make per-query decisions about whether or not to answer those queries.
脇に、「RFC7766」が汎用の区別（定期的なクエリとゾーン転送の間の）の使用に関する汎用区別をクライアントに区別します。トラフィックの種類したがって、サーバーはそれに接続する任意のクライアントの意図を知ることができません。それはそのような接続で受信したメッセージを検査し、それらのクエリに答えるかどうかについてのクエリごとの決定を下すことができます。
Example policies a XoT server might implement are:
ポリシーの例XOTサーバーが実装される可能性があります。
strict: REFUSE all queries on TLS connections, except SOA and authorized XFR requests
厳密：SOAと許可されたXFR要求を除く、TLS接続ですべてのクエリを拒否する
moderate: REFUSE all queries on TLS connections until one is received that is signed by a recognized TSIG/SIG(0) key, then answer all queries on the connection after that
適度：認識されたTSIG / SIG（0）キーによって署名されていることを受信するまで、TLS接続ですべてのクエリを拒否してから、その後接続のすべてのクエリに答えます。
complex: apply a heuristic to determine which queries on a TLS connections to REFUSE
複雑：拒否するTLS接続に関するクエリを決定するためにヒューリスティックを適用する
relaxed: answer all non-XoT queries on all TLS connections with the same policy applied to TCP queries
リラックス：TCPクエリに適用されたのと同じポリシーを持つすべてのTLS接続ですべての非XOTクエリに回答します。
Pros: Allows for flexible behavior by the server that could be changed over time.
長所：時間の経過とともに変更される可能性があるサーバーによる柔軟な動作を可能にします。
Cons: The server must handle the burden of accepting all TLS connections just to perform XFRs with a small number of secondaries. Client behavior to a REFUSED response is not clearly defined (see Section 7.8). Currently, none of the major open-source implementations of a DNS authoritative server offer an option for different response policies in different transports (but such functionality could potentially be implemented using a proxy).
短所：サーバーは、少数の2次元でXFRを実行するためだけに、すべてのTLS接続を受け入れる負担を処理する必要があります。拒否された応答へのクライアントの動作は明確に定義されていません（7.8項を参照）。現在、DNS権限サーバーの主要なオープンソース実装のどれもさまざまなトランスポートで異なる応答ポリシーのオプションを提供していない（ただし、そのような機能はプロキシを使用して潜在的に実装される可能性があります）。
In a similar fashion, XoT servers might use the presence of an SNI in the Client Hello to determine which response policy to initially apply to the TLS connections.
同様の方法では、XOTサーバはクライアントhello内のSNIの存在を使用して、最初にTLS接続に適用されるのかを判断することができる。
Pros: This has the potential to allow a clean distinction between a XoT service and any future DoT-based service for answering recursive queries.
長所：これは、XOTサービスと再帰的なクエリに答えるための将来のドットベースのサービスとの間のきれいな区別を可能にする可能性があります。
Cons: As above.
短所：上記のように。
Acknowledgements
謝辞
The authors thank Tony Finch, Benno Overeinder, Shumon Huque, Tim Wicinski, and many other members of DPRIVE for review and discussions.
著者らはTony Finch、Benno Overeinder、Shumon Huque、Tim Wicinski、そしてレビューや議論のための他の多くのメンバーに感謝します。
The authors particularly thank Peter van Dijk, Ondrej Sury, Brian Dickson, and several other open-source DNS implementers for valuable discussion and clarification on the issue associated with pipelining XFR queries and handling out-of-order/intermingled responses.
著者らは特にPeter Van Dijk、Ondrej Sure、Brian Dickson、および他のいくつかのオープンソースのDNS実装で、貴重な議論と明確化のために、XFRクエリのパイプライン化と順序の取り扱いに関連した問題について説明しています。
Contributors
貢献者
Significant contributions to the document were made by:
文書への重要な貢献は次のようにして行われました。
Han Zhang Salesforce San Francisco, CA United States of America
Han Zhang Salesforceサンフランシスコ、アメリカ合衆国
Email: hzhang@salesforce.com
Authors' Addresses
著者の住所
Willem Toorop NLnet Labs Science Park 400 1098 XH Amsterdam Netherlands
Willem Toorop NLNet Labs Science Park 400 1098 XHアムステルダムオランダ
Email: willem@nlnetlabs.nl
Sara Dickinson Sinodun IT Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom
SARA DICKINSON SINODUN ITマグダレンセンターオックスフォードサイエンスパークオックスフォードOX4 4GAイギリス
Email: sara@sinodun.com
Shivan Sahib Brave Software Vancouver BC Canada
Shivan Sahib Brave Software Vancouver BCカナダ
Email: shivankaulsahib@gmail.com
Pallavi Aras Salesforce Herndon, VA United States of America
Pallavi Aras Salesforce Herndon、VAアメリカ合衆国
Email: paras@salesforce.com
Allison Mankin Salesforce Herndon, VA United States of America
Allison Mankin Salesforce Herndon、アメリカ合衆国
Email: allison.mankin@gmail.com