Wildcard processing

Wildcards are useful when you have a large number of subdomains that are otherwise all the same. One common use is building an app that uses a different subdomain for every customer. While you could use the DNScaster API to dynamically create and manage all those records, a wildcard is usually a much better way to go.

; Configured records:
www.your-domain.com  300  A  192.0.2.1
*.your-domain.com    300  A  192.0.2.2

; Possible dynamic responses:
www.your-domain.com             300  A  192.0.2.1
some-customer.your-domain.com   300  A  192.0.2.2
other-customer.your-domain.com  300  A  192.0.2.2

DNScaster will always look for a non-wildcard record first (www in the example above) and use that if found. Only if not found will DNScaster then use the wildcard.

Comparison to wildcards at other providers

Most providers process wildcards according to the arcane rules built-in to popular DNS server daemons, including refusing to use wildcards when there are related (but non-matching) records. DNScaster instead returns the intuitively expected responses. See the next section for details.

The common workaround is to add extra records to placate those arcane rules. DNScaster will work fine with those extra records (even though it doesn’t need them itself) and you can safely migrate all such records into DNScaster without concern.

Technical details

The DNS specifications have an unexpected provision that requires a wildcard to only be substituted if the original record does not exist for any type, including any in-between subdomain. Consider this double example of testing a dual ipv4/ipv6 setup plus a corporate intranet at corp.your-domain.com plus a separate webmail server.

; Configured:
*.your-domain.com           3600  A     192.0.2.1   ; load balancer for all intranet services except webmail
mail.corp.your-domain.com   3600  A     192.0.2.2   ; webmail
dual-stack.your-domain.com  3600  AAAA  2001:db8::1

Most admins would intuitively believe that corp.your-domain.com will resolve to 192.0.2.1. However, it will actually return “domain not found”. What happened!?

DNS says that when mail.corp.your-domain.com is defined, it implicitly defines corp.your-domain.com as an empty record. Because it exists as an empty record, the wildcard is not allowed to be used and so the response is “domain not found”.

Similarly, when querying for an A record for dual-stack.your-domain.com, one would intuitively expect it to also resolve to 192.0.2.1. Once again, it will return “domain not found”. Similar to the above, because the AAAA record for dual-stack is defined, an empty record is implicitly defined for every other type. Thus, the wildcard isn’t allowed to be used here either.

We believe that both of the arcane rules behind this very counter-intuitive behavior are broken. The good news is, we’ve fixed them, made the configuration behavior intuitive and natural, and did it all without breaking compatibility with the rest of the internet. DNScaster will use a wildcard as long as there is not already another non-empty record with the same name and same type. Each of the above queries will work as intuitively expected on DNScaster!

Lastly, without going into the really gnarly details, when the DNS rules are followed to the letter, wildcard CNAMEs are almost universally guaranteed to go wrong at some point. We’ve seen it and it’s insanely hard to debug. Once again, DNScaster has built-in mitigations for this. You can safely use wildcard CNAMEs if you want (although we still suggest using a wildcard ALIAS when possible).