From 620b1c9d90d0a59a0d892fef089ce4f5f6f61742 Mon Sep 17 00:00:00 2001 From: Tomas Hozza Date: Fri, 1 Apr 2016 15:20:27 +0200 Subject: [PATCH] Added support for CAA records Signed-off-by: Tomas Hozza --- bin/tests/rdata_test.c | 17 +- doc/rfc/rfc6844.txt | 1011 ++++++++++++++++++++++++++++++++++++++ lib/dns/rdata.c | 95 ++-- lib/dns/rdata/generic/caa_257.c | 370 ++++++++++++++ lib/dns/rdata/generic/caa_257.h | 32 ++ lib/dns/rdata/generic/gpos_27.c | 2 +- lib/dns/rdata/generic/hinfo_13.c | 4 +- lib/dns/rdata/generic/isdn_20.c | 4 +- lib/dns/rdata/generic/naptr_35.c | 6 +- lib/dns/rdata/generic/spf_99.c | 2 +- lib/dns/rdata/generic/txt_16.c | 2 +- lib/dns/rdata/generic/uri_256.c | 23 +- lib/dns/rdata/generic/x25_19.c | 2 +- 13 files changed, 1478 insertions(+), 92 deletions(-) create mode 100644 doc/rfc/rfc6844.txt create mode 100644 lib/dns/rdata/generic/caa_257.c create mode 100644 lib/dns/rdata/generic/caa_257.h diff --git a/bin/tests/rdata_test.c b/bin/tests/rdata_test.c index 51cc406..0f25364 100644 --- a/bin/tests/rdata_test.c +++ b/bin/tests/rdata_test.c @@ -15,8 +15,6 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: rdata_test.c,v 1.52 2011/08/28 09:10:41 marka Exp $ */ - #include #include @@ -284,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); @@ -551,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); @@ -848,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/doc/rfc/rfc6844.txt b/doc/rfc/rfc6844.txt new file mode 100644 index 0000000..d923649 --- /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 a83dab4..9bf83a4 100644 --- a/lib/dns/rdata.c +++ b/lib/dns/rdata.c @@ -116,7 +116,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); @@ -130,9 +130,6 @@ multitxt_totext(isc_region_t *source, isc_buffer_t *target); static isc_result_t multitxt_fromtext(isc_textregion_t *source, isc_buffer_t *target); -static isc_result_t -multitxt_fromwire(isc_buffer_t *source, isc_buffer_t *target); - static isc_boolean_t name_prefix(dns_name_t *name, dns_name_t *origin, dns_name_t *target); @@ -1131,7 +1128,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; @@ -1146,13 +1143,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; @@ -1163,8 +1167,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++ = '\\'; @@ -1175,10 +1184,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, tp - (char *)region.base); isc_region_consume(source, *source->base + 1); return (ISC_R_SUCCESS); @@ -1274,6 +1285,9 @@ txt_fromwire(isc_buffer_t *source, isc_buffer_t *target) { return (ISC_R_SUCCESS); } +/* + * Conversion of TXT-like rdata fields without length limits. + */ static isc_result_t multitxt_totext(isc_region_t *source, isc_buffer_t *target) { unsigned int tl; @@ -1292,9 +1306,8 @@ multitxt_totext(isc_region_t *source, isc_buffer_t *target) { *tp++ = '"'; tl--; do { - n0 = n = *sp++; - - REQUIRE(n0 + 1 <= source->length); + n = source->length; + n0 = source->length - 1; while (n--) { if (*sp < 0x20 || *sp >= 0x7f) { @@ -1346,17 +1359,11 @@ 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; + while (n != 0) { --n; c = (*s++) & 0xff; @@ -1390,39 +1397,9 @@ multitxt_fromtext(isc_textregion_t *source, isc_buffer_t *target) { } if (escape) return (DNS_R_SYNTAX); - *t0 = t - t0 - 1; - isc_buffer_add(target, *t0 + 1); - } while (n != 0); - return (ISC_R_SUCCESS); -} - -static isc_result_t -multitxt_fromwire(isc_buffer_t *source, isc_buffer_t *target) { - unsigned int n; - isc_region_t sregion; - isc_region_t tregion; - - isc_buffer_activeregion(source, &sregion); - if (sregion.length == 0) - return(ISC_R_UNEXPECTEDEND); - n = 256U; - do { - if (n != 256U) - return (DNS_R_SYNTAX); - n = *sregion.base + 1; - if (n > sregion.length) - return (ISC_R_UNEXPECTEDEND); - isc_buffer_availableregion(target, &tregion); - if (n > tregion.length) - return (ISC_R_NOSPACE); - - if (tregion.base != sregion.base) - memcpy(tregion.base, sregion.base, n); - isc_buffer_forward(source, n); - isc_buffer_add(target, n); - isc_buffer_activeregion(source, &sregion); - } while (sregion.length != 0); + isc_buffer_add(target, t - t0); + } while (n != 0); return (ISC_R_SUCCESS); } diff --git a/lib/dns/rdata/generic/caa_257.c b/lib/dns/rdata/generic/caa_257.c new file mode 100644 index 0000000..671f332 --- /dev/null +++ b/lib/dns/rdata/generic/caa_257.c @@ -0,0 +1,370 @@ +/* + * 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 & 255U; + 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 char) 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)); + 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)); + 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); + + /* Check the Tag's value */ + for (i = 0; i < len; i++) + if (!alphanumeric[sr.base[i]]) + RETERR(DNS_R_FORMERR); + /* + * Tag + Value + */ + isc_buffer_forward(source, sr.length); + return (mem_tobuffer(target, sr.base, sr.length)); +} + +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 0000000..79866a5 --- /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 ce71822..5a90216 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 10b4fec..92038b7 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 5aac73f..059c247 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/naptr_35.c b/lib/dns/rdata/generic/naptr_35.c index 83439a5..be7d403 100644 --- a/lib/dns/rdata/generic/naptr_35.c +++ b/lib/dns/rdata/generic/naptr_35.c @@ -224,19 +224,19 @@ totext_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)); /* diff --git a/lib/dns/rdata/generic/spf_99.c b/lib/dns/rdata/generic/spf_99.c index 492e315..85594fd 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 e1bce6a..e0e8ea5 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 799eb69..62bdd25 100644 --- a/lib/dns/rdata/generic/uri_256.c +++ b/lib/dns/rdata/generic/uri_256.c @@ -115,15 +115,12 @@ fromwire_uri(ARGS_FROMWIRE) { isc_buffer_activeregion(source, ®ion); if (region.length < 4) return (ISC_R_UNEXPECTEDEND); - RETERR(mem_tobuffer(target, region.base, 4)); - isc_buffer_forward(source, 4); /* - * Target URI + * Priority, weight and target URI */ - RETERR(multitxt_fromwire(source, target)); - - return (ISC_R_SUCCESS); + isc_buffer_forward(source, region.length); + return (mem_tobuffer(target, region.base, region.length)); } static inline isc_result_t @@ -178,8 +175,6 @@ compare_uri(ARGS_COMPARE) { static inline isc_result_t fromstruct_uri(ARGS_FROMSTRUCT) { dns_rdata_uri_t *uri = source; - isc_region_t region; - isc_uint8_t len; REQUIRE(type == 256); REQUIRE(source != NULL); @@ -203,18 +198,6 @@ fromstruct_uri(ARGS_FROMSTRUCT) { /* * Target URI */ - len = 255U; - region.base = uri->target; - region.length = uri->tgt_len; - while (region.length > 0) { - REQUIRE(len == 255U); - len = uint8_fromregion(®ion); - isc_region_consume(®ion, 1); - if (region.length < len) - return (ISC_R_UNEXPECTEDEND); - isc_region_consume(®ion, len); - } - return (mem_tobuffer(target, uri->target, uri->tgt_len)); } diff --git a/lib/dns/rdata/generic/x25_19.c b/lib/dns/rdata/generic/x25_19.c index 6867fec..f9dfb8a 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 -- 2.4.3