Is there any standard, convention or practice that rules the use of static file server domains?

Question

I have the following scenario:

Each client of my service (Saas) has a custom url. For this, I created a CNAME record *.dominio.com pointing to my server.

Ex.: empresa1.dominio.com, empresa2.dominio.com, etc..

For the static files, I created another CNAME record pointing to my static file server as follows: *.static.dominio.com, to contain the company url.

Ex.: empresa1.static.dominio.com, empresa2.static.dominio.com, etc..

In practice, these subdomains point to the same file server.

I wonder if there is any convention on this scenario, if it would be a bad practice, if it would be better to just leave static.dominio.com, or if it makes no difference at all.

Answer 1

For HTTP, it makes no difference. The problem is when it involves HTTPS, and the tendency is for Web to migrate to HTTPS, so it would be good to predict the layout of domains to make things easier.

An Https certificate can be "wildcard", say *.empresa1.dominio.com, this certificate could be used on the static server Static.empresa1.dominio.com, but not if the server is empresa1.static.dominio.com. In the latter case it would be another certificate and the browser can complain because the content is coming from two domains with different identity (certificate).

The fact that the names point to the same server is no problem, since HTTPS servers can also serve different domains on the same IP for some time (SNI extension). Perhaps in the case of HTTPS one should use a DNS A record per client, not CNAME because CNAME actually changes the name for another, and then we return to the previous problem.