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.


  • I don't understand the question. Are you saying you have a server with an IP address and portal.client.com, but you want to also access it via app.company.com? Some DNS providers provide a URL re-direct service and they might confuse that with CNAME. It can be more secure because CNAME record can point to portal.client.com, but maybe that name is hijacked and its A record changed to a Russian server? Now app.company.com will also point to the Russian server. If the IP address of app.company.com was hard-coded with an A record, it would go directly to the IP address without the added lookup.
    – Chloe
    Jan 13, 2017 at 3:03
  • @Chloe portal.client.com is owned and managed by the client's IT team, we own the app.company.com. You are right that if company.com domain is hijacked, it can change the A record of app.company.com to a malicious server, but doesn't seem to be argument there. My purpose is that portal.client.com should be set as an alias of app.company.com so that we can update the IP address whenever we need to. A good scenario will be a multi region server where the IP address may be resolved differently depending on a Geo Location. Jan 13, 2017 at 4:08
  • “The fact that the CNAME is a URL redirect” ... is wrong. It’s not. Their point about “URL masquerade” is certainly valid in a multi-tenant application, but using an A record changes nothing. Simply ask them to use nslookup and they will see that there is no difference whatsoever.
    – Daniel B
    Jan 18, 2017 at 13:33

4 Answers 4


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 :).

  • Exactly this. The only thing that might make an A record slightly more secure than CNAME is that they will have administrative control over the record. This is obviously not something you want because you might change your IP address and then have to get them to update the record.
    – Cas
    Jan 18, 2017 at 13:42

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.

  • I'd rather make binds to IPs, not names.
    – Overmind
    Jan 19, 2017 at 12:24
  • The problem with that is if you need to change the IP then you need to change all the A records. If you use CNAMEs, then you only need to change 1 record.
    – D34DM347
    Jan 19, 2017 at 12:26
  • @Overmind can you please elaborate why you'd rather make binds to IP? In my situation if I had 100 clients chose to binds to IP, I would need to email and wait for them to change the A record everytime I need to move servers which is not idea. Jan 19, 2017 at 22:43
  • Because DNS records have a higher chance of being messed up compared to reserved IPs. I found a lot of situations where older records were not correctly removed even if the correct settings were configured or where hostnames were changed and messed things up. There is no practical reason to use a name where you can use an IP, except the situation when IPs are not reserved and keep changing.
    – Overmind
    Jan 20, 2017 at 6:11

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.


An A record would be more secure than a CNAME record in case company.com's DNS servers are compromised. Also, to be very nitpicking, a CNAME record would require slightly more time because of the additional name resolution. Apart from this, there's no much difference and in fact many Internet cloud services - such as Amazon Web Services - have the habit of setting CNAMEs for clients' domains.

Also, a URL is something like http://portal.client.com/myapp/foobar.html. A CNAME cannot point to a URL, only to a hostname. Given their response, it seems that your client doesn't know what they're talking about. You might want not to fight against their cluelessness and, as suggested by @Joe, indulge them in setting an A record.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .