So we're using Route53 and I wanted to set up a wildcard CNAME record to redirect any unmatched subdomains to our main domain. I tried it out and everything looks like it worked okay, but when I told a colleague about it he was adamently against wildcard CNAME records stating that there are issues/security concerns or something, but wouldn't go into detail. A web search didn't really turn up any explanation for this concern beyond issues isolated to specific DNS server implementations.

That being said are there security issues with wildcard CNAME records? Are there issues with SSL certs if you only have a cert for your top level domain? i.e. Does a CNAME redirect mean that the referrer seen by the server will be the subdomain or the top-level domain? What about cross-origin issues?

He specifically preferred going through the trouble of setting up server at the subdomain that performs a 301 permanent redirect. That seems overly complex when the DNS RFCs 1034 and 2672 describe a mechanism for this and Route53 seems to support this just fine.

If any out there explicitly recommends not setting wildcard CNAME records, can you explain why and under what circumstances you recommend against it?

  • 2
    Anyone who can't explain what they're talking about likely doesn't know what they're talking about and is just repeating something they heard and likely didn't understand. Without an original source or some kind of back up, ignore it. (Or, at best, use it to search fro an original source with some kind of technical defense of the position. As it is, you don't even know what the position really is.) – David Schwartz Apr 16 '14 at 20:51

There are no such security issues.

I must point out, however, that DNS provides no mechanism to "redirect" per se any requests; a CNAME defines an alias for another DNS name, but an HTTP server is required to actually "redirect" the browser -- otherwise a user who visits whatever.example.com will see whatever.example.com in their browser address bar still, not example.com as a "redirect" per se would act. The web server also would see whatever.example.com in the request, which may cause issues if you are using virtual hosts.

That caveat out of the way, there's really only two cases where wildcard DNS records may cause issues:

  1. You cannot provide NXDOMAIN responses, because every subdomain exists; this is only an issue if using DNSSEC, and even then it usually doesn't matter.
  2. SSL can only protect the domain it's issued for -- however a wildcard SSL certificate, as you mentioned you have, eliminates this issue.

In your case (based on what I've gleaned from your question) I would most likely use a wildcard record along with a web server that provides a 301 redirect to my "proper" address; some DNS providers make this convenient with a "web forwarder", just be aware that technically this is a web server not under your control that is responding to those requests with a 301 redirect. (The phrasing of that may sound scary, but if it's a trusted company it's nothing to worry about, and if it's not a trusted company you shouldn't have your DNS hosted with them at all in the first place!!)

| improve this answer | |
  • So as long as the server at the other end of the toplevel A record performs a 301 redirect whenever the request origin does not match the domain on the certificate, then there should be no problems, correct? – Andrew De Andrade Apr 16 '14 at 22:26
  • 1
    That's certainly a way to go about it, and if you're not serving any other virtual hosts from that server shouldn't have any problems. Actually, even if you are, if you do the redirect from the "default" vhost, you can in effect "override" it for any arbitrary host name -- so, yes, I would think so. – Kromey Apr 16 '14 at 22:34
  • Also, wouldn't a wildcard CNAME record also protect against NXDOMAIN hijacking by less scrupulous ISPs? Can you elaborate a bit on the NXDOMAIN issue with DNSSEC, since I'm not familiar with DNSSEC. – Andrew De Andrade Apr 16 '14 at 22:34
  • Yes, it would prevent NXDOMAIN hijacking, albeit only for subdomains of your domain, of course. The issue with respect to DNSSEC is that it's supposed to be able to not only provide authentication of responses, but also authenticated "non-responses", i.e. signed NXDOMAIN responses. In practice I can't think of a single case where this would actually matter, but I always get a wee bit hesitant when stepping outside of spec. In other words, the "real" answer is most likely "it doesn't matter, period", but since the spec calls for authenticated NXDOMAIN I'm unwilling to say that outright. – Kromey Apr 16 '14 at 22:38
  • 1
    Nope. If the client makes an HTTPS request, and you don't have a valid cert for that domain, you have only two choices: SSL cert error, or no response at all. After the cert error, you can of course redirect all you want, but short of getting yourself a valid cert there's just no way around that error. – Kromey Apr 21 '14 at 17:58

I'm using wildcards for years now and have never had any problems with it. So far I found that a Windows mobile phone in 2003 was the only device that did not handle the wildcard correctly.

IMHO using wildcards is very common today and problems only arise rarely. From the security point of view you get a few additional attack vectors. You may for example refer to "someevilXSScode.yourdomain.com" and still reach the original site. Only a minor issue IMHO.

| improve this answer | |
  • Can you give an example or further explanation of the evil XSS code example? – Andrew De Andrade Apr 16 '14 at 22:15
  • The basic think is that you have a "customizable" part in your domain. Think of the referer that may be included inside another page. Or the calling URL may be processed inside a PHP script. Just guessing ... – fr00tyl00p Apr 16 '14 at 22:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.