Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I asked my hoster to add three subdomains all pointing to the IP of the A record. It seems he simply added a wildcard DNS record because any random subdomain resolves to my IP now. This is OK for me from a technical point of view, since there are no subdomains pointing anywhere else. Then again I don't like him not doing what I asked for. And so I wonder whether there are other reasons to tell him to change that. Are there any?

The only negative I found is that someone could link to my site using

share|improve this question
Someone could link to your server using ""; but your server shouldn't respond unless it's configured to respond to it (via hostheaders or virtualhosts). – joeqwerty Mar 1 '13 at 0:36
In some cases wildcards can be required. For instance, multi-tenant webapps like Wordpress can be configured to automatically spawn new instances using sub-domains -- e.g., -- with the wildcard in place for *, you don't need to go configure each of these individually. – jscott Mar 2 '13 at 1:51
up vote 7 down vote accepted

If you ever put a computer in that domain, you will get bizarre DNS failures, where when you attempt to visit some random site on the Internet, you arrive at yours instead.

Consider: You own the domain You set up your workstation and name it. ... let's say, Now you will notice in its /etc/resolv.conf it has the line:


This is convenient because it means you can do hostname lookups for, e.g. www which will then search for automatically for you. But it has a dark side: If you visit, say, Google, then it will search for, and if you have wildcard DNS, then that will resolve to your site, and instead of reaching Google you will wind up on your own site.

This applies equally to the server on which you're running your web site! If it ever has to call external services, then the hostname lookups can fail in the same way. So for example suddenly becomes, routes directly back to your site, and of course fails.

This is why I never use wildcard DNS.

share|improve this answer
@ChrisLively Blame modern Linux systems for being "helpful" and adding it. BTW, using ".local" really is bad practice, and not just in Windows environments. – Michael Hampton Mar 1 '13 at 2:14
I actually blogged about this in regards to a Windows environment. Not to mention that at least three groups have bid on the .local TLD now that ICANN is selling them to anyone with a substantial enough wallet. .local isn't reserved and shouldn't be used. Doing so violates RFCs and isn't necessary at all. Best practice is to use a delegated third-level subdomain for internal resources like Just because you see something a lot doesn't make it right. – MDMarra Mar 1 '13 at 2:23
Could you please point me to the section of RFC 2606 that reserves .local? I've read this RFC at least a dozen times with people that use it in this argument and I can tell you with certainty that it's not there. – MDMarra Mar 1 '13 at 2:32
@Zypher It actually was never recommended by Microsoft (that's debunked in my blog post too. Go read it, it's a good one), but the fact that SBS shipped using .local by default really made MS look like a mess in that regard. SBS shipped with that configuration because it was meant for non-tech customers with low technical knowledge. It was the path of least resistance, but the actual AD docs recommend a third-level subdomain all the way back in the W2K era. – MDMarra Mar 1 '13 at 2:35
Oh, and in a few years it's going to be very difficult to get certificates for .local which means UCC/SAN certs for Lync/Exchange will have to be signed by an internal CA, making it painful if you have external non-domain joined users. – MDMarra Mar 1 '13 at 3:03

Is a wildcard DNS record bad practice?

Personally, I don't like it. Especially when there are machines in that domain. Typos go unchecked, errors are less obvious... but there's nothing fundamentally wrong with it.

The only negative I found is that someone could link to my site using

Have your http server redirect all such requests to the proper, canonical addresses, or not respond at all. For nginx that would be something like:

server {
    listen 80;
    server_name *.mywebsite.tld;
    return 301 $scheme://mywebsite.tld$request_uri;

and then the regular

server {
    listen  80;
    server_name mywebsite.tld;
share|improve this answer

It's all a matter of opinion. For me it's not bad practice.

I'm creating a multi-tenant app which uses a database per tenant. It then selects the database to be used based on the subdomain.

For example will use the tenant_milkman database.

Like this I have separated tables for each tenant, like, tenant_milkman.users, tenant_fisherman.users, tenant_bobs_garage.users, which in my opinion is a huge lot easier to maintain for this specific app, instead of having all users from all companies in the same table.

[edit - Michael Hampton has a good point]

That being said, if you don't have a specific reason to accept any (variable) subdomain, like I do, then you shouldn't accept them.

share|improve this answer
You have a good technical reason to use wildcard DNS. Most people don't. – Michael Hampton Jul 23 '14 at 14:46

Is a wildcard DNS record bad practice?

No, and contrary to others I believe it is good practice.

Most internet users fat finger a DNS name at some point. They will type or What would you rather happen an "oops we couldn't find that site" or for them to pull up your primary home page? More often than not having them pull up your primary home page is preferable. Which is what a LOT of people do.

Even if someone put a link to it would still pull up your home page, which is actually what you want. After all, they can't make that i.dont.... site go to their server, you still control the DNS routing so it goes to yours.

share|improve this answer
The problem I have with this reasoning is that 1. it breaks error handling, 2. it's entirely www-centric while your wildcard records will affect other protocols as well. The result being that you've broken error handling for other things where you have made no effort to patch things up. – Håkan Lindqvist Jul 23 '14 at 12:15

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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