From: Evan Hunt Date: Tue, 29 Jul 2014 15:41:40 +0000 (-0700) Subject: [v9_8] add CAA rdata support X-Git-Tag: v9.8.8b2~35 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=15717990950bea4e8b3f11f837c0d16976c0f312;p=thirdparty%2Fbind9.git [v9_8] add CAA rdata support 3056. [protocol] Added support for CAA record type (RFC 6844). [RT #36625] (cherry picked from commit eb898fa698dff36d2432bdcbac46bd0c2f90963f) (cherry picked from commit 001e08f10df06aa9a103cf5cbd164f4e5c6c3cd0) --- diff --git a/CHANGES b/CHANGES index 020dc3c381d..b8d177b1703 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,6 @@ +3056. [protocol] Added support for CAA record type (RFC 6844). + [RT #36625] + 3900. [bug] Fix a crash in PostgreSQL DLZ driver. [RT #36637] 3899. [bug] "request-ixfr" is only applicable to slave and redirect diff --git a/bin/tests/rdata_test.c b/bin/tests/rdata_test.c index 0e505a33476..b531e39ab58 100644 --- a/bin/tests/rdata_test.c +++ b/bin/tests/rdata_test.c @@ -282,6 +282,11 @@ viastruct(dns_rdata_t *rdata, isc_mem_t *mctx, result = dns_rdata_tostruct(rdata, sp = &uri, NULL); break; } + case dns_rdatatype_caa: { + static dns_rdata_caa_t caa; + result = dns_rdata_tostruct(rdata, sp = &caa, NULL); + break; + } case dns_rdatatype_wks: { static dns_rdata_in_wks_t in_wks; result = dns_rdata_tostruct(rdata, sp = &in_wks, NULL); @@ -549,6 +554,11 @@ viastruct(dns_rdata_t *rdata, isc_mem_t *mctx, result = dns_rdata_tostruct(rdata, sp = &uri, mctx); break; } + case dns_rdatatype_caa: { + static dns_rdata_caa_t caa; + result = dns_rdata_tostruct(rdata, sp = &caa, mctx); + break; + } case dns_rdatatype_wks: { static dns_rdata_in_wks_t in_wks; result = dns_rdata_tostruct(rdata, sp = &in_wks, mctx); @@ -846,6 +856,11 @@ viastruct(dns_rdata_t *rdata, isc_mem_t *mctx, result = dns_rdata_fromstruct(rdata2, rdc, rdt, &uri, b); break; } + case dns_rdatatype_caa: { + dns_rdata_caa_t caa; + result = dns_rdata_fromstruct(rdata2, rdc, rdt, &caa, b); + break; + } case dns_rdatatype_wks: { dns_rdata_in_wks_t in_wks; result = dns_rdata_fromstruct(rdata2, rdc, rdt, &in_wks, b); diff --git a/bin/tests/system/genzone.sh b/bin/tests/system/genzone.sh index 13ed0236281..ee0ebdef1bf 100644 --- a/bin/tests/system/genzone.sh +++ b/bin/tests/system/genzone.sh @@ -303,6 +303,11 @@ eui64 EUI64 01-23-45-67-89-ab-cd-ef uri01 URI 10 20 "https://www.isc.org/" uri02 URI 30 40 "https://www.isc.org/HolyCowThisSureIsAVeryLongURIRecordIDontEvenKnowWhatSomeoneWouldEverWantWithSuchAThingButTheSpecificationRequiresThatWesupportItSoHereWeGoTestingItLaLaLaLaLaLaLaSeriouslyThoughWhyWouldYouEvenConsiderUsingAURIThisLongItSeemsLikeASillyIdeaButEnhWhatAreYouGonnaDo/" +; type 257 +caa01 CAA 0 issue "ca.example.net; policy=ev" +caa02 CAA 128 tbs "Unknown" + +; keydata (internal type used for managed-keys) keydata TYPE65533 \# 0 keydata TYPE65533 \# 6 010203040506 keydata TYPE65533 \# 18 010203040506010203040506010203040506 diff --git a/bin/tests/system/xfer/dig1.good b/bin/tests/system/xfer/dig1.good index abf6e10649e..73092cda726 100644 --- a/bin/tests/system/xfer/dig1.good +++ b/bin/tests/system/xfer/dig1.good @@ -9,6 +9,8 @@ a601.example. 3600 IN A6 127 ::1 foo. a601.example. 3600 IN A6 128 . afsdb01.example. 3600 IN AFSDB 0 hostname.example. afsdb02.example. 3600 IN AFSDB 65535 . +caa01.example. 3600 IN CAA 0 issue "ca.example.net\; policy=ev" +caa02.example. 3600 IN CAA 128 tbs "Unknown" cdnskey01.example. 3600 IN CDNSKEY 512 255 1 AQMFD5raczCJHViKtLYhWGz8hMY9UGRuniJDBzC7w0aRyzWZriO6i2od GWWQVucZqKVsENW91IOW4vqudngPZsY3GvQ/xVA8/7pyFj6b7Esga60z yGW6LFe9r8n6paHrlG5ojqf0BaqHT+8= cds01.example. 3600 IN CDS 30795 1 1 310D27F4D82C1FC2400704EA9939FE6E1CEAA3B9 cert01.example. 3600 IN CERT 65534 65535 PRIVATEOID MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6V AuHAoNUz4YoU1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= diff --git a/bin/tests/system/xfer/dig2.good b/bin/tests/system/xfer/dig2.good index 9dd775b67a3..f5eed453d65 100644 --- a/bin/tests/system/xfer/dig2.good +++ b/bin/tests/system/xfer/dig2.good @@ -9,6 +9,8 @@ a601.example. 3600 IN A6 127 ::1 foo. a601.example. 3600 IN A6 128 . afsdb01.example. 3600 IN AFSDB 0 hostname.example. afsdb02.example. 3600 IN AFSDB 65535 . +caa01.example. 3600 IN CAA 0 issue "ca.example.net\; policy=ev" +caa02.example. 3600 IN CAA 128 tbs "Unknown" cdnskey01.example. 3600 IN CDNSKEY 512 255 1 AQMFD5raczCJHViKtLYhWGz8hMY9UGRuniJDBzC7w0aRyzWZriO6i2od GWWQVucZqKVsENW91IOW4vqudngPZsY3GvQ/xVA8/7pyFj6b7Esga60z yGW6LFe9r8n6paHrlG5ojqf0BaqHT+8= cds01.example. 3600 IN CDS 30795 1 1 310D27F4D82C1FC2400704EA9939FE6E1CEAA3B9 cert01.example. 3600 IN CERT 65534 65535 PRIVATEOID MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6V AuHAoNUz4YoU1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= diff --git a/bin/tests/system/xfer/tests.sh b/bin/tests/system/xfer/tests.sh index 75db0a43d2b..b38f13453a9 100644 --- a/bin/tests/system/xfer/tests.sh +++ b/bin/tests/system/xfer/tests.sh @@ -27,7 +27,7 @@ status=0 echo "I:testing basic zone transfer functionality" $DIG $DIGOPTS example. \ @10.53.0.2 axfr -p 5300 > dig.out.ns2 || status=1 -grep ";" dig.out.ns2 +grep "^;" dig.out.ns2 # # Spin to allow the zone to tranfer. @@ -37,13 +37,13 @@ do tmp=0 $DIG $DIGOPTS example. \ @10.53.0.3 axfr -p 5300 > dig.out.ns3 || tmp=1 - grep ";" dig.out.ns3 > /dev/null + grep "^;" dig.out.ns3 > /dev/null if test $? -ne 0 ; then break; fi echo "I: plain zone re-transfer" sleep 5 done if test $tmp -eq 1 ; then status=1; fi -grep ";" dig.out.ns3 +grep "^;" dig.out.ns3 $PERL ../digcomp.pl dig1.good dig.out.ns2 || status=1 @@ -53,7 +53,7 @@ echo "I:testing TSIG signed zone transfers" $DIG $DIGOPTS tsigzone. \ @10.53.0.2 axfr -y tsigzone.:1234abcd8765 -p 5300 \ > dig.out.ns2 || status=1 -grep ";" dig.out.ns2 +grep "^;" dig.out.ns2 # # Spin to allow the zone to tranfer. @@ -64,13 +64,13 @@ tmp=0 $DIG $DIGOPTS tsigzone. \ @10.53.0.3 axfr -y tsigzone.:1234abcd8765 -p 5300 \ > dig.out.ns3 || tmp=1 - grep ";" dig.out.ns3 > /dev/null + grep "^;" dig.out.ns3 > /dev/null if test $? -ne 0 ; then break; fi echo "I: plain zone re-transfer" sleep 5 done if test $tmp -eq 1 ; then status=1; fi -grep ";" dig.out.ns3 +grep "^;" dig.out.ns3 $PERL ../digcomp.pl dig.out.ns2 dig.out.ns3 || status=1 @@ -135,7 +135,7 @@ done $DIG $DIGOPTS example. \ @10.53.0.3 axfr -p 5300 > dig.out.ns3 || tmp=1 -grep ";" dig.out.ns3 +grep "^;" dig.out.ns3 $PERL ../digcomp.pl dig2.good dig.out.ns3 || tmp=1 @@ -151,11 +151,11 @@ tmp=0 $DIG $DIGOPTS master. \ @10.53.0.6 axfr -p 5300 > dig.out.ns6 || tmp=1 -grep ";" dig.out.ns6 +grep "^;" dig.out.ns6 $DIG $DIGOPTS master. \ @10.53.0.3 axfr -p 5300 > dig.out.ns3 || tmp=1 -grep ";" dig.out.ns3 && cat dig.out.ns3 +grep "^;" dig.out.ns3 && cat dig.out.ns3 $PERL ../digcomp.pl dig.out.ns6 dig.out.ns3 || tmp=1 @@ -171,11 +171,11 @@ tmp=0 $DIG $DIGOPTS slave. \ @10.53.0.6 axfr -p 5300 > dig.out.ns6 || tmp=1 -grep ";" dig.out.ns6 +grep "^;" dig.out.ns6 $DIG $DIGOPTS slave. \ @10.53.0.1 axfr -p 5300 > dig.out.ns1 || tmp=1 -grep ";" dig.out.ns1 +grep "^;" dig.out.ns1 $PERL ../digcomp.pl dig.out.ns6 dig.out.ns1 || tmp=1 @@ -200,11 +200,11 @@ tmp=0 $DIG $DIGOPTS slave. \ @10.53.0.1 axfr -p 5300 > dig.out.ns1 || tmp=1 -grep ";" dig.out.ns1 +grep "^;" dig.out.ns1 $DIG $DIGOPTS slave. \ @10.53.0.7 axfr -p 5300 > dig.out.ns7 || tmp=1 -grep ";" dig.out.ns1 +grep "^;" dig.out.ns1 $PERL ../digcomp.pl dig.out.ns7 dig.out.ns1 || tmp=1 diff --git a/doc/rfc/rfc6844.txt b/doc/rfc/rfc6844.txt new file mode 100644 index 00000000000..d923649863d --- /dev/null +++ b/doc/rfc/rfc6844.txt @@ -0,0 +1,1011 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Hallam-Baker +Request for Comments: 6844 Comodo Group, Inc. +Category: Standards Track R. Stradling +ISSN: 2070-1721 Comodo CA, Ltd. + January 2013 + + + DNS Certification Authority Authorization (CAA) Resource Record + +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. + CAA Resource Records allow a public Certification Authority 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 certificate issuers. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6844. + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://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. + + + + +Hallam-Baker & Stradling Standards Track [Page 1] + +RFC 6844 Certification Authority Authorization January 2013 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Definitions .....................................................3 + 2.1. Requirements Language ......................................3 + 2.2. Defined Terms ..............................................3 + 3. The CAA RR Type .................................................5 + 4. Certification Authority Processing ..............................7 + 4.1. Use of DNS Security ........................................8 + 5. Mechanism .......................................................8 + 5.1. Syntax .....................................................8 + 5.1.1. Canonical Presentation Format ......................10 + 5.2. CAA issue Property ........................................10 + 5.3. CAA issuewild Property ....................................12 + 5.4. CAA iodef Property ........................................12 + 6. Security Considerations ........................................13 + 6.1. Non-Compliance by Certification Authority .................13 + 6.2. Mis-Issue by Authorized Certification Authority ...........13 + 6.3. Suppression or Spoofing of CAA Records ....................13 + 6.4. Denial of Service .........................................14 + 6.5. Abuse of the Critical Flag ................................14 + 7. IANA Considerations ............................................14 + 7.1. Registration of the CAA Resource Record Type ..............14 + 7.2. Certification Authority Restriction Properties ............15 + 7.3. Certification Authority Restriction Flags .................15 + 8. Acknowledgements ...............................................16 + 9. References .....................................................16 + 9.1. Normative References ......................................16 + 9.2. Informative References ....................................17 + +1. Introduction + + 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. + Publication of CAA Resource Records allows a public Certification + Authority to implement additional controls to reduce the risk of + unintended certificate mis-issue. + + 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 certificate data. The distinction + between the two specifications is that CAA records specify an + authorization control to be performed by a certificate issuer before + issue of a certificate and TLSA records specify a verification + control to be performed by a relying party after the certificate is + issued. + + + + +Hallam-Baker & Stradling Standards Track [Page 2] + +RFC 6844 Certification Authority Authorization January 2013 + + + Conformance with a published CAA record is a necessary but not + sufficient condition for issuance of a certificate. Before issuing a + certificate, a PKIX CA is required to validate the request according + to the policies set out in its Certificate Policy. In the case of a + public CA that validates certificate requests as a third party, the + certificate will typically be issued under a public trust anchor + certificate embedded in one or more relevant Relying Applications. + + Criteria for inclusion of embedded trust anchor certificates in + applications are outside the scope of this document. Typically, such + criteria require the CA to publish a Certificate 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. + + A set of CAA records describes only current grants of authority to + issue certificates for the corresponding DNS domain. Since a + certificate is typically valid for at least a year, 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 Applications MUST + NOT use CAA records as part of certificate validation. + + CAA records MAY be used by Certificate Evaluators as a possible + indicator of a security policy violation. Such use SHOULD take + account of 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. + +2. Definitions + +2.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2.2. Defined Terms + + The following terms are used in this document: + + Authorization Entry: An authorization assertion that grants or + denies a specific set of permissions to a specific group of + entities. + + Certificate: An X.509 Certificate, as specified in [RFC5280]. + + + + +Hallam-Baker & Stradling Standards Track [Page 3] + +RFC 6844 Certification Authority Authorization January 2013 + + + 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. + + Certificate Policy (CP): Specifies the criteria that a Certification + Authority undertakes to meet in its issue of certificates. See + [RFC3647]. + + Certification Practices Statement (CPS): Specifies the means by + which the criteria of the Certificate Policy are met. In most + cases, this will be the document against which the operations of + the Certification Authority are audited. See [RFC3647]. + + Domain: A DNS Domain Name. + + Domain Name: A DNS Domain Name as specified in [STD13]. + + Domain Name System (DNS): The Internet naming system specified in + [STD13]. + + DNS Security (DNSSEC): Extensions to the DNS that provide + authentication services as specified in [RFC4033], [RFC4034], + [RFC4035], [RFC5155], and revisions. + + Issuer: An entity that issues certificates. See [RFC5280]. + + Property: The tag-value portion of a CAA Resource Record. + + Property Tag: The tag portion of a CAA Resource Record. + + Property Value: The value portion of a CAA Resource Record. + + Public Key Infrastructure X.509 (PKIX): Standards and specifications + issued by the IETF that apply the [X.509] certificate standards + specified by the ITU to Internet applications as specified in + [RFC5280] and related documents. + + Resource Record (RR): A particular entry in the DNS including the + owner name, class, type, time to live, and data, as defined in + [STD13] and [RFC2181]. + + Resource Record Set (RRSet): A set of Resource Records or a + particular owner name, class, and type. The time to live on all + RRs with an RRSet is always the same, but the data may be + different among RRs in the RRSet. + + + +Hallam-Baker & Stradling Standards Track [Page 4] + +RFC 6844 Certification Authority Authorization January 2013 + + + Relying Party: A party that makes use of an application whose + operation depends on use of a certificate for making a security + decision. See [RFC5280]. + + Relying Application: An application whose operation depends on use + of a certificate for making a security decision. + +3. The CAA RR Type + + A CAA RR consists of a flags byte and a tag-value pair referred to as + a property. Multiple properties MAY be associated with the same + domain name by publishing multiple CAA RRs at that domain name. The + following flag is defined: + + Issuer Critical: If set to '1', indicates that the corresponding + property tag MUST be understood if the semantics of the CAA record + are to be correctly interpreted by an issuer. + + Issuers MUST NOT issue certificates for a domain if the relevant + CAA Resource Record set contains unknown property tags that have + the Critical bit set. + + The following property tags are defined: + + issue [; = ]* : The issue property + entry authorizes the holder of the domain name or a party acting under the explicit authority of the holder + of that domain name to issue certificates for the domain in which + the property is published. + + issuewild [; = ]* : The issuewild + property entry authorizes the holder of the domain name or a party acting under the explicit authority of the + holder of that domain name to issue wildcard certificates for the + domain in which the property is published. + + iodef : Specifies a URL to which an issuer MAY report + certificate issue requests that are inconsistent with the issuer's + Certification Practices or Certificate Policy, or that a + Certificate Evaluator may use to report observation of a possible + policy violation. The Incident Object Description Exchange Format + (IODEF) format is used [RFC5070]. + + The following example is a DNS zone file (see [RFC1035]) that informs + CAs that certificates are not to be issued except by the holder of + the domain name 'ca.example.net' or an authorized agent thereof. + This policy applies to all subordinate domains under example.com. + + + + +Hallam-Baker & Stradling Standards Track [Page 5] + +RFC 6844 Certification Authority Authorization January 2013 + + + $ORIGIN example.com + . CAA 0 issue "ca.example.net" + + If the domain name holder specifies one or more iodef properties, a + certificate issuer MAY report invalid certificate requests to that + address. In the following example, the domain name holder specifies + that reports may be made by means of email with the IODEF data as an + attachment, a Web service [RFC6546], or both: + + $ORIGIN example.com + . CAA 0 issue "ca.example.net" + . CAA 0 iodef "mailto:security@example.com" + . CAA 0 iodef "http://iodef.example.com/" + + A certificate issuer MAY specify additional parameters that allow + customers to specify additional parameters governing certificate + issuance. This might be the Certificate Policy under which the + certificate is to be issued, the authentication process to be used + might be specified, or an account number specified by the CA to + enable these parameters to be retrieved. + + For example, the CA 'ca.example.net' has requested its customer + 'example.com' to specify the CA's account number '230123' in each of + the customer's CAA records. + + $ORIGIN example.com + . CAA 0 issue "ca.example.net; account=230123" + + The syntax of additional parameters is a sequence of name-value pairs + as defined in Section 5.2. The semantics of such parameters is left + to site policy and is outside the scope of this document. + + The critical flag is intended to permit future versions 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 domains. + + In the following example, the property 'tbs' is flagged as critical. + Neither the example.net CA nor any other issuer is authorized to + issue under either policy unless the processing rules for the 'tbs' + property tag are understood. + + $ORIGIN example.com + . CAA 0 issue "ca.example.net; policy=ev" + . CAA 128 tbs "Unknown" + + + + + +Hallam-Baker & Stradling Standards Track [Page 6] + +RFC 6844 Certification Authority Authorization January 2013 + + + Note that the above restrictions only apply at certificate issue. + Since the validity of an end entity certificate is typically a year + or more, it is quite possible that the CAA records published at a + domain will change between the time a certificate was issued and + validation by a relying party. + +4. Certification Authority Processing + + Before issuing a certificate, a compliant CA MUST check for + publication of a relevant CAA Resource Record set. If such a record + set exists, a CA MUST NOT issue a certificate unless the CA + determines that either (1) the certificate request is consistent with + the applicable CAA Resource Record set or (2) an exception specified + in the relevant Certificate Policy or Certification Practices + Statement applies. + + A certificate request MAY specify more than one domain name and MAY + specify wildcard domains. Issuers MUST verify authorization for all + the domains and wildcard domains specified in the request. + + The search for a CAA record climbs the DNS name tree from the + specified label up to but not including the DNS root '.'. + + Given a request for a specific domain X, or a request for a wildcard + domain *.X, the relevant record set R(X) is determined as follows: + + Let CAA(X) be the record set returned in response to performing a CAA + record query on the label X, P(X) be the DNS label immediately above + X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME + alias record specified at the label X. + + o If CAA(X) is not empty, R(X) = CAA (X), otherwise + + o If A(X) is not null, and R(A(X)) is not empty, then R(X) = + R(A(X)), otherwise + + o If X is not a top-level domain, then R(X) = R(P(X)), otherwise + + o R(X) is empty. + + For example, if a certificate is requested for X.Y.Z the issuer will + search for the relevant CAA record set in the following order: + + X.Y.Z + + Alias (X.Y.Z) + + Y.Z + + + +Hallam-Baker & Stradling Standards Track [Page 7] + +RFC 6844 Certification Authority Authorization January 2013 + + + Alias (Y.Z) + + Z + + Alias (Z) + + Return Empty + +4.1. Use of DNS Security + + 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 CAA Resource Record set, irrespective of + whether the corresponding DNS records are signed. + + DNSSEC provides a proof of non-existence for both DNS domains and RR + set within domains. DNSSEC verification thus enables an issuer to + determine if the answer to a CAA record query is empty because the RR + set is empty or if it is non-empty but the response has been + suppressed. + + Use of DNSSEC allows an issuer to acquire and archive a proof that + they were authorized to issue certificates for the domain. + 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. + +5. Mechanism + +5.1. Syntax + + A CAA RR contains a single property entry consisting of a tag-value + pair. Each tag represents a property of the CAA record. The value + of a CAA property is that specified in the corresponding value field. + + A domain name MAY have multiple CAA RRs associated with it and a + given property MAY be specified more than once. + + The CAA data field contains one property entry. A property entry + consists of the following data fields: + + + + + + + + + + +Hallam-Baker & Stradling Standards Track [Page 8] + +RFC 6844 Certification Authority Authorization January 2013 + + + +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 + remaining octets in the Value field (m = d - n - 2) where d is the + length of the RDATA section. + + The data fields are defined as follows: + + Flags: One octet containing the following fields: + + Bit 0, Issuer Critical Flag: If the value is set to '1', the + critical flag is asserted and the property MUST be understood + if the CAA record is to be correctly processed by a certificate + issuer. + + A Certification Authority MUST NOT issue certificates for any + Domain that contains a CAA critical property for an unknown or + unsupported property tag that for which the issuer critical + flag is set. + + 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, the Flags value 1 means that bit 7 is set while a value + of 128 means that bit 0 is set according to this convention. + + 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 flags bits. Applications that interpret + CAA records MUST ignore the value of all reserved flag bits. + + Tag Length: A single octet containing an unsigned integer specifying + the tag length in octets. The tag length MUST be at least 1 and + SHOULD be no more than 15. + + + + + + + + + +Hallam-Baker & Stradling Standards Track [Page 9] + +RFC 6844 Certification Authority Authorization January 2013 + + + Tag: The property identifier, a sequence of US-ASCII characters. + + Tag values MAY contain US-ASCII characters 'a' through 'z', 'A' + through 'Z', and the numbers 0 through 9. Tag values SHOULD NOT + contain any other characters. Matching of tag values is case + insensitive. + + Tag values submitted for registration by IANA MUST NOT contain any + characters other than the (lowercase) US-ASCII characters 'a' + through 'z' and the numbers 0 through 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 Resource Record data field. + +5.1.1. Canonical Presentation Format + + The canonical presentation format of the CAA record is: + + CAA + + Where: + + Flags: Is an unsigned integer between 0 and 255. + + Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower + case. + + Value: Is the encoding of the value field as + specified in [RFC1035], Section 5.1. + +5.2. CAA issue Property + + The issue property tag is used to request that certificate issuers + perform CAA issue restriction processing for the domain and to grant + authorization to specific certificate issuers. + + The CAA issue property value has the following sub-syntax (specified + in ABNF as per [RFC5234]). + + + + + + + + + +Hallam-Baker & Stradling Standards Track [Page 10] + +RFC 6844 Certification Authority Authorization January 2013 + + + issuevalue = space [domain] space [";" *(space parameter) space] + + domain = label *("." label) + label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT)) + + space = *(SP / HTAB) + + parameter = tag "=" value + + tag = 1*(ALPHA / DIGIT) + + value = *VCHAR + + For consistency with other aspects of DNS administration, domain name + values are specified in letter-digit-hyphen Label (LDH-Label) form. + + A CAA record with an issue parameter tag that does not specify a + domain name is a request that certificate issuers perform CAA issue + restriction processing for the corresponding domain without granting + authorization to any certificate issuer. + + This form of issue restriction would be appropriate to specify that + no certificates are to be issued for the domain in question. + + For example, the following CAA record set requests that no + certificates be issued for the domain 'nocerts.example.com' by any + certificate issuer. + + nocerts.example.com CAA 0 issue ";" + + A CAA record with an issue parameter tag that specifies a domain name + is a request that certificate issuers perform CAA issue restriction + processing for the corresponding domain and grants authorization to + the certificate issuer specified by the domain name. + + For example, the following CAA record set requests that no + certificates be issued for the domain 'certs.example.com' by any + certificate issuer other than the example.net certificate issuer. + + certs.example.com CAA 0 issue "example.net" + + CAA authorizations are additive; thus, the result of specifying both + the empty issuer and a specified issuer is the same as specifying + just the specified issuer alone. + + + + + + + +Hallam-Baker & Stradling Standards Track [Page 11] + +RFC 6844 Certification Authority Authorization January 2013 + + + An issuer MAY choose to specify issuer-parameters that further + constrain the issue of certificates by that issuer, for example, + specifying that certificates are to be subject to specific validation + polices, billed to certain accounts, or issued under specific trust + anchors. + + The semantics of issuer-parameters are determined by the issuer + alone. + +5.3. CAA issuewild Property + + The issuewild property has the same syntax and semantics as the issue + property except that issuewild properties only grant authorization to + issue certificates that specify a wildcard domain and issuewild + properties take precedence over issue properties when specified. + Specifically: + + issuewild properties MUST be ignored when processing a request for + a domain that is not a wildcard domain. + + If at least one issuewild property is specified in the relevant + CAA record set, all issue properties MUST be ignored when + processing a request for a domain that is a wildcard domain. + +5.4. CAA iodef Property + + The iodef property specifies a means of reporting certificate issue + requests or cases of certificate issue for the corresponding domain + that violate the security policy of the issuer or the domain name + holder. + + The Incident Object Description Exchange Format (IODEF) [RFC5070] is + used to present the incident report in machine-readable form. + + The iodef property takes a URL as its parameter. The URL scheme type + determines the method used for reporting: + + mailto: The IODEF incident 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. + + http or https: The IODEF report is submitted as a Web service + request to the HTTP address specified using the protocol specified + in [RFC6546]. + + + + + + +Hallam-Baker & Stradling Standards Track [Page 12] + +RFC 6844 Certification Authority Authorization January 2013 + + +6. Security Considerations + + CAA records assert a security policy that the holder of a domain name + wishes to be observed by certificate issuers. The effectiveness of + CAA records as an access control mechanism is thus dependent on + observance of CAA constraints by issuers. + + 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. + +6.1. Non-Compliance by Certification Authority + + 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. + +6.2. Mis-Issue by Authorized Certification Authority + + Use of CAA records does not prevent mis-issue by an authorized + Certification Authority, i.e., a CA that is authorized to issue + certificates for the domain in question by CAA records. + + Domain name holders SHOULD verify that the CAs they authorize to + issue certificates for their domains employ appropriate controls to + ensure that certificates are issued only to authorized parties within + their organization. + + Such controls are most appropriately determined by the domain name + holder and the authorized CA(s) directly and are thus out of scope of + this document. + +6.3. Suppression or Spoofing of CAA Records + + Suppression of the 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 that domain name. + + Where possible, issuers SHOULD perform DNSSEC validation to detect + missing or modified CAA record sets. + + In cases where DNSSEC is not deployed in a corresponding domain, an + issuer SHOULD attempt to mitigate this risk by employing appropriate + DNS security controls. For example, all portions of the DNS lookup + + + + +Hallam-Baker & Stradling Standards Track [Page 13] + +RFC 6844 Certification Authority Authorization January 2013 + + + process SHOULD be performed against the authoritative name server. + Data cached by third parties MUST NOT be relied on but MAY be used to + support additional anti-spoofing or anti-suppression controls. + +6.4. Denial of Service + + Introduction of a malformed or malicious CAA RR could in theory + enable a Denial-of-Service (DoS) attack. + + This specific threat is not considered to add significantly to the + risk of running an insecure DNS service. + + 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. + +6.5. Abuse of the Critical Flag + + A Certification Authority could make use of the critical flag to + trick customers into publishing records that prevent competing + Certification Authorities from issuing certificates even though the + customer intends to authorize multiple providers. + + 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. + +7. IANA Considerations + +7.1. Registration of the CAA Resource Record Type + + IANA has assigned Resource Record Type 257 for the CAA Resource + Record Type and added the line depicted below to the registry named + "Resource Record (RR) TYPEs" and QTYPEs as defined in BCP 42 + [RFC6195] and located at + http://www.iana.org/assignments/dns-parameters. + + RR Name Value and meaning Reference + ----------- --------------------------------------------- --------- + CAA 257 Certification Authority Restriction [RFC6844] + + + + + + + +Hallam-Baker & Stradling Standards Track [Page 14] + +RFC 6844 Certification Authority Authorization January 2013 + + +7.2. Certification Authority Restriction Properties + + IANA has created the "Certification Authority Restriction Properties" + registry with the following initial values: + + + Tag Meaning Reference + ----------- -------------------------------------- --------- + issue Authorization Entry by Domain [RFC6844] + issuewild Authorization Entry by Wildcard Domain [RFC6844] + iodef Report incident by IODEF report [RFC6844] + auth Reserved [HB2011] + path Reserved [HB2011] + policy Reserved [HB2011] + + + Although [HB2011] has expired, deployed clients implement the CAA + properties specified in the document and reuse of these property tags + for a different purpose could cause unexpected behavior. + + Addition of tag identifiers requires a public specification and + Expert Review as set out in [RFC6195], Section 3.1.1. + + The tag space is designed to be sufficiently large that exhausting + the possible tag space need not be a concern. The scope of Expert + Review SHOULD be limited to the question of whether the specification + provided is sufficiently clear to permit implementation and to avoid + unnecessary duplication of functionality. + +7.3. Certification Authority Restriction Flags + + IANA has created the "Certification Authority Restriction Flags" + registry with the following initial values: + + + Flag Meaning Reference + ----------- ---------------------------------- --------- + 0 Issuer Critical Flag [RFC6844] + 1-7 Reserved> [RFC6844] + + Assignment of new flags follows the RFC Required policy set out in + [RFC5226], Section 4.1. + + + + + + + + + +Hallam-Baker & Stradling Standards Track [Page 15] + +RFC 6844 Certification Authority Authorization January 2013 + + +8. Acknowledgements + + The authors would like to thank the following people who contributed + to the design and documentation of this work item: Chris Evans, + Stephen Farrell, Jeff Hodges, Paul Hoffman, Stephen Kent, Adam + Langley, Ben Laurie, James Manager, Chris Palmer, Scott Schmit, Sean + Turner, and Ben Wilson. + +9. References + +9.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident + Object Description Exchange Format", RFC 5070, + December 2007. + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, March 2008. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + + + +Hallam-Baker & Stradling Standards Track [Page 16] + +RFC 6844 Certification Authority Authorization January 2013 + + + [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, May 2008. + + [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA + Considerations", BCP 42, RFC 6195, March 2011. + + [RFC6546] Trammell, B., "Transport of Real-time Inter-network + Defense (RID) Messages over HTTP/TLS", RFC 6546, + April 2012. + + [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication + of Named Entities (DANE) Transport Layer Security (TLS) + Protocol: TLSA", RFC 6698, August 2012. + + [STD13] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [X.509] International Telecommunication Union, "ITU-T + Recommendation X.509 (11/2008): Information technology - + Open systems interconnection - The Directory: Public-key + and attribute certificate frameworks", ITU-T + Recommendation X.509, November 2008. + +9.2. Informative References + + [HB2011] Hallam-Baker, P., Stradling, R., and B. Laurie, "DNS + Certification Authority Authorization (CAA) Resource + Record", Work in Progress, May 2011. + + [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, + November 2003. + + + + + + + + + + + + + +Hallam-Baker & Stradling Standards Track [Page 17] + +RFC 6844 Certification Authority Authorization January 2013 + + +Authors' Addresses + + Phillip Hallam-Baker + Comodo Group, Inc. + + EMail: philliph@comodo.com + + + Rob Stradling + Comodo CA, Ltd. + + EMail: rob.stradling@comodo.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hallam-Baker & Stradling Standards Track [Page 18] + diff --git a/lib/dns/rdata.c b/lib/dns/rdata.c index c85b64d462f..a8cab548c81 100644 --- a/lib/dns/rdata.c +++ b/lib/dns/rdata.c @@ -114,7 +114,7 @@ typedef struct dns_rdata_textctx { } dns_rdata_textctx_t; static isc_result_t -txt_totext(isc_region_t *source, isc_buffer_t *target); +txt_totext(isc_region_t *source, isc_boolean_t quote, isc_buffer_t *target); static isc_result_t txt_fromtext(isc_textregion_t *source, isc_buffer_t *target); @@ -123,13 +123,16 @@ static isc_result_t txt_fromwire(isc_buffer_t *source, isc_buffer_t *target); static isc_result_t -multitxt_totext(isc_region_t *source, isc_buffer_t *target); +multitxt_totext(isc_region_t *source, isc_buffer_t *target, + isc_boolean_t lenbyte); static isc_result_t -multitxt_fromtext(isc_textregion_t *source, isc_buffer_t *target); +multitxt_fromtext(isc_textregion_t *source, isc_buffer_t *target, + isc_boolean_t lenbyte); static isc_result_t -multitxt_fromwire(isc_buffer_t *source, isc_buffer_t *target); +multitxt_fromwire(isc_buffer_t *source, isc_buffer_t *target, + isc_boolean_t lenbyte); static isc_boolean_t name_prefix(dns_name_t *name, dns_name_t *origin, dns_name_t *target); @@ -1123,7 +1126,7 @@ name_length(dns_name_t *name) { } static isc_result_t -txt_totext(isc_region_t *source, isc_buffer_t *target) { +txt_totext(isc_region_t *source, isc_boolean_t quote, isc_buffer_t *target) { unsigned int tl; unsigned int n; unsigned char *sp; @@ -1138,13 +1141,20 @@ txt_totext(isc_region_t *source, isc_buffer_t *target) { n = *sp++; REQUIRE(n + 1 <= source->length); + if (n == 0U) + REQUIRE(quote == ISC_TRUE); - if (tl < 1) - return (ISC_R_NOSPACE); - *tp++ = '"'; - tl--; + if (quote) { + if (tl < 1) + return (ISC_R_NOSPACE); + *tp++ = '"'; + tl--; + } while (n--) { - if (*sp < 0x20 || *sp >= 0x7f) { + /* + * \DDD space (0x20) if not quoting. + */ + if (*sp < (quote ? 0x20 : 0x21) || *sp >= 0x7f) { if (tl < 4) return (ISC_R_NOSPACE); *tp++ = 0x5c; @@ -1155,8 +1165,13 @@ txt_totext(isc_region_t *source, isc_buffer_t *target) { tl -= 4; continue; } - /* double quote, semi-colon, backslash */ - if (*sp == 0x22 || *sp == 0x3b || *sp == 0x5c) { + /* + * Escape double quote, semi-colon, backslash. + * If we are not enclosing the string in double + * quotes also escape at sign. + */ + if (*sp == 0x22 || *sp == 0x3b || *sp == 0x5c || + (!quote && *sp == 0x40)) { if (tl < 2) return (ISC_R_NOSPACE); *tp++ = '\\'; @@ -1167,10 +1182,12 @@ txt_totext(isc_region_t *source, isc_buffer_t *target) { *tp++ = *sp++; tl--; } - if (tl < 1) - return (ISC_R_NOSPACE); - *tp++ = '"'; - tl--; + if (quote) { + if (tl < 1) + return (ISC_R_NOSPACE); + *tp++ = '"'; + tl--; + } isc_buffer_add(target, (unsigned int)(tp - (char *)region.base)); isc_region_consume(source, *source->base + 1); return (ISC_R_SUCCESS); @@ -1266,8 +1283,17 @@ txt_fromwire(isc_buffer_t *source, isc_buffer_t *target) { return (ISC_R_SUCCESS); } +/* + * Conversion of TXT-like rdata fields without length limits. + * 'lenbyte' indicates whether to use length bytes in the encoding: + * The URI rdatatype uses length bytes for each 255-byte chunk of + * TXT, while the CAA rdatatype's length length is established by + * the overall rdata length. + */ static isc_result_t -multitxt_totext(isc_region_t *source, isc_buffer_t *target) { +multitxt_totext(isc_region_t *source, isc_buffer_t *target, + isc_boolean_t lenbyte) +{ unsigned int tl; unsigned int n0, n; unsigned char *sp; @@ -1284,9 +1310,13 @@ multitxt_totext(isc_region_t *source, isc_buffer_t *target) { *tp++ = '"'; tl--; do { - n0 = n = *sp++; - - REQUIRE(n0 + 1 <= source->length); + if (lenbyte) { + n0 = n = *sp++; + REQUIRE(n0 + 1 <= source->length); + } else { + n = source->length; + n0 = source->length - 1; + } while (n--) { if (*sp < 0x20 || *sp >= 0x7f) { @@ -1323,7 +1353,9 @@ multitxt_totext(isc_region_t *source, isc_buffer_t *target) { } static isc_result_t -multitxt_fromtext(isc_textregion_t *source, isc_buffer_t *target) { +multitxt_fromtext(isc_textregion_t *source, isc_buffer_t *target, + isc_boolean_t lenbyte) +{ isc_region_t tregion; isc_boolean_t escape; unsigned int n, nrem; @@ -1338,17 +1370,21 @@ multitxt_fromtext(isc_textregion_t *source, isc_buffer_t *target) { do { isc_buffer_availableregion(target, &tregion); - t0 = tregion.base; + t0 = t = tregion.base; nrem = tregion.length; if (nrem < 1) return (ISC_R_NOSPACE); - /* length byte */ - t = t0; - nrem--; - t++; - /* 255 byte character-string slice */ - if (nrem > 255) - nrem = 255; + + if (lenbyte) { + /* length byte */ + nrem--; + t++; + + /* 255 byte character-string slice */ + if (nrem > 255) + nrem = 255; + } + while (n != 0) { --n; c = (*s++) & 0xff; @@ -1382,14 +1418,20 @@ multitxt_fromtext(isc_textregion_t *source, isc_buffer_t *target) { } if (escape) return (DNS_R_SYNTAX); - *t0 = (unsigned char)(t - t0 - 1); - isc_buffer_add(target, *t0 + 1); + + if (lenbyte) { + *t0 = (unsigned char)(t - t0 - 1); + isc_buffer_add(target, *t0 + 1); + } else + isc_buffer_add(target, t - t0); } while (n != 0); return (ISC_R_SUCCESS); } static isc_result_t -multitxt_fromwire(isc_buffer_t *source, isc_buffer_t *target) { +multitxt_fromwire(isc_buffer_t *source, isc_buffer_t *target, + isc_boolean_t lenbyte) +{ unsigned int n; isc_region_t sregion; isc_region_t tregion; @@ -1401,9 +1443,12 @@ multitxt_fromwire(isc_buffer_t *source, isc_buffer_t *target) { do { if (n != 256U) return (DNS_R_SYNTAX); - n = *sregion.base + 1; - if (n > sregion.length) - return (ISC_R_UNEXPECTEDEND); + if (lenbyte) { + n = *sregion.base + 1; + if (n > sregion.length) + return (ISC_R_UNEXPECTEDEND); + } else + n = sregion.length; isc_buffer_availableregion(target, &tregion); if (n > tregion.length) diff --git a/lib/dns/rdata/generic/caa_257.c b/lib/dns/rdata/generic/caa_257.c new file mode 100644 index 00000000000..36f44f74774 --- /dev/null +++ b/lib/dns/rdata/generic/caa_257.c @@ -0,0 +1,376 @@ +/* + * Copyright (C) 2014 Internet Systems Consortium, Inc. ("ISC") + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +#ifndef GENERIC_CAA_257_C +#define GENERIC_CAA_257_C 1 + +#define RRTYPE_CAA_ATTRIBUTES (0) + +static unsigned char const alphanumeric[256] = { + /* 0x00-0x0f */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, + /* 0x10-0x1f */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, + /* 0x20-0x2f */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, + /* 0x30-0x3f */ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, + /* 0x40-0x4f */ 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, + /* 0x50-0x5f */ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, + /* 0x60-0x6f */ 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, + /* 0x70-0x7f */ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, + /* 0x80-0x8f */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, + /* 0x90-0x9f */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, + /* 0xa0-0xaf */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, + /* 0xb0-0xbf */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, + /* 0xc0-0xcf */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, + /* 0xd0-0xdf */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, + /* 0xe0-0xef */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, + /* 0xf0-0xff */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, +}; + +static inline isc_result_t +fromtext_caa(ARGS_FROMTEXT) { + isc_token_t token; + isc_textregion_t tr; + isc_uint8_t flags; + unsigned int i; + + REQUIRE(type == 257); + + UNUSED(type); + UNUSED(rdclass); + UNUSED(origin); + UNUSED(options); + UNUSED(callbacks); + + /* Flags. */ + RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number, + ISC_FALSE)); + if (token.value.as_ulong > 255U) + RETTOK(ISC_R_RANGE); + flags = token.value.as_ulong; + RETERR(uint8_tobuffer(flags, target)); + + /* + * Tag + */ + RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string, + ISC_FALSE)); + tr = token.value.as_textregion; + for (i = 0; i < tr.length; i++) + if (!alphanumeric[(unsigned int) tr.base[i]]) + RETTOK(DNS_R_SYNTAX); + RETERR(uint8_tobuffer(tr.length, target)); + RETERR(mem_tobuffer(target, tr.base, tr.length)); + + /* + * Value + */ + RETERR(isc_lex_getmastertoken(lexer, &token, + isc_tokentype_qstring, ISC_FALSE)); + if (token.type != isc_tokentype_qstring && + token.type != isc_tokentype_string) + RETERR(DNS_R_SYNTAX); + RETERR(multitxt_fromtext(&token.value.as_textregion, target, + ISC_FALSE)); + return (ISC_R_SUCCESS); +} + +static inline isc_result_t +totext_caa(ARGS_TOTEXT) { + isc_region_t region; + isc_uint8_t flags; + char buf[256]; + + UNUSED(tctx); + + REQUIRE(rdata->type == 257); + REQUIRE(rdata->length >= 3U); + REQUIRE(rdata->data != NULL); + + dns_rdata_toregion(rdata, ®ion); + + /* + * Flags + */ + flags = uint8_consume_fromregion(®ion); + sprintf(buf, "%u ", flags); + RETERR(str_totext(buf, target)); + + /* + * Tag + */ + RETERR(txt_totext(®ion, ISC_FALSE, target)); + RETERR(str_totext(" ", target)); + + /* + * Value + */ + RETERR(multitxt_totext(®ion, target, ISC_FALSE)); + return (ISC_R_SUCCESS); +} + +static inline isc_result_t +fromwire_caa(ARGS_FROMWIRE) { + isc_region_t sr; + unsigned int len, i; + + REQUIRE(type == 257); + + UNUSED(type); + UNUSED(rdclass); + UNUSED(dctx); + UNUSED(options); + + /* + * Flags + */ + isc_buffer_activeregion(source, &sr); + if (sr.length < 2) + return (ISC_R_UNEXPECTEDEND); + + /* + * Flags, tag length + */ + RETERR(mem_tobuffer(target, sr.base, 2)); + len = sr.base[1]; + isc_region_consume(&sr, 2); + isc_buffer_forward(source, 2); + + /* + * Zero length tag fields are illegal. + */ + if (sr.length < len || len == 0) + RETERR(DNS_R_FORMERR); + + /* Tag */ + for (i = 0; i < sr.length; i++) + if (!alphanumeric[sr.base[i]]) + RETERR(DNS_R_FORMERR); + RETERR(mem_tobuffer(target, sr.base, len)); + isc_region_consume(&sr, len); + isc_buffer_forward(source, len); + + /* + * Value + */ + RETERR(multitxt_fromwire(source, target, ISC_FALSE)); + + return (ISC_R_SUCCESS); +} + +static inline isc_result_t +towire_caa(ARGS_TOWIRE) { + isc_region_t region; + + REQUIRE(rdata->type == 257); + REQUIRE(rdata->length >= 3U); + REQUIRE(rdata->data != NULL); + + UNUSED(cctx); + + dns_rdata_toregion(rdata, ®ion); + return (mem_tobuffer(target, region.base, region.length)); +} + +static inline int +compare_caa(ARGS_COMPARE) { + isc_region_t r1, r2; + + REQUIRE(rdata1->type == rdata2->type); + REQUIRE(rdata1->rdclass == rdata2->rdclass); + REQUIRE(rdata1->type == 257); + REQUIRE(rdata1->length >= 3U); + REQUIRE(rdata2->length >= 3U); + REQUIRE(rdata1->data != NULL); + REQUIRE(rdata2->data != NULL); + + dns_rdata_toregion(rdata1, &r1); + dns_rdata_toregion(rdata2, &r2); + return (isc_region_compare(&r1, &r2)); +} + +static inline isc_result_t +fromstruct_caa(ARGS_FROMSTRUCT) { + dns_rdata_caa_t *caa = source; + isc_region_t region; + unsigned int i; + + REQUIRE(type == 257); + REQUIRE(source != NULL); + REQUIRE(caa->common.rdtype == type); + REQUIRE(caa->common.rdclass == rdclass); + REQUIRE(caa->tag != NULL && caa->tag_len != 0); + REQUIRE(caa->value != NULL); + + UNUSED(type); + UNUSED(rdclass); + + /* + * Flags + */ + RETERR(uint8_tobuffer(caa->flags, target)); + + /* + * Tag length + */ + RETERR(uint8_tobuffer(caa->tag_len, target)); + + /* + * Tag + */ + region.base = caa->tag; + region.length = caa->tag_len; + for (i = 0; i < region.length; i++) + if (!alphanumeric[region.base[i]]) + RETERR(DNS_R_SYNTAX); + RETERR(isc_buffer_copyregion(target, ®ion)); + + /* + * Value + */ + region.base = caa->value; + region.length = caa->value_len; + return (isc_buffer_copyregion(target, ®ion)); +} + +static inline isc_result_t +tostruct_caa(ARGS_TOSTRUCT) { + dns_rdata_caa_t *caa = target; + isc_region_t sr; + + REQUIRE(rdata->type == 257); + REQUIRE(target != NULL); + REQUIRE(rdata->length >= 3U); + REQUIRE(rdata->data != NULL); + + caa->common.rdclass = rdata->rdclass; + caa->common.rdtype = rdata->type; + ISC_LINK_INIT(&caa->common, link); + + dns_rdata_toregion(rdata, &sr); + + /* + * Flags + */ + if (sr.length < 1) + return (ISC_R_UNEXPECTEDEND); + caa->flags = uint8_fromregion(&sr); + isc_region_consume(&sr, 1); + + /* + * Tag length + */ + if (sr.length < 1) + return (ISC_R_UNEXPECTEDEND); + caa->tag_len = uint8_fromregion(&sr); + isc_region_consume(&sr, 1); + + /* + * Tag + */ + if (sr.length < caa->tag_len) + return (ISC_R_UNEXPECTEDEND); + caa->tag = mem_maybedup(mctx, sr.base, caa->tag_len); + if (caa->tag == NULL) + return (ISC_R_NOMEMORY); + isc_region_consume(&sr, caa->tag_len); + + /* + * Value + */ + caa->value_len = sr.length; + caa->value = mem_maybedup(mctx, sr.base, sr.length); + if (caa->value == NULL) + return (ISC_R_NOMEMORY); + + caa->mctx = mctx; + return (ISC_R_SUCCESS); +} + +static inline void +freestruct_caa(ARGS_FREESTRUCT) { + dns_rdata_caa_t *caa = (dns_rdata_caa_t *) source; + + REQUIRE(source != NULL); + REQUIRE(caa->common.rdtype == 257); + + if (caa->mctx == NULL) + return; + + if (caa->tag != NULL) + isc_mem_free(caa->mctx, caa->tag); + if (caa->value != NULL) + isc_mem_free(caa->mctx, caa->value); + caa->mctx = NULL; +} + +static inline isc_result_t +additionaldata_caa(ARGS_ADDLDATA) { + REQUIRE(rdata->type == 257); + REQUIRE(rdata->data != NULL); + REQUIRE(rdata->length >= 3U); + + UNUSED(rdata); + UNUSED(add); + UNUSED(arg); + + return (ISC_R_SUCCESS); +} + +static inline isc_result_t +digest_caa(ARGS_DIGEST) { + isc_region_t r; + + REQUIRE(rdata->type == 257); + REQUIRE(rdata->data != NULL); + REQUIRE(rdata->length >= 3U); + + dns_rdata_toregion(rdata, &r); + + return ((digest)(arg, &r)); +} + +static inline isc_boolean_t +checkowner_caa(ARGS_CHECKOWNER) { + + REQUIRE(type == 257); + + UNUSED(name); + UNUSED(type); + UNUSED(rdclass); + UNUSED(wildcard); + + return (ISC_TRUE); +} + +static inline isc_boolean_t +checknames_caa(ARGS_CHECKNAMES) { + + REQUIRE(rdata->type == 257); + REQUIRE(rdata->data != NULL); + REQUIRE(rdata->length >= 3U); + + UNUSED(rdata); + UNUSED(owner); + UNUSED(bad); + + return (ISC_TRUE); +} + +static inline int +casecompare_caa(ARGS_COMPARE) { + return (compare_caa(rdata1, rdata2)); +} + +#endif /* GENERIC_CAA_257_C */ diff --git a/lib/dns/rdata/generic/caa_257.h b/lib/dns/rdata/generic/caa_257.h new file mode 100644 index 00000000000..79866a5cbfc --- /dev/null +++ b/lib/dns/rdata/generic/caa_257.h @@ -0,0 +1,32 @@ +/* + * Copyright (C) 2014 Internet Systems Consortium, Inc. ("ISC") + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + * PERFORMANCE OF THIS SOFTWARE. + */ + +#ifndef GENERIC_CAA_257_H +#define GENERIC_CAA_257_H 1 + +/* $Id$ */ + +typedef struct dns_rdata_caa { + dns_rdatacommon_t common; + isc_mem_t * mctx; + isc_uint8_t flags; + unsigned char * tag; + isc_uint8_t tag_len; + unsigned char *value; + isc_uint8_t value_len; +} dns_rdata_caa_t; + +#endif /* GENERIC_CAA_257_H */ diff --git a/lib/dns/rdata/generic/gpos_27.c b/lib/dns/rdata/generic/gpos_27.c index ce71822b823..5a9021660bd 100644 --- a/lib/dns/rdata/generic/gpos_27.c +++ b/lib/dns/rdata/generic/gpos_27.c @@ -61,7 +61,7 @@ totext_gpos(ARGS_TOTEXT) { dns_rdata_toregion(rdata, ®ion); for (i = 0; i < 3; i++) { - RETERR(txt_totext(®ion, target)); + RETERR(txt_totext(®ion, ISC_TRUE, target)); if (i != 2) RETERR(str_totext(" ", target)); } diff --git a/lib/dns/rdata/generic/hinfo_13.c b/lib/dns/rdata/generic/hinfo_13.c index 10b4fec79de..92038b7875d 100644 --- a/lib/dns/rdata/generic/hinfo_13.c +++ b/lib/dns/rdata/generic/hinfo_13.c @@ -58,9 +58,9 @@ totext_hinfo(ARGS_TOTEXT) { REQUIRE(rdata->length != 0); dns_rdata_toregion(rdata, ®ion); - RETERR(txt_totext(®ion, target)); + RETERR(txt_totext(®ion, ISC_TRUE, target)); RETERR(str_totext(" ", target)); - return (txt_totext(®ion, target)); + return (txt_totext(®ion, ISC_TRUE, target)); } static inline isc_result_t diff --git a/lib/dns/rdata/generic/isdn_20.c b/lib/dns/rdata/generic/isdn_20.c index 0bf2146013e..388cae17c9a 100644 --- a/lib/dns/rdata/generic/isdn_20.c +++ b/lib/dns/rdata/generic/isdn_20.c @@ -65,11 +65,11 @@ totext_isdn(ARGS_TOTEXT) { UNUSED(tctx); dns_rdata_toregion(rdata, ®ion); - RETERR(txt_totext(®ion, target)); + RETERR(txt_totext(®ion, ISC_TRUE, target)); if (region.length == 0) return (ISC_R_SUCCESS); RETERR(str_totext(" ", target)); - return (txt_totext(®ion, target)); + return (txt_totext(®ion, ISC_TRUE, target)); } static inline isc_result_t diff --git a/lib/dns/rdata/generic/spf_99.c b/lib/dns/rdata/generic/spf_99.c index c7cdfc9fbba..10e86b888f3 100644 --- a/lib/dns/rdata/generic/spf_99.c +++ b/lib/dns/rdata/generic/spf_99.c @@ -64,7 +64,7 @@ totext_spf(ARGS_TOTEXT) { dns_rdata_toregion(rdata, ®ion); while (region.length > 0) { - RETERR(txt_totext(®ion, target)); + RETERR(txt_totext(®ion, ISC_TRUE, target)); if (region.length > 0) RETERR(str_totext(" ", target)); } diff --git a/lib/dns/rdata/generic/txt_16.c b/lib/dns/rdata/generic/txt_16.c index 76109251a76..41e27027921 100644 --- a/lib/dns/rdata/generic/txt_16.c +++ b/lib/dns/rdata/generic/txt_16.c @@ -71,7 +71,7 @@ totext_txt(ARGS_TOTEXT) { dns_rdata_toregion(rdata, ®ion); while (region.length > 0) { - RETERR(txt_totext(®ion, target)); + RETERR(txt_totext(®ion, ISC_TRUE, target)); if (region.length > 0) RETERR(str_totext(" ", target)); } diff --git a/lib/dns/rdata/generic/uri_256.c b/lib/dns/rdata/generic/uri_256.c index aa5b1946dc8..7af073a3c25 100644 --- a/lib/dns/rdata/generic/uri_256.c +++ b/lib/dns/rdata/generic/uri_256.c @@ -58,7 +58,8 @@ fromtext_uri(ARGS_FROMTEXT) { isc_tokentype_qstring, ISC_FALSE)); if (token.type != isc_tokentype_qstring) RETTOK(DNS_R_SYNTAX); - RETTOK(multitxt_fromtext(&token.value.as_textregion, target)); + RETTOK(multitxt_fromtext(&token.value.as_textregion, target, + ISC_TRUE)); return (ISC_R_SUCCESS); } @@ -94,7 +95,7 @@ totext_uri(ARGS_TOTEXT) { /* * Target URI */ - RETERR(multitxt_totext(®ion, target)); + RETERR(multitxt_totext(®ion, target, ISC_TRUE)); return (ISC_R_SUCCESS); } @@ -121,7 +122,7 @@ fromwire_uri(ARGS_FROMWIRE) { /* * Target URI */ - RETERR(multitxt_fromwire(source, target)); + RETERR(multitxt_fromwire(source, target, ISC_TRUE)); return (ISC_R_SUCCESS); } diff --git a/lib/dns/rdata/generic/x25_19.c b/lib/dns/rdata/generic/x25_19.c index 6867fecd86f..f9dfb8acbea 100644 --- a/lib/dns/rdata/generic/x25_19.c +++ b/lib/dns/rdata/generic/x25_19.c @@ -60,7 +60,7 @@ totext_x25(ARGS_TOTEXT) { REQUIRE(rdata->length != 0); dns_rdata_toregion(rdata, ®ion); - return (txt_totext(®ion, target)); + return (txt_totext(®ion, ISC_TRUE, target)); } static inline isc_result_t diff --git a/lib/dns/rdata/in_1/naptr_35.c b/lib/dns/rdata/in_1/naptr_35.c index e5df80b0c7b..b539351c937 100644 --- a/lib/dns/rdata/in_1/naptr_35.c +++ b/lib/dns/rdata/in_1/naptr_35.c @@ -226,19 +226,19 @@ totext_in_naptr(ARGS_TOTEXT) { /* * Flags. */ - RETERR(txt_totext(®ion, target)); + RETERR(txt_totext(®ion, ISC_TRUE, target)); RETERR(str_totext(" ", target)); /* * Service. */ - RETERR(txt_totext(®ion, target)); + RETERR(txt_totext(®ion, ISC_TRUE, target)); RETERR(str_totext(" ", target)); /* * Regexp. */ - RETERR(txt_totext(®ion, target)); + RETERR(txt_totext(®ion, ISC_TRUE, target)); RETERR(str_totext(" ", target)); /*