Wildcard DNS

Wildcard DNS is a single DNS record that answers for hostnames you have not created one by one. You add something like *.example.com as an A record, and names such as app.example.com or demo.example.com resolve to that same address. It is a DNS setting only. It is not a wildcard SSL certificate, and AutoSSL will not automatically cover every random name that hits the record.

What a wildcard DNS record matches

A wildcard covers one label to the left of the domain you attach it to. So *.example.com matches foo.example.com, but it does not match foo.bar.example.com. It also does not match the bare apex name example.com. More specific records always win. If mail.example.com already has its own A or MX record, that explicit record is used instead of the wildcard. The order of rows in the DNS panel is not what decides priority. Exact matches take precedence over the star.

If you only need the apex and www, you do not need a wildcard. Create those names explicitly. The usual reason to use a star is a multi-tenant app that mints many customer subdomains under a fixed pattern. Even then, plan the naming carefully so typos do not land on the wrong site.

How this affects certificates, vhosts, and cookies

On shared hosting you use cPanel with LiteSpeed and CloudLinux LVE, and you do not have root. If a LiteSpeed vhost is the default for that IP, every name the wildcard catches can be served by that default site. That can include paths such as wp-login.php on a hostname you never meant to publish. Cookie domains set to .example.com can then share sessions across those unexpected names.

AutoSSL and Let’s Encrypt on cPanel issue certificates per hostname they can prove. They do not watch your wildcard and mint a cert for every random label that appears in the logs. WP Toolkit on WordPress accounts does not change that behavior. Be explicit with hostnames unless you truly need a multi-tenant map.

If you do need the star, put it on a dedicated tree such as *.cust.example.com rather than on the main customer-facing names. Keep mail, www, and ftp as explicit records so a later wildcard cannot override them by surprise.

Mail names and related records

Mail is a common casualty of a broad wildcard. An A record for *.example.com with no explicit MX on a name you thought pointed elsewhere can send traffic the wrong way. Keep mail-related names explicit. Reverse DNS is a different record type entirely. If the next question is PTR versus a wildcard A, see rDNS and PTR.

When your domain uses our nameservers ns1.logicweb.com and ns2.logicweb.com, you can manage these records in the DNS tools for that domain. Add only the wildcard you actually need, then test a few known and unknown hostnames before you rely on the change in production.