RFC 9102 - TLS DNSSEC Chain Extension 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9102.html
タイトル : RFC 9102 - TLS DNSSECチェーン拡張
翻訳編集 : 自動生成

[要約] RFC 9102は、TLS接続のセキュリティを強化するためにDNSSECの情報をTLSハンドシェイクに組み込む方法を定義します。この拡張機能の目的は、クライアントがサーバーの身元をより確実に検証できるようにすることです。主に、セキュリティを重視するWeb通信やメールサーバーなどで利用されます。

Independent Submission                                       V. Dukhovni
Request for Comments: 9102                                     Two Sigma
Category: Experimental                                          S. Huque
ISSN: 2070-1721                                               Salesforce
                                                               W. Toorop
                                                              NLnet Labs
                                                              P. Wouters
                                                                   Aiven
                                                                M. Shore
                                                                  Fastly
                                                             August 2021

TLS DNSSEC Chain Extension

TLS DNSSECチェーン拡張

Abstract

概要

This document describes an experimental TLS extension for the in-band transport of the complete set of records that can be validated by DNSSEC and that are needed to perform DNS-Based Authentication of Named Entities (DANE) of a TLS server. This extension obviates the need to perform separate, out-of-band DNS lookups. When the requisite DNS records do not exist, the extension conveys a denial-of-existence proof that can be validated.

このドキュメントでは、DNSSECによって検証可能な、およびTLSサーバーの名前付きエンティティ（DANE）の認証を実行するために必要な一連のレコードの完全なセットのインバンドトランスポートの実験的TLS拡張について説明します。この拡張機能は、別々の帯域外DNSルックアップを実行する必要がなくなります。必要なDNSレコードが存在しない場合、拡張子は検証可能な存在証明を伝えます。

This experimental extension is developed outside the IETF and is published here to guide implementation of the extension and to ensure interoperability among implementations.

この実験的な拡張はIETFの外部で開発され、ここでは拡張の実装を導き、実装間の相互運用性を確保するために公開されています。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

この文書はインターネット標準のトラック仕様ではありません。検査、実験的実施、評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

この文書は、インターネットコミュニティの実験的プロトコルを定義しています。これは、他のRFCストリームとは無関係にRFCシリーズへの貢献です。RFCエディタは、この文書を裁量で公開することを選択し、実装または展開のためのその値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補者ではありません。RFC 7841のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9102.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9102で入手できます。

著作権表示

著作権（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.

この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。

Table of Contents

   1.  Introduction
     1.1.  Scope of the Experiment
     1.2.  Requirements Notation
   2.  DNSSEC Authentication Chain Extension
     2.1.  Protocol, TLS 1.2
     2.2.  Protocol, TLS 1.3
     2.3.  DNSSEC Authentication Chain Data
       2.3.1.  Authenticated Denial of Existence
   3.  Construction of Serialized Authentication Chains
   4.  Caching and Regeneration of the Authentication Chain
   5.  Expired Signatures in the Authentication Chain
   6.  Verification
   7.  Extension Pinning
   8.  Trust Anchor Maintenance
   9.  Virtual Hosting
   10. Operational Considerations
   11. Security Considerations
   12. IANA Considerations
   13. References
     13.1.  Normative References
     13.2.  Informative References
   Appendix A.  Test Vectors
     A.1.  "_443._tcp.www.example.com"
     A.2.  "_25._tcp.example.com" NSEC Wildcard
     A.3.  "_25._tcp.example.org" NSEC3 Wildcard
     A.4.  "_443._tcp.www.example.org" CNAME
     A.5.  "_443._tcp.www.example.net" DNAME
     A.6.  "_25._tcp.smtp.example.com" NSEC Denial of Existence
     A.7.  "_25._tcp.smtp.example.org" NSEC3 Denial of Existence
     A.8.  "_443._tcp.www.insecure.example" NSEC3 Opt-Out Insecure
           Delegation
   Acknowledgments
   Authors' Addresses

1. Introduction

1. はじめに

This document describes an experimental TLS [RFC5246] [RFC8446] extension for in-band transport of the complete set of resource records (RRs) validated by DNSSEC [RFC4033] [RFC4034] [RFC4035]. This extension enables a TLS client to perform DANE authentication [RFC6698] [RFC7671] of a TLS server without the need to perform out-of-band DNS lookups. Retrieval of the required DNS records may be unavailable to the client [DISCOVERY] or may incur undesirable additional latency.

このドキュメントでは、DNSSEC [RFC4033] [RFC4034] [RFC4034] [RFC4034] [RFC4034] [RFC4034] [RFC4034] [RFC4034] [RFC4034] [RFC4034] [RFC4034] [RFC4034] [RFC4034]。[RFC4034]。[RFC4446]の範囲内の実験的TLS [RFC8446]拡張子について説明します。この拡張機能により、帯域外DNSルックアップを実行する必要なしに、TLSクライアントがTLSサーバのDANE認証[RFC6698] [RFC7671]を実行できます。必要なDNSレコードの検索は、クライアント[検出]に対して使用できなくなるか、または望ましくない追加の待ち時間が発生する可能性があります。

The extension described here allows a TLS client to request that the TLS server return the DNSSEC authentication chain corresponding to its DNSSEC-validated DANE TLSA resource record set (RRset) or authenticated denial of existence of such an RRset (as described in Section 2.3.1). If the server supports this extension, it performs the appropriate DNS queries, builds the authentication chain, and returns it to the client. The server will typically use a previously cached authentication chain, but it will need to rebuild it periodically as described in Section 4. The client then authenticates the chain using a preconfigured DNSSEC trust anchor.

ここで説明されている拡張機能により、TLSクライアントは、TLSサーバがそのDNSSEC検証されたDANE TLSAリソースレコード・セット（RRSET）またはそのようなRRSetの存在の認証拒否を認証するように要求することを可能にします（セクション2.3.1で説明されているように）。）。サーバーがこの拡張機能をサポートしている場合は、適切なDNSクエリを実行し、認証チェーンを構築してクライアントに返します。サーバーは通常、以前にキャッシュされた認証チェーンを使用しますが、セクション4で説明されているように定期的に再構築する必要があります。その後、クライアントは事前設定されたDNSSEC Trust Anchorを使用してチェーンを認証します。

In the absence of TLSA records, this extension conveys the required authenticated denial of existence. Such proofs are needed to securely signal that specified TLSA records are not available so that TLS clients can safely fall back to authentication based on Public Key Infrastructure X.509 (PKIX, sometimes called WebPKI) if allowed by local policy. These proofs are also needed to avoid downgrade from opportunistic authenticated TLS (when DANE TLSA records are present) to unauthenticated opportunistic TLS (in the absence of DANE). Denial-of-existence records are also used by the TLS client to clear extension pins that are no longer relevant, as described in Section 7.

TLSAレコードがない場合、この拡張機能は必要な認証済み存在拒否を伝えます。このような証明は、ローカルポリシーで許可されていれば、TLSクライアントが公開鍵インフラストラクチャX.509（PKIX、WebPKIとも呼ばれる）を安全に立ち返すことができるように、指定されたTLSAレコードが使用できないことを確実にシグナリングする必要があります。これらの証明は、機会認証されたTLS（Dane TLSAレコードが存在する場合）からのダウングレードを避けるために（デーンがない場合）には、日和見の認証されたTLS（Dane TLSAレコードが存在する場合）を避けるために必要です。存在拒否レコードは、セクション7で説明されているように、もはや関連性がなくなる拡張ピンをクリアするためにTLSクライアントによっても使用されます。

This extension supports DANE authentication of either X.509 certificates or raw public keys, as described in the DANE specification [RFC6698] [RFC7671] [RFC7250].

この拡張機能は、Dane Specification [RFC6698] [RFC7671] [RFC7250]で説明されているように、X.509証明書または生の公開鍵のいずれかのデーン認証をサポートしています。

This extension also mitigates against an unknown key share (UKS) attack [DANE-UKS] when using raw public keys since the server commits to its DNS name (normally found in its certificate) via the content of the returned TLSA RRset.

この拡張機能は、サーバーが返されたTLSA RRSetのコンテンツを介してDNS名（通常は証明書にあります）にコミットされているため、未知のキーシェア（UKS）攻撃[DANE-UKS]に対しても軽減されます。

This experimental extension is developed outside the IETF and is published here to guide implementation of the extension and to ensure interoperability among implementations.

この実験的な拡張はIETFの外部で開発され、ここでは拡張の実装を導き、実装間の相互運用性を確保するために公開されています。

1.1. Scope of the Experiment

1.1. 実験の範囲

The mechanism described in this document is intended to be used with applications on the wider internet. One application of TLS well suited for the TLS DNSSEC Chain extension is DNS over TLS [RFC7858]. In fact, one of the authentication methods for DNS over TLS _is_ the mechanism described in this document, as specified in Section 8.2.2 of [RFC8310].

このドキュメントに記載されているメカニズムは、より広いインターネット上のアプリケーションと共に使用されることを意図しています。TLS DNSSECチェーン拡張によく適したTLSの1つのアプリケーションは、TLS上のDNS [RFC7858]です。実際、TLSを介したDNSの認証方法の1つは、[RFC8310]のセクション8.2.2で規定されているように、この文書に記載されているメカニズムです。

The need for this mechanism when using DANE to authenticate a DNS-over-TLS resolver is obvious, since DNS may not be available to perform the required DNS lookups. Other applications of TLS would benefit from using this mechanism as well. The client sides of those applications would not be required to be used on endpoints with a working DNSSEC resolver in order for them to use the DANE authentication of the TLS service. Therefore, we invite other TLS services to try out this mechanism as well.

DNSを使用してDNS-over-TLSリゾルバを認証するときのこのメカニズムの必要性は、DNSが必要なDNSルックアップを実行するのに利用できない可能性があるため、明らかです。TLSの他のアプリケーションもこのメカニズムを使用することからも利益を得ています。これらのアプリケーションのクライアント側は、TLSサービスのデーン認証を使用するために、Working DNSSECリゾルバを使用してエンドポイントで使用する必要はありません。したがって、このメカニズムも試すために他のTLSサービスを招待します。

In the TLS Working Group, concerns have been raised that the pinning technique as described in Section 7 would complicate deployability of the TLS DNSSEC chain extension. The goal of the experiment is to study these complications in real-world deployments. This experiment hopefully will give the TLS Working Group some insight into whether or not this is a problem.

TLSワーキンググループでは、セクション7に記載されているピン止め技術は、TLS DNSSECチェーン拡張のデプロイ可能性を複雑にすることが懸念されています。実験の目的は、実際の展開におけるこれらの合併症を研究することです。この実験は、これが問題であるかどうかについてTLSワーキンググループを洞察に与えることを願っています。

If the experiment is successful, it is expected that the findings of the experiment will result in an updated document for Standards Track approval.

実験が成功した場合、実験の調査結果は標準トラック承認のための更新された文書をもたらすと予想されます。

1.2. Requirements Notation

1.2. 要件表記法

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]で説明されているように、すべて大文字の場合にのみ解釈されます。

2. DNSSEC Authentication Chain Extension

2. DNSSEC認証チェーン拡張

2.1. Protocol, TLS 1.2

2.1. プロトコル、TLS 1.2

A client MAY include an extension of type "dnssec_chain" in the (extended) ClientHello. The "extension_data" field of this extension consists of the server's 16-bit TCP port number in network (big-endian) byte order. Clients sending this extension MUST also send the Server Name Identification (SNI) extension [RFC6066]. Together, these make it possible for the TLS server to determine which authenticated TLSA RRset chain needs to be used for the "dnssec_chain" extension.

クライアントは、（拡張）ClientHelloのタイプ「DNSSEC_CHAIN」の拡張を含めることができます。この拡張子の「Extension_Data」フィールドは、ネットワーク（Big-Endian）バイト順のサーバーの16ビットTCPポート番号で構成されています。この拡張子を送信するクライアントもサーバー名識別（SNI）拡張子[RFC6066]を送信する必要があります。これらは、TLSサーバが「DNSSEC_CHAIN」拡張子にどの認証されたTLSA RRSETチェーンを使用する必要があるかを判断することを可能にします。

When a server that implements (and is configured to enable the use of) this extension receives a "dnssec_chain" extension in the ClientHello, it MUST first check whether the requested TLSA RRset (based on the port number in this extension and hostname in the SNI extension) is associated with the server. If the extension, the SNI hostname, or the port number is unsupported, the server's extended ServerHello message MUST NOT include the "dnssec_chain" extension.

この拡張子を実装するサーバー（および使用を有効にするように設定）するサーバーがClientHelloで "DNSSEC_CHAIN"拡張子を受け取ると、最初に要求されたTLSA rrset（この拡張子のポート番号とSNIのホスト名に基づく）が確認されなければなりません。拡張子）はサーバーに関連付けられています。拡張子、SNI hostname、またはポート番号がサポートされていない場合、サーバーの拡張ServerHelloメッセージは "DNSSEC_CHAIN"拡張子を含めてはいけません。

Otherwise, the server's extended ServerHello message MUST contain a serialized authentication chain using the format described below. If the server does not have access to the requested DNS chain -- for example, due to a misconfiguration or expired chain -- the server MUST omit the extension rather than send an incomplete chain. Clients that are expecting this extension MUST interpret this as a downgrade attack and MUST abort the TLS connection. Therefore, servers MUST send denial-of-existence proofs unless, for the particular application protocol or service, clients are expected to continue even in the absence of such a proof. As with all TLS extensions, if the server does not support this extension, it will not return any authentication chain.

それ以外の場合、サーバーの拡張ServerHelloメッセージには、以下の形式を使用してシリアル化された認証チェーンが含まれている必要があります。たとえば、誤構成または期限切れチェーンのために、サーバーが要求されたDNSチェーンにアクセスできない場合 - サーバーは不完全なチェーンを送信するのではなく、サーバーは拡張子を省略する必要があります。この拡張機能を期待しているクライアントはこれをダウングレード攻撃として解釈し、TLS接続を中止する必要があります。したがって、サーバーは、特定のアプリケーションプロトコルまたはサービスのために、そのような証明がない場合でも顧客が続行されると予想されない限り、サーバーは存在拒否証明を送信しなければなりません。すべてのTLS拡張と同様に、サーバーがこの拡張機能をサポートしていない場合は、認証チェーンを返しません。

The set of supported combinations of a port number and SNI name may be configured explicitly by server administrators or could be inferred from the available certificates combined with a list of supported ports. It is important to note that the client's notional port number may be different from the actual port on which the server is receiving connections.

ポート番号とSNI名のサポートされている組み合わせのセットは、サーバー管理者によって明示的に構成されているか、またはサポートされているポートのリストと組み合わせた利用可能な証明書から推測できます。クライアントの概念的なポート番号が、サーバーが接続を受信している実際のポートとは異なる場合があります。

Differences between the client's notional port number and the actual port at the server could be a result of intermediate systems performing network address translation or a result of a redirect via HTTPS or SVCB records (both defined in [DNSOP-SVCB-HTTPS]).

クライアントの概念的なポート番号とサーバーの実際のポートの違いは、ネットワークアドレス変換を実行する中間システム、またはHTTPSまたはSVCBレコードを介したリダイレクトの結果（両方ともDNSOP-SVCB-HTTPS]）の結果である可能性があります。

Though a DNS zone's HTTPS or SVCB records may be signed, a client using this protocol might not have direct access to a validating resolver and might not be able to check the authenticity of the target port number or hostname. In order to avoid downgrade attacks via forged DNS records, the SNI name and port number inside the client extension MUST be based on the original SNI name and port and MUST NOT be taken from the encountered HTTPS or SVCB record. The client supporting this document and HTTPS or SVCB records MUST still use the HTTPS or SVCB records to select the target transport endpoint. Servers supporting this extension that are targets of HTTPS or SVCB records MUST be provisioned to process client extensions based on the client's logical service endpoint's SNI name and port as it is prior to HTTPS or SVCB indirection.

