Blob Blame History Raw
From 620b1c9d90d0a59a0d892fef089ce4f5f6f61742 Mon Sep 17 00:00:00 2001
From: Tomas Hozza <thozza@redhat.com>
Date: Fri, 1 Apr 2016 15:20:27 +0200
Subject: [PATCH] Added support for CAA records

Signed-off-by: Tomas Hozza <thozza@redhat.com>
---
 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 <config.h>
 
 #include <stdlib.h>
@@ -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 <Issuer Domain Name> [; <name>=<value> ]* :  The issue property
+      entry authorizes the holder of the domain name <Issuer 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 <Issuer Domain Name> [; <name>=<value> ]* :  The issuewild
+      property entry authorizes the holder of the domain name <Issuer
+      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 <URL> :  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 <flags> <tag> <value>
+
+   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 <character-string> 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, &region);
+
+	/*
+	 * Flags
+	 */
+	flags = uint8_consume_fromregion(&region);
+	sprintf(buf, "%u ", flags);
+	RETERR(str_totext(buf, target));
+
+	/*
+	 * Tag
+	 */
+	RETERR(txt_totext(&region, ISC_FALSE, target));
+	RETERR(str_totext(" ", target));
+
+	/*
+	 * Value
+	 */
+	RETERR(multitxt_totext(&region, 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, &region);
+	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, &region));
+
+	/*
+	 * Value
+	 */
+	region.base = caa->value;
+	region.length = caa->value_len;
+	return (isc_buffer_copyregion(target, &region));
+}
+
+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, &region);
 
 	for (i = 0; i < 3; i++) {
-		RETERR(txt_totext(&region, target));
+		RETERR(txt_totext(&region, 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, &region);
-	RETERR(txt_totext(&region, target));
+	RETERR(txt_totext(&region, ISC_TRUE, target));
 	RETERR(str_totext(" ", target));
-	return (txt_totext(&region, target));
+	return (txt_totext(&region, 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, &region);
-	RETERR(txt_totext(&region, target));
+	RETERR(txt_totext(&region, ISC_TRUE, target));
 	if (region.length == 0)
 		return (ISC_R_SUCCESS);
 	RETERR(str_totext(" ", target));
-	return (txt_totext(&region, target));
+	return (txt_totext(&region, 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(&region, target));
+	RETERR(txt_totext(&region, ISC_TRUE, target));
 	RETERR(str_totext(" ", target));
 
 	/*
 	 * Service.
 	 */
-	RETERR(txt_totext(&region, target));
+	RETERR(txt_totext(&region, ISC_TRUE, target));
 	RETERR(str_totext(" ", target));
 
 	/*
 	 * Regexp.
 	 */
-	RETERR(txt_totext(&region, target));
+	RETERR(txt_totext(&region, 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, &region);
 
 	while (region.length > 0) {
-		RETERR(txt_totext(&region, target));
+		RETERR(txt_totext(&region, 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, &region);
 
 	while (region.length > 0) {
-		RETERR(txt_totext(&region, target));
+		RETERR(txt_totext(&region, 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, &region);
 	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(&region);
-		isc_region_consume(&region, 1);
-		if (region.length < len)
-			return (ISC_R_UNEXPECTEDEND);
-		isc_region_consume(&region, 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, &region);
-	return (txt_totext(&region, target));
+	return (txt_totext(&region, ISC_TRUE, target));
 }
 
 static inline isc_result_t
-- 
2.4.3