atdomain
atdomain.at / Domain guides / Understanding DNS
Understanding DNS

Wildcard DNS for your .at domain: what the asterisk actually does

An asterisk in DNS does not create a finished website. Check wildcard records, existing subdomains and HTTPS before connecting your .at domain.

The essentials

A wildcard DNS record can supply answers for nonexistent names under specific conditions. It is not a blanket rule for every address. Existing names and the structure of the DNS zone affect the result. Website configuration, valid HTTPS and email remain separate tasks.

Blue globe with an asterisk symbol and fine paths to blank address cards
The asterisk represents a conditional DNS rule. It does not mean every existing address is overridden or a website is configured automatically.

1. Decide whether you actually need a wildcard

For a website using a main address and www, the specific records in its connection instructions are often enough. A wildcard becomes relevant when an application explicitly supports many changing subdomains and asks for a shared DNS rule. Ask the website service what the rule is intended to do before adding an asterisk. One conceptual use is an application with separate project addresses for several workspaces. That is a possible application design, not an additional feature of your domain account. If you need only three fixed addresses, write them down first. This keeps the intended connections understandable before choosing the mechanism.

Distinguish a subdomain from a registered domain

2. Understand the asterisk as a conditional DNS rule

The standards describe wildcards as sources for synthesised DNS answers. In a simplified example zone, *.projekt.example may supply an answer for a nonexistent name such as neu.projekt.example. projekt.example is a documentation example here. The rule does not replace projekt.example itself. Existing names, intervening nodes and delegations can affect selection. An existing name can prevent wildcard use even when it lacks the requested record type. Do not treat the asterisk as a global override. If the result differs from expectations, inspect the actual structure instead of adding more asterisks or assuming that every name below the domain must behave identically.

3. Record the names and services already in use

Before changing anything, make a short inventory: which addresses are already used, which values connect the website, and which belong to email or verification? Mark the records that must stay unchanged. You do not need to delete an existing subdomain just to make a wildcard test appear successful. For an Austrian association, the public website and a registration area might have different technical contacts. Review both responsibilities separately. If you no longer know what a record does, clarify it first. An asterisk is not a useful shortcut for an incomplete inventory or a substitute for agreeing the scope of a change.

Document your DNS records before making changesFind the DNS zone that is actually active
Two separate address cards with distinct paths to a server and an asterisk tile
Document explicitly configured names and their destinations. Check them independently of a new wildcard record.

4. Take the record type and destination from real instructions

With our default nameservers, manage DNS records in your account; custom nameservers are supported too. The host field in our DNS management accepts the relative name *. However, the asterisk alone determines neither the record type nor the correct destination. Whether A, AAAA or CNAME is required must follow the actual connection instructions. Do not enter an example IP address from this or another guide. With custom nameservers, edit the active zone there. Record the previous value and the time of your change so you can make a targeted correction if the selected service does not respond as intended. Change only what you have a reason to change.

Choose between an A record and a CNAME correctly

5. Check the website, HTTPS and email separately

A DNS answer does not create a website or redirect visitors to a particular page. The website service must handle the requested hostname. For HTTPS, the connection also needs a certificate valid for that hostname. A DNS wildcard and a wildcard certificate are different things with different matching rules; the same asterisk notation does not mean identical coverage. Ask explicitly about the hostnames you plan to use. An asterisk does not create email mailboxes or aliases either. atdomain.at does not currently sell hosting or mailboxes. Preserve existing mail settings when your task concerns only an additional website address, and check that working services still work afterwards.

Separate DNS from valid HTTPSTreat mailboxes and email aliases as separate setup tasks
Checklist beside a globe, browser model and certificate sheet on a white surface
The DNS answer, website hostname configuration and valid HTTPS need separate checks. A successful DNS test does not confirm the other steps.

6. Test a list of cases rather than one address

Write down the expected result for each address before testing. Afterwards, check the actual DNS answer and the browser request separately. A useful test sheet includes the main address, a name that already has explicit configuration, and a new name selected for the test under your own domain. Add a deeper address if your application actually needs it; do not infer its behaviour from a shorter name. Do not use other customers’ domains for experiments. If DNS answers correctly but the browser reports a problem, check website hostname configuration and the certificate. Repeated DNS edits will not complete those separate tasks or establish which layer was wrong.

  • Existing addresses still work as documented.
  • The planned new name reaches the service you actually intended.
  • HTTPS opens without a certificate warning.
  • Any required mail service still receives and sends messages.
Understand caches and when changes become visible

7. Plan the domain independently of the connection rule

A wildcard replaces neither domain registration nor renewal. At atdomain.at, a standard new .at domain currently costs €12.99 total price for the first year; renewal costs €15.99 total price per additional year. New standard .at domains also offer a three-year package for €39.00 total price, including registration and two annual renewals. This saves €5.97 against €44.97 through annual payments assuming today’s prices remain unchanged. Transfers and existing renewals are excluded. Afterwards, arrange renewal in good time at the price then offered; there is no automatic card charge. The prepaid-through date and the technical expiry advanced through annual renewals are separate details.

Search for a suitable .at domainCompare current total prices and terms

An idea needs an address.

Search .at domains ↗