methodology behind using cname to verify domain ownership for use with a host

Question

Webhosting services, such as Squarespace, enable customers to connect their third-party-hosted domains to their site without transferring ownership or switching Nameservers. This is achieved by adding specific records to the dns configuration of the domain itself. Here is what Squarespace requires:

HOST            RECORD    VALUE
9aa5s43zpykpn   cname     verify.squarespace.com
www             cname     ext-cust.squarespace.com
@               a         192.49.23.144
@               a         192.185.159.145
@               a         192.185.159.144
@               a         192.49.23.145

Presumably, when the domain is visited, the A record connects to the appropriate server, which, using the verify.squarespace.com CNAME record, discerns and directs the request to the proper content based on the unique identifier stashed in the host (9aa5s43zpykpn).

Is this actually how that works and the reason for doing it?

Does verify.squarespace.com get queried as part of the dns resolve? (before squarespace's servers get the request via the A record)

Are there any other purposes at work here for this type of setup?

Why the need for the www record?

Most importantly, what technique would Squarespace be using to actually view the CNAME record for verification? ie, is there an appropriate DNS record for this on their end, or would the server have to identify the incoming host (domain), match and find the associated hash (9aa5s43zpykpn) in a database, and then use a tool like dig to verify the cname record exists?

Insight appreciated.

Answer 1

Yes proving ownership of the domain can be made by asking to change the content of the zone, be it by a CNAME record or a TXT record. CAs typically asks for things like that before validating the request to generate a certificate (this is called "dns validation").

A single change (with some "random" token) in the zone should be enough to prove ownership. What each provider does is then its own business policies. But from the content you quote, the changes asked for are both to verify ownership (first record) and then (www and @ records) just to really install the site on their infrastructure. So basically they are asking their clients to do both steps at once so that they have to change the content of the zone only once.

The CNAME can be viewed, like any DNS record, by just querying for it. If you had given the real name, people could have shown it to you, but as a generic answer: dig 9aa5s43zpykpn.example.com CNAME will show you if there is a CNAME record or not for that name (and if there is it will show the target).

The specific value could be random, or a hash between known parts (the domain name being verified) and some secret local string.

This is not standardized, but many providers do DNS validations like that. To see the closest thing to a standard you can use documents from the CA world:

• https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.6.pdf section "3.2.2.4.7 DNS Change": "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"
• the ACME protocol at https://www.rfc-editor.org/rfc/rfc8555 section 8.4 DNS Challenge: "When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a TXT resource record containing a designated value for a specific validation domain name."

PS: contrary to the first sentence, there is a slight gap between the fact of "owning the domain" and "being able to change content of the zone". The DNS provider for the domain can change the content of zone, so that is not fully aligned with the "owner of the domain", as displayed in whois of RDAP for example. For current operational needs, everyone just agrees that we can forget about this gap (which could be of course used for tailored attacks).