In this case study the clients identity “Bob” will be spelled backwards “boB” so nobody will know to whom we are referring … coming right into an ongoing discussion regarding DNS, “A” records, MultiSites and SSL Certificate provisioning …
Part of the answer is indeed boB no longer has a dedicated IP as he added a second entry to his IP being a dev site that then changes the dedicated IP to a shared IP ( but still only shared exclusively by his hosting account ) by said action and therefore the behavior as described above regarding “A” records sending a domain at the server that the server does not know about and the server cannot resolve – therefore the symptoms of not resolving correctly to the WordPress MultiSite installation.
When using a dedicated IP the server actually does not come into play and WordPress itself resolves the DNS in the “A” record type setup to the applicable subdomain/subdirectory site.
Being that we are the hosting company involved I know exactly every in and out of these MultiSites and servers of course and we can certainly take care of boB by moving his dev site off the formally dedicated IP and make the IP once again dedicated to just his MultiSite … but this in itself will present several other challenges …
For example going https:// on the addon domain in an “A” record DNS environment WITHOUT making an alias or addon domain entry means each and every domain that uses SSL ( https:// ) will require a purchased SSL certificate to be created and installed.
I say purchased due to the fact that unless the server has appropriate DNS entries itself one cannot take advantage of our FREE SSL certificates that are now automatically issued and assigned to every domain added to the server which includes both alias and addon domains.
Now I am strictly referring to Domain Mapping and not the MultiSites main domain which can be either subdomain ( use a purchased wildcard SSL certificate ) ~or~ subdirectory/sub folder which our systems will automatically add a Grade “A” SSL Certificate in association with cPanel and Comodo themselves.
So the choices are as follows …
A) Unsecure – Going only http with mapped domains – no problem and the dedicated IP is the solution even if the main MultiSite domain has the applicable SSL certificate installed – the MultiSites subdomains ~or~ subfolders will still work as secure with a https:// URL but not the domain mapped domains. Note: For SEO and security this would not be good … see below.
B) Secure https:// URL’s for mapped domains – In this scenario to get the mapped domain secure and to work correctly boB or client/end user will need to pay for SSL certificate first creating the applicable CSR which is then submitted to the SSL certificate supplier and then in turn the SSL certificate supplier will send an email to the domains registered owner to authorize the SSL certificate.
When the SSL certificate is authorized by the registrant which is usually as simple as clicking a link … then the SSL certificate is issued and sent to the purchaser in which then needs to be manually installed on the server which boB certainly has the access to perform.
Then every year when the certificate expires the same procedure must be re-enacted including the CSR and manual installation.
Now lets compare this to the other option which is a whole lot simpler, requires the least amount of interaction by all concerned parties and what I recommend which providing for the least expense and manual labor/intervention … whereas option B above requires much more interaction not limited to but including interaction of the admin and the client/end user of approving the certificate and certificate installation …
C) Secure https:// URL’s for mapped domains the client proceeds as normal sending the domain to the MultiSite installation using the “A” record method. boB manually adds the mapped domain to his cPanel either as a addon domain ~or~ alias ( formally called parked ) resolving to /public_html
The SSL Certificate is automatically added to the domain by our systems FREE without any further interaction by either the administrator nor the client/end user. These FREE SSL Certificates also auto renew themselves so that portion is also removed from the equation.
This is far more efficient and less costly even IF boB decided to charge a nominal fee for the “secure” URL version for manually adding the domain to the server as a addon on or alias taking only a minute or two to perform and most likely cheaper then the cost of a SSL Certificate not to mention the hassle of creating and submitting the CSR etc. etc.
Furthermore considering that the Google Chrome Security team announced the Chrome browser will begin labeling HTTP connections as insecure starting in January 2017 and that HTTPS:// secure sites are also rated higher then non secure sites as reported in the WPMU DEV newsletter referring to the WP Tavern article https://wptavern.com/chrome-to-add-security-warning-to-http-sites-beginning-2017 – it is my opinion that NOT making all the sites forced SSL is a disservice to the client/end user and to said clients/end users visitors and it appears Google agrees considering they are the ones that are marking sites secure or not and giving further ranking to secure sites versus unsecure sites.
Secure sites obviously improve the user experience by not only encrypting the transmissions between the two but also security wise in the perspective that hacker injections to date are almost always to an insecure domain making the injection super obvious in a secure environment which would then indicate it is insecure making the injection stick out like a sore thumb making detection and mitigation easy peasy.
With the big picture at hand … with all the above realized and factual – it is my opinion that boB and his cleints/end users would be best served forcing SSL on everything, using the fact that “all sites are secure with FREE SSL certificate” as an advertised or mentioned feature would please the potential client/end user and everything secure would get the SEO secure ranking bonus … and all boB needs to do is add the “A” record mapped domain to his control panel as either a addon domain ~or~ alias/parked domain to achieve all of the aforementioned.