DNSゾーンのHTTPSまたはSVCBレコードを署名することができますが、このプロトコルを使用するクライアントは検証対象のリゾルバに直接アクセスできない可能性があり、ターゲットポート番号またはホスト名の信頼性を確認できない可能性があります。鍛造DNSレコードを介してダウングレード攻撃を回避するためには、クライアント拡張内部のSNI名とポート番号は、元のSNI名とポートに基づいており、検出されたHTTPSまたはSVCBレコードから取得してはなりません。このドキュメントとHTTPSまたはSVCBレコードをサポートするクライアントは、ターゲットトランスポートエンドポイントを選択するためにHTTPSまたはSVCBレコードを使用する必要があります。HTTPSまたはSVCBレコードのターゲットであるこの拡張子をサポートするサーバーは、HTTPSまたはSVCB間接の前のクライアントの論理サービスエンドポイントのSNI名とポートに基づいてクライアント拡張を処理するためにプロビジョニングされている必要があります。

2.2. Protocol, TLS 1.3

2.2. プロトコル、TLS 1.3

In TLS 1.3 [RFC8446], when the server receives the "dnssec_chain" extension, it adds its "dnssec_chain" extension to the extension block of the Certificate message containing the end-entity certificate being validated rather than to the extended ServerHello message.

TLS 1.3 [RFC8446]では、サーバーが「DNSSEC_CHAIN」拡張子を受信すると、拡張されたServerHelloメッセージではなく、検証されているエンドエンティティ証明書を含む証明書メッセージの拡張ブロックに「DNSSEC_CHAIN」拡張子を追加します。

The extension protocol behavior otherwise follows that specified for TLS version 1.2 [RFC5246].

その他の拡張プロトコルの動作は、TLSバージョン1.2 [RFC5246]に指定されています。

2.3. DNSSEC Authentication Chain Data

2.3. DNSSEC認証チェーンデータ

The "extension_data" field of the client's "dnssec_chain" extension MUST contain the server's 16-bit TCP port number in network (big-endian) byte order:

クライアントの「DNSSEC_CHAIN」拡張子の「Extension_Data」フィールドには、ネットワーク（Big-Endian）バイト順にサーバーの16ビットTCPポート番号を含める必要があります。

       struct {
           uint16 PortNumber;
       } DnssecChainExtension;

The "extension_data" field of the server's "dnssec_chain" extension MUST contain a DNSSEC authentication chain encoded in the following form:

サーバーの「DNSSEC_CHAIN」拡張子の「Extension_Data」フィールドには、次の形式でエンコードされたDNSSEC認証チェーンが含まれている必要があります。

       struct {
           uint16 ExtSupportLifetime;
           opaque AuthenticationChain<1..2^16-1>
       } DnssecChainExtension;

The ExtSupportLifetime value is the number of hours that the TLS server has committed itself to serving this extension. A value of zero prohibits the client from unilaterally requiring ongoing use of the extension based on prior observation of its use (extension pinning). This is further described in Section 7.

extSupportLifeTime値は、TLSサーバーがこの拡張機能を提供するように自分自身をコミットした時間数です。ゼロの値は、その使用の前の観察（拡張ピニング）に基づいて、延長の継続的な継続的な使用を一方的に必要とすることを禁止する。これはセクション7でさらに説明される。

The AuthenticationChain is composed of a sequence of uncompressed wire format DNS RRs (including all requisite RRSIG RRs [RFC4034]) in no particular order. The format of the resource record is described in [RFC1035], Section 3.2.1.

認証チェーンは、特定の順序なしで、一連の非圧縮ワイヤフォーマットDNS RR（RRSIG RRS [RFC4034]を含む）で構成されています。リソースレコードのフォーマットは[RFC1035]、3.2.1に記載されています。

       RR = { owner, type, class, TTL, RDATA length, RDATA }

The order of returned RRs is unspecified, and a TLS client MUST NOT assume any ordering of RRs.

返されたRRSの順序は指定されていません、そしてTLSクライアントはRRSの順序を想定してはいけません。

Use of DNS wire format records enables easier generation of the data structure on the server and easier verification of the data on the client by means of existing DNS library functions.

DNSワイヤフォーマットレコードを使用すると、サーバー上のデータ構造をより簡単に生成することができ、既存のDNSライブラリ関数によってクライアント上のデータの検証が簡単になります。

The returned RRsets MUST contain either the TLSA RRset or the associated denial-of-existence proof of the configured (and requested) SNI name and port. In either case, the chain of RRsets MUST be accompanied by the full set of DNS records needed to authenticate the TLSA record set or its denial of existence up the DNS hierarchy to either the root zone or another trust anchor mutually configured by the TLS server and client.

返されたRRSETSには、設定されている（および要求された）SNI名とポートのTLSA RRSETまたは関連する存在拒否証明のいずれかを含める必要があります。どちらの場合でも、RRSETのチェーンには、TLSAレコードセットを認証するために必要なDNSレコードのフルセット、またはTLSサーバーによって相互に設定されているルートゾーンまたは別の信頼アンカーのいずれかのDNS階層の拒否を伴う必要があります。クライアント。

When some subtree in the chain is subject to redirection via DNAME records, the associated inferred CNAME records need not be included. They can be inferred by the DNS validation code in the client. Any applicable ordinary CNAME records that are not synthesized from DNAME records MUST be included along with their RRSIGs.

チェーン内のサブツリーがDNAMEレコードを介してリダイレクトされる可能性がある場合は、関連する推定CNAMEレコードを含める必要はありません。それらはクライアント内のDNS検証コードによって推測されます。DNAMEレコードから合成されていない適切な通常のCNAMEレコードは、RRSIGと一緒に含める必要があります。

In case of a server-side DNS problem, servers may be unable to construct the authentication chain and would then have no choice but to omit the extension.

サーバー側のDNSの問題が発生した場合、サーバーは認証チェーンを構築できなくなり、その後拡張子を省略する必要はありません。

In the case of a denial-of-existence response, the authentication chain MUST include all DNSSEC-signed records, starting with those from the trust anchor zone, that chain together to reach a proof of either:

存在拒否応答の場合、認証チェーンは、信頼アンカーゾーンからのもの、そのチェーンから始めて、そのチェーンからのすべてのDNSSEC署名付きレコードを含める必要があります。

* the nonexistence of the TLSA records (possibly redirected via aliases) or

* TLSAレコードの存在しない（おそらくエイリアスを介してリダイレクトされます）。

* an insecure delegation above or at the (possibly redirected) owner name of the requested TLSA RRset.

* 要求されたTLSA rrsetの上の不安定な代表団は、または（おそらくリダイレクトされた）所有者名。

Names that are aliased via CNAME and/or DNAME records may involve multiple branches of the DNS tree. In this case, the authentication chain structure needs to include DS and DNSKEY record sets that cover all the necessary branches.

CNAMEおよび/またはDNAMEレコードを介してエイリアスされている名前は、DNSツリーの複数のブランチを含みます。この場合、認証チェーン構造は、必要なすべてのブランチをカバーするDSおよびDNSKEYレコードセットを含める必要があります。

The returned chain SHOULD also include the DNSKEY RRsets of all relevant trust anchors (typically just the root DNS zone). Though the same trust anchors are presumably also preconfigured in the TLS client, including them in the response from the server permits TLS clients to use the automated trust anchor rollover mechanism defined in [RFC5011] to update their configured trust anchors.

返されたチェーンには、関連するすべての信託アンカーのDNSKey RRSET（通常はルートDNSゾーンだけ）も含める必要があります。同じ信頼のアンカーはTLSクライアントでも事前設定されていますが、サーバーからの応答には、TLSクライアントが[RFC5011]で定義されている自動トラストアンカーロールオーバーメカニズムを使用して設定された信頼アンカーを更新することができます。

Barring prior knowledge of particular trust anchors that the server shares with its clients, the chain constructed by the server MUST be extended as closely as possible to the root zone. Truncation of the chain at some intermediate trust anchor is generally only appropriate inside private networks where all clients and the server are expected to be configured with DNS trust anchors for one or more non-root domains.

サーバーがクライアントと共有する特定の信頼アンカーに関する事前の知識を考慮に入れると、サーバーによって構築されたチェーンはルートゾーンにできるだけ厳密に拡張されなければなりません。一部の中間信頼アンカーでのチェーンの切り捨ては、一般に、すべてのクライアントとサーバーが1つ以上の非ルートドメインのDNS Trustアンカーで構成されていると予想されるプライベートネットワーク内でのみ適切です。

The following is an example of the records in the AuthenticationChain structure for the HTTPS server at "www.example.com", where there are zone cuts at "com" and "example.com" (record data are omitted here for brevity):

以下は、 "www.example.com"のHTTPSサーバーの認証チェーン構造内のレコードの例です。ここで、 "com"と "example.com"にゾーンカットがある場合（レコードデータはここでは簡潔にするために省略されます）。

_443._tcp.www.example.com. TLSA RRSIG(_443._tcp.www.example.com. TLSA) example.com. DNSKEY RRSIG(example.com. DNSKEY) example.com. DS RRSIG(example.com. DS) com. DNSKEY RRSIG(com. DNSKEY) com. DS RRSIG(com. DS) . DNSKEY RRSIG(. DNSKEY)

_443._tcp.www.example.com。TLSA RRSIG（_443._tcp.www.example.com。TLSA）example.com。DNSKEY RRSIG（example.com。DNSKEY）example.com。DS RRSIG（example.com。DS）COM。DNSKEY RRSIG（COM。DNSKEY）COM。DS RRSIG（COM。DS）。DNSKEY RRSIG（。DNSKEY）

The following is an example of denial of existence for a TLSA RRset at "_443._tcp.www.example.com". The NSEC record in this example asserts the nonexistence of both the requested RRset and any potentially relevant wildcard records.

以下は、 "_443._tcp.www.example.com"のTLSA RRSetの存在拒否の例です。この例のNSECレコードは、要求されたRRSetと潜在的に関連するワイルドカードレコードの両方の存在しないことをアサートします。

www.example.com. IN NSEC example.com. A NSEC RRSIG RRSIG(www.example.com. NSEC) example.com. DNSKEY RRSIG(example.com. DNSKEY) example.com. DS RRSIG(example.com. DS) com. DNSKEY RRSIG(com. DNSKEY) com. DS RRSIG(com. DS) . DNSKEY RRSIG(. DNSKEY)

www.example.com。NSEC example.comで。NSEC RRSIG RRSIG（www.example.com .NSEC）example.com。DNSKEY RRSIG（example.com。DNSKEY）example.com。DS RRSIG（example.com。DS）COM。DNSKEY RRSIG（COM。DNSKEY）COM。DS RRSIG（COM。DS）。DNSKEY RRSIG（。DNSKEY）

The following is an example of (hypothetical) insecure delegation of "example.com" from the ".com" zone. This example shows NSEC3 records [RFC5155] with opt-out.

以下は、 ".com"ゾーンからの "example.com"の（仮説的な）不安定な委任の例です。この例では、NSEC3レコード[RFC5155]がオプトアウトで示しています。

   ; covers example.com
   onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3 (1 1 0 -
     onib9mgub9h0rml3cdf5bgrj59dkjhvl NS DS RRSIG)
   RRSIG(onib9mgub9h0rml3cdf5bgrj59dkjhvj.com. NSEC3)
   ; covers *.com
   3rl2r262eg0n1ap5olhae7mah2ah09hi.com. NSEC3 (1 1 0 -
     3rl2r262eg0n1ap5olhae7mah2ah09hk NS DS RRSIG)
   RRSIG(3rl2r262eg0n1ap5olhae7mah2ah09hj.com. NSEC3)
   ; closest-encloser "com"
   ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3 (1 1 0 -
     ck0pojmg874ljref7efn8430qvit8bsm.com
     NS SOA RRSIG DNSKEY NSEC3PARAM)
   RRSIG(ck0pojmg874ljref7efn8430qvit8bsm.com. NSEC3)
   com. DNSKEY
   RRSIG(com. DNSKEY)
   com. DS
   RRSIG(com. DS)
   . DNSKEY
   RRSIG(. DNSKEY)

2.3.1. Authenticated Denial of Existence

2.3.1. 認証された存在拒否

TLS servers that support this extension and respond to a request containing this extension that do not have a signed TLSA record for the configured (and requested) SNI name and port MUST instead return a DNSSEC chain that provides authenticated denial of existence for the configured SNI name and port. A TLS client receiving proof of authenticated denial of existence MUST use an alternative method to verify the TLS server identity or close the connection. Such an alternative could be the classic PKIX model of preinstalled root certificate authorities (CAs).

この拡張をサポートし、設定された（および要求された）SNI名とポートの署名付きTLSAレコードを持たないこの拡張子を含む要求に応答するTLSサーバーは、代わりに設定されたSNI名の認証済みの存在拒否を提供するDNSSECチェーンを返してください。そして港。認証された存在拒否の証明を受け取るTLSクライアントは、TLS Server IDを検証するか、接続を閉じるための代替方法を使用する必要があります。そのような代替手段は、インストールされたルート認証局（CAS）の古典的なPKIXモデルであり得る。

Authenticated denial chains include NSEC or NSEC3 records that demonstrate one of the following facts:

認証された拒否チェーンには、次の事実のいずれかを示すNSECまたはNSEC3レコードが含まれます。

* The TLSA record (after any DNSSEC-validated alias redirection) does not exist.

* TLSAレコード（DNSSEC検証済みエイリアスリダイレクト後）が存在しません。

* There is no signed delegation to a DNS zone that is either an ancestor of or the same as the TLSA record name (after any DNSSEC-validated alias redirection).

* TLSAレコード名（DNSSEC検証済みエイリアスリダイレクトの後に）の先祖または同じであるDNSゾーンへの署名付き委任はありません。

3. Construction of Serialized Authentication Chains

3. 直列化認証チェーンの構築

This section describes a possible procedure for the server to use to build the serialized DNSSEC chain.

このセクションでは、サーバーがシリアル化されたDNSSECチェーンを構築するために使用するための可能な手順について説明します。

When the goal is to perform DANE authentication [RFC6698] [RFC7671] of the server, the DNS record set to be serialized is a TLSA record set corresponding to the server's domain name, protocol, and port number.

目標がDANE認証を実行することをサーバーのDANE認証[RFC6698] [RFC7671]を実行する場合、シリアル化するDNSレコードは、サーバーのドメイン名、プロトコル、およびポート番号に対応するTLSAレコードセットです。

The domain name of the server MUST be that included in the TLS "server_name" (SNI) extension [RFC6066]. If the server does not recognize the SNI name as one of its own names but wishes to proceed with the handshake rather than abort the connection, the server MUST NOT send a "dnssec_chain" extension to the client.

サーバーのドメイン名は、TLS "server_name"（SNI）拡張子[RFC6066]に含まれている必要があります。サーバーがそれ自身の名前の1つとしてSNI名を認識しないが、接続を中止するのではなくハンドシェイクを進めることを希望する場合、サーバーは「DNSSEC_CHAIN」拡張子をクライアントに送信してはなりません。

The name in the client's SNI extension MUST NOT be CNAME expanded by the server. The TLSA base domain (Section 3 of [RFC6698]) SHALL be the hostname from the client's SNI extension, and the guidance in Section 7 of [RFC7671] does not apply. See Section 9 for further discussion.

クライアントのSNI拡張子内の名前は、サーバーによってCNAMEに展開されてはいけません。TLSAベースドメイン（[RFC6698]のセクション3）は、クライアントのSNI拡張のホスト名であり、[RFC7671]のセクション7のガイダンスは適用されません。さらなる議論については9節を参照してください。

