Is a wildcard DNS record bad practice?

Question

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 http://i.dont.like.your.website.mywebsite.tld.

Someone could link to your server using "http://i.dont.like.your.website.mywebsite.tld" but your server shouldn't respond unless it's configured to respond to it (via hostheaders or virtualhosts). — joeqwerty, Mar 01 '13 at 00: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. site1.blog.example.com, site2.blog.example.com -- with the wildcard in place for `*.blog.example.com`, you don't need to go configure each of these individually. — jscott, Mar 02 '13 at 01:51

score 25 · Accepted Answer · answered Mar 01 '13 at 01:53

25

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 example.com. You set up your workstation and name it. ... let's say, yukon.example.com. Now you will notice in its /etc/resolv.conf it has the line:

search example.com

This is convenient because it means you can do hostname lookups for, e.g. www which will then search for www.example.com automatically for you. But it has a dark side: If you visit, say, Google, then it will search for www.google.com.example.com, 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 api.twitter.com for example suddenly becomes api.twitter.com.example.com, routes directly back to your site, and of course fails.

This is why I never use wildcard DNS.

answered Mar 01 '13 at 01:53

Michael Hampton

244,070
43
506
972

3

@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 01 '13 at 02:14
Yeah, definitely never use made up TLDs anywhere, even internally. – MDMarra Mar 01 '13 at 02:17
7

[I actually blogged about this in regards to a Windows environment](https://web.archive.org/web/20190313031110/www.mdmarra.com/2012/11/why-you-shouldnt-use-local-in-your.html). 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 `internal.company.com`. Just because you see something a lot doesn't make it right. – MDMarra Mar 01 '13 at 02:23
2

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 01 '13 at 02:32
@ChrisLively you see it a lot because it _was_ MS Best practices for a long time. From when Windows 2000 and AD came out till at least just before 2008R0. It is no longer considered good practice to do this. – Zypher Mar 01 '13 at 02:33
3

@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 01 '13 at 02:35
1

@ChrisLively there are plenty of other reasons not to use it other than it's a violation of RFCs *as they're currently written* (which is really all that matters anyway). For example, have fun introducing anything needing mDNS into your AD .local environment and still leaving mDNS enabled. I think you're looking at things the wrong way. You shouldn't be justifying why it's OK to break the RFCs, you should be asking what *benefit* there is to using .local and the answer is that there are none. It's equal work to configure it either way and one is standards compliant and one isn't. It's simple. – MDMarra Mar 01 '13 at 02:44
1

I absolutely agree that it shouldn't use your public DNS name, it should use a delegated (separate) subdomain like `internal.example.com` where your external namespace is `example.com`. There's no reason to make up a TLD and using a delegated subdomain doesn't have any downside. Seriously, if you're going to advocate in favor of violating an RFC and using non-standard naming, you should bring good, solid reasons why. It's not on the people following the standards and published best practices to prove their side of the argument. If you'd like to continue this discussion, hop into [chat]. – MDMarra Mar 01 '13 at 03:01
3

Oh, and in a few years it's [going to be very difficult to get certificates for .local](http://blog.schertz.name/2013/01/lync-server-certificate-cliff/) 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 01 '13 at 03:03
1

@MDMarra actually a few days before your comment, the IETF proposed the RFC 6762 where in section 3 they specify `.local` as a special TLD for link-local use only: https://tools.ietf.org/html/rfc6762#section-3 – comfreak Nov 24 '16 at 09:58
It is even worse if the client runs Mac OS X. A long time ago I created a record for `*.example.net`. And to get around the problem you mention I ended up creating a subdomain named `search.example.net` to advertised through DHCP. That worked until a Mac OS X client came along and when told to use `search.example.net` actually searched both `search.example.net` and `example.net`. – kasperd Jan 09 '17 at 00:29
@comfreak To elaborate, RFC 6762 says `.local` MUST be resolved via a multicast query. It conflicts with a typical use of an internal domain as of today. – kubanczyk Jan 10 '17 at 16:48
1

Sorry, does this refer to WINDOWS domains? Or to adding a computer on the same network as *.example.com? – Eliezer Berlin Oct 18 '20 at 13:21

score 19 · Answer 2 · answered Mar 01 '13 at 01:26

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 http://i.dont.like.your.website.mywebsite.tld.

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;
    [...]
    }

