Wildcard DNS

Wildcard DNS is a configuration that allows a wildcard record, typically using an asterisk as the label, to provide a response for certain undefined names within a zone. A wildcard such as *.example.it can be used to respond to requests for arbitrary subdomains, directing them to a service or page. It does not automatically create separate records for each hostname, and its behavior depends on DNS rules regarding name and intermediate node existence. It is not a wildcard that replaces every part of the full domain name.

How it applies

The wildcard operates within the zone and name where it is configured. It can be an A, AAAA, CNAME, or another accepted record type, with its value determined by the service. Queries for names without a specific record may receive the wildcard response, while explicit records usually take precedence for exact matches. The presence of intermediate nodes or other data in the zone can alter expected behavior; thus, it should not be assumed that an asterisk covers every hostname at any depth.

A common use case is a multi-tenant platform assigning a subdomain to each client, such as customer.example.it. The wildcard routes requests to the application, which must then validate the hostname, tenant, and authorization before displaying content. If the app accepts any name without checks, an attacker could claim subdomains, impersonate tenants, or misuse the service for phishing. DNS directs the request to the server, but application logic determines what content to serve.

Wildcard and security

A wildcard DNS does not equate to a TLS wildcard certificate, even though both use the asterisk in different contexts. The certificate covers specific hostnames according to X.509 rules and does not perform DNS resolution. A wildcard DNS does not guarantee that the server holds a valid certificate for the name. Browsers and applications must verify both levels. Domain cookies and CORS policies also require careful configuration, as an arbitrary subdomain could become part of the attack surface.

A wildcard record can resolve random names and increase traffic, noisy logs, and scanning risks. It may also obscure errors: a misspelled subdomain might show a generic page instead of a clear NXDOMAIN error. The owner must ensure the response is appropriate and does not expose internal information or default server details. If a service is deprecated, the wildcard should be removed or updated to prevent continued redirection to uncontrolled infrastructure.

Configuration and verification

The zone should document the purpose, responsible party, and target of the wildcard. Valid, non-existent, deep, and already defined hostnames should be tested by querying the authoritative nameserver and checking web behavior. Caches may retain previous responses after changes. Verification must include certificates, application routing, tenant isolation, logs, and DNS monitoring. A wildcard is powerful but increases the number of hosts pointing to a service, so it should be paired with server-side validation.

In summary, Wildcard DNS provides responses for names not explicitly defined, within zone rules. It is useful for dynamic services and multi-tenant environments, but does not replace application controls or certificates and can expand the attack surface if used without governance.