The TLSA record to be queried is constructed by prepending underscore-prefixed port number and transport name labels to the domain name as described in [RFC6698]. The port number is taken from the client's "dnssec_chain" extension. The transport name is "tcp" for TLS servers and "udp" for DTLS servers. The port number label is the leftmost label, followed by the transport name label, followed by the server domain name (from SNI).

照会されるTLSAレコードは、[RFC6698]で説明されているように、アンダースコアプレフィックス付きポート番号とトランスポート名ラベルをドメイン名に追加することによって構築されます。ポート番号は、クライアントの「DNSSEC_CHAIN」拡張子から取得されます。トランスポート名は、TLSサーバー用の「TCP」とDTLSサーバー用の「UDP」です。ポート番号のラベルは左端のラベルであり、その後にトランスポート名のラベルが続き、その後にサーバードメイン名が続きます（SNI）。

The components of the authentication chain are typically built by starting at the target record set and its corresponding RRSIG, then traversing the DNS tree upwards towards the trust anchor zone (normally the DNS root). For each zone cut, the DNSKEY, DS RRsets, and their signatures are added. However, see Section 2.3 for specific processing needed for aliases. If DNS response messages contain any domain names utilizing name compression [RFC1035], then they MUST be uncompressed prior to inclusion in the chain.

認証チェーンのコンポーネントは通常、ターゲットレコードセットとその対応するRRSIGから始めて構築され、次にDNSツリーを信頼アンカーゾーン（通常はDNSルート）に向かって上向きに移動します。各ゾーンカットの場合、DNSKEY、DS RRSET、およびそれらのシグニチャが追加されます。ただし、エイリアスに必要な特定の処理については、セクション2.3を参照してください。DNS応答メッセージに名前の圧縮を利用したドメイン名が含まれている場合は、[RFC1035]を含めて、それらをチェーンに含める前に圧縮されなければなりません。

Implementations of EDNS CHAIN query requests as specified in [RFC7901] may offer an easier way to obtain all of the chain data in one transaction with an upstream DNSSEC-aware recursive server.

[RFC7901]で指定されているEDNSチェーンクエリ要求の実装は、アップストリームDNSSEC対応再帰サーバーを使用して1つのトランザクション内のすべてのチェーンデータを取得するための簡単な方法を提供することがあります。

4. Caching and Regeneration of the Authentication Chain

4. 認証チェーンのキャッシングと再生

DNS records have Time To Live (TTL) parameters, and DNSSEC signatures have validity periods (specifically signature expiration times). After the TLS server constructs the serialized authentication chain, it SHOULD cache and reuse it in multiple TLS connection handshakes. However, it SHOULD refresh and rebuild the chain as TTL values require. A server implementation could carefully track TTL parameters and requery component records in the chain correspondingly. Alternatively, it could be configured to rebuild the entire chain at some predefined periodic interval that does not exceed the DNS TTLs of the component records in the chain. If a record in the chain has a very short TTL (e.g., 0 up to a few seconds), the server MAY decide to serve the authentication chain a few seconds past the minimum TTL in the chain. This allows an implementation to dedicate a process or single thread to building the authentication chain and reuse it for more than a single waiting TLS client before needing to rebuild the authentication chain.

DNSレコードにはLive（TTL）パラメータに時間があり、DNSSECシグニチャには有効期間（特にシグネチャの有効期限）があります。 TLS Serverがシリアル化認証チェーンを構築した後、それはキャッシュして複数のTLS接続ハンドシェイクでそれを再利用する必要があります。ただし、TTL値が必要な場合は、チェーンを更新して再構築する必要があります。サーバー実装は、チェーン内のTTLパラメータおよびクレオリーコンポーネントレコードを対応して慎重に追跡することができます。あるいは、チェーン内のコンポーネントレコードのDNS TTLSを超えない、チェーン全体を再構築するように構成することもできます。チェーン内のレコードが非常に短いTTL（例えば、0.2秒まで）を有する場合、サーバはチェーン内の最小TTLを数秒経過した認証チェーンにサービスを提供することを決定することができる。これにより、実装は、認証チェーンを構築して認証チェーンを再構築する前に、プロセスまたはシングルスレッドを専用にし、それを単一の待機中のTLSクライアントのために再利用することができます。

5. Expired Signatures in the Authentication Chain

5. 認証チェーン内の期限切れのシグネチャ

A server MAY look at the signature expiration of RRSIG records. While these should never expire before the TTL of the corresponding DNS record is reached, if this situation is nevertheless encountered, the server MAY lower the TTL to prevent serving expired RRSIGs if possible. If the signatures are already expired, the server MUST still include these records in the authentication chain. This allows the TLS client to either support a grace period for staleness or give a detailed error, either as a log message or a message to a potential interactive user of the TLS connection. The TLS client SHOULD handle expired RRSIGs similarly to how it handles expired PKIX certificates.

サーバーはRRSIGレコードのシグネチャの有効期限を調べることがあります。これらが対応するDNSレコードのTTLに達する前に期限切れになるはずではないが、この状況が発生した場合、サーバはTTLを下げることができ、可能であれば期限切れのRRSIGSを処理するのを防ぐことができる。署名がすでに期限切れになっている場合、サーバーはまだこれらのレコードを認証チェーンに含める必要があります。これにより、TLSクライアントは、LOGメッセージまたはTLS接続の潜在的な対話型ユーザーへのメッセージとして、細部をサポートするか、または詳細なエラーを与えることができます。TLSクライアントは、期限切れのPKIX証明書をどのように処理するかと同様に、期限切れのRRSIGを処理する必要があります。

6. Verification

6. 検証

A TLS client performing DANE-based verification might not need to use this extension. For example, the TLS client could perform DNS lookups and DANE verification without this extension, or it could fetch authentication chains via another protocol. If the TLS client already possesses a valid TLSA record, it MAY bypass use of this extension. However, if it includes this extension, it MUST use the TLS server reply to update the extension pinning status of the TLS server's extension lifetime. See Section 7.

DANEベースの検証を実行するTLSクライアントは、この拡張機能を使用する必要がないかもしれません。たとえば、TLSクライアントはこの拡張なしにDNSルックアップとデーン検証を実行することも、他のプロトコルを介して認証チェーンを取得することもできます。TLSクライアントが既に有効なTLSAレコードを所有している場合は、この拡張機能の使用をバイパスすることがあります。ただし、この拡張機能が含まれている場合は、TLSサーバーのエクステンションの有効期間の拡張子ピン止めステータスを更新するには、TLSサーバーの応答を使用する必要があります。7を参照してください。

A TLS client making use of this specification that receives a valid DNSSEC authentication chain extension from a TLS server MUST use this information to perform DANE authentication of the TLS server. In order to perform the validation, it uses the mechanism specified by the DNSSEC protocol [RFC4035] [RFC5155]. This mechanism is sometimes implemented in a DNSSEC validation engine or library.

TLSサーバーから有効なDNSSEC認証チェーン拡張を受信するこの仕様を使用したTLSクライアントは、TLSサーバーのデーン認証を実行するためにこの情報を使用する必要があります。検証を実行するために、DNSSECプロトコル[RFC4035] [RFC5155]で指定されたメカニズムを使用します。このメカニズムは、DNSSEC検証エンジンまたはライブラリに実装されることがあります。

If the authentication chain validates, the TLS client then performs DANE authentication of the server according to the DANE TLS protocol [RFC6698] [RFC7671].

認証チェーンが検証すると、TLSクライアントはDane TLSプロトコル[RFC6698] [RFC7671]に従ってサーバのデーン認証を実行します。

Clients MAY cache the server's validated TLSA RRset to amortize the cost of receiving and validating the chain over multiple connections. The period of such caching MUST NOT exceed the TTL associated with those records. A client that possesses a validated and unexpired TLSA RRset or the full chain in its cache does not need to send the "dnssec_chain" extension for subsequent connections to the same TLS server. It can use the cached information to perform DANE authentication.

クライアントは、サーバーの検証されたTLSA RRSetをキャッシュして、複数の接続を介してチェーンの受信および検証のコストを充電することができます。そのようなキャッシュの期間は、それらのレコードに関連付けられているTTLを超えてはいけません。検証済みおよび期限切れのTLSA RRSetまたはそのキャッシュ内のフルチェーンを持つクライアントは、同じTLSサーバーへの後続の接続に対して「DNSSEC_CHAIN」拡張子を送信する必要はありません。キャッシュされた情報を使用してデーン認証を実行できます。

Note that when a client and server perform TLS session resumption, the server sends no "dnssec_chain". This is particularly clear with TLS 1.3, where the certificate message to which the chain might be attached is also not sent on resumption.

クライアントとサーバーがTLSセッションの再開を実行すると、サーバーは「DNSSEC_CHAIN」を送信しません。これはTLS 1.3では特に明確です。ここで、チェーンが接続されている証明書メッセージも再開時に送信されません。

7. Extension Pinning

7. 拡張ピニング

TLS applications can be designed to unconditionally mandate this extension. Such TLS clients requesting this extension would abort a connection to a TLS server that does not respond with an extension reply that can be validated.

TLSアプリケーションは無条件にこの拡張を義務付けるように設計できます。この拡張機能を要求するそのようなTLSクライアントは、検証可能なエクステンション応答で応答しないTLSサーバへの接続を中止します。

However, in a mixed-use deployment of PKIX and DANE, there is the possibility that the security of a TLS client is downgraded from DANE to PKIX. This can happen when a TLS client connection is intercepted and redirected to a rogue TLS server presenting a TLS certificate that is considered valid from a PKIX point of view but does not match the legitimate server's TLSA records. By omitting this extension, such a rogue TLS server could downgrade the TLS client to validate the mis-issued certificate using only PKIX and not via DANE, provided the TLS client is also not able to fetch the TLSA records directly from DNS.

ただし、PKIXとDANEの混在使用展開では、TLSクライアントのセキュリティがDANEからPKIXに格下げされる可能性があります。これは、PKIXのビューから有効であるが正当なサーバのTLSAレコードと一致しない、TLSクライアント接続が傍受され、Rogue TLSサーバーにリダイレクトされたときに発生する可能性があります。この拡張機能を省略すると、そのような不正なTLSサーバは、TLSクライアントを介してPKIXを使用して失敗した証明書を検証することができ、TLSクライアントがDNSから直接TLSAレコードを取得することができない場合には、TLSクライアントを発行した証明書を検証できます。

The ExtSupportLifetime element of the extension provides a countermeasure against such downgrade attacks. Its value represents the number of hours that the TLS server (or cluster of servers serving the same server name) commits to serving this extension in the future. This is referred to as the "pinning time" or "extension pin" of the extension. A non-zero extension pin value received MUST ONLY be used if the extension also contains a valid TLSA authentication chain that matches the server's certificate chain (the server passes DANE authentication based on the enclosed TLSA RRset).

拡張子のextSupportLifetime要素は、そのような格下の攻撃に対する対策を提供します。その値は、将来この拡張機能を提供することを約束するためにTLSサーバ（またはサーバのクラスタ）がコミットする時間数を表します。これは、拡張の「ピン止め時間」または「拡張ピン」と呼ばれます。エクステンションには、サーバーの証明書チェーンに一致する有効なTLSA認証チェーンも含まれている場合にのみ、ゼロ以外の拡張子ピン値を使用する必要があります（サーバは、囲まれたTLSA RRSetに基づいてデーン認証を渡します）。

Any existing extension pin for the server instance (name and port) MUST be cleared on receipt of a valid denial of existence for the associated TLSA RRset. The same also applies if the client obtained the denial-of-existence proof via another method, such as through direct DNS queries. Based on the TLS client's local policy, it MAY then terminate the connection or MAY continue using PKIX-based server authentication.

サーバーインスタンス（名前とポート）の既存の拡張ピンは、関連するTLSA RRSetの有効な存在の拒否を受信してクリアする必要があります。クライアントが、直接DNSクエリを介して、別の方法を介して存在拒否プルーフを取得した場合も同様です。その後、TLSクライアントのローカルポリシーに基づいて、接続を終了するか、PKIXベースのサーバー認証を使用している場合があります。

Extension pins MUST also be cleared upon the completion of a DANE-authenticated handshake with a server that returns a "dnssec_chain" extension with a zero ExtSupportLifetime.

拡張子ピンは、ゼロextSupportLifetimeを使用して「DNSSEC_CHAIN」拡張子を返すサーバーを使用して、DANE認証されたハンドシェイクが完了するとクリアされなければなりません。

Upon completion of a fully validated handshake with a server that returns a "dnssec_chain" extension with a non-zero ExtSupport lifetime, the client MUST update any existing pin lifetime for the service (name and port) to a value that is not longer than that indicated by the server. The client MAY, subject to local policy, create a previously nonexistent pin, again for a lifetime that is not longer than that indicated by the server.

ゼロ以外のextSupport LifeTimeを使用して「DNSSEC_CHAIN」拡張子を返すサーバーを使用した完全に検証されたハンドシェイクが完了すると、クライアントはサービス（名前とポート）の既存のPINライフタイムをそれ以外の値に更新する必要があります。サーバーによって示されます。クライアントは、ローカルポリシーを受けることがあります。これまでにサーバーが示していないリフタイムに対して、以前は存在しないピンを作成します。

The extension support lifetime is not constrained by any DNS TTLs or RRSIG expirations in the returned chain. The extension support lifetime is the time for which the TLS server is committing itself to serve the extension; it is not a validity time for the returned chain data. During this period, the DNSSEC chain may be updated. Therefore, the ExtSupportLifetime value is not constrained by any DNS TTLs or RRSIG expirations in the returned chain.

拡張サポートの有効期間は、返されたチェーン内のDNS TTLSまたはRRSIGの呼び方によって制約されていません。拡張サポートの有効期間は、TLSサーバーが拡張機能を果たすために自分自身をコミットしている時間です。返されたチェーンデータの有効期間ではありません。この間、DNSSECチェーンを更新することができます。したがって、extSupportLifeTime値は、返されたチェーン内のDNS TTLSまたはRRSIGの呼び方によって制約されません。

Clients MAY implement support for a subset of DANE certificate usages. For example, clients may support only DANE-EE(3) and DANE-TA(2) [RFC7218], only PKIX-EE(1) and PKIX-TA(0), or all four. Clients that implement DANE-EE(3) and DANE-TA(2) MUST implement the relevant updates in [RFC7671].

クライアントは、デーン証明書の使用状況のサブセットのサポートを実装することができます。例えば、クライアントは、DANE - EE（3）およびDANE - TA（2）[RFC7218]、PKIX - EE（1）およびPKIX - TA（0）のみ、または4つだけをサポートすることができる。dane-ee（3）とdane-ta（2）を実装するクライアントは、[RFC7671]に関連する更新を実装する必要があります。

For a non-zero saved value ("pin") of the ExtSupportLifetime element of the extension, TLS clients that do not have a cached TLSA RRset with an unexpired TTL MUST use the extension for the associated name and port to obtain this information from the TLS server. This TLS client then MUST require that the TLS server respond with this extension, which MUST contain a valid TLSA RRset or proof of nonexistence of the TLSA RRset that covers the requested name and port. Note that a nonexistence proof or proof of insecure delegation will clear the pin. The TLS client MUST require this for as long as the time period specified by the pin value, independent of the DNS TTLs. During this process, if the TLS client fails to receive this information, it MUST either abort the connection or delay communication with the server via the TLS connection until it is able to obtain valid TLSA records (or proof of nonexistence) out of band, such as via direct DNS lookups. If attempts to obtain the TLSA RRset out of band fail, the client MUST abort the TLS connection. It MAY try a new TLS connection again (for example, using an exponential back-off timer) in an attempt to reach a different TLS server instance that does properly serve the extension.

