Is A record more secure than CNAME record
I have a client which uses our white label web application. Their url is portal.client.com. When I asked them to point the url to CNAME app.company.com, they said that it has to be an A record.
I argued that CNAME would be ideal because if we ever have ever need to change the ip address, we can just do it in one place rather than contacting each of our clients to update their DNS record, saving time and hassle for both parties.
And here is the response I got from them:
The fact that the CNAME is a URL redirect the best approach is to set an A record to the Hosting provider webserver. This provides a more secure approach as we can't guarantee that the CNAME will continue to masquerade the third party URL as far as end users are concerned on the browser level.
Now, none of that makes sense to me. First and foremost, CNAME is not a URL redirect... Can someone shine a light how or in what situation an A record would be a better or more secure approach than CNAME and if that is applicable in this case.
Thanks,
I can't really think of a situation where CNAME would be less secure.
One might argue that since the alias spans over a zone (client.com
-> company.com
), it's not safe since the endpoint is not in client.com
's administrative control. However the client supposedly trusts you enough to use your application, so why not trust that you don't mess up with the app.company.com
record.
From a sysadmin point of view i'd rather have a CNAME as you've suggested, but you might just suck it and keep your customer happy :).
No, a CNAME record is not less secure than an A record.
In fact, this type of situation is exactly why CNAMEs exist in the first place.
From RFC 1034 Section 3.6.2. Aliases and canonical names:
hosts and other resources often have several names that identify the same resource. For example, the names C.ISI.EDU and USC-ISIC.ARPA both identify the same host.
It should also be mentioned that a CNAME is not really a URL redirect. DNS queries happen before any connection to the server is made and simple give your client an IP address to use for its session. The client still knows what URL was originally requested.
In theory assuming your application is designed to be multi tenanted with different domains. ... there's no real difference.
cnames arn't 'redirects', they're aliases. They're simply an alternate name for a resource. Past the DNS lookup your application isn't going to care.
This provides a more secure approach as we can't guarantee that the CNAME will continue to masquerade the third party URL as far as end users are concerned on the browser level.
Makes no sense, technically speaking. I'd consider losing control of an A name ... somewhat only less terrible and careless than losing control of the ip address your application is running on.
You also shouldn't (but could) have a cname pointing at another cname.
And well, there's no reason you can't keep this client happy with an A name assuming your record keeping is good enough, and keeping other clients on a cname. Just tack on a service charge, and adjust your SLA.