Re: [lamps] Next steps on CAA

[Patrick Donahue <[e-mail]>]

I've provided a real-world counter example below that illustrates why
climbing the CNAME tree will cause significant real-world breakages for
companies like Cloudflare who provide free SSL certificate issuance and
termination.

While we believe that erratum 5065 fixes this, we are very much in support
of seeing straightforward RFC confirmed that will make it clear to CAs that
CNAME tree climbing is no longer required.

*Example:*
Cloudflare customers have, collectively, over 400,000 CNAMEs to
ghs.google.com. This CNAME value is what Google instructs[1] their Blogger
customers to use to serve their blog on their own custom domain.

Were a CA have to check for a CAA record at google.com (in addition to
ghs.google.com) they'd see this:

$ dig CAA +short ghs.google.com
$ dig CAA +short google.com
*0 issue "pki.goog"*

1 - https://support.google.com/blogger/answer/58317?hl=en

In article <[e-mail]>; you write:
> >> 1) The CNAME is there to make the names equivalent so the CAA record at
> example.net <http://example.net/> should aply
> >>
> >> 2) The CNAME is only there to make the CDN work and the CAA record at
> example.net <http://example.net/> should be ignored.
> >
> >If one looks in the DNS for www.ietf.org, one will see:
> >
> > www.ietf.org. 607 IN CNAME www.ietf.org.cdn.cloudflare.net.
> >
> >I'm not sure how you would expect to distinguish the two cases.
> If your CDN tries to lock you in with a rogue CAA record, that's a
> business issue, not a technical one.
> R's,
> John



-- 
Patrick R. Donahue
[e-mail]

PGP Fingerprint: 2E8D 5A38 682E EC00 C0F3  E7F2 D9BE 68D2 ABF3 6B24