[dns-operations] CNAMEs pointing off into the weeds - inconsistent behavior from different recursive codebases

Daniel McCarney cpu at letsencrypt.org
Wed Oct 9 14:32:52 UTC 2019


[posting in a personal capacity]

> Let's Encrypt is in general very happy to follow indirections

I believe the CNAME processing being discussed in this thread is
standard practice for CAs beyond Let's Encrypt / ACME / RFC 8555 that
perform domain validation through the "DNS change" mechanism outlined
by the CA/browser forum baseline requirements. That section of the BRs
(3.2.2.4.7 of v1.6.6) explicitly (though with limited detail) mentions
CNAMEs:

> Confirming the Applicant's control over the FQDN by confirming the presence of
> a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record
> for either 1) an Authorization Domain Name; or 2) an Authorization Domain Name
> that is prefixed with a label that begins with an underscore character.

As a concrete example Amazon's Certificate Manager product handles DNS
validation through CNAME in a similar fashion. See "Why does ACM use
CNAME records for DNS validation instead of TXT records?" in the FAQ:
https://aws.amazon.com/certificate-manager/faqs/

On Wed, Oct 9, 2019 at 8:00 AM Tony Finch <dot at dotat.at> wrote:
>
> Rob Seastrom <rs-lists at seastrom.com> wrote:
> >
> > I might add that I was slightly surprised that this works - it seems
> > unaddressed in the ACME spec but kind of feels like a potential attack
> > surface tparticularly since it works even to a non-child,
> > non-same-origin (pedantically, not quite "out of baliwick" but YKWIM)
> > zone.
>
> Viktor has answered your question, but wrt this point, Let's Encrypt is in
> general very happy to follow indirections, whether CNAMEs for dns-01 or
> redirects for http-01. RFC 8555 mentions HTTP redirects but not CNAMEs.
> Both kinds of aliasing allow for lots of fun games.
>
> Tony.
> --
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
> Trafalgar: Northerly or northeasterly 4 to 6, increasing 7 at times in east.
> Rough or very rough. Fair. Good.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



More information about the dns-operations mailing list