拡張子のExtSupportLifetime要素のゼロ以外の保存値（ "PIN"）の場合、期限切れのTLSA RRSetを持つCached TLSA RRSetを持たないTLSクライアントは、関連する名前とポートの拡張子を使用してこの情報を取得する必要があります。 TLSサーバーその後、このTLSクライアントでは、TLSサーバーがこの拡張子で応答する必要があります。これには、要求された名前とポートをカバーするTLSA RRSetの有効なTLSA RRSetまたは実証が含まれている必要があります。不安定な証明または不安定な委任の証明がピンをクリアすることに注意してください。 TLSクライアントは、DNS TTLSとは無関係に、PIN値によって指定された期間限りでこれを要求する必要があります。このプロセスの間、TLSクライアントがこの情報を受信できない場合は、有効なTLSAレコード（または存在の証明）が帯域外に取得できるようになるまで、接続を中止したり、サーバーとの通信を中止する必要があります。直接DNSルックアップを介して。帯域外のTLSA RRSETを取得しようとすると失敗した場合、クライアントはTLS接続を中止する必要があります。拡張機能を適切に提供する別のTLSサーバーインスタンスに到達しようとして、新しいTLS接続を（たとえば、指数バックオフタイマーを使用して）再度試してください。

A TLS client that has a cached validated TLSA RRset and a valid non-zero extension pin time MAY still refrain from requesting the extension as long as it uses the cached TLSA RRset to authenticate the TLS server. This RRset MUST NOT be used beyond its received TTL. Once the TLSA RRset's TTL has expired, the TLS client with a valid non-zero extension pin time MUST request the extension and MUST abort the TLS connection if the server responds without the extension. A TLS client MAY attempt to obtain the valid TLSA RRset by some other means before initiating a new TLS connection.

キャッシュされた検証されたTLSA RRSetと有効なゼロ以外の拡張ピン時間を持つTLSクライアントは、キャッシュされたTLSA RRSetを使用してTLSサーバーを認証する限り、拡張機能を要求することを控えてください。このRRセットは、受信したTTLを超えて使用してはいけません。TLSA RRSetのTTLが期限切れになると、有効なゼロ以外の拡張子PIN時間を持つTLSクライアントは拡張子を要求し、サーバーが拡張子なしで応答した場合はTLS接続を中止する必要があります。TLSクライアントは、新しいTLS接続を開始する前に、他の手段によって有効なTLSA RRSetを取得しようとする可能性があります。

Note that requiring the extension is NOT the same as requiring the use of DANE TLSA records or even DNSSEC. A DNS zone operator may at any time delete the TLSA records or even remove the DS records to disable the secure delegation of the server's DNS zone. The TLS server will replace the chain with the corresponding denial-of-existence chain when it updates its cached TLSA authentication chain. The server's only obligation is continued support for this extension.

拡張子を必要とすることは、Dane TLSAレコードの使用またはDNSSECの使用を要求することと同じではないことに注意してください。DNSゾーンオペレータはいつでもTLSAレコードを削除したり、サーバーのDNSゾーンの安全な委任を無効にするためにDSレコードを削除したりすることさえできます。TLSサーバーは、キャッシュされたTLSA認証チェーンを更新するときに、チェーンを対応する存在拒否チェーンと置き換えます。サーバーの唯一の義務は、この拡張のための継続的なサポートです。

8. Trust Anchor Maintenance

8. 信頼アンカーメンテナンス

The trust anchor may change periodically, e.g., when the operator of the trust anchor zone performs a DNSSEC key rollover. TLS clients using this specification MUST implement a mechanism to keep their trust anchors up to date. They could use the method defined in [RFC5011] to perform trust anchor updates in-band in TLS by tracking the introduction of new keys seen in the trust anchor DNSKEY RRset. However, alternative mechanisms external to TLS may also be utilized. Some operating systems may have a system-wide service to maintain and keep the root trust anchor up to date. In such cases, the TLS client application could simply reference that as its trust anchor, periodically checking whether it has changed. Some applications may prefer to implement trust anchor updates as part of their automated software updates.

信頼アンカーゾーンのオペレータがDNSSECキーロールオーバーを実行すると、信頼アンカーは定期的に変化することができる。この仕様を使用しているTLSクライアントは、信頼のアンカーを最新の状態に保つためのメカニズムを実装する必要があります。RFC5011で定義された方法を使用して、TLSのインバンド内のインバンドをTLSのインバンドインバンドの更新を実行できます。これは、信頼Anchor DNSKEY RRSETに表示されている新しいキーの導入を追跡します。しかしながら、TLSの外部の代替のメカニズムもまた利用され得る。一部のオペレーティングシステムは、根本的な信頼を最新のアンカーに保つためのシステム全体のサービスを提供することがあります。そのような場合、TLSクライアントアプリケーションは、それが定期的に変更されたかどうかを定期的にチェックしているというTLSクライアントアプリケーションを単に参照できます。一部のアプリケーションは、自動化されたソフトウェアアップデートの一部として信頼アンカーアップデートを実装することを好むかもしれません。

9. Virtual Hosting

9. 仮想ホスティング

Delivery of application services is often provided by a third party on behalf of the domain owner (hosting customer). Since the domain owner may want to be able to move the service between providers, non-zero support lifetimes for this extension should only be enabled by mutual agreement between the provider and domain owner.

アプリケーションサービスの配信は、ドメイン所有者（ホスティング顧客）に代わって第三者によって提供されます。ドメインの所有者はプロバイダ間でサービスを移動させることができるので、この拡張のためのゼロ以外のサポート寿命は、プロバイダとドメイン所有者の間の相互合意によってのみ有効にされるべきである。

When CNAME records are employed to redirect network connections to the provider's network, as mentioned in Section 3, the server uses the client's SNI hostname as the TLSA base domain without CNAME expansion. When the certificate chain for the service is managed by the provider, it is impractical to coordinate certificate changes by the provider with updates in the hosting customer's DNS. Therefore, the TLSA RRset for the hosted domain is best configured as a CNAME from the customer's domain to a TLSA RRset that is managed by the provider as part of delivering the hosted service. For example:

セクション3で述べたように、CNameレコードをプロバイダのネットワークにリダイレクトするために採用されている場合、サーバーはCNAME展開なしでTLSAベースドメインとしてクライアントのSNIホスト名を使用します。サービスの証明書チェーンがプロバイダによって管理されている場合は、ホスティング顧客のDNSの更新をプロバイダによって証明書の変更を調整することは実用的ではありません。したがって、ホストされているドメインのTLSA RRSETは、ホストされているサービスを提供する部分としてプロバイダによって管理されているTLSA RRSetからProviderによって管理されているTLSA RRSetへのCNAMEとして設定されています。例えば：

; Customer DNS www.example.com. IN CNAME node1.provider.example. _443._tcp.www.example.com. IN CNAME _dane443.node1.provider.example. ; Provider DNS node1.provider.example. IN A 192.0.2.1 _dane443.node1.provider.example. IN TLSA 1 1 1 ...

;顧客DNS www.example.com。cname node1.provider.exampleで。_443._tcp.www.example.com。CNAME _DANE443.NODE1.PROVIDER.EXAMPLE。;プロバイダDNS Node1.Provider.Example。192.0.2.1 _dane443.node1.provider.exampleで。TLSA 1 1 1 ...

Clients that obtain TLSA records directly from DNS, bypassing this extension, may perform CNAME expansion as in Section 7 of [RFC7671]. If TLSA records are associated with the fully expanded name, that name may be used as the TLSA base domain and SNI name for the TLS handshake.

この拡張子をバイパスするDNSからTLSAレコードを直接取得するクライアントは、[RFC7671]のセクション7のようにCNAME展開を実行することができます。TLSAレコードが完全に展開された名前に関連付けられている場合、その名前はTLSAベースドメインとしてTLSハンドシェイクのSNI名として使用できます。

To avoid confusion, it is RECOMMENDED that server operators not publish TLSA RRs (_port._tcp. + base domain) based on the expanded CNAMEs used to locate their network addresses. Instead, the server operator SHOULD publish TLSA RRs at an alternative DNS node (as in the example above), to which the hosting customer will publish a CNAME alias. This results in all clients (whether they obtain TLSA records from DNS directly or employ this extension) seeing the same TLSA records and sending the same SNI name.

混乱を避けるために、ネットワークアドレスを見つけるために使用される拡張されたCNAMEに基づいて、サーバ演算子がTLSA RRS（_Port._TCP。ベースドメイン）を公開しないことをお勧めします。代わりに、サーバー演算子は、ホスティング顧客がCNAMEエイリアスを公開する代替DNSノードでTLSA RRSを公開してください。これにより、すべてのクライアント（DNSからTLSAレコードを直接取得するか、この拡張子を使用するか）が同じ結果が発生します。同じTLSAレコードを参照して同じSNI名を送信します。

10. Operational Considerations

10. 運用上の考慮事項

When DANE is being introduced incrementally into an existing PKIX environment, there may be scenarios in which DANE authentication for a server fails but PKIX succeeds, or vice versa. What happens here depends on TLS client policy. If DANE authentication fails, the client may decide to fall back to regular PKIX authentication. In order to do so efficiently within the same TLS handshake, the TLS server needs to have provided the full X.509 certificate chain. When TLS servers only support DANE-EE or DANE-TA modes, they have the option to send a much smaller certificate chain: just the EE certificate for the former and a short certificate chain from the DANE trust anchor to the EE certificate for the latter. If the TLS server supports both DANE and regular PKIX and wants to allow efficient PKIX fallback within the same handshake, they should always provide the full X.509 certificate chain.

デーンが既存のPKIX環境に段階的に導入されている場合、サーバーのデーン認証が失敗するがPKIXが成功する、またはその逆のシナリオがある可能性があります。ここで起こることは、TLSクライアントポリシーによって異なります。DANE認証が失敗した場合、クライアントは通常のPKIX認証に立ち下がります。同じTLSハンドシェイク内で効率的に行うためには、TLSサーバは完全X.509証明書チェーンを提供する必要があります。TLSサーバーがDANE-EEまたはDANE-TAモードのみをサポートしている場合、それらははるかに小さい証明書チェーンを送信することができます。前者のEE証明書とDane Trustアンカーから後者のEE証明書への短い証明書チェーン。TLSサーバーがDANEとREGURES PKIXの両方をサポートし、同じハンドシェイク内で効率的なPKIXフォールバックを許可したい場合は、常にフルX.509証明書チェーンを提供する必要があります。

When a TLS server operator wishes to no longer deploy this extension, it must properly decommission its use. If a non-zero pin lifetime is presently advertised, it must first be changed to 0. The extension can be disabled once all previously advertised pin lifetimes have expired. Removal of TLSA records or even DNSSEC signing of the zone can be done at any time, but the server MUST still be able to return the associated denial-of-existence proofs to any clients that have unexpired pins.

TLS Serverオペレーターがこの拡張機能をデプロイしなくなったら、その使用を正しく廃止する必要があります。ゼロ以外のピンの寿命が現在アドバタイズされている場合は、まず0に変更する必要があります。以前に広告されているすべてのPINライフタイムが期限切れになったら、拡張機能を無効にすることができます。TLSAレコードの削除またはゾーンのDNSSEC署名さえ任意のときに行うことができますが、サーバーは、未使用のピンを持つ任意のクライアントに関連付けられている存在拒否証明を依然として返すことができます。

TLS clients MAY reduce the received extension pin value to a maximum set by local policy. This can mitigate a theoretical yet unlikely attack where a compromised TLS server is modified to advertise a pin value set to the maximum of 7 years. Care should be taken not to set a local maximum that is too short as that would reduce the downgrade attack protection that the extension pin offers.

TLSクライアントは、受信した拡張子PIN値をローカルポリシーで設定された最大値に減らすことができます。これにより、妥協のあるTLSサーバが最大7年に設定されたPIN値をアドバタイズするように変更されている、理論的なものながら、攻撃が軽減される可能性があります。延長ピンが提供するダウングレード攻撃保護を減らすであろうと短すぎる局所最大値を設定しないように注意する必要があります。

If the hosting provider intends to use end-entity TLSA records (certificate usage PKIX-EE(1) or DANE-EE(3)), then the simplest approach is to use the same key pair for all the certificates at a given hosting node and publish "1 1 1" or "3 1 1" RRs matching the common public key. Since key rollover cannot be simultaneous across multiple certificate updates, there will be times when multiple "1 1 1" (or "3 1 1") records will be required to match all the extant certificates. Multiple TLSA records are, in any case, needed a few TTLs before certificate updates as explained in Section 8 of [RFC7671].

ホスティングプロバイダがエンドエンティティTLSAレコードを使用する予定の場合（証明書使用PKIX-EE（1）またはDANE-EE（3））、最も簡単な方法は、特定のホスティングノードのすべての証明書に同じキーペアを使用することです。一般公開鍵と一致する「1 1 1」または「3 1 1」RRを公開します。キーロールオーバーが複数の証明書の更新にまたがることは同時にできないため、すべての存在する証明書を一致させるには、複数の "1 1 1"（または "3 1 1"）レコードが必要になる時間がかかります。複数のTLSAレコードは、いずれにせよ、[RFC7671]のセクション8で説明されているように、証明書の更新前に数TTLを必要としています。

If the hosting provider intends to use trust anchor TLSA records (certificate usage PKIX-TA(0) or DANE-TA(2)), then the same TLSA record can match all end-entity certificates issues by the certification authority in question and continues to work across end-entity certificate updates so long as the issuer certificate or public keys remain unchanged. This can be easier to implement at the cost of greater reliance on the security of the selected certification authority.

ホスティングプロバイダが信頼ANCHOR TLSAレコードを使用する予定の場合（証明書使用PKIX-TA（0）またはDANE-TA（2））、同じTLSAレコードは、問題の認証局によってすべてのエンドエンティティ証明書の問題を一致させることができます。発行者証明書または公開鍵が変更されていない限り、エンドエンティティ証明書の更新を継続するため。これは、選択された認証局のセキュリティに依存する費用で実装が容易になる可能性があります。

The provider can, of course, publish separate TLSA records for each customer, which increases the number of such RRsets that need to be managed but makes each one independent of the rest.

プロバイダは、もちろん、各顧客に対して別々のTLSAレコードを公開することができます。これにより、管理する必要があるそのようなRRSETの数が増えますが、それぞれが残りとは無関係になります。

11. Security Considerations

11. セキュリティに関する考慮事項

The security considerations of the normatively referenced RFCs all pertain to this extension. Since the server is delivering a chain of DNS records and signatures to the client, it MUST rebuild the chain in accordance with TTL and signature expiration of the chain components as described in Section 4. TLS clients need roughly accurate time in order to properly authenticate these signatures. This could be achieved by running a time synchronization protocol like NTP [RFC5905] or SNTP [RFC5905], which are already widely used today. TLS clients MUST support a mechanism to track and roll over the trust anchor key or be able to avail themselves of a service that does this, as described in Section 8. Security considerations related to mandating the use of this extension are described in Section 7.

規範的に参照されているRFCのセキュリティ上の考慮事項はすべてこの拡張に関連しています。サーバーはクライアントにチェーンのDNSレコードと署名を配信しているため、セクション4で説明されているチェーンコンポーネントのTTLとシグネチャの有効期限に従ってチェーンを再構築する必要があります.TLSクライアントは、これらを正しく認証するために大幅に正確な時間が必要です。署名これは、NTP [RFC5905]またはSNTP [RFC5905]のような時間同期プロトコルを実行することによって達成することができます。これは、すでに今日広く使用されています。TLSクライアントは、セクション8で説明されているように、これを行うサービスを提供し、これを行うサービスを利用できるようにするメカニズムをサポートしている必要があります。この拡張機能の使用法に関連するセキュリティ上の考慮事項についてはセクション7に記載されています。

