DNS records answer different questions. A and AAAA map names to IP addresses, CNAME aliases a name, MX identifies mail exchangers, TXT carries text data, and PTR serves reverse lookups. Editing one type does not automatically update the others.
Match the record to the job
| Type | Purpose | Example intent |
|---|---|---|
| A | IPv4 address | Point a web hostname at an IPv4 server |
| AAAA | IPv6 address | Publish a working IPv6 web endpoint |
| CNAME | Alias to another name | Send www to a canonical service hostname |
| MX | Mail exchanger with preference | Direct incoming domain email |
| TXT | Text strings | Publish service-verification or email-policy data |
| PTR | Reverse name mapping | Give an IP address a reverse-DNS hostname |
DNS does not encode a website's URL path or ordinarily choose its TCP port. An A record value should be an address, not https://host/path. Specialized service records exist, but web browsers do not turn an arbitrary TXT value into a web redirect.
Plan a simple website change
Suppose you move a site to a new server. Update the hostname's A record and, if the new host supports IPv6, its AAAA record. Verify both paths before publishing them. Leaving AAAA pointed at the old host can produce failures for visitors who prefer IPv6 even when IPv4 tests look correct.
A CNAME points to another hostname, not an IP address. Conventional CNAME records cannot coexist with other record data at the same name. Provider-specific ALIAS or flattening features may support an apex arrangement; inspect that provider's documentation rather than treating those features as ordinary CNAME behavior.
Inspect records with nslookup
nslookup -type=A example.com
nslookup -type=AAAA example.com
nslookup -type=MX example.com
nslookup -type=TXT example.comCompare the resolver shown in the output with the one you intended to use. An internal corporate resolver may deliberately provide different answers than a public resolver. DNS answers are also time-sensitive: caches can retain older records until their remaining TTL expires.
Avoid common publishing errors
- Confirm you are editing the authoritative DNS provider, not an unused zone at a former registrar.
- Check whether its input field automatically appends the domain to hostnames.
- Keep email records intact during a website move unless email is also moving.
- Test the service itself after checking the DNS answer.
For reverse DNS, the address owner or hosting provider normally controls the reverse zone. Adding a PTR record to your ordinary forward zone is not enough. For email, MX correctness is only one requirement; authentication policies and server behavior need their own checks.
Put it into practice
References & further reading
Protocol standards and official documentation supporting this guide. Device menus and provider policies vary; use the documentation for your equipment when applying a change.