Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchYou can support both example.com and www.example.com without requiring every customer to use the same DNS provider or routing feature. Treat the two hostnames as separate DNS inputs: www can commonly point to your service with a CNAME, while the zone apex needs a provider-supported alternative, such as CNAME flattening, ALIAS/ANAME, a provider-specific alias, or host-documented address records. Your application can then decide which hostname is canonical and redirect the other over HTTP.
Why the apex and www need different DNS treatment
The apex, also called the zone root, is the bare domain name, such as example.com. www.example.com is a subdomain. A standard DNS CNAME makes one name an alias for another DNS name, but it cannot occupy the zone apex: the apex must also carry the zone’s authoritative records. AWS documents both the apex restriction and that a CNAME owner name cannot also contain other record types. AWS: Supported DNS record types
This means a CNAME at www is often straightforward, but the same instruction cannot simply be copied to example.com. At www, do not try to combine a CNAME with TXT, A, or other records at that exact name; place any needed verification record at the hostname specified by the verifier or use another supported verification method.
How to point an apex domain and www to a site
For a customer-domain product, ask for the hostname or hostnames the customer wants to serve, then provide record instructions that match the customer’s authoritative DNS provider and your hosting platform. The customer does not necessarily need to change DNS providers or nameservers: that depends on whether their provider supports a compatible apex mechanism and on your platform’s requirements.
#1 Best Overall
- Choose the hostnames. Identify whether the customer needs the apex,
www, or both, and which hostname the site should treat as canonical. - Set up
www. If your hosting platform instructs customers to use a CNAME, have them create it atwwwpointing to the exact hostname the platform specifies. - Set up the apex separately. Use the exact method your host documents and the DNS provider supports: an apex-flattened CNAME, ALIAS/ANAME-style record, a provider-specific alias, or documented A/AAAA records.
- Complete domain verification. Add any verification records at the exact names and with the exact values requested by the host. Check whether the DNS provider’s flattening or proxy settings affect the verification method.
- Configure the site behavior. Ensure the application or hosting platform accepts the requested hostnames and, if desired, redirects one to the canonical hostname. DNS does not perform that HTTP redirect.
For example, Netlify’s external-DNS instructions describe apex options that depend on provider support and an A-record fallback when alias-like support is unavailable; its domain setup also gives separate apex and www destinations. These are Netlify-specific instructions, not values to copy for another host. Netlify: Configure external DNS for a custom domain · Netlify: Get started with domains
Can you use a CNAME at the root domain?
Not as an ordinary DNS CNAME under standard DNS behavior. Some DNS providers offer features with names such as CNAME flattening, ALIAS, or ANAME that make an apex hostname resolve toward another hostname while returning address answers to DNS clients. These are provider features or conventions, not interchangeable standard record types. Availability, settings, and response behavior vary, so follow the provider’s documentation rather than assuming a record name means the same thing everywhere.
CNAME flattening
With flattening, the provider resolves the CNAME target and returns its address records instead of exposing the CNAME answer directly. Cloudflare describes this as: “With CNAME flattening, Cloudflare finds the IP address that a CNAME points to.” Its documentation says apex flattening is enabled by default for Cloudflare zones; other flattening options have their own configuration and plan details. Cloudflare: CNAME flattening · Cloudflare: Set up CNAME flattening
ALIAS and ANAME-style records
Some DNS providers use names such as ALIAS or ANAME for apex-to-hostname behavior. These labels do not guarantee identical implementation, support, or answers across providers. Confirm that the customer’s provider supports the record at the apex and that your host accepts the resulting resolution.
Route 53 alias records
Amazon Route 53’s alias is an AWS-specific feature, not a portable synonym for every provider’s ALIAS record. It supports particular AWS resources and other documented targets, with constraints that depend on the target and record configuration. Review the supported targets before designing customer instructions around it. AWS: Supported DNS record types · AWS: Choosing between alias and non-alias records
Compare the apex options before documenting customer setup
| Method | Apex support and DNS answer | Provider or target constraints | Customer and maintenance implications |
|---|---|---|---|
| Standard CNAME | Not valid at the zone apex under standard DNS behavior; commonly used for a subdomain such as www. The DNS answer exposes the CNAME. |
The owner name cannot also hold other record types. AWS documents this restriction. AWS: Supported DNS record types | Often usable for www without changing authoritative DNS provider, if the host specifies a CNAME target. |
| CNAME flattening | Can support the apex by resolving the target and returning address records rather than the target CNAME. Cloudflare documents this behavior. Cloudflare: CNAME flattening | Provider-specific; behavior and configuration are not universal. Cloudflare warns a flattened CNAME used for third-party verification may leave the raw CNAME unavailable to the verifier. A dangling target with no A/AAAA records can produce NODATA. Cloudflare: CNAME flattening | May let customers keep their authoritative provider if its feature meets the host’s requirements. Confirm verification and proxy settings with that provider. |
| ALIAS/ANAME-style record | May support an apex-to-hostname configuration; the exact answer behavior depends on the provider. | Names and implementation vary by DNS provider; confirm apex support and expected resolution with both provider and host. Netlify lists alias-like options among its external-DNS approaches. Netlify: Configure external DNS for a custom domain | Can avoid a standard apex CNAME restriction without necessarily changing nameservers, but availability is provider-dependent. |
| Route 53 alias | Supports alias records for the zone apex and other eligible names, using AWS’s alias mechanism rather than an ordinary CNAME answer. | Only documented target types and configurations are supported; do not assume any arbitrary hostname works. AWS: Choosing between alias and non-alias records | Requires using Route 53 for the relevant DNS zone if relying on this feature; it is not a generic record type available at every provider. |
| Host-documented A/AAAA records | Can point the apex at specified IPv4 and/or IPv6 addresses rather than another hostname. | Use only addresses the host explicitly publishes for this purpose. The Netlify guidance documents an A-record fallback in contexts where the DNS provider lacks alias-like support; it is not a universal value or guarantee of an AAAA record. Netlify: Configure external DNS for a custom domain | The DNS configuration is tied to the published addresses. If the host changes them, the customer may need to update records; use the platform’s maintenance instructions. |
These options do not establish a universal DNSSEC comparison: consult the DNS provider and hosting platform for their specific requirements. Likewise, a flattened response can differ from a directly exposed CNAME, so verification systems and diagnostics may observe different records.
Keep DNS routing separate from canonical-host redirects
DNS answers help a client locate a service for a hostname; they do not tell a browser to change from example.com to www.example.com, or the reverse. The web server or application handles that choice after the HTTP request reaches it. Configure each hostname at DNS level as needed, ensure the hosting platform recognizes both names, and configure the desired canonical redirect in the application or platform. Do not assume that pointing both names to the same service automatically enables both hostnames or creates a redirect.
Checks for a reliable customer-domain setup
- Authoritative provider: Verify which DNS provider serves the zone. Records entered at a registrar’s interface do not help if another provider’s nameservers are authoritative.
- Exact record name and target: Distinguish the apex from
wwwand use only the hostname or address the hosting platform currently specifies. - Address families: Add AAAA only when the host documents IPv6 addresses or the selected provider feature supplies IPv6 answers as expected; do not assume an A record covers IPv6.
- Proxying: If the DNS provider offers proxying, check whether the host supports it for custom domains and verification. DNS proxy behavior is separate from the record type itself.
- Verification visibility: If a host or third-party service asks to see a CNAME, check whether flattening hides the raw CNAME answer and use the verification method the service supports.
- Target resolution: Ensure the configured target remains valid and resolves as the provider expects; Cloudflare documents NODATA for a flattened record whose target is dangling and has no address records. Cloudflare: CNAME flattening
- DNSSEC and provider requirements: Follow the specific instructions from the authoritative DNS provider and hosting platform; no single DNSSEC rule applies to all the mechanisms above.
- Canonical behavior: Test both hostnames over HTTPS and confirm that the intended hostname serves the site while the other redirects only if that is the configured application behavior.
How to avoid coupling your product to one DNS pattern
Design the customer setup flow around the outcome—serving the apex, www, or both—rather than requiring a single record type. Publish a default path and a clear alternative for providers without apex aliasing. For each supported path, state the exact record name, type, target, verification steps, proxy expectations, and whether nameserver changes are required. Keep the service-specific target and any fixed addresses in the host’s current documentation so customers are not left relying on generic or stale values.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitches
