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.
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.
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 an 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 must (but we recommend using a wildcard ALIAS instead, when possible).