Most small websites do not need wildcard DNS. Separate records for the main domain and the few subdomains you actually use are usually easier to review. A wildcard can be useful when a supported application deliberately accepts many changing subdomains. Before buying a plan around that feature, confirm how the application handles unknown names, HTTPS and separate services such as email.
Before you begin
- List the exact hostnames your website or application needs.
- Ask whether the application supports wildcard hostnames and unknown visitors.
- Check HTTPS coverage separately from DNS resolution.
- Keep the main domain, email records and named exceptions in the plan.
- Record the previous settings and test before removing anything.
1. What the asterisk means in DNS
A wildcard DNS owner name begins with an asterisk label, such as *.example.co.uk. Under DNS matching rules it can supply an answer for a name that does not already exist. It is a fallback mechanism, not a command to overwrite every existing record. The exact result depends on the existing name tree and the record type requested.
The root of your registered domain, example.co.uk in this fictional example, needs its own configuration. Do not assume that a wildcard covers it. Nested subdomains also need careful testing: DNS wildcard matching is not simply the rule that one star always equals one level. Existing names and delegations can change which fallback applies.
2. Choose explicit names for a small, predictable website
Start with a short inventory: the main website, www, a shop and perhaps a booking service. Ask each service for the records it needs and add those specific names. This makes later checks easier because each entry has a known purpose and a person responsible for it.
A wildcard becomes worth discussing when a supported application creates changing customer or project addresses. Ask the developer why explicit records would be impractical, what happens to a mistyped address and how unused names are rejected. Do not buy an elaborate hosting plan because a wildcard sounds like a standard requirement for every .co.uk website.
3. Work through a fallback and an exception
Imagine a fictional demonstration service using example.co.uk. Its application is designed to accept changing project names, while shop.example.co.uk uses a separate shop platform. The developer proposes a wildcard for the projects and an explicit record for shop. This is a planning example, not a set of live records to copy.
An existing name is considered before wildcard synthesis. Even a name containing another record type can prevent the fallback you expected. Keep the exception list and check real answers rather than assuming that adding one wildcard finishes the work.
Swipe sideways to compare the hostname checks.
| Name | Intended behaviour | Check |
|---|---|---|
| example.co.uk | Main website | Separate root-domain setup |
| project-name.example.co.uk | Supported project application | Fallback, application routing and HTTPS |
| shop.example.co.uk | Separate shop platform | Explicit record and correct shop response |
| mistyped-name.example.co.uk | Deliberate unknown-name response | No accidental customer page |
4. Treat HTTPS certificates as a separate requirement
DNS resolution does not issue a certificate or configure a web server. A browser still needs the service to present a valid certificate for the hostname requested. Ask the host which names it accepts, how certificates are obtained and renewed, and whether any plan limits apply before sending visitors to the new addresses.
Certificate wildcard matching differs from DNS wildcard matching. Under the TLS identity rules, *.example.co.uk can match a single label such as shop.example.co.uk, but it does not by itself cover example.co.uk or a.b.example.co.uk. A certificate can include additional names; confirm the actual coverage rather than guessing from one wildcard entry.
Sources: IETF RFC 9525: TLS service identity and wildcard matching ↗
5. Keep mailbox rules and website routing separate
A wildcard website record does not create an email inbox or decide which messages your mail service accepts. Keep the provider’s required mail-routing and authentication records. If the goal is to receive messages sent to unlisted addresses, ask the email host about a catch-all policy rather than treating a website wildcard as the solution.
Before a change, save the current DNS entries and note which service uses each one. In NameUK, manage a domain’s records from its domain page when its DNS is hosted with us. If it uses an external DNS service, make the record change there. Registering with NameUK does not make an unrelated DNS dashboard authoritative.
6. Agree a test and rollback checklist
Write down the intended result for the main website, one new application address, a named exception and a deliberately unknown name. Test each through DNS and then through the browser. Include HTTPS, the expected page and any sign-in or project boundary. A DNS answer alone does not demonstrate that the application routes visitors correctly.
Keep normal sending and receiving email in the checklist too. Record the earlier values and the time of the change so the administrator can restore the specific entry if needed. Cached answers can remain until their applicable lifetime ends; repeated unrelated changes make diagnosis harder. Ask for help with a clear list of expected and actual results.
7. Compare domain renewal and application charges separately
Register .co.uk for £9.99 for one year, with annual renewal currently £9.99. Or choose a new three-year .co.uk registration for £25.99. Check the selected name and term before payment. Future renewal prices can change.
Your domain registration and renewal cover the registered name for its paid term. They do not automatically include an application, unlimited customer sites or wildcard certificates. Ask the hosting service about custom-hostname support and recurring charges. For an ordinary brochure website, explicit DNS entries and a suitable basic hosting service may already meet the requirement.
NameUK’s current registration and annual renewal amounts are shown together here. Our own recommendation is for buyers who value standalone registration, visible renewal pricing and dashboard DNS controls while choosing their website service independently. The initial three-year registration offer is not a hosting bundle or a permanent promise about later prices.
NameUK’s own guidance, reviewed 26 October 2026. All example names and routing plans in this guide are fictional. Obtain the actual record values and hostname requirements from your hosting service.
Further readingIETF RFC 4592: the role of wildcards in DNS ↗IETF RFC 9525: TLS service identity and wildcard matching ↗IETF RFC 1034: DNS records, queries and caching ↗Extension rules and provider processes can change. Check the current registrar instructions before a registration, transfer or renewal.
Low-cost registration. Affordable UK renewals.
Register .co.uk for £9.99 for one year, with annual renewal currently £9.99. Or choose a new three-year .co.uk registration for £25.99. Check the selected name and term before payment. Future renewal prices can change.