sub-domains, A NAME, security and routing

Question

NOTE: I am a marketing strategy consultant not a technology consultant, so:

I have a client for whom we are using a 3rd party's cloud hosting solution to create small (single page) websites for their customers. In the end client sector, it will be very difficult for all customers to get their own MyWebSite.com name, which is one factor why my client wants to use sub-domains for these sites: XYZ.MyClient.com. End customers are fine with this solution from what we have seen.

The 3rd party cloud hosting firm we are using says we should just use a wildcard A NAME (e.g. *.MyClient.com), and this will route all sub-domain traffic through their platform and to the correct site without affecting the main domain at all (www.MyClient.com).

My client's outsourced IT firm maintains that no, this wildcard solution will in fact route all www.MyClient.com traffic through the 3rd party hosting firm before getting to the right site. They assert the best solution is to create an A NAME record for each subdomain and to manage those moving forward for hundreds of sites.

I just need answers for I can facilitate the discussion between all parties - I don't really care what the answer is. I just want my client to have a secure, manageable, cost-effective solution. My questions then are:

1. Will using an A NAME wildcard approach in fact route the core www.MyClient.com through the 3rd party hosting firm?
   2. If so, why is that a problem? Delay? Security? Other?
   3. I have read elsewhere (tho it was a 5 year old post) that it would be good to have a separate security certificate for the sub-domain setup. Is that so? If so, can anyone point me to a good reference on that?
   4. Managing hundreds of A NAME records for subdomains strikes me as creating a lot of work that will lend itself to errors and rework. True, or not?
   5. Am I missing something?

Thanks

Answer 1

Will using an A NAME wildcard approach in fact route the core www.MyClient.com through the 3rd party hosting firm?

No. Existing specific names always take priority over wildcard matches. (See "Existence rules" in the earlier linked RFC 4592.)

If so, why is that a problem? Delay? Security? Other?

Delay, and imposing quite a bit of bandwidth requirement on the 3rd-party provider since it has to relay all traffic to your real webserver. (I'm willing to bet they just outright won't do that at all.)

And of course the 3rd-party provider gains full control over your main website's contents. That's undesirable even if you already trust them with your clients' webpages.

I have read elsewhere (tho it was a 5 year old post) that it would be good to have a separate security certificate for the sub-domain setup.

I don't know very much about this, but essentially you have three options:

• Issue a new certificate for every subdomain. Quite possible nowadays with Let's Encrypt, and the 3rd-party provider can do it by themselves.
• Issue a few certificates with each valid for a few dozen subdomains at once. This used to be done in the past (before LE), but is probably the most difficult to maintain in comparison.
• Issue a wildcard certificate for *.myclient.com. Although easiest to manage, it costs more and theoretically makes it easier for the 3rd party host to somehow impersonate your www subdomain. (It's a bit stretched argument though; the same issues exist with LE anyway.)

Managing hundreds of A NAME records for subdomains strikes me as creating a lot of work that will lend itself to errors and rework. True, or not?

The biggest problem I can see with direct A/AAAA records is that it would be rather annoying to update all of them if the server's IP address ever changed. Having all those subdomains be CNAMEs (aliases) would make things easier, since only a single domain (the CNAME target) would need to be updated.

But the amount of subdomains, in general, doesn't seem like a problem – as long as their creation and deletion is clearly defined as part of the procedure of setting up a new client. (That is, if your system cannot outright automate it when bringing up a new client's webpage...)

Still, a wildcard would be even easier.