Pedro Moreira · Answer 3 · 2014-07-23T19:13:46.070

10

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 milkman.example.com 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.

edited Jul 23 '14 at 19:13

answered Jul 23 '14 at 12:06

Pedro Moreira

291
3
5

6

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

As a matter of fact, this seems highly dangerous to me - it allows you to access an arbitrary database by changing the domain name. I'd argue that this is a type of injection vulnerability. Admittedly it's not necessarily exploitable - but why take chances? – sleske Jan 06 '17 at 11:25
2

@sleske It's not, because the user must authenticate against that subdomain (for that database). If he switches, he will need to authenticate again, as it is seen as a completely different "site". – Pedro Moreira Jan 06 '17 at 11:35
@PedroMoreira: Yes, that reduces the attack surface. Still, providing access to arbitrary databases seems dangerous. For example, what if there is a backup database with identical credentials, but data that was purged from the main db - this would allow anyone access who knows the name. Still, I realize security is always a tradeoff - just wanted to point out the inherent danger. – sleske Jan 06 '17 at 11:43
1

@sleske That's why all the accessible databases are prefixed with `tenant_`. I made sure the application can't even connect to them. – Pedro Moreira Jan 06 '17 at 14:29
*... can't event connect to those who aren't prefixed. – Pedro Moreira Jan 06 '17 at 14:46

score 2 · Answer 4 · edited Sep 21 '18 at 15:49

2

