On Thu, Apr 20, 2023 at 11:46 AM Paul Wouters <p...@nohats.ca> wrote:
> > > ### CNAME chaining > > > > In §3.2 we see the text "Another issue with CNAME records is that they > must > > not point to another CNAME" provided, with no reference. But CNAME > chains are > > in heavy use on the internet in practice with no ill effect (case in > point: my > > employer's CDN business), so I'd recommend removing the discussion of > CNAME > > chaining, or supplying a reference and discussion around them that is > closer > > to the deployment reality. > Yes, my employer too! :) > Looking up the exact reference, I do find in > https://www.rfc-editor.org/rfc/rfc1034.html#section-3.6.2 > > CNAME chains should be followed > > So perhaps our advise here was a bit too strong. We already had an open > item at looking to change the language there to make it less restrictive > on CNAMEs so we will take item this into that discussion. Thanks Paul (and Ben ..), We've now addressed this in the current github draft by just removing the discussion on CNAME chains, as I don't think it is crucial to the potential pitfalls with CNAMEs used for domain control validation. We've also relaxed the recommendation against using CNAME based methods. The original rationale for that was because they can't coexist with any other records at the same name. However, there are many providers that do CNAME based validation by placing the validation record at a random subdomain of the name being validated, rather than at the actual name itself, which avoids the collision problem entirely. See an example in the appendix for Amazon ACM, although quite a number of others can be cited (Docusign, Sectigo, etc). We also account for the delegated validation model which employs a CNAME pointing to a TXT record hosted at a 3rd party. We still recommend the TXT based method, as it uses an application specific underscore prefix label (which both avoids collisions with CNAMEs and makes it easier to identify the service associated with the validation record). Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
