Wildcard DNS (*.domain.uz): When It Helps and When It Hurts

Normally each subdomain gets its own DNS record: www, shop, mail and so on. A wildcard record answers for every name not explicitly defined in the zone. With an A record for *.example.uz, abc.example.uz, test.example.uz and even the typo wwww.example.uz all reach the same server. It is convenient, but used without understanding its rules it causes problems for both the website and email.

How matching works

A wildcard only applies to names that do not exist in the zone. An explicit record for shop.example.uz overrides it. If a name has a record of any type, even just TXT, it counts as existing and an A query for it returns an empty answer rather than the wildcard. The wildcard also does not cover the apex example.uz, which needs its own record.

example.uz.      3600  IN  A      203.0.113.10
*.example.uz.    3600  IN  A      203.0.113.10
shop.example.uz. 3600  IN  A      203.0.113.20

Wildcards can also match deeper names: a.b.example.uz is answered from *.example.uz if b.example.uz does not exist at all. If it does exist, you need a separate *.b.example.uz. Test with dig +short A random-name.example.uz.

Where it genuinely helps

Multi-tenant services are the classic case. A Tashkent startup running storefronts for small shops gives each one an address like shop-name.misol.uz. One wildcard record sends them all to the application, which picks the right shop by the Host header, so a new shop works the moment it signs up. Development previews such as feature-123.dev.example.uz are the other common case, best placed under a dedicated *.dev.example.uz rather than the main zone.

server {
    listen 443 ssl;
    server_name ~^(?<tenant>[a-z0-9-]+)\.misol\.uz$;
    location / {
        fastcgi_param TENANT $tenant;
    }
}

The risks

SEO first: if the wildcard points at your main site and the server returns the same page for any name, you create endless duplicates. Return 404 or a 301 redirect to the main domain for unknown subdomains. Trust is the second issue: any name such as login-bank.example.uz opens on your server, which helps phishing if the app reflects user input. Third, wildcards hide mistakes, because a mistyped api2.example.uz lands on the wrong server instead of failing. Fourth, wildcard MX invites spam to non-existent subdomains and wildcard TXT can confuse SPF checks, so keep wildcards away from mail records. A wildcard CNAME to an external service whose account is later closed lets someone else take over any subdomain.

Wildcard SSL certificates

A *.example.uz certificate covers one level only: shop.example.uz yes, a.b.example.uz and the apex no, so certificates usually include both names. Let's Encrypt issues wildcards only via the DNS-01 challenge with a _acme-challenge TXT record.

certbot certonly --manual --preferred-challenges dns \
  -d example.uz -d '*.example.uz'

Manual mode also means manual renewal, so in practice you use a DNS provider API plugin. Free Let's Encrypt certificates on sayt.uz hosting renew automatically; for a wildcard certificate, check the option in the cabinet or with support.

Rules for safe use

Scope wildcards narrowly, for example *.app.example.uz instead of *.example.uz.
Always add explicit records for important names such as www, mail and api.
Make the web server answer unknown names with 404 or a redirect.
Do not use wildcards for MX or TXT.

A wildcard is added in the DNS section of the sayt.uz cabinet by entering * as the record name. Afterwards, query a few random names with dig and confirm they reach the expected address and page.