Wildcard for A and MX records possible?

domain-name-system subdomain mx-record wildcard

14,134

RFC1912 explicitly acknowledges the existence of wildcard MX records, but warns

A wildcard MX will apply only to names in the zone which aren't listed in the DNS at all.

RFC4592 is a standard-track RFC that clarifies the existence of MX wildcards (see the example in section 2.2.1). I'm pretty sure your DNS provider is, thus, full of it.

I can imagine some DNS software having trouble with the situation, too, either because they don't support wildcard MX records at all, or because they take the "no other records" thing a bit too literally and don't allow both a wildcard MX and a wildcard A. This software is non-standards-compliant, but good luck getting that fixed.

Given how trivial it is (or should be) to automatically setup DNS records when customers sign up, I'd skip the wildcards entirely and just have your app configure DNS records for each customer.

14,134

wyred

Updated on September 18, 2022

Comments

wyred almost 2 years

I'm building an app where each customer can have their own subdomain. For this example, he setup his subdomain to be: whisky

I created a wildcard subdomain in my DNS:

*.myapp.example A 192.0.2.123

So when he accesses my webapp, he would use the URL: whisky.myapp.example and it would resolve to 192.0.2.123.

My app also sends email (email will be handled by sendgrid) using the same subdomain my customer chooses: e.g. [email protected]

But when I tried to setup a wildcard MX record to sendgrid's servers, my DNS provider does not allow me to do so, citing some standards violation.

e.g. *.myapp.example MX sendgrid.com

Is there any way I can have wildcard subdomains for both?
- user9517 almost 12 years
  
  Which standards violation do they state ?
- Mike Pennington almost 12 years
  
  @wyred are you suggesting that you want requests for both whiskey.myapp.com and cognac.myapp.com to go to 123.123.123.123? If so, what should happen to mail for cognac.myapp.com? Does this also go to whiskey's MX record?
- wyred almost 12 years
  
  @MikePennington yes, I'm using sendgrid so all mail from all subdomains should point to the same MX record
- wyred almost 12 years
  
  @lain Sorry, the "standards violation" part is just what I heard from a colleague. When I tried to add a wildcard subdomain MX in addition to an already existing wildcard subdomain CNAME, the system simply refuses with the error: "Cannot add data at a node with a CNAME"
- wyred almost 12 years
  
  Firstly, this may not be an elegant solution. Womble's solution sounds better but my boss isn't convinced. Since the email addresses are only used by our web application, and thus the local-part of an email address is fixed across all subdomains, our current solution is to include the customer's subdomain into the local-part, separated with a hyphen. e.g. [email protected] Our callback url for sendgrid will do the routing to different client's databases by dissecting the local-part for the subdomain.
- Garcia over 9 years
  
  It is possible through the site www.cloudflare.com Even better, you can do this through the free plan!
- Patrick Mevzek over 4 years
  
  "*.myapp.example MX sendgrid.com" is not a valid MX record (you miss the weight/priority) and "When I tried to add a wildcard subdomain MX in addition to an already existing wildcard subdomain CNAME" for any label you can not have a CNAME record if you have any other record and you can not add any other record if you already have a CNAME one. This is unrelated to having a wildcard in fact.
BillThor almost 12 years

Wildcard MX is a great way to say "Open to spammers". Any subdomain will appear to be a legitimate sender
womble almost 12 years

Yeah, but there's no shortage of legitimate domains to forge, and anyone who is using "is a valid sender domain" as anything other than the weakest of all possible spam scoring methods deserves whatever they get.
wyred almost 12 years

Thanks, it's a possible solution, to configure DNS on signup. But I think another problem may occur where some customers are not able to resolve the new domain as soon as it's created.
womble almost 12 years

Why wouldn't they be able to? If your DNS infrastructure doesn't suck, the name will be available everywhere by the time the "thanks for your signup" page is finished rendering.
wyred almost 12 years

I'm not familiar with DNS so correct me if I'm wrong. Even if I have everything configured right, we can't be sure if the user's ISP will be able to resolve the new subdomain quickly right?
womble almost 12 years

You can't be sure of anything -- the user's ISP may run entirely out of a hosts file. But no, DNS doesn't work the way you think it does. Once the records are on all authoritative servers (which should be near-instant, see "DNS infrastructure that doesn't suck", above), the records are available to the entire Internet.
wyred almost 12 years

I just brought up your suggestion to my boss and it seems that with this solution (create a new DNS record for each customer), we will end up with a huge zone file to maintain and there are disadvantages to it.
womble almost 12 years

There's advantages and disadvantages to everything. I've got an 18,000 record zone file, though, and managing it is not appreciably harder than any other.
Juanjo Daza over 11 years

@BillThor an ADSP or DMARC entry can prevent wildcard MX records from being used by spammers.
BillThor over 11 years

@makerofthings7 Would be nice if I could try these. DMARC appears to still be pending submission as a Draft standard. My experience validating DKIM is most DKIM signed messages don't have a published key. Trying to build ADSP on top of it require much better deployments than we currently have.
Juanjo Daza over 11 years

Just a word for anyone considering ADSP... is to almost never use it. It breaks anytime you send to a mailing list, an alumni at a university (who forwards email) and many more. Even the author of ADSP recommends to never use it and says it's a bad idea for almost everyone.