Choose a record for the exact owner name
Use the target type supplied by the web provider; an ordinary apex CNAME conflicts with records required at a zone root.
A and AAAA publish IPv4 and IPv6 addresses; CNAME aliases a name to another name. Match the record type to the web provider’s target. The zone apex, such as example.com, has required records; www.example.com is a separate owner name. This choice does not determine the target or DNS authority.
Use only a target supplied for the actual service. Addresses in examples are documentation placeholders, never Novasean infrastructure details.
Match the provider target to a valid record type
If the provider supplies an IPv4 address, an A record may be appropriate; if it supplies working IPv6, use AAAA for that address. An AAAA answer should not point to an untested service merely to “enable IPv6”. If the provider supplies a hostname and recommends an alias, a CNAME is normal for a non-apex hostname such as www, provided no other data exists at that exact owner name. Follow the target chain and verify it resolves.
Ordinary DNS rules do not allow a CNAME to coexist with other records at the same name. The zone apex normally needs SOA and NS records and may have MX or TXT, so an ordinary apex CNAME is incompatible there. Some DNS providers offer proprietary ALIAS/ANAME or CNAME flattening that answers A/AAAA publicly while following a hostname internally. Check that the current authoritative provider actually supports the feature and the destination provider accepts it.
Check records that must remain
Before editing, list every record at the exact name and its role, especially apex NS, MX, TXT, CAA and DNSSEC-related records. Do not delete mail or verification data to make room for an ordinary CNAME. A CNAME at www does not conflict with apex MX because they are different owner names, but a TXT verification record at www may conflict with a www CNAME. Ask the application or verification provider for a supported alternative location or method in that case.
At the authoritative panel, inspect its final FQDN preview. Entering www.example.com in a field that appends example.com can create a doubled name. Record the previous value and TTL for rollback.
Query the public answer and actual service
After the authorised change, query the actual authoritative server for A, AAAA and CNAME at the exact name, then compare recursive answers as cached TTLs expire. An apex flattening service may return A/AAAA without showing a public CNAME; verify its resolved target against provider documentation. Test the website over HTTPS with the intended Host name, its certificate, redirects and real application route. DNS success alone does not prove the destination serves the hostname.
For a provider-supplied www CNAME, expect a CNAME at that exact name and a working final target; a working apex A record does not verify www.
If the new answer points to the wrong place, restore the saved record and confirm directly at the authority. If the panel rejects an apex CNAME, use a supported address or alias strategy from the host and DNS provider; do not remove required apex records. Ask support with the exact owner name, supplied target and observed answer, without credentials.
Common questions
Can I always put a CNAME on the root? No. Ordinary apex CNAME conflicts with required zone data; provider-specific flattening or alias support varies.
Should I add A and CNAME for www? Not at the same owner name.
Does an AAAA record make IPv6 work? Only if the destination actually serves the site at that address.
Will an apex alias always appear as a public CNAME? No. Provider flattening can return A or AAAA answers; verify the resulting destination and site.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.