In brief
Back up the zone and identify the actual name servers before editing. Check website, email and verification records separately.
Who actually manages DNS?
The domain registrar, name server operator, web host and email provider can be four separate organizations. Identify the active name servers first. If you edit a zone that is not served by those name servers, visitors’ DNS resolution will not change even if the control panel reports success.
Record the current DNS entries and the purpose of the change. For example, the website may move while mailboxes stay. Changing the website address does not automatically justify deleting email settings. A complete zone copy also makes later comparisons easier.
A, AAAA and CNAME
An A record specifies an IPv4 address; AAAA specifies IPv6. A CNAME aliases a name to another name, unlike an HTTP redirect in the browser. Root-domain handling may depend on the provider’s implementation, so follow your DNS provider’s rules.
If you updated the A record but left an old AAAA record, some visitors may reach the website by a different route. Check www and the root domain separately. Correct DNS is not enough: the SSL certificate and web server domain configuration must also be right.
| Rekord | Feladat | What should you check? |
|---|---|---|
| A / AAAA | IPv4 / IPv6 address | The correct server address |
| CNAME | A reference to another name | Correct target name |
| MX | Email routing | Email provider details |
| TXT | Text-based settings | Values specified by your provider |
MX and TXT: email takes a separate route
MX records identify receiving mail servers. TXT records may contain provider verifications and email authentication information. Your email provider supplies the exact values; do not copy them from another similarly named domain.
To troubleshoot, send a message from an independent external address to your mailbox, then reply. Check delivery errors and timestamps. Email from website forms needs a separate test: a mailbox receiving email does not prove that the application’s sending configuration is correct.
TTL and seemingly random errors
DNS responses are cached, so a change may not become visible everywhere at once. Lowering TTL in advance can help, but does not retroactively shorten the lifetime of previously cached responses. Repeatedly changing records also makes troubleshooting harder.
For each change, record the old and new values, exact time and resolver used to verify it. This helps distinguish zone errors from cached old responses. What appears in a browser alone is not a complete DNS diagnosis.
A safe change plan
Change only the necessary records in each update. Do not delete external service verification records simply because you do not recognize them. When changing name servers, copy the required entries into the new zone before pointing the domain to it.
Keep the completion checklist short: website on the root domain and www, HTTPS, incoming email, outgoing email and form notifications. Use two-factor authentication and least-privilege access for DNS management. An incorrect zone can interrupt business even if nobody changed the application code.
Example: www works, but the root domain does not
If www works but the root domain returns an error, first compare the records for both names. Do not start by reinstalling the application. The root domain may point elsewhere, the server configuration may be missing or the certificate may not cover that name. These are distinct problems that can be isolated.
During testing, record whether you see a DNS resolution error, connection failure, certificate error or HTTP response. Distinguishing these helps resolve the issue faster. Investigate browser redirects between the two names only after verifying DNS and HTTPS.
What should you give the system administrator?
A useful support ticket includes the exact domain or subdomain, expected provider, change time, affected record and error received. Do not send full password lists or email contents. Note if the problem occurs only on certain networks.
A DNS change log also helps when multiple teams manage a website. Assign an approver for name server changes and edits to critical records. A documented handover reduces the risk of deleting an old verification record and later disrupting an external service.
- Identify the active name server before changing any records.
- Back up the DNS zone and record when the change was made.
- Test the website and email separately.
