The answer these days is the Ten Blessed Methods
Public CAs for the Web PKI (the PKI of the Internet's SSL/TLS services) are trusted by various entities, but by far the most important are the Web Browser vendors, who in practice are also more or less the Operating System vendors. These are Microsoft, Apple, Mozilla (who stand in for all the Free Unix systems), and Google. Trust by these organizations means certificates from the CA are trusted by web browsers ordinary people use, which is in effect necessary to get much done.
These trust stores, and almost all public CAs, take part in a standing meeting between the two groups call the CA/Browser Forum or CA/B for short. The meeting agrees requirements documents, which set down what CAs must do in order to remain trusted by any of the browser members. The most important these days are the Baseline Requirements or BRs.
Historically the BRs said that CAs could use "any method" to validate that the applicant controls the name requested if they were confident that it was "equivalent" to a list of methods commonly known to be used. It had become apparent that CAs weren't very good at actually judging if their methods were effective, and so this requirement was unsatisfactory.
Last year a sub-committee of the CA/B agreed a revision to the BRs called "Ballot 169" which listed exactly ten concrete methods by which a public CA could verify the DNS name in a trustworthy certificate. Although the ballot passed, a ridiculous series of events occurred which led to it not taking effect yet. However CA/B BRs are just the baseline so Mozilla as part of its own requirements on top demanded that CAs begin using only these methods which folks involved tend to call the ten blessed methods.
At time of writing they're listed in Section 3.2.2.4 "Validation of Domain Authorization or Control" of the newest BR documents and they are:
3.2.2.4.1 Validating the Applicant as a Domain Contact
3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
3.2.2.4.3 Phone Contact with Domain Contact
3.2.2.4.4 Constructed Email to Domain Contact
3.2.2.4.5 Domain Authorization Document
3.2.2.4.6 Agreed‐Upon Change to Website
3.2.2.4.7 DNS Change
3.2.2.4.8 IP Address
3.2.2.4.9 Test Certificate
3.2.2.4.10. TLS Using a Random Number
So, today a public CA must use one of those exact methods (each is discussed in detail in the BRs, use the newest available version to catch any errata) to confirm that a DNS name is controlled by the applicant before creating a certificate. They're allowed to do more, but they are required to do at least that.
For example Let's Encrypt, one of the most popular CAs, offers to let applicants use either 3.2.2.4.6, 3.2.2.4.7 or 3.2.2.4.10
