7

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. customer@whisky.myapp.example

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?

Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42
wyred
  • 207
  • 1
  • 2
  • 7
  • 2
    Which standards violation do they state ? – user9517 Jul 07 '12 at 09:25
  • @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? – Mike Pennington Jul 07 '12 at 09:29
  • @MikePennington yes, I'm using sendgrid so all mail from all subdomains should point to the same MX record – wyred Jul 07 '12 at 09:42
  • @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 Jul 09 '12 at 05:31
  • How you end up implementing this? I'm in exact same situation right now, looking how to either use wildcards or dynamically create new DNS records when new client sign up. – Igor Romanov Sep 18 '12 at 14:06
  • 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. documents-whisky@myapp.com Our callback url for sendgrid will do the routing to different client's databases by dissecting the local-part for the subdomain. – wyred Sep 19 '12 at 08:18
  • It is possible through the site www.cloudflare.com Even better, you can do this through the free plan! – Garcia Mar 08 '15 at 21:13
  • "*.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. – Patrick Mevzek Mar 02 '20 at 20:45

1 Answers1

8

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.

Community
  • 1
womble
  • 95,029
  • 29
  • 173
  • 228
  • Wildcard MX is a great way to say "Open to spammers". Any subdomain will appear to be a legitimate sender – BillThor Jul 07 '12 at 14:50
  • 3
    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. – womble Jul 07 '12 at 15:20
  • @womple: But I still manage to drop emails using invalid domains. SPF is totally ineffective with wildcard sending domains, but is effectively used by a number of organizations. – BillThor Jul 07 '12 at 16:44
  • 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. – wyred Jul 09 '12 at 05:28
  • 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. – womble Jul 09 '12 at 06:01
  • 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? – wyred Jul 09 '12 at 07:00
  • 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. – womble Jul 09 '12 at 07:19
  • 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. – wyred Jul 09 '12 at 07:56
  • 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. – womble Jul 09 '12 at 08:15
  • @BillThor an ADSP or DMARC entry can prevent wildcard MX records from being used by spammers. – makerofthings7 Nov 21 '12 at 16:06
  • @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. – BillThor Nov 21 '12 at 22:22
  • 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. – makerofthings7 Nov 22 '12 at 05:38