Which nameservers are active? Check your .at domain

1. Start with the correct domain

Write down the exact domain you want to investigate. In an address such as shop.example.at, shop is a subdomain; begin the check of the registered main domain with example.at. Remove https://, the path and any query parameters from your working note. Record separately which address fails: the main website, www, a shop or email. This avoids comparing different names without noticing. The addresses in this guide are placeholders, not configuration instructions. You do not need to delete records or change nameservers to take an inventory. Leave the existing settings in place while you gather evidence about the current setup.

2. Obtain the public nameserver assignment

For a .at domain, use the official nic.at Whois lookup. It provides technical information about a delegated domain, including its nameservers. Copy the complete server names into your notes and record the date and time. An A-record lookup answers a different question: it gives an IPv4 destination for a particular name. It is not a full nameserver list. If you use a DNS query with type NS, also note the tool or resolver used. Treat an empty response or an error as an unresolved check. It does not automatically mean the domain is available or that you need to buy it again.

3. Compare the result with your account

Open the affected domain and its nameserver settings in your atdomain.at account. Compare each saved hostname with the public lookup; the order of otherwise identical names does not matter. Some displays include a final dot. With our default nameservers, you manage the corresponding DNS records in your account. With custom nameservers, the active DNS zone is managed at their associated service. Saving a missing change in a different, unused zone will not make it effective there. If an agency manages the setup, ask it to identify the exact relationship between the domain, the nameservers and the management access.

4. Separate assignment from DNS answers

Delegation points towards the nameservers responsible for a zone. An authoritative server holds that zone’s authoritative data; a recursive resolver obtains answers for its users and may cache them. Check three things separately: public delegation, the responsible server’s answer and the result through your usual resolver. A direct answer from a new server does not by itself prove that the parent delegation already points to it. For a more technical investigation, ask support to check those three results separately. Avoid treating one successful lookup as evidence that the entire change has finished.

5. Check the specific record in the active zone

For a website issue, record the complete hostname and the record type required by the website service. For email, investigate receiving and sending separately. Compare the saved values with the current instructions for each service. Do not replace a real destination with an example copied from a guide. During a technical cross-check, have the same question sent to every assigned authoritative server. Different answers deserve investigation rather than random changes to more records. An existing record also does not establish that the web or mail service behind it is configured. Keep the required service connection and the DNS evidence together in your notes.

6. Record timing and the exact failure

If a change is in progress, record both the previous and the intended setup. Resolvers can still use cached answers. TTL helps explain timing but does not promise that every network switches simultaneously; some resolvers can continue serving older data when fresh authoritative answers are unavailable. Compare the same name and record type at documented times. Switching your phone between networks gives another viewpoint, but does not replace a delegation check. Repeated nameserver changes make the cause harder to follow. DNSSEC also deserves a separate investigation when results conflict; do not remove security data simply to see whether something changes.

7. Give support a focused check record

A useful ticket describes the discrepancy clearly enough for someone to reproduce the check. Include only the necessary data and redact private details from screenshots. Passwords, API keys and transfer codes do not belong in this record. Explain whether anything changed since the last working connection and who made that change. Ask which layer is affected before saving further settings. If a switch is actually needed, first back up the active zone and plan separate website and email tests. This investigation is an inventory of the current setup and does not itself change your services.

• Give the domain and the affected hostname.
• Compare complete public and account nameserver lists.
• Include time, query type and the exact error message.
• Describe the intended state and the last known change.

A new .at domain with clear management

If you are planning another Austrian address, decide who will manage its technical setup before purchasing it. A standard new .at domain at atdomain.at currently costs €12.99 total price for the first year; annual renewal costs €15.99 total price. DNS management with our default nameservers and custom nameservers are supported. Plan hosting and email mailboxes separately. Keep the relationship between the domain and the services actually used alongside your domain records. That gives the next investigation a clear starting point, rather than leaving you to discover which of several visible record lists is responsible.