The received DNSSEC chain could contain DNS RRs that are not related to the TLSA verification of the intended DNS name. If such an unrelated RR is not DNSSEC signed, it MUST be discarded. If the unrelated RRset is DNSSEC signed, the TLS client MAY decide to add these RRsets and their DNSSEC signatures to its cache. It MAY even pass this data to the local system resolver for caching outside the application. However, care must be taken because caching these records could be used for timing and caching attacks to de-anonymize the TLS client or its user. A TLS client that wants to present the strongest anonymity protection to their users MUST refrain from using and caching all unrelated RRs.

受信したDNSSECチェーンには、意図したDNS名のTLSA検証に関連しないDNS RRが含まれている可能性があります。そのような無関係なRRがDNSSECに署名されていない場合は、破棄する必要があります。無関係なRRSetがDNSSECに署名されている場合、TLSクライアントはこれらのRRSETとそのDNSSECシグネチャをそのキャッシュに追加することを決定します。アプリケーションの外部でキャッシュするためにこのデータをローカルシステムリゾルバに渡すことさえあります。ただし、TLSクライアントまたはそのユーザーを匿名化するためのタイミングとキャッシング攻撃にこれらのレコードをキャッシュすることができるため、注意を払う必要があります。それらのユーザーに最も強い匿名性保護を提示したいTLSクライアントは、すべての無関係なRRを使用してキャッシュすることを控える必要があります。

12. IANA Considerations

12. IANAの考慮事項

IANA has made the following assignment in the "TLS ExtensionType Values" registry:

IANAは、「TLS ExtensionType値」レジストリに次の割り当てを行っています。

      +=======+================+=========+=============+===========+
      | Value | Extension Name | TLS 1.3 | Recommended | Reference |
      +=======+================+=========+=============+===========+
      |    59 | dnssec_chain   | CH      | No          | RFC 9102  |
      +-------+----------------+---------+-------------+-----------+

Table 1

表1

13. References

13. 参考文献

13.1. Normative References

13.1. 引用文献

