Optimal Implementation of DNS Wildcard Records for Domain Routing


2 views

When configuring domain routing, DNS wildcard records (*) provide an elegant solution to handle unlimited subdomains with a single entry. The wildcard character acts as a catch-all for any undefined subdomain requests.

The most common pattern combines an A record with a CNAME wildcard:

example.net.    60  IN  A       1.2.3.4
*.example.net.  60  IN  CNAME   example.net.

For direct IP mapping without CNAME:

example.net.    60  IN  A       1.2.3.4
*.example.net.  60  IN  A       1.2.3.4

Using CNAME introduces an additional DNS lookup but provides flexibility when IP changes occur. Direct A records reduce resolution time but require manual updates.

For complex routing needs, consider these patterns:

; Tiered wildcard implementation
*.dev.example.net.  IN CNAME dev-gateway.example.net.
*.prod.example.net. IN CNAME prod-cluster.example.net.
  • Always verify record propagation using dig or nslookup
  • Remember TTL values affect how quickly changes propagate
  • Some DNS providers require special syntax for wildcards

Wildcards can expose your infrastructure if improperly configured. Consider:

; Restrict wildcard to specific subdomain levels
app-*.example.net. IN CNAME appcluster.example.net.

A wildcard DNS record (specified as *) acts as a catch-all for any undefined subdomains of a domain. The most common implementation pattern:

example.net.    300 IN  A       1.2.3.4
*.example.net.  300 IN  CNAME   example.net.

Direct A Record Approach

For single-server setups, you can simplify further by pointing both records to the same IP:

example.net.    300 IN  A       1.2.3.4
*.example.net.  300 IN  A       1.2.3.4

Modern DNS Providers

Services like Cloudflare offer simplified syntax:

*.example.net {
    respond 1.2.3.4
}
  • TTL (Time-To-Live) values should be balanced between performance (lower) and DNS traffic (higher)
  • Avoid mixing CNAME and other record types at the apex (naked domain)
  • Wildcards don't cover the apex domain itself - you must define it separately

Here's a complete BIND zone file implementation:

$TTL 300
@       IN SOA   ns1.example.net. admin.example.net. (
                2023081501 ; serial
                7200       ; refresh
                3600       ; retry
                1209600    ; expire
                300 )      ; minimum

@       IN NS    ns1.example.net.
@       IN A     1.2.3.4
*       IN CNAME @

Verify your configuration with dig:

dig any-subdomain.example.net +short
dig example.net +short

Both should return the same IP address if configured correctly.