DNS for ecommerce
A store that cannot resolve cannot check out.
Campaign traffic hits DNS first. If authority is slow or an origin IP stays published after a failure, paid traffic never reaches the storefront or CDN.
Host the shop zone on Cloud DNS. Point the storefront at Cloud CDN with flattening. Health-check origin or regional failovers. Keep TTLs low on records you might move during a sale.
Why teams use Aptranet
What DNS for ecommerce looks like on this network.
Cloud DNS answers on 210+ Anycast servers, with GeoDNS, health checks and a one-second minimum TTL for change.
Authority that survives a sale
210+ Anycast servers and DDoS-protected DNS sit in front of the shop name.
Regional storefronts when you have them
GeoDNS can send resolvers to a nearby shop or CDN hostname.
Failover during incidents
Health checks stop advertising a dead checkout origin.
How to set it up
A cutover you can validate before DNS moves.
Create the Cloud DNS configuration, prove it on an Aptranet hostname, then point production DNS when the path looks correct.
- 1Move the shop zone to Cloud DNS
Preserve MX, SPF and verification records.
- 2Point the storefront at Cloud CDN
Flatten the apex if the shop is on the root domain.
- 3Health-check anything you might fail over
Payment-adjacent origins need a rehearsed DNS path.
- 4Lower TTLs before peak events
Do it days ahead of the campaign, not during it.
Outcomes
What changes once the hostname is on Aptranet.
- Shop DNS is Anycast and DDoS-protected
- Storefront names can follow Cloud CDN
- Dead origins can leave the answer set
- Campaign cutovers are not stuck on TTL
Keep reading
Related pages
More DNS use cases on the same Cloud DNS footprint.
Frequently Asked Questions
Often yes for PCI and cache policy. Both names can live in the same Cloud DNS zone.
Yes. MX and related TXT records stay in the zone when you move NS.
Yes. DNS still has to resolve. Flattening and low TTLs are how you point the shop at Cloud CDN.
Use GeoDNS or separate hostnames per market. Health checks still apply.