[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>。

[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>。

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.

[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ紹介および要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https：//www.rfc-editor.org/info/rfc4033>。

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.

[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ拡張のためのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、<https://www.rfc-editor.org/info/rfc4034>。

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/info/rfc4035>.

[RFC4035] Arends、R.、Austein、R.、Larson、M.、M.、Massey、D.、およびS. Rose、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、<https://www.rfc-editor.org/info/rfc4035>。

[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>。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.

[RFC5246] Dierks、T.およびE. Rescorla、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https：//www.rfc-editor.org/info/ RFC5246>。

[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.

[RFC6066]イーストレイク3RD、D.、「トランスポート層セキュリティ（TLS）拡張：拡張定義」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<https：//www.rfc-editor.org/info/rfc6066>。

[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.

[RFC6698] Hoffman、P.およびJ.Schlyter、「名前付きエンティティのDNSベース認証（DANE）トランスポート層セキュリティ（TLSA」、RFC 6698、DOI 10.17487 / RFC6698、2012年8月、<https：//www.rfc-editor.org/info/rfc6698>。

[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 2014, <https://www.rfc-editor.org/info/rfc7218>.

[RFC7218] Gudmundsson、O.、「名前付きエンティティのDNSベース認証（DANE）の認証に関する会話を簡素化する頭字語の追加（DANE）」、RFC 7218、DOI 10.17487 / RFC7218、2014年4月、<https://www.rfc-editor.org/ info / rfc7218>。

[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <https://www.rfc-editor.org/info/rfc7671>.

[RFC7671] Dukhovni、V.およびW.Sharkaker、 "名前付きエンティティのDNSベースの認証（DANE）プロトコルの認証：更新および運用ガイダンス、RFC 7671、DOI 10.17487 / RFC7671、2015年10月、<https：// www。rfc-editor.org/info/rfc7671>。

[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>。

13.2. Informative References

13.2. 参考引用

[DANE-UKS] Barnes, R., Thomson, M., and E. Rescorla, "Unknown Key-Share Attacks on DNS-Based Authentications of Named Entities (DANE)", Work in Progress, Internet-Draft, draft-barnes-dane-uks-00, 9 October 2016, <https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00>.

[Dane-UKS] Barnes、R.、Thomson、M.、E. Rescorla、「名前付きエンティティのDNSベースの認証（DANE）」、進行中、インターネットドラフト、ドラフトバーヌスへの作業-dane-uks-00,2016、<https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00>

[DISCOVERY] Gorjon, X. and W. Toorop, "Discovery method for a DNSSEC validating stub resolver", 14 July 2015, <https://www.nlnetlabs.nl/downloads/publications/ os3-2015-rp2-xavier-torrent-gorjon.pdf>.

[発見] Gorjon、X.およびW.TOOROP 2015年7月14日、<https://www.nlnetlabs.nl/downloads/publications/OS3-2015-RP2-XAVIER-の「DNSSECの検証のディスカバリ方法」torrent-gorjon.pdf>。

[DNSOP-SVCB-HTTPS] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (DNS SVCB and HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf-dnsop-svcb-https-07, 16 June 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07>.

[DNSOP-SVCB-HTTPS] Schwartz、B.、Bishop、M.、およびE. Nygren、「DNS（DNS SVCBとHTTPS RRSによるサービスバインディングとパラメータ仕様」、進行中の作業、インターネットドラフト、ドラフト - IETF-DNSOP-SVCB-HTTPS-07,16 6月16日、<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07>。

[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, <https://www.rfc-editor.org/info/rfc5011>.

[RFC5011] Stjohns、M。、「DNSセキュリティ（DNSSEC）信託アンカーの自動更新」、STD 74、RFC 5011、DOI 10.17487 / RFC5011、2007年9月、<https：//www.rfc-editor.org/info/RFC5011>。

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.

[RFC5905]ミルズ、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルおよびアルゴリズム仕様」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月<https://www.rfc-editor.org/info/rfc5905>。

[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <https://www.rfc-editor.org/info/rfc7250>.

[RFC7250] Wouters、P.、ED、Tschofenig、H.、ED。、Gilmore、J.、Weiler、S.、T.Kivinen、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層での生の公開鍵を使用する」セキュリティ（DTLS） "、RFC 7250、DOI 10.17487 / RFC7250、2014年6月、<https://www.rfc-editor.org/info/rfc7250>。

[RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, DOI 10.17487/RFC7901, June 2016, <https://www.rfc-editor.org/info/rfc7901>.

[RFC7901] Wouters、P.、DNSの「チェーンクエリ要求」、RFC 7901、DOI 10.17487 / RFC7901、2016年6月、<https://www.rfc-editor.org/info/rfc7901>。

[SERIALIZECHAIN] Langley, A., "Serializing DNS Records with DNSSEC Authentication", Work in Progress, Internet-Draft, draft-agl-dane-serializechain-01, 1 July 2011, <https://datatracker.ietf.org/doc/html/draft-agl-dane-serializechain-01>.

[SerializeChain] Langley、A。、「DNSSEC認証を使用したDNSレコードの直列化」、進行中の作業、インターネットドラフト、ドラフト-AGL-DANE-SERIALIZECHAIN-01、<https：//datatracker.ietf.org/doc / html / froms-agl-dane-serializechain-01>。

Appendix A. Test Vectors

付録A.テストベクトル

The test vectors in this appendix are representations of the content of the "opaque AuthenticationChain" field in DNS presentation format and, except for the "extension_data" in Appendix A.1, do not contain the "uint16 ExtSupportLifetime" field.

この付録のテストベクトルは、DNSプレゼンテーション形式の「OPAQUE認証チェーン」フィールドの内容の表現であり、付録A.1の「Extension_Data」を除いて、「uint16 extSupportLifetime」フィールドを含まない。

For brevity and reproducibility, all DNS zones involved with the test vectors are signed using keys with algorithm 13 (ECDSA Curve P-256 with SHA-256).

簡潔さと再現性のために、テストベクトルに関わるすべてのDNSゾーンは、アルゴリズム13（SHA-256を搭載したECDSA曲線P-256）を使用して署名されています。

To reflect operational practice, different zones in the examples are in different phases of rolling their signing keys:

運用慣行を反映するために、例の異なるゾーンは、それらの署名キーを転動するというさまざまな段階にあります。

* All zones use a Key Signing Key (KSK) and Zone Signing Key (ZSK), except for the "example.com" and "example.net" zones, which use a Combined Signing Key (CSK).

* すべてのゾーンは、「example.com」と「example.net」ゾーンを除いて、キー署名キー（KSK）とゾーン署名キー（ZSK）を使用します。これは、複合署名キー（CSK）を使用します。

* The root and org zones are rolling their ZSKs.

* ルートゾーンとORGゾーンはそれらのZSKをローリングしています。

* The com and org zones are rolling their KSKs.

* COMゾーンとORGゾーンはそれらのKSKをローリングしています。

The test vectors are DNSSEC valid in the same period as the certificate is valid, which is between November 28, 2018 and December 2, 2020 with the following root trust anchor:

テストベクトルは、証明書が有効であるのと同じ期間で有効です。

. IN DS ( 47005 13 2 2eb6e9f2480126691594d649a5a613de3052e37861634 641bb568746f2ffc4d4 )

。DSで（47005 13 2 2 2 2 YE9 F2480126691594D649A5A613DE3052E37861634 641BB563444441BB568746F2FFC4D4）

The test vectors will authenticate the certificate used with "https://example.com/", "https://example.net/", and "https://example.org/" at the time of writing:

テストベクトルは、 "https://example.com/"、 "https://example.net/"、 "https://example.org/"で使用されている証明書を認証します。

A.1. "_443._tcp.www.example.com"

   _443._tcp.www.example.com.  3600  IN  TLSA  ( 3 1 1
           8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
           922 )
   _443._tcp.www.example.com.  3600  IN  RRSIG  ( TLSA 13 5 3600
           20201202000000 20181128000000 1870 example.com.
           rqY69NnTf4CN3GBGQjKEJCLAMsRkUrXe0JW8IqDb5rQHHzxNqqPeEoi+2vI6S
           z2BhaswpGLVVuoijuVdzxYjmw== )
   example.com.  3600  IN  DNSKEY  ( 257 3 13
           JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
           /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
   example.com.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
           20201202000000 20181128000000 1870 example.com.
           nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt
           QHPGSpvRxTUC4tZi62z1UgGDw== )
   example.com.  172800  IN  DS  ( 1870 13 2 e9b533a049798e900b5c29c90cd
          25a986e8a44f319ac3cd302bafc08f5b81e16)
   example.com.  172800  IN  RRSIG  ( DS 13 2 172800
           20201202000000 20181128000000 34327 com.
           sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO
           J1hhWSB6jgubEVl17rGNOA/YQ== )
   com.  172800  IN  DNSKEY  ( 256 3 13
           7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj
           3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327
   com.  172800  IN  DNSKEY  ( 257 3 13
           RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
           Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
   com.  172800  IN  DNSKEY  ( 257 3 13
           szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt
           DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809
   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
           20181128000000 18931 com.
           LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5
           7LFdPKpcvb8BvhM+GqKWGBEsg== )
   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
           20181128000000 28809 com.
           sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev
           mDXqz6KEhhQjT+aQWDt6WFHlA== )
   com.  86400  IN  DS  ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202
           f9eabb94487e658c188e7bcb52115 )
   com.  86400  IN  DS  ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e
           70643bbde681db342a9e5cf2bb380 )
   com.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
           20181128000000 31918 .
           nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb
           vBKTf6pk8JRCqnfzlo2QY+WXA== )
   .  86400  IN  DNSKEY  ( 256 3 13
           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
   .  86400  IN  DNSKEY  ( 256 3 13
           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
   .  86400  IN  DNSKEY  ( 257 3 13
           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
           20181128000000 47005 .
           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
           nBT1dtNjIczvLG9pQTnOKUsHQ== )

A hex dump of the "extension_data" of the server's "dnssec_chain" extension representation of this with an ExtSupportLifetime value of 0 is:

extSupportLifetime 0が0の「DNSSEC_CHAIN」の拡張子表現の「Extension_Data」のHEXダンプは、次のとおりです。

0000: 00 00 04 5f 34 34 33 04 5f 74 63 70 03 77 77 77 0010: 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 34 00 0020: 01 00 00 0e 10 00 23 03 01 01 8b d1 da 95 27 2f 0030: 7f a4 ff b2 41 37 fc 0e d0 3a ae 67 e5 c4 d8 b3 0040: c5 07 34 e1 05 0a 79 20 b9 22 04 5f 34 34 33 04 0050: 5f 74 63 70 03 77 77 77 07 65 78 61 6d 70 6c 65 0060: 03 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 00 0070: 34 0d 05 00 00 0e 10 5f c6 d9 00 5b fd da 80 07 0080: 4e 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ce 1d 0090: 3a de b7 dc 7c ee 65 6d 61 cf b4 72 c5 97 7c 8c 00a0: 9c ae ae 9b 76 51 55 c5 18 fb 10 7b 6a 1f e0 35 00b0: 5f ba af 75 3c 19 28 32 fa 62 1f a7 3a 8b 85 ed 00c0: 79 d3 74 11 73 87 59 8f cc 81 2e 1e f3 fb 07 65 00d0: 78 61 6d 70 6c 65 03 63 6f 6d 00 00 30 00 01 00 00e0: 00 0e 10 00 44 01 01 03 0d 26 70 35 5e 0c 89 4d 00f0: 9c fe a6 c5 af 6e b7 d4 58 b5 7a 50 ba 88 27 25 0100: 12 d8 24 1d 85 41 fd 54 ad f9 6e c9 56 78 9a 51 0110: ce b9 71 09 4b 3b b3 f4 ec 49 f6 4c 68 65 95 be 0120: 5b 2e 89 e8 79 9c 77 17 cc 07 65 78 61 6d 70 6c 0130: 65 03 63 6f 6d 00 00 2e 00 01 00 00 0e 10 00 5f 0140: 00 30 0d 02 00 00 0e 10 5f c6 d9 00 5b fd da 80 0150: 07 4e 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 46 0160: 28 38 30 75 b8 e3 4b 74 3a 20 9b 27 ae 14 8d 11 0170: 0d 4e 1a 24 61 38 a9 10 83 24 9c b4 a1 2a 2d 9b 0180: c4 c2 d7 ab 5e b3 af b9 f5 d1 03 7e 4d 5d a8 33 0190: 9c 16 2a 92 98 e9 be 18 07 41 a8 ca 74 ac cc 07 01a0: 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 2b 00 01 01b0: 00 02 a3 00 00 24 07 4e 0d 02 e9 b5 33 a0 49 79 01c0: 8e 90 0b 5c 29 c9 0c d2 5a 98 6e 8a 44 f3 19 ac 01d0: 3c d3 02 ba fc 08 f5 b8 1e 16 07 65 78 61 6d 70 01e0: 6c 65 03 63 6f 6d 00 00 2e 00 01 00 02 a3 00 00 01f0: 57 00 2b 0d 02 00 02 a3 00 5f c6 d9 00 5b fd da 0200: 80 86 17 03 63 6f 6d 00 a2 03 e7 04 a6 fa cb eb 0210: 13 fc 93 84 fd d6 de 6b 50 de 56 59 27 1f 38 ce 0220: 81 49 86 84 e6 36 31 72 d4 7e 23 19 fd b4 a2 2a 0230: 58 a2 31 ed c2 f1 ff 4f b2 81 1a 18 07 be 72 cb 0240: 52 41 aa 26 fd ae e0 39 03 63 6f 6d 00 00 30 00 0250: 01 00 02 a3 00 00 44 01 00 03 0d ec 82 04 e4 3a 0260: 25 f2 34 8c 52 a1 d3 bc e3 a2 65 aa 5d 11 b4 3d 0270: c2 a4 71 16 2f f3 41 c4 9d b9 f5 0a 2e 1a 41 ca 0280: f2 e9 cd 20 10 4e a0 96 8f 75 11 21 9f 0b dc 56 0290: b6 80 12 cc 39 95 33 67 51 90 0b 03 63 6f 6d 00 02a0: 00 30 00 01 00 02 a3 00 00 44 01 01 03 0d 45 b9 02b0: 1c 3b ef 7a 5d 99 a7 a7 c8 d8 22 e3 38 96 bc 80 02c0: a7 77 a0 42 34 a6 05 a4 a8 88 0e c7 ef a4 e6 d1 02d0: 12 c7 3c d3 d4 c6 55 64 fa 74 34 7c 87 37 23 cc 02e0: 5f 64 33 70 f1 66 b4 3d ed ff 83 64 00 ff 03 63 02f0: 6f 6d 00 00 30 00 01 00 02 a3 00 00 44 01 01 03 0300: 0d b3 37 3b 6e 22 e8 e4 9e 0e 1e 59 1a 9f 5b d9 0310: ac 5e 1a 0f 86 18 7f e3 47 03 f1 80 a9 d3 6c 95 0320: 8f 71 c4 af 48 ce 0e bc 5c 79 2a 72 4e 11 b4 38 0330: 95 93 7e e5 34 04 26 81 29 47 6e b1 ae d3 23 93 0340: 90 03 63 6f 6d 00 00 2e 00 01 00 02 a3 00 00 57 0350: 00 30 0d 01 00 02 a3 00 5f c6 d9 00 5b fd da 80 0360: 49 f3 03 63 6f 6d 00 18 a9 48 eb 23 d4 4f 80 ab 0370: c9 92 38 fc b4 3c 5a 18 de be 57 00 4f 73 43 59 0380: 3f 6d eb 6e d7 1e 04 65 4a 43 3f 7a a1 97 21 30 0390: d9 bd 92 1c 73 dc f6 3f cf 66 5f 2f 05 a0 aa eb 03a0: af b0 59 dc 12 c9 65 03 63 6f 6d 00 00 2e 00 01 03b0: 00 02 a3 00 00 57 00 30 0d 01 00 02 a3 00 5f c6 03c0: d9 00 5b fd da 80 70 89 03 63 6f 6d 00 61 70 e6 03d0: 95 9b d9 ed 6e 57 58 37 b6 f5 80 bd 99 db d2 4a 03e0: 44 68 2b 0a 35 96 26 a2 46 b1 81 2f 5f 90 96 b7 03f0: 5e 15 7e 77 84 8f 06 8a e0 08 5e 1a 60 9f c1 92 0400: 98 c3 3b 73 68 63 fb cc d4 d8 1f 5e b2 03 63 6f 0410: 6d 00 00 2b 00 01 00 01 51 80 00 24 49 f3 0d 02 0420: 20 f7 a9 db 42 d0 e2 04 2f bb b9 f9 ea 01 59 41 0430: 20 2f 9e ab b9 44 87 e6 58 c1 88 e7 bc b5 21 15 0440: 03 63 6f 6d 00 00 2b 00 01 00 01 51 80 00 24 70 0450: 89 0d 02 ad 66 b3 27 6f 79 62 23 aa 45 ed a7 73 0460: e9 2c 6d 98 e7 06 43 bb de 68 1d b3 42 a9 e5 cf 0470: 2b b3 80 03 63 6f 6d 00 00 2e 00 01 00 01 51 80 0480: 00 53 00 2b 0d 01 00 01 51 80 5f c6 d9 00 5b fd 0490: da 80 7c ae 00 12 2e 27 6d 45 d9 e9 81 6f 79 22 04a0: ad 6e a2 e7 3e 82 d2 6f ce 0a 4b 71 86 25 f3 14 04b0: 53 1a c9 2f 8a e8 24 18 df 9b 89 8f 98 9d 32 e8 04c0: 0b c4 de ab a7 c4 a7 c8 f1 72 ad b5 7c ed 7f b5 04d0: e7 7a 78 4b 07 00 00 30 00 01 00 01 51 80 00 44 04e0: 01 00 03 0d cc ac fe 0c 25 a4 34 0f ef ba 17 a2 04f0: 54 f7 06 aa c1 f8 d1 4f 38 29 90 25 ac c4 48 ca 0500: 8c e3 f5 61 f3 7f c3 ec 16 9f e8 47 c8 fc be 68 0510: e3 58 ff 7c 71 bb 5e e1 df 0d be 51 8b c7 36 d4 0520: ce 8d fe 14 00 00 30 00 01 00 01 51 80 00 44 01 0530: 00 03 0d f3 03 19 67 89 73 1d dc 8a 67 87 ef f2 0540: 4c ac fe dd d0 32 58 2f 11 a7 5b b1 bc aa 5a b3 0550: 21 c1 d7 52 5c 26 58 19 1a ec 01 b3 e9 8a b7 91 0560: 5b 16 d5 71 dd 55 b4 ea e5 14 17 11 0c c4 cd d1 0570: 1d 17 11 00 00 30 00 01 00 01 51 80 00 44 01 01 0580: 03 0d ca f5 fe 54 d4 d4 8f 16 62 1a fb 6b d3 ad 0590: 21 55 ba cf 57 d1 fa ad 5b ac 42 d1 7d 94 8c 42 05a0: 17 36 d9 38 9c 4c 40 11 66 6e a9 5c f1 77 25 bd 05b0: 0f a0 0c e5 e7 14 e4 ec 82 cf df ac c9 b1 c8 63 05c0: ad 46 00 00 2e 00 01 00 01 51 80 00 53 00 30 0d 05d0: 00 00 01 51 80 5f c6 d9 00 5b fd da 80 b7 9d 00 05e0: de 7a 67 40 ee ec ba 4b da 1e 5c 2d d4 89 9b 2c 05f0: 96 58 93 f3 78 6c e7 47 f4 1e 50 d9 de 8c 0a 72 0600: df 82 56 0d fb 48 d7 14 de 32 83 ae 99 a4 9c 0f 0610: cb 50 d3 aa ad b1 a3 fc 62 ee 3a 8a 09 88 b6 be

0000：00 00 04 5F 34 33 04 77 77 77 0010：07 65 77 77 0010：07 65 78 61 6D 70 6D 0020 34 0020：01 000 0 00 0 00 0 0 00 0 00 0 0 0 00 0 00 0 0 0 0 0 0 0 0 2 23 03 01 01 0 10 00 23 03 01 01 01 8B D1 DA 95 27 2F 0030：7F A4 FF B2 41 37 FC 0E D0 3A AE 67 E5 C4 D8 B3 0040：C5 07 34 E1 05 0A 79 20 B9 22 04 5F 34 34 33 04 0050：5F 74 63 70 03 77 77 77 07 65 78 61 6D 70 64 65 0060：03 63 6F 6D 00 00 01 00 01 00 0 00 0 01 00 0 00 0 01 00 0 00 0 0 0 01 00 0 00 0 01 00 0 00 0 01 00 0 0 0 0 0 01 00 61 6D 70 6C 65 03 63 6F 6D 00 CE 1D 0090：3A DE B7 DC 7C EE 65 6D 61 CF B4 72 C5 97 7 C 8 C 00A0：9C AE AE 9B 76 51 55 C5 18 FB 10 7B 6A 1F E0 35 00B0： 5F BA AF 75 3C 19 28 28 32 FA 62 1F A7 3A 8B 85 ED 00C0：79 D3 74 11 73 87 59 8F CC 81 2E 1E F3 FB 07 65 00D0：78 61 6D 70 6 C 65 03 63 6F 6D 00 30 00 01 00 00e0：00 0e 10 00 44 01 01 03 0D 26 70 35 5E 0 C 89 4D 00F0：9 C Fe A6 C5 AF 6E B7 D4 58 B5 7A 50 BA 88 27 25 0100：12 D8 24 1D 85 41 FD 54 AD F9 6E C9 56 78 9A 51 0110：CE B9 71 09 4B 3B B3 F4 EC 49 F6 4cと68 65 95 0120である。図5B 2E 89 E8 79 9C 77 1 7 CC 07 65 78 61 6D 70 6 C 0130：65 03 63 6F 6D 00 00 2 00 0 01 00 0 0 0 01 00 0 0 0 0 0 01 00 0 J-10 5F C6 D9 00 5B FD DA 80 0150：07 4E 07 65 78 61 6D 70 6C 65 03 63 6F 6D 00 46 0160：28 3 3 A 20 9B 27 AE 14 8D 11 0170：0D 4E 1A 24 61 38 A9 10 83 24 9C B4 A1 2A 2D 9B 0180 ：C4 C2 D7 AB 5E B3 AF B9 F5 D1 03 7E 4D 5D A8 33 0190：9C 16 2A 92 98 E9 18 07 41 A8 CA 74 AC CC 07 01A0：65 78 61 63 6F 6D 00 00 2B 00 01 01b0：00 02 A3 00 00 24 07 4E 0D 02 E9 B5 33 A0 49 79 01C0：8E 90 0B 5C 29 C9 0C D2 5A 98 6E 8A 44 F3 19 AC 01d0：3C D3 02 BA FC 08 F5 B8 1E 16 07 65 78 61 6D 70 01E0：6F 6D 00 01 00 01 00 01 00 02 00 02 00 02 00 02 00 02 A3 00 5F C6 D9 00 5B FD DA 0200：80 86 17 03 63 6F 6D 00 A2 03 E7 04 A6 FA CB EB 0210：13 FC 93 84 FD D6 DE 6B 50 DE 56 59 27 1F 38 CE 0220：81 49 86 84 E6 36 31 72 D4 7E 23 19 FD B4 A2 2A 0230：58 A2 31 ED C2 F1 FF 4F B2 81 1A 18 07 Be 72 CB 0240：52 41 AA 26 FD AE E0 39 03 63 6F 6D 00 00 30 00 02 50：01 00 02 A3 00 00 44 01 00 03 0D EC 82 04 E4 3A 0260：25 F2 34 8C 52 65 AA 5D 11 B4 3D 0270：C2 A4 71 16 2F F5 0A 2E 1A 41 CA 0280：F2 E9 CD 20 10 4E A0 96 8F 75 11 21 9F 0 B DC 56 0290：B6 80 12 CC 39 95 33 63 6F 6D 00 02 A0：00 30 00 01 00 02 A3 00 00 44 01 01 03 0D 45 B9 02b0：1C 3B EF 7A 5D 99 A7 A7 C8 D8 22 E3 38 96 02c0 80 BC：A7 77 A0 42 34 A6 05 A4 A8 88 0E C7 EF A4 E6 D1 02D0：12 C7 3C D3 D4 C6 55 64 FA 74 34 7C 87 37 23 23 CC 02E0：5F 64 33 70 F1 66 B4 3D ED FF 83 64 00 FF 03 63 02F0：6F 6D 00 00 30 00 44 01 02 A3 00 00 44 01 03 0300： 0D B3 37 3B 6E 22 E8 E4 9E 0 E D9 0310：AC 5E 1A 0F 86 18 7F E3 47 03 F1 80 A9 D3 6C 95 0320：8F 71 C4 AF 48 CE 0E BC 5 C 79 2A 72 4E 11 B4 38 0330：95 93 7E E5 34 04 26 81 29 47 6E B1 AE D3 23 93 0340：90 03 63 6F 6D 00 00 2 00 00 02 A3 00 02 A3 00 5F C6 D9 00 5B FD DA 80 0360：49 F3 03 63 6F 6D 00 18 A9 48 EB 23 D4 4F 80 AB 0370：C9 92 38 FC B4 3C 5A 18 DE BE 57 00 4F 73 43 59 0380：3F 6D EB 6E D7 1E 04 65 4A 43 3F 7A A1 97 21 30 0390：D9 BD 92 1 C 73 DC F6 3F CF 66 5F 2F 05 A0 AA EB 03A0：AF B0 59 DC 12 C9 65 03 63 6F 6D 00 00 2E 00 02 A3 00 57 00 02 A3 00 5F C6 03 C0：D9 00 5B FD DA 80 70 89 03 63 6F 6D 00 61 70 E6 03D0： 95 9B D9 ED 6E 57 58 37 B6 F5 80 BD 99 DB D2 4A 03E0：44 68 2B 0A 35 96 26 26 A2 46 B1 81 2F 5F 90 96 B7 03F0：5E 15 7E 77 84 8F 06 8A E0 08 5E 1A 60 9F C1 92 0400：98 C3 3B 73 68 63 FB CC D4 D8 1F 5E B2 03 63 6F 0410：6D 00 00 01 00 01 51 80 00 24 49 F3 0D 02 0420：20 F7 A9 DB 42 D0 E2 04 2F BB B9 F9 EA 01 59 41 0430：20 2F 9E AB B9 44 87 E6 58 C1 88 E7 BC B5 21 15 0440：03 63 6F 6D 00 00 2B 00 2 2 00 01 51 80 00 24 70 0450：89 0D 02 AD 66 B3 27 6F 79 62 23 AA 45 73 73 0460：E9 2C 6D 98 E7 06 43 BB DE 68 1D B3 42 A9 E5 CF 0470：2B B3 80 03 63 6F 6D 00 00 2E 00 01 00 01 51 80 0480：00 53ダ80 7C AE 00 12 2E 27 6D 45 D9 E9 81 6F 79 22 04a0：00 2Bは、01 00 01 51 80 5F C6 D9 00 5B FD 0490 0D ：広告6E A2 E7 3E 82 D2 6F CE 0A 4B 71 86 25 F3 14 04b0：53 1A C9 2F 8A E8 24 18 DF 9B 89 8F 98 9D 32 E8 04c0：0B C4デAB A7 C4 A7 C8 F1 72広告B5部7c ED 7F B5 04D0：E7 00 30 00 30 00 01 00 01 51 80 00 44 04e0：01 00 44 04e0：01 00 44 04 0 4〜01 00 7 A 4 34 0F EF BA 17 A2 04F0：54 F7 06 AA C1 F8 D1 4F 38 29 90 25 AC C4 48 CA 0500：8 C E3 F5 61 F3 7F C3 EC 16 9F E8 47 C8 FC BE 68 0510：E3 58 FF 7C 71 BB 5E E1 DF 0D 51 8B C7 36 D4 0520：CE 8D FE 14 00 00 30 00 01 00 01 51 87 00 44 01 0530：00 03 0 D F3 03 19 67 89 73 1D DC 8A 67 87 EF F2 0540：4C AC FE DD D0 32 58 2F 11 A7 5B B1 BC AA 5A B3 0550：21 C1 D7 52 5C 26 58 19 1A EC 01 B3 E9 8A B7 91 0560：5B 16 D5 71 DD 55 B4 E5 14 17 11 0 C C4 CD D1 0570：1 D 17 11 00 00 30 00 44 01 01 0580：03 03 0D CA F5 FE 54 D4 D4 8F 16 62 1A FB 6B D3 AD 0590：21 55 BA CF 42 D1 7D 94 8C 42 05A0：17 36 D9 38 9 C 4 C 40 11 66 6E A9 5C F1 77 25 BD 05B0：0F A0 0 C E5 E7 14 E4 EC 82 CF DF AC C9 B1 C8 63 05 C0：AD 46 00 00 2 00 01

A.2. "_25._tcp.example.com" NSEC Wildcard

A.2. "_25._tcp.example.com" "NSECワイルドカード

   _25._tcp.example.com.  3600  IN  TLSA  ( 3 1 1
           8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
           922 )
   _25._tcp.example.com.  3600  IN  RRSIG  ( TLSA 13 3 3600
           20201202000000 20181128000000 1870 example.com.
           BZawXvte5SyF8hnXviKDWqll5E2v+RMXqaSE+NOcAMlZOrSMUkfyPqvkv53K2
           rfL4DFP8rO3VMgI0v+ogrox0w== )
   *._tcp.example.com.  3600  IN  NSEC  ( smtp.example.com. RRSIG
           NSEC TLSA )
   *._tcp.example.com.  3600  IN  RRSIG  ( NSEC 13 3 3600
           20201202000000 20181128000000 1870 example.com.
           K6u8KrR8ca5bjtbce3w8yjMXr9vw12225lAwyIHpxptY43OMLCUCenwpYW5qd
           mpFvAacqj4+tSkKiN279SI9pA== )
   example.com.  3600  IN  DNSKEY  ( 257 3 13
           JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
           /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
   example.com.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
           20201202000000 20181128000000 1870 example.com.
           nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt
           QHPGSpvRxTUC4tZi62z1UgGDw== )
   example.com.  172800  IN  DS  ( 1870 13 2 e9b533a049798e900b5c29c90cd
           25a986e8a44f319ac3cd302bafc08f5b81e16 )
   example.com.  172800  IN  RRSIG  ( DS 13 2 172800
           20201202000000 20181128000000 34327 com.
           sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO
           J1hhWSB6jgubEVl17rGNOA/YQ== )
   com.  172800  IN  DNSKEY  ( 256 3 13
           7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj
           3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327
   com.  172800  IN  DNSKEY  ( 257 3 13
           RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
           Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
   com.  172800  IN  DNSKEY  ( 257 3 13
           szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt
           DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809
   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
           20181128000000 18931 com.
           LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5
           7LFdPKpcvb8BvhM+GqKWGBEsg== )
   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
           20181128000000 28809 com.
           sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev
           mDXqz6KEhhQjT+aQWDt6WFHlA== )
   com.  86400  IN  DS  ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202
           f9eabb94487e658c188e7bcb52115 )
   com.  86400  IN  DS  ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e
           70643bbde681db342a9e5cf2bb380 )
   com.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
           20181128000000 31918 .
           nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb
           vBKTf6pk8JRCqnfzlo2QY+WXA== )
   .  86400  IN  DNSKEY  ( 256 3 13
           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
   .  86400  IN  DNSKEY  ( 256 3 13
           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
   .  86400  IN  DNSKEY  ( 257 3 13
           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
           20181128000000 47005 .
           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
           nBT1dtNjIczvLG9pQTnOKUsHQ== )

A.3. "_25._tcp.example.org" NSEC3 Wildcard

A.3. "_25._tcp.example.org" NSEC3ワイルドカード

   _25._tcp.example.org.  3600  IN  TLSA  ( 3 1 1
           8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
           922 )
   _25._tcp.example.org.  3600  IN  RRSIG  ( TLSA 13 3 3600
           20201202000000 20181128000000 56566 example.org.
           lNp6th/CJel5WsYlLsLadcQ/YdSTJAIOttzYKnNkNzeZ0jxtDyEP818Q1R4lL
           cYzJ7vCvqb9gFCiCJjK2gAamw== )
   dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org.  3600  IN  NSEC3  (
           1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA )
   dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org.  3600  IN  RRSIG  (
           NSEC3 13 3 3600 20201202000000 20181128000000 56566
           example.org.
           guUyy9LIZlYb0FZttAdYJGrFNKpKu91Tm+dPOz98rnpwIlwwvLifXIvIl90nE
           X38cWzEQOpreJu3t4WAfPsxdg== )
   example.org.  3600  IN  DNSKEY  ( 256 3 13
           NrbL6utGqIW1wrhhjeexdA6bMdD1lC1hj0Fnpevaa1AMyY2uy83TmoGnR996N
           UR5TlG4Zh+YPbbmUIixe4nS3w== ) ; Key ID = 56566
   example.org.  3600  IN  DNSKEY  ( 257 3 13
           uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr
           Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384
   example.org.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
           20201202000000 20181128000000 44384 example.org.
           ttse9pYp9PSu0pJ+TOpIVFLWJ6NKOMWZX4Q/SlU6ZfaiKQc0Bg7Tut9+wPunk
           6OPPvyHjVXMAsvk0tqV0B+/ag== )
   example.org.  86400  IN  DS  ( 44384 13 2 ec307e2efc8f0117ed96ab48a51
           3c8003e1d9121f1ff11a08b4cdd348d090aa6 )
   example.org.  86400  IN  RRSIG  ( DS 13 2 86400 20201202000000
           20181128000000 9523 org.
           m86Xz0CEa2sWG40a0bS2kqLKPmIlyiVyDeoWXAq3djeGiPaikLuKORNzWXu62
           clpAfvZHx59Ackst4X+zXYpUA== )
   org.  86400  IN  DNSKEY  ( 256 3 13
           fuLp60znhSSEr9HowILpTpyLKQdM6ixcgkTE0gqVdsLx+DSNHSc69o6fLWC0e
           HfWx7kzlBBoJB0vLrvsJtXJ6g== ) ; Key ID = 47417
   org.  86400  IN  DNSKEY  ( 256 3 13
           zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy
           mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523
   org.  86400  IN  DNSKEY  ( 257 3 13
           Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6
           Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352
   org.  86400  IN  DNSKEY  ( 257 3 13
           0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ
           HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651
   org.  86400  IN  RRSIG  ( DNSKEY 13 1 86400 20201202000000
           20181128000000 12651 org.
           Gq9wf+z3pasXXUwE210jYc0LhJnMAhcwXydnvkHtCVY6/0jUafHO4RksN84Zt
           us0pUgWngbT/OWXskdMYXZU4A== )
   org.  86400  IN  RRSIG  ( DNSKEY 13 1 86400 20201202000000
           20181128000000 49352 org.
           VGEkEMWBJ2IbOpm2Z56Qxu2NGPcVUDWCbYRyk+Qk1+HzGtyd2qPEKkpgMs/0p
           vZEMj1YXD+dIqb2nUK9PGBAXw== )
   org.  86400  IN  DS  ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f
           9db5c24a75743eb1e704b97a9fabc )
   org.  86400  IN  DS  ( 49352 13 2 03d11a1aa114abbb8f708c3c0ff0db765fe
           f4a2f18920db5f58710dd767c293b )
   org.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
           20181128000000 31918 .
           adiFuP2UIulQw5Edsb/7WSPqr5nkRSTVXbZ2tkBeZRQcMjdCD3pyonWO5JPRV
           EemgaE357S4pX5D0tVZzeZJ6A== )
   .  86400  IN  DNSKEY  ( 256 3 13
           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
   .  86400  IN  DNSKEY  ( 256 3 13
           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
   .  86400  IN  DNSKEY  ( 257 3 13
           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
           20181128000000 47005 .
           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
           nBT1dtNjIczvLG9pQTnOKUsHQ== )

A.4. "_443._tcp.www.example.org" CNAME

A.4. "_443._tcp.www.example.org" CNAME.

   _443._tcp.www.example.org.  3600  IN  CNAME  (
           dane311.example.org. )
   _443._tcp.www.example.org.  3600  IN  RRSIG  ( CNAME 13 5 3600
           20201202000000 20181128000000 56566 example.org.
           R0dUe6Rt4G+2ablrQH9Zw8j9NhBLMgNYTI5+H7nO8SNz5Nm8w0NZrXv3Qp7gx
           Qb/a90O696120NsYaZX2+ebBA== )
   dane311.example.org.  3600  IN  TLSA  ( 3 1 1
           8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
           922 )
   dane311.example.org.  3600  IN  RRSIG  ( TLSA 13 3 3600
           20201202000000 20181128000000 56566 example.org.
           f6TbTZTpu3h6MYpLkKQwWILAkYQ3EUY+Nsoa6any6yt+aeuunMUjw+IJB2QLm
           0x0PrD7m39JA3NUSkUp9riNNQ== )
   example.org.  3600  IN  DNSKEY  ( 256 3 13
           NrbL6utGqIW1wrhhjeexdA6bMdD1lC1hj0Fnpevaa1AMyY2uy83TmoGnR996N
           UR5TlG4Zh+YPbbmUIixe4nS3w== ) ; Key ID = 56566
   example.org.  3600  IN  DNSKEY  ( 257 3 13
           uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr
           Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384
   example.org.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
           20201202000000 20181128000000 44384 example.org.
           ttse9pYp9PSu0pJ+TOpIVFLWJ6NKOMWZX4Q/SlU6ZfaiKQc0Bg7Tut9+wPunk
           6OPPvyHjVXMAsvk0tqV0B+/ag== )
   example.org.  86400  IN  DS  ( 44384 13 2 ec307e2efc8f0117ed96ab48a51
           3c8003e1d9121f1ff11a08b4cdd348d090aa6 )
   example.org.  86400  IN  RRSIG  ( DS 13 2 86400 20201202000000
           20181128000000 9523 org.
           m86Xz0CEa2sWG40a0bS2kqLKPmIlyiVyDeoWXAq3djeGiPaikLuKORNzWXu62
           clpAfvZHx59Ackst4X+zXYpUA== )
   org.  86400  IN  DNSKEY  ( 256 3 13
           fuLp60znhSSEr9HowILpTpyLKQdM6ixcgkTE0gqVdsLx+DSNHSc69o6fLWC0e
           HfWx7kzlBBoJB0vLrvsJtXJ6g== ) ; Key ID = 47417
   org.  86400  IN  DNSKEY  ( 256 3 13
           zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy
           mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523
   org.  86400  IN  DNSKEY  ( 257 3 13
           Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6
           Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352
   org.  86400  IN  DNSKEY  ( 257 3 13
           0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ
           HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651
   org.  86400  IN  RRSIG  ( DNSKEY 13 1 86400 20201202000000
           20181128000000 12651 org.
           Gq9wf+z3pasXXUwE210jYc0LhJnMAhcwXydnvkHtCVY6/0jUafHO4RksN84Zt
           us0pUgWngbT/OWXskdMYXZU4A== )
   org.  86400  IN  RRSIG  ( DNSKEY 13 1 86400 20201202000000
           20181128000000 49352 org.
           VGEkEMWBJ2IbOpm2Z56Qxu2NGPcVUDWCbYRyk+Qk1+HzGtyd2qPEKkpgMs/0p
           vZEMj1YXD+dIqb2nUK9PGBAXw== )
   org.  86400  IN  DS  ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f
           9db5c24a75743eb1e704b97a9fabc )
   org.  86400  IN  DS  ( 49352 13 2 03d11a1aa114abbb8f708c3c0ff0db765fe
           f4a2f18920db5f58710dd767c293b )
   org.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
           20181128000000 31918 .
           adiFuP2UIulQw5Edsb/7WSPqr5nkRSTVXbZ2tkBeZRQcMjdCD3pyonWO5JPRV
           EemgaE357S4pX5D0tVZzeZJ6A== )
   .  86400  IN  DNSKEY  ( 256 3 13
           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
   .  86400  IN  DNSKEY  ( 256 3 13
           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
   .  86400  IN  DNSKEY  ( 257 3 13
           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
           20181128000000 47005 .
           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
           nBT1dtNjIczvLG9pQTnOKUsHQ== )

A.5. "_443._tcp.www.example.net" DNAME

A.5. "_443._tcp.www.example.net" dname.

   example.net.  3600  IN  DNAME  example.com.
   example.net.  3600  IN  RRSIG  ( DNAME 13 2 3600 20201202000000
           20181128000000 48085 example.net.
           o3uV5k5Ewp5fdrOZt0n4QuH+/Hpku2Lo3CzGRt9/MS2zZt2Qb/AXz435UFQBx
           OI/pDnjJcLSd/gBLtqR52WLMA== )
   ; _443._tcp.www.example.net.  3600  IN  CNAME  (
   ;         _443._tcp.www.example.com. )
   _443._tcp.www.example.com.  3600  IN  TLSA  ( 3 1 1
           8bd1da95272f7fa4ffb24137fc0ed03aae67e5c4d8b3c50734e1050a7920b
           922 )
   _443._tcp.www.example.com.  3600  IN  RRSIG  ( TLSA 13 5 3600
           20201202000000 20181128000000 1870 example.com.
           rqY69NnTf4CN3GBGQjKEJCLAMsRkUrXe0JW8IqDb5rQHHzxNqqPeEoi+2vI6S
           z2BhaswpGLVVuoijuVdzxYjmw== )
   example.net.  3600  IN  DNSKEY  ( 257 3 13
           X9GHpJcS7bqKVEsLiVAbddHUHTZqqBbVa3mzIQmdp+5cTJk7qDazwH68Kts8d
           9MvN55HddWgsmeRhgzePz6hMg== ) ; Key ID = 48085
   example.net.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
           20201202000000 20181128000000 48085 example.net.
           CkwqgEt1p97oMa3w5LctIjKIuG5XVSapKrfwuHhb5p04fWXRMNsXasG/kd2F/
           wlmMWiq38gOQaYCLNm+cjQzpQ== )
   example.net.  172800  IN  DS  ( 48085 13 2 7c1998ce683df60e2fa41460c4
           53f88f463dac8cd5d074277b4a7c04502921be )
   example.net.  172800  IN  RRSIG  ( DS 13 2 172800
           20201202000000 20181128000000 10713 net.
           w0JxDeiBJZNlpCdxKtRENlqfTpSxcs6Vftscsyfo/hyeTPYcIt4yItDkYsYK+
           KQ6FYAVE4nisA3vDQoZVL4wow== )
   net.  172800  IN  DNSKEY  ( 256 3 13
           061EoQs4sBcDsPiz17vt4nFSGLmXAGguqLStOesmKNCimi4/lw/vtyfqALuLF
           JiFjtCK3HMPi8HQ1jbGEwbGCA== ) ; Key ID = 10713
   net.  172800  IN  DNSKEY  ( 257 3 13
           LkNCPE+v3S4MVnsOqZFhn8n2NSwtLYOZLZjjgVsAKgu4XZncaDgq1R/7ZXRO5
           oVx2zthxuu2i+mGbRrycAaCvA== ) ; Key ID = 485
   net.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
           20181128000000 485 net.
           031jXg06zSuDwI5zqYuYFJg1O5p+zy85csMXagvRxB9W2lL/wJRi6Gn9BcaCV
           RnDId5WR+yCADhsbKfSrrd9vQ== )
   net.  86400  IN  DS  ( 485 13 2 ab25a2941aa7f1eb8688bb783b25587515a0c
           d8c247769b23adb13ca234d1c05 )
   net.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
           20181128000000 31918 .
           vOXoTjxggGTYKIwssQ3kpML0ag6D0Hcm+Syy7++4zT7gaFHfRH9a6uZekIWdb
           oss8y7q4onW4rxKdtw2S28hwQ== )
   .  86400  IN  DNSKEY  ( 256 3 13
           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
   .  86400  IN  DNSKEY  ( 256 3 13
           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
   .  86400  IN  DNSKEY  ( 257 3 13
           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
           20181128000000 47005 .
           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
           nBT1dtNjIczvLG9pQTnOKUsHQ== )
   example.com.  3600  IN  DNSKEY  ( 257 3 13
           JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
           /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
   example.com.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
           20201202000000 20181128000000 1870 example.com.
           nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt
           QHPGSpvRxTUC4tZi62z1UgGDw== )
   example.com.  172800  IN  DS  ( 1870 13 2 e9b533a049798e900b5c29c90cd
           25a986e8a44f319ac3cd302bafc08f5b81e16 )
   example.com.  172800  IN  RRSIG  ( DS 13 2 172800
           20201202000000 20181128000000 34327 com.
           sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO
           J1hhWSB6jgubEVl17rGNOA/YQ== )
   com.  172800  IN  DNSKEY  ( 256 3 13
           7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj
           3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327
   com.  172800  IN  DNSKEY  ( 257 3 13
           RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
           Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
   com.  172800  IN  DNSKEY  ( 257 3 13
           szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt
           DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809
   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
           20181128000000 18931 com.
           LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5
           7LFdPKpcvb8BvhM+GqKWGBEsg== )
   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
           20181128000000 28809 com.
           sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev
           mDXqz6KEhhQjT+aQWDt6WFHlA== )
   com.  86400  IN  DS  ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202
           f9eabb94487e658c188e7bcb52115 )
   com.  86400  IN  DS  ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e
           70643bbde681db342a9e5cf2bb380 )
   com.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
           20181128000000 31918 .
           nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb
           vBKTf6pk8JRCqnfzlo2QY+WXA== )

A.6. "_25._tcp.smtp.example.com" NSEC Denial of Existence

A.6. "_25._tcp.smtp.example.com" NSEC存在の否定

   smtp.example.com.  3600  IN  NSEC  ( www.example.com. A AAAA
           RRSIG NSEC )
   smtp.example.com.  3600  IN  RRSIG  ( NSEC 13 3 3600
           20201202000000 20181128000000 1870 example.com.
           rH/K4wghCOm4jpEHwQKiyZzvFIa7qpFySuKIGGetW4SE4O2Mh5jPxcEzf78Hf
           crlsQZmnAUlfmBNCygxAd7JNw== )
   example.com.  3600  IN  DNSKEY  ( 257 3 13
           JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s
           /TsSfZMaGWVvlsuieh5nHcXzA== ) ; Key ID = 1870
   example.com.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
           20201202000000 20181128000000 1870 example.com.
           nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIzt
           QHPGSpvRxTUC4tZi62z1UgGDw== )
   example.com.  172800  IN  DS  ( 1870 13 2 e9b533a049798e900b5c29c90cd
           25a986e8a44f319ac3cd302bafc08f5b81e16 )
   example.com.  172800  IN  RRSIG  ( DS 13 2 172800
           20201202000000 20181128000000 34327 com.
           sEAKvX4H6pJfN8nKcclB1NRcRSPOztx8omr4fCSHu6lp+uESP/Le4iF2sKukO
           J1hhWSB6jgubEVl17rGNOA/YQ== )
   com.  172800  IN  DNSKEY  ( 256 3 13
           7IIE5Dol8jSMUqHTvOOiZapdEbQ9wqRxFi/zQcSdufUKLhpByvLpzSAQTqCWj
           3URIZ8L3Fa2gBLMOZUzZ1GQCw== ) ; Key ID = 34327
   com.  172800  IN  DNSKEY  ( 257 3 13
           RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0f
           Ic3I8xfZDNw8Wa0Pe3/g2QA/w== ) ; Key ID = 18931
   com.  172800  IN  DNSKEY  ( 257 3 13
           szc7biLo5J4OHlkan1vZrF4aD4YYf+NHA/GAqdNslY9xxK9Izg68XHkqck4Rt
           DiVk37lNAQmgSlHbrGu0yOTkA== ) ; Key ID = 28809
   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
           20181128000000 18931 com.
           LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA5
           7LFdPKpcvb8BvhM+GqKWGBEsg== )
   com.  172800  IN  RRSIG  ( DNSKEY 13 1 172800 20201202000000
           20181128000000 28809 com.
           sO+4X2N21yS6x8+dBVBzbRo9+55MM8n7+RUvdBuxRFVh6JaBlqDOC5LLkl7Ev
           mDXqz6KEhhQjT+aQWDt6WFHlA== )
   com.  86400  IN  DS  ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202
           f9eabb94487e658c188e7bcb52115 )
   com.  86400  IN  DS  ( 28809 13 2 ad66b3276f796223aa45eda773e92c6d98e
           70643bbde681db342a9e5cf2bb380 )
   com.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
           20181128000000 31918 .
           nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5Pb
           vBKTf6pk8JRCqnfzlo2QY+WXA== )
   .  86400  IN  DNSKEY  ( 256 3 13
           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
   .  86400  IN  DNSKEY  ( 256 3 13
           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
   .  86400  IN  DNSKEY  ( 257 3 13
           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
           20181128000000 47005 .
           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
           nBT1dtNjIczvLG9pQTnOKUsHQ== )

A.7. "_25._tcp.smtp.example.org" NSEC3 Denial of Existence

A.7. "_25._tcp.smtp.example.org" NSEC3存在の否定

   vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org.  3600  IN  NSEC3  (
           1 0 1 - 93u63bg57ppj6649al2n31l92iedkjd6 A AAAA RRSIG )
   vkv62jbv85822q8rtmfnbhfnmnat9ve3.example.org.  3600  IN  RRSIG  (
           NSEC3 13 3 3600 20201202000000 20181128000000 56566
           example.org.
           wn3cePVdc5VPPniYzGp+1CBPOY2m83/A3cjnAb7FTZuwL45B25fwVUyjKQksh
           gQeV5KgP1cdvPt1BEowKqK4Sw== )
   dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org.  3600  IN  NSEC3  (
           1 0 1 - t6lf7uuoi0qofq0nvdjroavo46pp20im RRSIG TLSA )
   dlm7rss9pejqnh0ev6h7k1ikqqcl5mae.example.org.  3600  IN  RRSIG  (
           NSEC3 13 3 3600 20201202000000 20181128000000 56566
           example.org.
           guUyy9LIZlYb0FZttAdYJGrFNKpKu91Tm+dPOz98rnpwIlwwvLifXIvIl90nE
           X38cWzEQOpreJu3t4WAfPsxdg== )
   a73bi8coh6dvf1arqdeuogf95r0828mk.example.org.  3600  IN  NSEC3  (
           1 0 1 - c1p0lp7l1l8gdn0jl13pp1o41h35untj CNAME RRSIG )
   a73bi8coh6dvf1arqdeuogf95r0828mk.example.org.  3600  IN  RRSIG  (
           NSEC3 13 3 3600 20201202000000 20181128000000 56566
           example.org.
           ePBUuWdj8Bc+/41gHBm2Bx/IK/j/Q4W7A5uTgSj/0Sd57mP/NTWRZq3p8yBNe
           FPC2mBJ2oWQFi6/V9dmyiBh2A== )
   example.org.  3600  IN  DNSKEY  ( 256 3 13
           NrbL6utGqIW1wrhhjeexdA6bMdD1lC1hj0Fnpevaa1AMyY2uy83TmoGnR996N
           UR5TlG4Zh+YPbbmUIixe4nS3w== ) ; Key ID = 56566
   example.org.  3600  IN  DNSKEY  ( 257 3 13
           uspaqp17jsMTX6AWVgmbog/3Sttz+9ANFUWLn6qKUHr0BOqRuChQWj8jyYUUr
           Wy9txxesNQ9MkO4LUrFght1LQ== ) ; Key ID = 44384
   example.org.  3600  IN  RRSIG  ( DNSKEY 13 2 3600
           20201202000000 20181128000000 44384 example.org.
           ttse9pYp9PSu0pJ+TOpIVFLWJ6NKOMWZX4Q/SlU6ZfaiKQc0Bg7Tut9+wPunk
           6OPPvyHjVXMAsvk0tqV0B+/ag== )
   example.org.  86400  IN  DS  ( 44384 13 2 ec307e2efc8f0117ed96ab48a51
           3c8003e1d9121f1ff11a08b4cdd348d090aa6 )
   example.org.  86400  IN  RRSIG  ( DS 13 2 86400 20201202000000
           20181128000000 9523 org.
           m86Xz0CEa2sWG40a0bS2kqLKPmIlyiVyDeoWXAq3djeGiPaikLuKORNzWXu62
           clpAfvZHx59Ackst4X+zXYpUA== )
   org.  86400  IN  DNSKEY  ( 256 3 13
           fuLp60znhSSEr9HowILpTpyLKQdM6ixcgkTE0gqVdsLx+DSNHSc69o6fLWC0e
           HfWx7kzlBBoJB0vLrvsJtXJ6g== ) ; Key ID = 47417
   org.  86400  IN  DNSKEY  ( 256 3 13
           zTHbb7JM627Bjr8CGOySUarsic91xZU3vvLJ5RjVix9YH6+iwpBXb6qfHyQHy
           mlMiAAoaoXh7BUkEBVgDVN8sQ== ) ; Key ID = 9523
   org.  86400  IN  DNSKEY  ( 257 3 13
           Uf24EyNt51DMcLV+dHPInhSpmjPnqAQNUTouU+SGLu+lFRRlBetgw1bJUZNI6
           Dlger0VJTm0QuX/JVXcyGVGoQ== ) ; Key ID = 49352
   org.  86400  IN  DNSKEY  ( 257 3 13
           0SZfoe8Yx+eoaGgyAGEeJax/ZBV1AuG+/smcOgRm+F6doNlgc3lddcM1MbTvJ
           HTjK6Fvy8W6yZ+cAptn8sQheg== ) ; Key ID = 12651
   org.  86400  IN  RRSIG  ( DNSKEY 13 1 86400 20201202000000
           20181128000000 12651 org.
           Gq9wf+z3pasXXUwE210jYc0LhJnMAhcwXydnvkHtCVY6/0jUafHO4RksN84Zt
           us0pUgWngbT/OWXskdMYXZU4A== )
   org.  86400  IN  RRSIG  ( DNSKEY 13 1 86400 20201202000000
           20181128000000 49352 org.
           VGEkEMWBJ2IbOpm2Z56Qxu2NGPcVUDWCbYRyk+Qk1+HzGtyd2qPEKkpgMs/0p
           vZEMj1YXD+dIqb2nUK9PGBAXw== )
   org.  86400  IN  DS  ( 12651 13 2 3979a51f98bbf219fcaf4a4176e766dfa8f
           9db5c24a75743eb1e704b97a9fabc )
   org.  86400  IN  DS  ( 49352 13 2 03d11a1aa114abbb8f708c3c0ff0db765fe
           f4a2f18920db5f58710dd767c293b )
   org.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
           20181128000000 31918 .
           adiFuP2UIulQw5Edsb/7WSPqr5nkRSTVXbZ2tkBeZRQcMjdCD3pyonWO5JPRV
           EemgaE357S4pX5D0tVZzeZJ6A== )
   .  86400  IN  DNSKEY  ( 256 3 13
           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
   .  86400  IN  DNSKEY  ( 256 3 13
           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
   .  86400  IN  DNSKEY  ( 257 3 13
           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
           20181128000000 47005 .
           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
           nBT1dtNjIczvLG9pQTnOKUsHQ== )

A.8. "_443._tcp.www.insecure.example" NSEC3 Opt-Out Insecure Delegation

A.8. "_443._tcp.www.insecure.example" NSEC3オプトアウト不安定な代理人

   c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example.  43200  IN  NSEC3  (
           1 1 1 - shn05itmoa45mmnv74lc4p0nnfmimtjt NS SOA RRSIG DNSKEY
           NSEC3PARAM )
   c1kgc91hrn9nqi2qjh1ms78ki8p7s75o.example.  43200  IN  RRSIG  (
           NSEC3 13 2 43200 20201202000000 20181128000000 15903
           example.
           pW16gQOLhLpKYgXpGt4XB4o92W/QoPYyG5CjQ+t+g7LBVcCiPQv8ars1j9UOg
           RpXUsJhZBDax2dfDhK7zOk7ow== )
   shn05itmoa45mmnv74lc4p0nnfmimtjt.example.  43200  IN  NSEC3  (
           1 1 1 - a3ib1dvf1bdtfmd91usrdem5fiiepi6p NS DS RRSIG )
   shn05itmoa45mmnv74lc4p0nnfmimtjt.example.  43200  IN  RRSIG  (
           NSEC3 13 2 43200 20201202000000 20181128000000 15903
           example.
           5Aq//A8bsWNwcXbT91pMX2Oqf8VpJQRjqH4D2yZElW00wKmt85mhgu2qYPrvH
           QwGEB4STMz2Nefq01/GY6NHKg== )
   example.  432000  IN  DNSKEY  ( 257 3 13
           yrkqXSbVwXOoUxCjr/E9yg8XUzbZNlwPllVsoUPd73TLOnBQQ+03Qw4/k+Nme
           /66WIw+ZTlHYcTNalxiGYm0uQ== ) ; Key ID = 15903
   example.  432000  IN  RRSIG  ( DNSKEY 13 1 432000
           20201202000000 20181128000000 15903 example.
           wwEo3ri6JBuCqx5b33w8axFWOhIen1l+/mm0Isyc9FciuLhBiP+IqSgt+Igc8
           9nR8zRpJpo1D6XR/qJxZgnfaA== )
   example.  86400  IN  DS  ( 15903 13 2 7e0ebaf1cc0d309d4a73ca7d711719d
           d940f4da87b3d72865167650fc73ea577 )
   example.  86400  IN  RRSIG  ( DS 13 1 86400 20201202000000
           20181128000000 31918 .
           B5vx4zZaS+bOYfz0PzpaPfk9VxxBvYbGjIvGhpUZV3diXzfCguXxN4JIT1Sz8
           eJX6BYT5QPIrbG/N35U1sIskw== )
   .  86400  IN  DNSKEY  ( 256 3 13
           zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjW
           P98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918
   .  86400  IN  DNSKEY  ( 256 3 13
           8wMZZ4lzHdyKZ4fv8kys/t3QMlgvEadbsbyqWrMhwddSXCZYGRrsAbPpireRW
           xbVcd1VtOrlFBcRDMTN0R0XEQ== ) ; Key ID = 2635
   .  86400  IN  DNSKEY  ( 257 3 13
           yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8Xclv
           Q+gDOXnFOTsgs/frMmxyGOtRg== ) ; Key ID = 47005
   .  86400  IN  RRSIG  ( DNSKEY 13 0 86400 20201202000000
           20181128000000 47005 .
           0EPW1ca+N/ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9m
           nBT1dtNjIczvLG9pQTnOKUsHQ== )

Acknowledgments

謝辞

Many thanks to Adam Langley for laying the groundwork for this extension in [SERIALIZECHAIN]. The original idea is his, but our acknowledgment in no way implies his endorsement. This document also benefited from discussions with and review from the following people: Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick McManus, Rick van Rein, Ilari Liusvaara, Eric Rescorla, Gowri Visweswaran, Duane Wessels, Nico Williams, and Richard Barnes.

[SerializeChain]でこの拡張のために基礎を築くためのAdam Langleyに感謝します。元のアイデアは彼のものですが、私たちの承認は決して彼の支持を意味します。この文書はまた、次の人々との議論とレビューの恩恵を受けています.Daniel Kahn Gillmor、Jeff Hodges、Allison Mankin、Patrick Mcmanus、Rick Van Rein、Ilari Liusvaara、Eric Rescorla、Gowri Visweswaran、Duane Wessels、Nico Williams、Richard Barnes。

Authors' Addresses

著者の住所

Viktor Dukhovni Two Sigma

viktor dukhovni 2匹のシグマ

   Email: ietf-dane@dukhovni.org

Shumon Huque Salesforce 3rd Floor 415 Mission Street San Francisco, CA 94105 United States of America

Shuquon Huque Salesforce 3階のミッションストリートサンフランシスコ、CA 94105アメリカ合衆国

   Email: shuque@gmail.com

Willem Toorop NLnet Labs Science Park 400 1098 XH Amsterdam Netherlands

Willem Toorop NLNet Labs Science Park 400 1098 XHアムステルダムオランダ

   Email: willem@nlnetlabs.nl

Paul Wouters Aiven Toronto Canada

Paul Wouters Ariven Torontoカナダ

   Email: paul.wouters@aiven.io

Melinda Shore Fastly

   Email: mshore@fastly.com