[要約] RFC 8659は、DNS Certification Authority Authorization（CAA）リソースレコードに関する標準化された仕様です。CAAレコードは、特定のドメインに対して証明書発行を許可する認証局を制御するために使用されます。このRFCの目的は、CAAレコードの一貫性とセキュリティを向上させることです。
Internet Engineering Task Force (IETF) P. Hallam-Baker
Request for Comments: 8659 Venture Cryptography
Obsoletes: 6844 R. Stradling
Category: Standards Track Sectigo
ISSN: 2070-1721 J. Hoffman-Andrews
Let's Encrypt
November 2019
DNS Certification Authority Authorization (CAA) Resource Record
DNS証明機関承認（CAA）リソースレコード
Abstract
概要
The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by CAs.
証明機関承認（CAA）DNSリソースレコードを使用すると、DNSドメイン名の所有者は、そのドメイン名の証明書を発行することを承認された1つ以上の証明機関（CA）を指定できます。 CAAリソースレコードを使用すると、パブリックCAは追加の制御を実装して、意図しない証明書の誤発行のリスクを軽減できます。このドキュメントでは、CAAレコードの構文と、CAがCAAレコードを処理するためのルールを定義します。
This document obsoletes RFC 6844.
このドキュメントはRFC 6844を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8659.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8659で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Definitions
2.1. Requirements Language
2.2. Defined Terms
3. Relevant Resource Record Set
4. Mechanism
4.1. Syntax
4.1.1. Canonical Presentation Format
4.2. CAA issue Property
4.3. CAA issuewild Property
4.4. CAA iodef Property
4.5. Critical Flag
5. Security Considerations
5.1. Use of DNS Security
5.2. Non-compliance by Certification Authority
5.3. Mis-Issue by Authorized Certification Authority
5.4. Suppression or Spoofing of CAA Records
5.5. Denial of Service
5.6. Abuse of the Critical Flag
6. Deployment Considerations
6.1. Blocked Queries or Responses
6.2. Rejected Queries and Malformed Responses
6.3. Delegation to Private Nameservers
6.4. Bogus DNSSEC Responses
7. Differences from RFC 6844
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain name. Publication of CAA Resource Records allows a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue.
証明機関承認（CAA）DNSリソースレコードを使用すると、DNSドメイン名の所有者は、そのドメイン名の証明書を発行することを承認された証明機関（CA）を指定できます。 CAAリソースレコードの公開により、パブリックCAは追加の制御を実装して、意図しない証明書の誤発行のリスクを軽減できます。
Like the TLSA record defined in DNS-Based Authentication of Named Entities (DANE) [RFC6698], CAA records are used as a part of a mechanism for checking PKIX [RFC6698] certificate data. The distinction between CAA and TLSA is that CAA records specify an authorization control to be performed by a CA before issuing a certificate and TLSA records specify a verification control to be performed by a Relying Party after the certificate is issued.
名前付きエンティティのDNSベース認証（DANE）[RFC6698]で定義されているTLSAレコードと同様に、CAAレコードは、PKIX [RFC6698]証明書データをチェックするメカニズムの一部として使用されます。 CAAとTLSAの違いは、CAAレコードは証明書を発行する前にCAが実行する承認制御を指定し、TLSAレコードは証明書が発行された後に証明書利用者が実行する検証制御を指定することです。
Conformance with a published CAA record is a necessary, but not sufficient, condition for the issuance of a certificate.
公開されたCAAレコードとの適合性は、証明書の発行に必要ですが、十分ではありません。
Criteria for the inclusion of embedded trust anchor certificates in applications are outside the scope of this document. Typically, such criteria require the CA to publish a Certification Practices Statement (CPS) that specifies how the requirements of the Certificate Policy (CP) are achieved. It is also common for a CA to engage an independent third-party auditor to prepare an annual audit statement of its performance against its CPS.
組み込みトラストアンカー証明書をアプリケーションに含める基準は、このドキュメントの範囲外です。通常、このような基準では、証明書ポリシー（CP）の要件がどのように達成されるかを指定する認証実施規定（CPS）を発行することをCAに要求します。 CAがCPSに対するパフォーマンスの年次監査ステートメントを作成するために独立した第三者監査人を雇うことも一般的です。
A set of CAA records describes only current grants of authority to issue certificates for the corresponding DNS domain name. Since certificates are valid for a period of time, it is possible that a certificate that is not conformant with the CAA records currently published was conformant with the CAA records published at the time that the certificate was issued. Relying Parties MUST NOT use CAA records as part of certificate validation.
CAAレコードのセットには、対応するDNSドメイン名の証明書を発行するための現在の権限付与のみが記述されています。証明書は一定期間有効であるため、現在発行されているCAAレコードに準拠していない証明書が、証明書の発行時に発行されたCAAレコードに準拠していた可能性があります。依拠当事者は、証明書検証の一部としてCAAレコードを使用してはなりません。
CAA records MAY be used by Certificate Evaluators as a possible indicator of a security policy violation. Such use SHOULD take into account the possibility that published CAA records changed between the time a certificate was issued and the time at which the certificate was observed by the Certificate Evaluator.
CAAレコードは、セキュリティポリシー違反の可能性のあるインジケータとして、証明書エバリュエーターによって使用される場合があります。そのような使用は、発行されたCAAレコードが、証明書が発行されたときと、証明書が証明書エバリュエーターによって監視されたときの間に変更された可能性を考慮に入れるべきです（SHOULD）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following terms are used in this document:
このドキュメントでは、次の用語が使用されています。
Certificate: An X.509 Certificate, as specified in [RFC5280].
証明書：[RFC5280]で指定されているX.509証明書。
Certificate Evaluator: A party other than a Relying Party that evaluates the trustworthiness of certificates issued by Certification Authorities.
証明書エバリュエーター：証明機関によって発行された証明書の信頼性を評価する証明書利用者以外の当事者。
Certification Authority (CA): An Issuer that issues certificates in accordance with a specified Certificate Policy.
証明機関（CA）：指定された証明書ポリシーに従って証明書を発行する発行者。
Certificate Policy (CP): Specifies the criteria that a CA undertakes to meet in its issue of certificates. See [RFC3647].
証明書ポリシー（CP）：証明書の発行で満たすためにCAが行う基準を指定します。 [RFC3647]を参照してください。
Certification Practices Statement (CPS): Specifies the means by which the criteria of the CP are met. In most cases, this will be the document against which the operations of the CA are audited. See [RFC3647].
認証実務声明（CPS）：CPの基準を満たす手段を指定します。ほとんどの場合、これはCAの操作が監査されるドキュメントになります。 [RFC3647]を参照してください。
Domain Name: The label assigned to a node in the Domain Name System.
ドメイン名：ドメインネームシステムのノードに割り当てられたラベル。
Domain Name System (DNS): The Internet naming system specified in [RFC1034] and [RFC1035].
ドメインネームシステム（DNS）：[RFC1034]と[RFC1035]で指定されたインターネットネームシステム。
DNS Security (DNSSEC): Extensions to the DNS that provide authentication services as specified in [RFC4033], [RFC4034], [RFC4035], [RFC5155], and any revisions to these specifications.
DNSセキュリティ（DNSSEC）：[RFC4033]、[RFC4034]、[RFC4035]、[RFC5155]で指定されている認証サービスを提供するDNSの拡張機能、およびこれらの仕様の改訂。
Fully Qualified Domain Name (FQDN): A domain name that includes the labels of all superior nodes in the DNS.
完全修飾ドメイン名（FQDN）：DNS内のすべての上位ノードのラベルを含むドメイン名。
Issuer: An entity that issues certificates. See [RFC5280].
発行者：証明書を発行するエンティティ。 [RFC5280]を参照してください。
Property: The tag-value portion of a CAA Resource Record.
プロパティ：CAAリソースレコードのタグ値部分。
Property Tag: The tag portion of a CAA Resource Record.
プロパティタグ：CAAリソースレコードのタグ部分。
Property Value: The value portion of a CAA Resource Record.
プロパティ値：CAAリソースレコードの値の部分。
Relevant Resource Record Set (Relevant RRset): A set of CAA Resource Records resulting from applying the algorithm in Section 3 to a specific FQDN or Wildcard Domain Name.
関連リソースレコードセット（関連RRset）：セクション3のアルゴリズムを特定のFQDNまたはワイルドカードドメイン名に適用した結果のCAAリソースレコードのセット。
Relying Party: A party that makes use of an application whose operation depends on the use of a certificate for making a security decision. See [RFC5280].
証明書利用者：セキュリティ決定を行うための証明書の使用に依存して動作するアプリケーションを利用する当事者。 [RFC5280]を参照してください。
Resource Record (RR): A particular entry in the DNS, including the owner name, class, type, time to live, and data, as defined in [RFC1034] and [RFC2181].
リソースレコード（RR）：[RFC1034]および[RFC2181]で定義されている、所有者名、クラス、タイプ、存続時間、およびデータを含む、DNSの特定のエントリ。
Resource Record Set (RRset): A set of RRs of a particular owner name, class, and type. The time to live on all RRs within an RRset is always the same, but the data may be different among RRs in the RRset.
リソースレコードセット（RRset）：特定の所有者名、クラス、およびタイプのRRのセット。 RRset内のすべてのRRで存続する時間は常に同じですが、データはRRset内のRR間で異なる場合があります。
Wildcard Domain Name: A domain name consisting of a single asterisk character followed by a single "full stop" character ("*.") followed by an FQDN.
ワイルドカードドメイン名：単一のアスタリスク文字の後に単一の「完全停止」文字（ "*。"）が続き、その後にFQDNが続くドメイン名。
Before issuing a certificate, a compliant CA MUST check for publication of a Relevant RRset. If such an RRset exists, a CA MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA RRset or (2) an exception specified in the relevant CP or CPS applies. If the Relevant RRset for an FQDN or Wildcard Domain Name contains no Property Tags that restrict issuance (for instance, if it contains only iodef Property Tags or only Property Tags unrecognized by the CA), CAA does not restrict issuance.
証明書を発行する前に、準拠するCAは、関連するRRsetの公開を確認する必要があります。そのようなRRsetが存在する場合、CAは、（1）証明書要求が該当するCAA RRsetと一致しているか、または（2）関連するCPまたはCPSで指定された例外が適用されると判断しない限り、証明書を発行してはなりません。 FQDNまたはワイルドカードドメイン名の関連RRsetに発行を制限するプロパティタグが含まれていない場合（たとえば、iodefプロパティタグのみ、またはCAによって認識されないプロパティタグのみが含まれている場合）、CAAは発行を制限しません。
A certificate request MAY specify more than one FQDN and MAY specify Wildcard Domain Names. Issuers MUST verify authorization for all the FQDNs and Wildcard Domain Names specified in the request.
証明書要求は、複数のFQDNを指定してもよいし（MAY）、ワイルドカードドメイン名を指定してもよい（MAY）。発行者は、リクエストで指定されたすべてのFQDNとワイルドカードドメイン名の承認を確認する必要があります。
The search for a CAA RRset climbs the DNS name tree from the specified label up to, but not including, the DNS root "." until a CAA RRset is found.
CAA RRsetの検索では、指定されたラベルからDNSルート「。」まで（ただし、それを含まない）までDNS名ツリーをたどります。 CAA RRsetが見つかるまで。
Given a request for a specific FQDN X or a request for a Wildcard Domain Name *.X, the Relevant RRset RelevantCAASet(X) is determined as follows (in pseudocode):
特定のFQDN Xの要求またはワイルドカードドメイン名* .Xの要求が与えられると、関連するRRset RelevantCAASet（X）は次のように決定されます（疑似コード）。
Let CAA(X) be the RRset returned by performing a CAA record query for the FQDN X, according to the lookup algorithm specified in Section 4.3.2 of [RFC1034] (in particular, chasing aliases). Let Parent(X) be the FQDN produced by removing the leftmost label of X.
[RFC1034]のセクション4.3.2で指定されたルックアップアルゴリズム（特に、エイリアスの追跡）に従って、FQDN XのCAAレコードクエリを実行して返されるRRsetをCAA（X）とします。 Parent（X）をXの左端のラベルを削除することによって生成されたFQDNとします。
RelevantCAASet(domain):
while domain is not ".":
if CAA(domain) is not Empty:
return CAA(domain)
domain = Parent(domain)
return Empty
For example, processing CAA for the FQDN "X.Y.Z" where there are no CAA records at any level in the tree RelevantCAASet would have the following steps:
たとえば、ツリーRelevantCAASetのどのレベルにもCAAレコードがないFQDN "X.Y.Z"のCAAを処理するには、次の手順を実行します。
CAA("X.Y.Z.") = Empty; domain = Parent("X.Y.Z.") = "Y.Z."
CAA("Y.Z.") = Empty; domain = Parent("Y.Z.") = "Z."
CAA("Z.") = Empty; domain = Parent("Z.") = "."
return Empty
Processing CAA for the FQDN "A.B.C" where there is a CAA record "issue example.com" at "B.C" would terminate early upon finding the CAA record:
"B.C"にCAAレコード "issue example.com"があるFQDN "A.B.C"のCAAの処理は、CAAレコードを見つけると早期に終了します。
CAA("A.B.C.") = Empty; domain = Parent("A.B.C.") = "B.C."
CAA("B.C.") = "issue example.com"
return "issue example.com"
A CAA RR contains a single Property consisting of a tag-value pair. An FQDN MAY have multiple CAA RRs associated with it, and a given Property Tag MAY be specified more than once across those RRs.
CAA RRには、タグと値のペアで構成される単一のプロパティが含まれています。 FQDNには複数のCAA RRが関連付けられている場合があり（MAY）、特定のプロパティタグはそれらのRRにわたって複数回指定される場合があります。
The RDATA section for a CAA RR contains one Property. A Property consists of the following:
CAA RRのRDATAセクションには、1つのプロパティが含まれています。プロパティは次のもので構成されます。
+0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-|
| Flags | Tag Length = n |
+----------------|----------------+...+---------------+
| Tag char 0 | Tag char 1 |...| Tag char n-1 |
+----------------|----------------+...+---------------+
+----------------|----------------+.....+----------------+
| Value byte 0 | Value byte 1 |.....| Value byte m-1 |
+----------------|----------------+.....+----------------+
Where n is the length specified in the Tag Length field and m is the number of remaining octets in the Value field. They are related by (m = d - n - 2) where d is the length of the RDATA section.
ここで、nはTag Lengthフィールドで指定された長さで、mはValueフィールドで残っているオクテットの数です。それらは（m = d-n-2）によって関連付けられます。ここで、dはRDATAセクションの長さです。
The fields are defined as follows:
フィールドは次のように定義されています。
Flags: One octet containing the following field:
フラグ：次のフィールドを含む1つのオクテット：
Bit 0, Issuer Critical Flag: If the value is set to "1", the Property is critical. A CA MUST NOT issue certificates for any FQDN if the Relevant RRset for that FQDN contains a CAA critical Property for an unknown or unsupported Property Tag.
ビット0、発行者の重要なフラグ：値が「1」に設定されている場合、プロパティは重要です。 FQDNの関連RRsetに不明またはサポートされていないプロパティタグのCAAクリティカルプロパティが含まれている場合、CAはFQDNの証明書を発行してはなりません（MUST NOT）。
Note that according to the conventions set out in [RFC1035], bit 0 is the Most Significant Bit and bit 7 is the Least Significant Bit. Thus, according to those conventions, the Flags value 1 means that bit 7 is set, while a value of 128 means that bit 0 is set.
[RFC1035]で規定されている規則に従って、ビット0が最上位ビットであり、ビット7が最下位ビットであることに注意してください。したがって、これらの規則に従って、フラグ値1はビット7が設定されていることを意味し、値128はビット0が設定されていることを意味します。
All other bit positions are reserved for future use.
他のすべてのビット位置は、将来の使用のために予約されています。
To ensure compatibility with future extensions to CAA, DNS records compliant with this version of the CAA specification MUST clear (set to "0") all reserved flag bits. Applications that interpret CAA records MUST ignore the value of all reserved flag bits.
CAAの将来の拡張との互換性を確保するために、このバージョンのCAA仕様に準拠するDNSレコードは、すべての予約済みフラグビットをクリア（ "0"に設定）する必要があります。 CAAレコードを解釈するアプリケーションは、すべての予約済みフラグビットの値を無視する必要があります。
Tag Length: A single octet containing an unsigned integer specifying the tag length in octets. The tag length MUST be at least 1.
タグの長さ：オクテットでタグの長さを指定する符号なし整数を含む単一のオクテット。タグの長さは少なくとも1でなければなりません。
Tag: The Property identifier -- a sequence of ASCII characters.
タグ：プロパティ識別子-ASCII文字のシーケンス。
Tags MAY contain ASCII characters "a" through "z", "A" through "Z", and the numbers 0 through 9. Tags MUST NOT contain any other characters. Matching of tags is case insensitive.
タグには、ASCII文字「a」から「z」、「A」から「Z」、および0から9の数字を含めることができます。タグに他の文字を含めることはできません。タグのマッチングでは、大文字と小文字は区別されません。
Tags submitted for registration by IANA MUST NOT contain any characters other than the (lowercase) ASCII characters "a" through "z" and the numbers 0 through 9.
IANAによる登録のために送信されたタグには、（小文字の）ASCII文字「a」から「z」および0から9までの数字以外の文字を含めてはなりません。
Value: A sequence of octets representing the Property Value. Property Values are encoded as binary values and MAY employ sub-formats.
値：プロパティ値を表すオクテットのシーケンス。プロパティ値はバイナリ値としてエンコードされ、サブフォーマットを使用する場合があります。
The length of the Value field is specified implicitly as the remaining length of the enclosing RDATA section.
Valueフィールドの長さは、それを囲むRDATAセクションの残りの長さとして暗黙的に指定されます。
The canonical presentation format of the CAA record is:
CAAレコードの標準的な表示形式は次のとおりです。
CAA <flags> <tag> <value>
Where:
ただし：
Flags: An unsigned integer between 0 and 255.
フラグ：0〜255の符号なし整数。
Tag: A non-zero-length sequence of ASCII letters and numbers in lowercase.
タグ：長さ0以外の小文字のASCII文字と数字のシーケンス。
Value: The Value field, expressed as either (1) a contiguous set of characters without interior spaces or (2) a quoted string. See the <character-string> format specified in [RFC1035], Section 5.1, but note that the Value field contains no length byte and is not limited to 255 characters.
値：（1）内部スペースのない連続した文字セット、または（2）引用符付き文字列のいずれかで表される値フィールド。 [RFC1035]のセクション5.1で指定されている<character-string>形式を参照してください。ただし、Valueフィールドには長さバイトが含まれておらず、255文字に制限されていないことに注意してください。
If the issue Property Tag is present in the Relevant RRset for an FQDN, it is a request that Issuers:
問題のプロパティタグがFQDNの関連RRsetに存在する場合、それは発行者が要求するものです。
1. Perform CAA issue restriction processing for the FQDN, and
1. FQDNのCAA問題制限処理を実行します。
2. Grant authorization to issue certificates containing that FQDN to the holder of the issuer-domain-name or a party acting under the explicit authority of the holder of the issuer-domain-name.
2. そのFQDNを含む証明書を発行する権限を、発行者ドメイン名の所有者、または発行者ドメイン名の所有者の明示的な権限の下で行動する当事者に付与します。
The CAA issue Property Value has the following sub-syntax (specified in ABNF as per [RFC5234]).
CAA発行のプロパティ値には、次のサブ構文があります（[RFC5234]に従ってABNFで指定）。
issue-value = *WSP [issuer-domain-name *WSP]
[";" *WSP [parameters *WSP]]
issuer-domain-name = label *("." label)
label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))
parameters = (parameter *WSP ";" *WSP parameters) / parameter
parameter = tag *WSP "=" *WSP value
tag = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))
value = *(%x21-3A / %x3C-7E)
For consistency with other aspects of DNS administration, FQDN values are specified in letter-digit-hyphen Label (LDH-Label) form.
DNS管理の他の側面との一貫性を保つために、FQDN値は文字数字ハイフンラベル（LDH-ラベル）形式で指定されます。
The following CAA RRset requests that no certificates be issued for the FQDN "certs.example.com" by any Issuer other than ca1.example.net or ca2.example.org.
次のCAA RRsetは、ca1.example.netまたはca2.example.org以外の発行者がFQDN「certs.example.com」に対して発行する証明書がないことを要求します。
certs.example.com CAA 0 issue "ca1.example.net" certs.example.com CAA 0 issue "ca2.example.org"
certs.example.com CAA 0の問題「ca1.example.net」certs.example.com CAA 0の問題「ca2.example.org」
Because the presence of an issue Property Tag in the Relevant RRset for an FQDN restricts issuance, FQDN owners can use an issue Property Tag with no issuer-domain-name to request no issuance.
FQDNの関連RRsetに課題プロパティタグが存在すると、発行が制限されるため、FQDNの所有者は、発行者ドメイン名のない課題プロパティタグを使用して、発行を要求できません。
For example, the following RRset requests that no certificates be issued for the FQDN "nocerts.example.com" by any Issuer.
たとえば、次のRRsetは、発行者がFQDN "nocerts.example.com"に対して証明書を発行しないことを要求しています。
nocerts.example.com CAA 0 issue ";"
nocerts.example.com CAA 0の問題 ";"
An issue Property Tag where the issue-value does not match the ABNF grammar MUST be treated the same as one specifying an empty issuer-domain-name. For example, the following malformed CAA RRset forbids issuance:
issue-valueがABNF文法と一致しない課題プロパティタグは、空のissuer-domain-nameを指定するものと同じように扱わなければなりません（MUST）。たとえば、次の不正なCAA RRsetは発行を禁止します。
malformed.example.com CAA 0 issue "%%%%%"
malformed.example.com CAA 0の問題「%%%%%」
CAA authorizations are additive; thus, the result of specifying both an empty issuer-domain-name and a non-empty issuer-domain-name is the same as specifying just the non-empty issuer-domain-name.
CAA許可は追加的です。したがって、空の発行者ドメイン名と空でない発行者ドメイン名の両方を指定した結果は、空でない発行者ドメイン名だけを指定した場合と同じです。
An Issuer MAY choose to specify parameters that further constrain the issue of certificates by that Issuer -- for example, specifying that certificates are to be subject to specific validation policies, billed to certain accounts, or issued under specific trust anchors.
発行者は、その発行者による証明書の発行をさらに制約するパラメーターを指定することを選択できます-たとえば、証明書が特定の検証ポリシーの対象、特定のアカウントに請求される、または特定のトラストアンカーの下で発行されることを指定します。
For example, if ca1.example.net has requested that its customer account.example.com specify their account number "230123" in each of the customer's CAA records using the (CA-defined) "account" parameter, it would look like this:
たとえば、ca1.example.netが顧客account.example.comに、（CA定義の）「アカウント」パラメータを使用して、顧客の各CAAレコードでアカウント番号「230123」を指定するように要求した場合、次のようになります。 ：
account.example.com CAA 0 issue "ca1.example.net; account=230123"
account.example.com CAA 0の問題「ca1.example.net; account = 230123」
The semantics of parameters to the issue Property Tag are determined by the Issuer alone.
課題プロパティタグへのパラメーターのセマンティクスは、発行者のみによって決定されます。
The issuewild Property Tag has the same syntax and semantics as the issue Property Tag except that it only grants authorization to issue certificates that specify a Wildcard Domain Name and each issuewild Property takes precedence over each issue Property when specified. Specifically:
issuewildプロパティタグの構文とセマンティクスは、ワイルドカードドメイン名を指定する証明書の発行のみを許可し、指定された場合は各issuewildプロパティが各issueプロパティよりも優先されることを除いて、issueプロパティタグと同じです。具体的には：
Each issuewild Property MUST be ignored when processing a request for an FQDN that is not a Wildcard Domain Name.
ワイルドカードドメイン名ではないFQDNのリクエストを処理するときは、各issuewildプロパティを無視する必要があります。
If at least one issuewild Property is specified in the Relevant RRset for a Wildcard Domain Name, each issue Property MUST be ignored when processing a request for that Wildcard Domain Name.
ワイルドカードドメイン名の関連RRsetで少なくとも1つのissuewildプロパティが指定されている場合、そのワイルドカードドメイン名のリクエストを処理するときに、各issueプロパティを無視する必要があります。
For example, the following RRset requests that _only_ ca1.example.net issue certificates for "wild.example.com" or "sub.wild.example.com", and that _only_ ca2.example.org issue certificates for "*.wild.example.com" or "*.sub.wild.example.com". Note that this presumes that there are no CAA RRs for sub.wild.example.com.
たとえば、次のRRsetは、_only_ ca1.example.netが「wild.example.com」または「sub.wild.example.com」の証明書を発行し、_only_ ca2.example.orgが「* .wild」の証明書を発行することを要求します.example.com」または「* .sub.wild.example.com」。これは、sub.wild.example.comのCAA RRがないことを前提としています。
wild.example.com CAA 0 issue "ca1.example.net" wild.example.com CAA 0 issuewild "ca2.example.org"
wild.example.com CAA 0の問題「ca1.example.net」wild.example.com CAA 0の問題ワイルド「ca2.example.org」
The following RRset requests that _only_ ca1.example.net issue certificates for "wild2.example.com", "*.wild2.example.com", or "*.sub.wild2.example.com".
次のRRsetは、_only_ ca1.example.netが「wild2.example.com」、「*。wild2.example.com」、または「* .sub.wild2.example.com」の証明書を発行することを要求します。
wild2.example.com CAA 0 issue "ca1.example.net"
wild2.example.com CAA 0の問題「ca1.example.net」
The following RRset requests that _only_ ca2.example.org issue certificates for "*.wild3.example.com" or "*.sub.wild3.example.com". It does not permit any Issuer to issue for "wild3.example.com" or "sub.wild3.example.com".
以下のRRsetは、_only_ ca2.example.orgが「* .wild3.example.com」または「* .sub.wild3.example.com」の証明書を発行することを要求します。発行者が「wild3.example.com」または「sub.wild3.example.com」に対して発行することは許可されていません。
wild3.example.com CAA 0 issuewild "ca2.example.org" wild3.example.com CAA 0 issue ";"
wild3.example.com CAA 0の問題wild "ca2.example.org" wild3.example.com CAA 0の問題 ";"
The following RRset requests that _only_ ca2.example.org issue certificates for "*.wild3.example.com" or "*.sub.wild3.example.com". It permits any Issuer to issue for "wild3.example.com" or "sub.wild3.example.com".
以下のRRsetは、_only_ ca2.example.orgが「* .wild3.example.com」または「* .sub.wild3.example.com」の証明書を発行することを要求します。イシュアが「wild3.example.com」または「sub.wild3.example.com」に対して発行することを許可します。
wild3.example.com CAA 0 issuewild "ca2.example.org"
will3.example.comの0issuevild "k2.example.org"
The iodef Property specifies a means of reporting certificate issue requests or cases of certificate issue for domains for which the Property appears in the Relevant RRset, when those requests or issuances violate the security policy of the Issuer or the FQDN holder.
iodefプロパティは、要求または発行が発行者またはFQDN所有者のセキュリティポリシーに違反する場合に、プロパティが関連RRsetに表示されるドメインの証明書発行要求または証明書発行のケースを報告する手段を指定します。
The Incident Object Description Exchange Format (IODEF) [RFC7970] is used to present the incident report in machine-readable form.
インシデントオブジェクト記述交換フォーマット（IODEF）[RFC7970]は、機械読み取り可能な形式でインシデントレポートを提示するために使用されます。
The iodef Property Tag takes a URL as its Property Value. The URL scheme type determines the method used for reporting:
iodefプロパティタグは、プロパティ値としてURLを取ります。 URLスキームのタイプによって、レポートに使用される方法が決まります。
mailto: The IODEF report is reported as a MIME email attachment to an SMTP email that is submitted to the mail address specified. The mail message sent SHOULD contain a brief text message to alert the recipient to the nature of the attachment.
mailto：IODEFレポートは、指定されたメールアドレスに送信されるSMTP電子メールのMIME電子メール添付ファイルとして報告されます。送信されるメールメッセージには、添付ファイルの性質を受信者に警告する簡単なテキストメッセージを含める必要があります（SHOULD）。
http or https: The IODEF report is submitted as a web service request to the HTTP address specified using the protocol specified in [RFC6546].
httpまたはhttps：IODEFレポートは、[RFC6546]で指定されたプロトコルを使用して指定されたHTTPアドレスにWebサービス要求として送信されます。
These are the only supported URL schemes.
これらはサポートされている唯一のURLスキームです。
The following RRset specifies that reports may be made by means of email with the IODEF data as an attachment, a web service [RFC6546], or both:
次のRRsetは、IODEFデータを添付した電子メール、Webサービス[RFC6546]、またはその両方を使用してレポートを作成できることを指定しています。
report.example.com CAA 0 issue "ca1.example.net"
report.example.com CAA 0 iodef "mailto:security@example.com"
report.example.com CAA 0 iodef "https://iodef.example.com/"
The critical flag is intended to permit future versions of CAA to introduce new semantics that MUST be understood for correct processing of the record, preventing conforming CAs that do not recognize the new semantics from issuing certificates for the indicated FQDNs.
クリティカルフラグは、CAAの将来のバージョンがレコードを正しく処理するために理解しなければならない新しいセマンティクスを導入できるようにすることを目的としており、新しいセマンティクスを認識しない適合CAが示されたFQDNの証明書を発行することを防ぎます。
In the following example, the Property with a Property Tag of "tbs" is flagged as critical. Neither the ca1.example.net CA nor any other Issuer is authorized to issue for "new.example.com" (or any other domains for which this is the Relevant RRset) unless the Issuer has implemented the processing rules for the "tbs" Property Tag.
次の例では、プロパティタグが「tbs」のプロパティに重要なフラグが設定されています。発行者が「tbs」の処理規則を実装していない限り、ca1.example.net CAも他の発行者も、「new.example.com」（またはこれが関連RRsetである他のドメイン）に対して発行することを許可されていません。プロパティタグ。
new.example.com CAA 0 issue "ca1.example.net" new.example.com CAA 128 tbs "Unknown"
new.example.com CAA 0の問題 "ca1.example.net" new.example.com CAA 128 tbs "不明"
CAA records assert a security policy that the holder of an FQDN wishes to be observed by Issuers. The effectiveness of CAA records as an access control mechanism is thus dependent on observance of CAA constraints by Issuers.
CAAレコードは、FQDNの所有者が発行者によって監視されることを希望するセキュリティポリシーをアサートします。したがって、アクセス制御メカニズムとしてのCAAレコードの有効性は、発行者によるCAA制約の遵守に依存しています。
The objective of the CAA record properties described in this document is to reduce the risk of certificate mis-issue rather than avoid reliance on a certificate that has been mis-issued. DANE [RFC6698] describes a mechanism for avoiding reliance on mis-issued certificates.
このドキュメントで説明されているCAAレコードプロパティの目的は、誤って発行された証明書への依存を回避するのではなく、証明書の誤った発行のリスクを減らすことです。 DANE [RFC6698]は、誤って発行された証明書への依存を回避するためのメカニズムについて説明しています。
The use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not required. An Issuer MUST NOT issue certificates if doing so would conflict with the Relevant RRset, irrespective of whether the corresponding DNS records are signed.
DNSSECを使用してCAA RRを認証することを強くお勧めしますが、必須ではありません。対応するDNSレコードが署名されているかどうかに関係なく、発行者は、関連するRRsetと競合する場合、証明書を発行してはなりません（MUST NOT）。
DNSSEC provides a proof of non-existence for both DNS FQDNs and RRsets within FQDNs. DNSSEC verification thus enables an Issuer to determine whether the answer to a CAA record query (1) is empty because the RRset is empty or (2) is non-empty but the response has been suppressed.
DNSSECは、DNS FQDNとFQDN内のRRsetの両方が存在しないことを証明します。したがって、DNSSEC検証により、発行者はCAAレコードクエリへの回答が（1）RRsetが空のため空であるか、（2）空ではないが応答が抑制されているかを判断できます。
The use of DNSSEC allows an Issuer to acquire and archive a proof that they were authorized to issue certificates for the FQDN. Verification of such archives may be an audit requirement to verify CAA record-processing compliance. Publication of such archives may be a transparency requirement to verify CAA record-processing compliance.
DNSSECを使用すると、発行者はFQDNの証明書を発行する権限が与えられたという証明を取得してアーカイブできます。このようなアーカイブの検証は、CAAレコード処理のコンプライアンスを検証するための監査要件になる場合があります。このようなアーカイブの公開は、CAAレコード処理のコンプライアンスを検証するための透明性の要件となる場合があります。
CAA records offer CAs a cost-effective means of mitigating the risk of certificate mis-issue: the cost of implementing CAA checks is very small, and the potential costs of a mis-issue event include the removal of an embedded trust anchor.
CAAレコードは、CAに証明書の誤発行のリスクを軽減する費用効果の高い手段を提供します。CAAチェックの実装コストは非常に小さく、誤発行イベントの潜在的なコストには、埋め込まれたトラストアンカーの削除が含まれます。
The use of CAA records does not prevent mis-issue by an authorized CA, i.e., a CA that is authorized to issue certificates for the FQDN in question by CAA records.
CAAレコードを使用しても、承認されたCA、つまり、問題のFQDNの証明書をCAAレコードで発行することが許可されているCAによる誤発行を防ぐことはできません。
FQDN holders SHOULD verify that the CAs they authorize to issue certificates for their FQDNs employ appropriate controls to ensure that certificates are issued only to authorized parties within their organization.
FQDN保有者は、FQDNの証明書の発行を許可するCAが適切な制御を使用して、組織内の承認された関係者にのみ証明書が発行されることを確認する必要があります（SHOULD）。
Such controls are most appropriately determined by the FQDN holder and the authorized CA(s) directly and are thus outside the scope of this document.
このような制御は、FQDNの所有者と承認されたCAによって直接適切に決定されるため、このドキュメントの範囲外です。
Suppression of a CAA record or insertion of a bogus CAA record could enable an attacker to obtain a certificate from an Issuer that was not authorized to issue for an affected FQDN.
CAAレコードの抑制または偽のCAAレコードの挿入により、攻撃者は、影響を受けるFQDNに対して発行することが許可されていない発行者から証明書を取得する可能性があります。
Where possible, Issuers SHOULD perform DNSSEC validation to detect missing or modified CAA RRsets.
発行者は、可能であれば、DNSSEC検証を実行して、欠落または変更されたCAA RRsetを検出する必要があります（SHOULD）。
In cases where DNSSEC is not deployed for a corresponding FQDN, an Issuer SHOULD attempt to mitigate this risk by employing appropriate DNS security controls. For example, all portions of the DNS lookup process SHOULD be performed against the authoritative nameserver. Data cached by third parties MUST NOT be relied on as the sole source of DNS CAA information but MAY be used to support additional anti-spoofing or anti-suppression controls.
対応するFQDNにDNSSECが展開されていない場合、発行者は、適切なDNSセキュリティコントロールを採用することにより、このリスクを軽減しようとする必要があります（SHOULD）。たとえば、DNSルックアッププロセスのすべての部分は、信頼できるネームサーバーに対して実行する必要があります（SHOULD）。サードパーティによってキャッシュされたデータは、DNS CAA情報の唯一のソースとして依存してはなりません（MUST）が、追加のスプーフィング防止または抑制抑制制御をサポートするために使用される場合があります。
Introduction of a malformed or malicious CAA RR could, in theory, enable a Denial-of-Service (DoS) attack. This could happen by modification of authoritative DNS records or by spoofing inflight DNS responses.
不正な形式または悪意のあるCAA RRの導入により、理論的にはサービス拒否（DoS）攻撃が可能になります。これは、信頼できるDNSレコードの変更または機内DNS応答のなりすましによって発生する可能性があります。
This specific threat is not considered to add significantly to the risk of running an insecure DNS service.
この特定の脅威は、安全でないDNSサービスを実行するリスクを大幅に増大するとは考えられていません。
An attacker could, in principle, perform a DoS attack against an Issuer by requesting a certificate with a maliciously long DNS name. In practice, the DNS protocol imposes a maximum name length, and CAA processing does not exacerbate the existing need to mitigate DoS attacks to any meaningful degree.
攻撃者は原則として、悪意を持って長いDNS名を持つ証明書を要求することにより、発行者に対してDoS攻撃を実行する可能性があります。実際には、DNSプロトコルは名前の最大長を課し、CAA処理は、意味のある程度までDoS攻撃を軽減するという既存のニーズを悪化させることはありません。
A CA could make use of the critical flag to trick customers into publishing records that prevent competing CAs from issuing certificates even though the customer intends to authorize multiple providers. This could happen if the customers were setting CAA records based on data provided by the CA rather than generating those records themselves.
CAはクリティカルフラグを利用して、顧客が複数のプロバイダーを承認するつもりでも、競合するCAが証明書を発行できないようにするレコードを公開するように顧客をだますことができます。これは、顧客がCAAレコードを生成するのではなく、CAから提供されたデータに基づいてCAAレコードを設定した場合に発生する可能性があります。
In practice, such an attack would be of minimal effect, since any competent competitor that found itself unable to issue certificates due to lack of support for a Property marked critical should investigate the cause and report the reason to the customer. The customer will thus discover that they had been deceived.
クリティカルとマークされたプロパティのサポートが不足しているために証明書を発行できなかった有能な競争者は原因を調査し、理由を顧客に報告する必要があるため、実際には、このような攻撃の影響は最小限です。したがって、顧客は彼らがだまされていたことに気付くでしょう。
A CA implementing CAA may find that they receive errors looking up CAA records. The following are some common causes of such errors, so that CAs may provide guidance to their subscribers on fixing the underlying problems.
CAAを実装するCAは、CAAレコードの検索中にエラーを受け取る場合があります。以下は、そのようなエラーのいくつかの一般的な原因です。CAは、根本的な問題の修正についてサブスクライバーにガイダンスを提供する場合があります。
Some middleboxes -- in particular, anti-DDoS appliances -- may be configured to drop DNS packets of unknown types, or they may start dropping such packets when they consider themselves under attack. This generally manifests as a timed-out DNS query or as a SERVFAIL at a local recursive resolver.
一部のミドルボックス（特に、DDoS対策アプライアンス）は、不明なタイプのDNSパケットをドロップするように設定されている場合や、攻撃を受けていると見なしたときに、そのようなパケットのドロップを開始する場合があります。これは通常、タイムアウトしたDNSクエリとして、またはローカルの再帰リゾルバでのSERVFAILとして現れます。
Some authoritative nameservers respond with REJECTED or NOTIMP when queried for an RR type they do not recognize. At least one authoritative resolver produces a malformed response (with the QR (Query/Response) bit set to "0") when queried for unknown RR types. Per [RFC1034], the correct response RCODE for unknown RR types is 0 ("No error condition").
一部の権威ネームサーバーは、認識できないRRタイプを照会すると、REJECTEDまたはNOTIMPで応答します。少なくとも1つの信頼できるリゾルバーは、不明なRRタイプを照会されたときに、不正な形式の応答（QR（クエリ/応答）ビットが "0"に設定されている）を生成します。 [RFC1034]によると、不明なRRタイプの正しい応答RCODEは0（「エラー状態なし」）です。
Some FQDN administrators make the contents of a subdomain unresolvable on the public Internet by delegating that subdomain to a nameserver whose IP address is private. A CA processing CAA records for such subdomains will receive SERVFAIL from its recursive resolver. The CA MAY interpret that as preventing issuance. FQDN administrators wishing to issue certificates for private FQDNs SHOULD use split-horizon DNS with a publicly available nameserver, so that CAs can receive a valid, empty CAA response for those FQDNs.
一部のFQDN管理者は、IPアドレスがプライベートであるネームサーバーにサブドメインを委任することにより、サブドメインのコンテンツをパブリックインターネット上で解決できないようにします。このようなサブドメインのCAAレコードを処理するCAは、その再帰リゾルバーからSERVFAILを受け取ります。 CAはそれを発行を妨げると解釈してもよい（MAY）。プライベートFQDNの証明書を発行するFQDN管理者は、公開されているネームサーバーでスプリットホライズンDNSを使用して、CAがそれらのFQDNに対して有効な空のCAA応答を受信できるようにする必要があります。
Queries for CAA RRs are different from most DNS RR types, because a signed, empty response to a query for CAA RRs is meaningfully different from a bogus response. A signed, empty response indicates that there is definitely no CAA policy set at a given label. A bogus response may mean either a misconfigured zone or an attacker tampering with records. DNSSEC implementations may have bugs with signatures on empty responses that go unnoticed, because for more common RR types like A and AAAA, the difference to an end user between empty and bogus is irrelevant; they both mean a site is unavailable.
CAA RRのクエリに対するほとんどのDNS RRタイプとは異なります。CAARRのクエリに対する署名された空の応答は、偽の応答とは意味が異なるためです。署名された空の応答は、特定のラベルにCAAポリシーが設定されていないことを示しています。偽の応答は、誤って構成されたゾーンまたはレコードを改ざんする攻撃者のいずれかを意味する場合があります。 DNSSECの実装には、AやAAAAなどのより一般的なRRタイプでは、空と偽のエンドユーザーとの違いは関係がないため、気付かれない空の応答の署名にバグがある可能性があります。どちらもサイトが利用できないことを意味します。
In particular, at least two authoritative resolvers that implement live signing had bugs when returning empty RRsets for DNSSEC-signed zones, in combination with mixed-case queries. Mixed-case queries, also known as DNS 0x20, are used by some recursive resolvers to increase resilience against DNS poisoning attacks. DNSSEC-signing authoritative resolvers are expected to copy the same capitalization from the query into their ANSWER section but also to sign the response as if they had used all lowercase. In particular, PowerDNS versions prior to 4.0.4 had this bug.
特に、ライブ署名を実装する少なくとも2つの信頼できるリゾルバーには、大文字と小文字が混在するクエリと組み合わせて、DNSSEC署名ゾーンの空のRRsetを返すときにバグがありました。 DNS 0x20とも呼ばれる大文字と小文字が混在するクエリは、DNSポイズニング攻撃に対する回復力を高めるために、一部の再帰リゾルバによって使用されます。 DNSSEC署名の信頼できるリゾルバーは、同じ大文字をクエリからANSWERセクションにコピーするだけでなく、すべて小文字を使用しているかのように応答に署名することが期待されています。特に、4.0.4より前のバージョンのPowerDNSにはこのバグがありました。
This document obsoletes [RFC6844]. The most important change is to the "Certification Authority Processing" section (now called "Relevant Resource Record Set" (Section 3), as noted below). [RFC6844] specified an algorithm that performed DNS tree-climbing not only on the FQDN being processed but also on all CNAMEs and DNAMEs encountered along the way. This made the processing algorithm very inefficient when used on FQDNs that utilize many CNAMEs and would have made it difficult for hosting providers to set CAA policies on their own FQDNs without setting potentially unwanted CAA policies on their customers' FQDNs. This document specifies a simplified processing algorithm that only performs tree-climbing on the FQDN being processed, and it leaves the processing of CNAMEs and DNAMEs up to the CA's recursive resolver.
このドキュメントは廃止されました[RFC6844]。最も重要な変更は、「認証局の処理」セクションです（現在、「関連リソースレコードセット」（セクション3）と呼ばれています）。 [RFC6844]は、処理中のFQDNだけでなく、途中で遭遇したすべてのCNAMEおよびDNAMEでもDNSツリークライミングを実行するアルゴリズムを指定しました。これにより、多くのCNAMEを使用するFQDNで処理アルゴリズムを使用すると非常に非効率になり、ホスティングプロバイダーが顧客のFQDNに潜在的に不要なCAAポリシーを設定せずに独自のFQDNにCAAポリシーを設定することが困難になります。このドキュメントでは、処理中のFQDNでのみツリークライミングを実行する簡略化された処理アルゴリズムを指定し、CNAMEとDNAMEの処理をCAの再帰リゾルバに任せています。
This document also includes a "Deployment Considerations" section (Section 6) detailing experience gained with practical deployment of CAA enforcement among CAs in the WebPKI.
このドキュメントには、「展開に関する考慮事項」セクション（セクション6）も含まれています。WebPKIのCA間でCAA実施を実際に展開して得られた経験の詳細が記載されています。
This document clarifies the ABNF grammar for the issue and issuewild tags and resolves some inconsistencies with the document text. In particular, it specifies that parameters are separated with semicolons. It also allows hyphens in Property Tags.
このドキュメントでは、issueとissuewildタグのABNF文法を明確にし、ドキュメントテキストとの不整合を解決します。特に、パラメーターがセミコロンで区切られていることを指定します。プロパティタグでハイフンを使用することもできます。
This document also clarifies the processing of a CAA RRset that is not empty but that does not contain any issue or issuewild tags.
このドキュメントでは、空ではないがissueまたはissuewildタグを含まないCAA RRsetの処理についても説明しています。
This document removes the section titled "The CAA RR Type," merging it with "Mechanism" (Section 4) because the definitions were mainly duplicates. It moves the "Use of DNS Security" section into Security Considerations (Section 5). It renames "Certification Authority Processing" to "Relevant Resource Record Set" (Section 3) and emphasizes the use of that term to more clearly define which domains are affected by a given RRset.
このドキュメントでは、「CAA RRタイプ」というタイトルのセクションを削除し、「メカニズム」（セクション4）とマージしています。これは、定義が主に重複しているためです。 「DNSセキュリティの使用」セクションをセキュリティの考慮事項（セクション5）に移動します。 「認証局処理」の名前を「関連リソースレコードセット」（セクション3）に変更し、その用語の使用を強調して、特定のRRsetによって影響を受けるドメインをより明確に定義します。
IANA has added this document as a reference for the "Certification Authority Restriction Flags" and "Certification Authority Restriction Properties" registries and updated references to [RFC6844] within those registries to refer instead to this document. IANA has also updated the CAA TYPE in the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry with a reference to this document.
IANAは、このドキュメントを「認証局制限フラグ」および「認証局制限プロパティ」レジストリの参照として追加し、これらのレジストリ内の[RFC6844]への参照を更新して、代わりにこの文書を参照しました。 IANAは、「ドメインネームシステム（DNS）パラメータ」レジストリの「リソースレコード（RR）タイプ」サブレジストリのCAAタイプもこのドキュメントへの参照で更新しました。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https://www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https://www.rfc-editor.org/info/rfc1035>。
[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。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>.
[RFC2181] Elz、R。およびR. Bush、「Clarifications to the DNS Specification」、RFC 2181、DOI 10.17487 / RFC2181、1997年7月、<https://www.rfc-editor.org/info/rfc2181>。
[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 Security Extensionsのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、< https://www.rfc-editor.org/info/rfc4034>。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/info/rfc4035>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、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. Blacka、「DNS Security（DNSSEC）Hashed Authenticated Denial of Existence」、RFC 5155、DOI 10.17487 / RFC5155、2008年3月、<https： //www.rfc-editor.org/info/rfc5155>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC6546] Trammell, B., "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", RFC 6546, DOI 10.17487/RFC6546, April 2012, <https://www.rfc-editor.org/info/rfc6546>.
[RFC6546] Trammell、B。、「HTTP / TLSを介したリアルタイムネットワーク間防御（RID）メッセージのトランスポート」、RFC 6546、DOI 10.17487 / RFC6546、2012年4月、<https：//www.rfc-editor。 org / info / rfc6546>。
[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）トランスポート層セキュリティ（TLS）プロトコルの認証：TLSA」、RFC 6698、DOI 10.17487 / RFC6698、2012年8月、<https：/ /www.rfc-editor.org/info/rfc6698>。
[RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 6844, DOI 10.17487/RFC6844, January 2013, <https://www.rfc-editor.org/info/rfc6844>.
[RFC6844] Hallam-Baker、P。およびR. Stradling、「DNS Certification Authority Authorization（CAA）Resource Record」、RFC 6844、DOI 10.17487 / RFC6844、2013年1月、<https://www.rfc-editor.org/ info / rfc6844>。
[RFC7970] Danyliw, R., "The Incident Object Description Exchange Format Version 2", RFC 7970, DOI 10.17487/RFC7970, November 2016, <https://www.rfc-editor.org/info/rfc7970>.
[RFC7970] Danyliw、R。、「The Incident Object Description Exchange Format Version 2」、RFC 7970、DOI 10.17487 / RFC7970、2016年11月、<https://www.rfc-editor.org/info/rfc7970>。
[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>。
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, DOI 10.17487/RFC3647, November 2003, <https://www.rfc-editor.org/info/rfc3647>.
[RFC3647] Chokhani、S.、Ford、W.、Sabett、R.、Merrill、C.、and S. Wu、 "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework"、RFC 3647、DOI 10.17487 / RFC3647、2003年11月、<https://www.rfc-editor.org/info/rfc3647>。
Acknowledgements
謝辞
The authors would like to thank the following people who contributed to the design and documentation of this work item: Corey Bonnell, Chris Evans, Stephen Farrell, Jeff Hodges, Paul Hoffman, Tim Hollebeek, Stephen Kent, Adam Langley, Ben Laurie, James Manger, Chris Palmer, Scott Schmit, Sean Turner, and Ben Wilson.
著者は、この作業項目の設計と文書化に貢献した次の人々に感謝します：Corey Bonnell、Chris Evans、Stephen Farrell、Jeff Hodges、Paul Hoffman、Tim Hollebeek、Stephen Kent、Adam Langley、Ben Laurie、James Manger 、クリス・パーマー、スコット・シュミット、ショーン・ターナー、ベン・ウィルソン。
Authors' Addresses
著者のアドレス
Phillip Hallam-Baker Venture Cryptography
Phillip Hallam-Bakerベンチャー暗号
Email: phill@hallambaker.com
Rob Stradling Sectigo Ltd.
ロブストラドリングセティゴ株式会社
Email: rob@sectigo.com
Jacob Hoffman-Andrews Let's Encrypt
Jacob Hoffman-Andrews Let's Encrypt
Email: jsha@letsencrypt.org