How DNS works
When a browser is sent to shop.example.com it first checks its own cache, then asks the local DNS resolver — usually the provider’s, or a public one such as 8.8.8.8. If the answer is not cached, the query climbs the DNS hierarchy up to the domain’s authoritative server.
The whole process, a DNS lookup, normally takes 1–50 ms on a cache miss. Once the answer arrives the browser caches it for the length of the TTL and opens a TCP connection to the returned IP.
The main record types
| Record | What it does | An e-commerce example |
|---|---|---|
| A | Domain to an IPv4 address | shop.example.com → 185.10.1.1 |
| AAAA | Domain to an IPv6 address | shop.example.com → 2606:4700::1 |
| CNAME | An alias for another domain | cdn.shop.example.com → edge.cloudflare.com |
| MX | Mail servers | Receiving mail addressed to the domain |
| TXT | Arbitrary text | Domain verification, SPF, DKIM |
| NS | Name servers | Who is authoritative for the zone |
DNS in e-commerce: the usual scenarios
Connecting a CDN. You create a CNAME from cdn.shop.example.com to the CDN provider’s edge address. Static assets — images, JS, CSS — are then served from the node nearest the visitor.
A certificate through the DNS challenge. Let’s Encrypt and most certificate authorities can verify domain ownership through a TXT record. For wildcard certificates the DNS challenge is the only route.
A subdomain for first-party tracking. Analytics and personalization platforms recommend using a subdomain, for example metrics.shop.example.com, so that tracking files are set as first-party cookies. That extends cookie lifetime in Safari and other browsers running ITP.
Failover. If the primary server fails, the DNS record switches to a standby IP. How fast the switch takes effect is bounded by the TTL on the active record.
Important: before any planned DNS change — a server move, a change of CDN — lower the record’s TTL to 60–300 seconds 24 to 48 hours ahead. That guarantees fast propagation and minimal downtime during the cut-over.