Another issue here is the SEO: if all *.example.com showing the same content, your website will be badly referenced, at least by Google (https://support.google.com/webmasters/answer/66359).

edited Sep 21 '18 at 15:49

Patrick Mevzek

9,921
7
32
43

answered Jun 20 '16 at 10:13

Clément Moulin - SimpleRezo

239
1
9

2

Both points are orthogonal. Even if all names point to the same IP, the webserver gets the name requested and can deliver completely different content. – Patrick Mevzek Jul 31 '19 at 15:29
That's why I have precized "if all *.example.com showing the same content"... The SEO risk sounds to me to something interesting to mention. – Clément Moulin - SimpleRezo Aug 01 '19 at 16:06
"The SEO risk sounds to me to something interesting to mention." Maybe but they are completely unrelated to using a wildcard or not. You can have many separate names all resolving to a single IP address without any kind of wildcards and hence having (or not) the SEO risks you speak about. The use of a wildcard does not change anything in any direction here. – Patrick Mevzek Aug 01 '19 at 16:11

score 1 · Answer 5 · answered Dec 13 '18 at 07:55

I know this is an old question, however I'd like to share a real world example of where using wildcard domains can cause problems. I am however going to change the domain name and also hide the full SPF record to save embarrassment.

I was helping someone who was having issues with DMARC, as part of the checks I always look up the DMARC record with DIG

;; ANSWER SECTION:
_dmarc.somedomain.com. 21599 IN      CNAME   somedomain.com.
somedomain.com.      21599   IN      TXT     "v=spf1 <rest of spf record> -all"

I also got the same result when looking for their DKIM record.

Consequently emails sent from this domain will get a DKIM fail as the DKIM module will try parsing the SPF record for a DKIM key and fail, and will also get a Permerror for DMARC for the same reason.

Wildcard domains might seem like a good idea but set up wrongly they can cause all sorts of issues.

score 0 · Answer 6 · answered Jan 12 '21 at 12:23

Using wildcard DNS record is bad practice only if you don't actually serve wildcard service. In addition, some ancient programs may have greater change to fail DNS query.

Other answers have already provided lots of examples where you try to mix wildcard domain with static names and there're potential pitfalls for those cases. Those cases are actually cases where the original intent wasn't to serve wildcard service and as a result, some static usage accidentally slipped to wrong static service (instead of slipping to a wildcard service that can correctly handle any wildcard or it's not a true wildcard service).

TL;DR: wildcard DNS is good for wildcard services, but it's bad practice to use wildcard DNS for static services because any errors are harder to diagnose.

MrPete · Answer 7 · 2023-04-27T02:35:33.603

There's one rather important crucially GOOD use of wildcard DNS: to block subdomain spam via spf!

Along with whatever else is configured, it is rather important to also set up:

*.example.com.      21599   IN      TXT     "v=spf1 -all"

Why? Because without this, a spammer can and will send millions of emails using random (non-existent) subdomains spoofing your primary domain.

Real world data from 2023 (plus global research from 1 1/2 years ago)

There are now about 1 1/2 billion email servers have a domain that responds to a DNS query
About 1/3 do use/check spf in some way (I'm ignoring misconfiguration for this)
About 0.03% use/check DMARC and DKIM. (DMARC can block invalid subdomain email.)

So: how do we tell a billion email servers that we don't send email from miscellaneous nonexistent subdomains? With a wildcard TXT subdomain entry.

Real world data on what happens when we don't do that...

I have a small email server. It never sends or receives email using its own domain. It only services our other domains. ANY email sent with its domain is by definition invalid.
I have properly configured SPF, DKIM and DMARC for the domain. All (spam) emails from joe@example.com do get blocked at the recipient end, by spf and/or DMARC.

Without wildcard TXT spf subdomain, what happens?

From DMARC reporting, we know the 0.03% of DMARC-capable servers block over 4200 spam emails a week (mostly from Asia). They are emails from "joe@ubx.example.com" ... @clt.example.com... etc etc
Since that represents only 0.03% of servers at best (not all send reports!), the other 99.97% are receiving over 14 million spam emails a week on my non-existent subdomains!
AND, the 1/3 of servers -- about half a billion -- that have SPF... they APPROVE the emails because I don't have an spf record for every possible subdomain.
That's 5+ million spams a week getting through to servers that DO check spf!

By setting up wildcard TXT as shown above, those ten million spams are all blocked. Yes, the other 2/3 of servers don't block, but that's not our problem.

Data Sources:

RedHunt Labs, "Wave 6 Internet=Wide Study: State of SPF, DKIM and DMARC" 10 Feb, 2022
Real world spam capture data: DMARC reports for one of my own domains.

score 0 · Answer 8 · answered Jun 20 '16 at 10:19

0

This is really a bad idea, suppose if you want to host one subdomain a.company.com in one web server, and b.company.com in another web server, may be another ISP. What you will do ?. So wildcard DNS is not an option, it should be precise, create A record for each sub domain and points to relevant IP. Chances are there to move your web server from one ISP to another ISP, in this case what will you do ?

answered Jun 20 '16 at 10:19

BDRSuite

400
1
9

not gonna work if you want to allow thousands of people to sign up w/o human intervention. – Ajax Aug 18 '21 at 07:29
and adding dns on demand would be slow. wildcard means no latency to propagate DNS if you wanna spin up a new namespace. – Ajax Aug 18 '21 at 07:30

score -2 · Answer 9 · answered Jan 08 '17 at 19:35

-2

I think the best reason not to have a wildcard DNS record in the first place is to avoid giving away your server IP address to a potential attacker and reduce the exposition to DDOS attacks. This is also recommended setup by Cloudflare: https://blog.cloudflare.com/ddos-prevention-protecting-the-origin/

answered Jan 08 '17 at 19:35

Michael Rogers

60
1
3
16

2

Using wildcard domains does not change exposure to such attacks. And the link does not support your incorrect claims. All that link says is that Cloudflare happen to be charging a higher price for wildcard domains. That only says something about Cloudflare's business models and nothing about the practice of using wildcard domains. – kasperd Jan 09 '17 at 00:23
1

If you use wildcard dns with cloudflare since it doesn't go through cloudflare (unless you pay enterprise, most don't) anyone can ping any a made up subdomain and find your real IP. Without wildcard they can't. that's all there is to it. – Michael Rogers Jan 09 '17 at 13:26
Yes in case of such service, they may charge you more for wildcard protection. Although this question isn't about those types of services its about wildcarding dns and whether it should be done or not under normal situations. – CodingInTheUK Sep 25 '19 at 20:55

score -3 · Answer 10 · answered Mar 01 '13 at 02:17

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 ww.mycompany.com or wwe.mycompany.com 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 i.dont.like.your.website.whatever.com 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.

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

Is a wildcard DNS record bad practice?

10 Answers10

Linked

Related