DNS performance and resilience are now eCommerce identity issues

At a glance

What this is: This is a DigiCert blog post arguing that DNS performance and outage resilience are material to eCommerce availability and customer experience.

Why it matters: It matters because IAM and security teams that govern digital access paths need to treat DNS as part of operational trust, availability, and business continuity for customer-facing services.

By the numbers:

• The forecast for eCommerce sales grows from 2020's $4.28 trillion mark to over $6 trillion by 2024.
• The average cost of downtime is $5,600 per minute for the average company.

Context

DNS performance is the speed and reliability of the lookup path that turns a domain name into a reachable service. For eCommerce, that lookup is part of the customer access experience, so latency, redundancy, and outage recovery affect whether a shopper reaches the storefront at all.

The governance gap is that many teams still treat DNS as a network utility rather than an operational trust layer. In practice, the same availability discipline that applies to identity, access, and service continuity also applies to the DNS path that resolves customer sessions and transaction traffic.

Key questions

Q: How should eCommerce teams reduce the risk of DNS outages affecting customer access?

A: Treat DNS as a first-hop availability dependency, not a background utility. Use secondary DNS, verify synchronized zone data, and test failover so the domain still resolves when the primary provider or region fails. For customer-facing stores, the goal is to preserve reachability before the application stack even comes into play.

Q: Why does DNS provider latency matter for eCommerce performance?

A: Because every visit starts with a lookup, authoritative DNS speed affects how quickly a browser reaches the site. Even small delays add friction at the first access step and can translate into abandoned sessions, especially during high-volume shopping periods. Low latency only helps if the provider is also operationally reliable.

Q: What breaks when an organisation has only one DNS provider?

A: A single DNS provider creates a shared failure point for websites, APIs, authentication services, and internal resolution. If that provider has an outage or configuration issue, the organisation may lose access to critical systems at once. Secondary providers and failover testing reduce that exposure, but only if they are kept current.

Q: What should teams look at when comparing DNS providers for eCommerce?

A: Compare more than average query time. Review outage history, regional resilience, zone synchronization behaviour, and whether the provider can support failover in the geographies where customers actually shop. A provider that is fast on paper but brittle during incidents can create a larger business risk.

Technical breakdown

Why DNS lookup latency affects eCommerce access

Every browser session begins with a DNS query, which means name resolution sits on the critical path before the storefront can even load. An authoritative nameserver returns the final answer for a domain, so its speed and reliability directly influence how quickly a user reaches the site. When that answer is slow, the delay compounds across each request chain and becomes visible as checkout friction, abandoned sessions, or failed page loads. The operational point is not that DNS is the only performance variable, but that it is an upstream dependency whose delay is experienced as access delay by the customer.

Practical implication: measure DNS resolution time as part of customer-facing access performance, not as a background network metric.

How secondary DNS and failover preserve availability

Secondary DNS creates a second authoritative provider, which gives the domain another path to answer queries if the primary provider fails. Failover extends that idea by rerouting traffic to a backup resource when a primary host or IP becomes unavailable. These controls do not make outages impossible, but they narrow the blast radius by giving the domain alternate resolution and delivery paths. For eCommerce, the core architectural point is that redundancy has to exist at the DNS layer as well as in the application stack, otherwise the storefront can remain unreachable even when backend systems are healthy.

Practical implication: design DNS redundancy as a first-class availability control, with tested failover paths and synchronized zone data.

Why outage history belongs in provider selection

The article’s outage examples show that DNS providers can fail regionally or globally, and that past uptime patterns are a meaningful signal when choosing an authoritative service. Outage history matters because DNS is not just a routing convenience, it is the mechanism that determines whether users can find the domain at all. The governance challenge is that a provider with acceptable average speed can still create unacceptable business risk if its failure profile is poor. For eCommerce, provider evaluation must consider both latency and resilience over time, not one metric in isolation.

Practical implication: include outage history and regional resilience in DNS provider reviews alongside latency and geographic fit.

Threat narrative

Attacker objective: The practical objective is to deny availability at the first access step and disrupt customer traffic before a transaction can begin.

1. Entry occurs when a shopper or automated client initiates a DNS lookup to reach the eCommerce domain.
2. Escalation occurs when slow resolution or a provider outage interrupts name resolution and prevents the site from being reached.
3. Impact occurs when the storefront becomes unavailable, which can turn into abandoned sessions, revenue loss, and customer trust damage.

Breaches seen in the wild

• GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

DNS is an identity-adjacent availability control, not just a hosting detail. eCommerce users encounter the DNS lookup before they encounter the application, so the trust path begins with resolution, not login. That makes DNS resilience part of the operational identity perimeter for customer access. Practitioners should treat name resolution as a governed service dependency, not an invisible utility.

Provider selection must weigh failure history as heavily as average latency. The article shows that query speed matters, but the governance mistake is to optimise only for best-case response times. A fast resolver with poor outage history can create a worse business outcome than a slightly slower but more resilient one. The implication is that availability risk belongs in the provider selection model from the start.

Redundancy at the DNS layer changes the blast radius of an outage. Secondary DNS and failover do not eliminate downtime risk, but they reduce the chance that one provider failure becomes total storefront inaccessibility. That is why DNS resilience should be part of continuity planning alongside application failover and regional architecture. Practitioners should validate that redundancy exists where customer access actually begins.

DNS performance is a customer experience control with financial consequences. The article links slow or failed resolution to lost visits, and the broader point is that trust in digital commerce is operationally enforced by response time and uptime. When users abandon a site in seconds, a DNS delay becomes a business event, not a technical inconvenience. Security and IAM leaders should fold DNS into service assurance discussions.

Identity programmes should care about DNS because access governance includes reachability. A customer identity flow cannot complete if the domain cannot be resolved, which means access control and availability control meet at the name service layer. That overlap is where programme boundaries often fail: identity teams own trust decisions, while infrastructure teams own resolution, but the user experiences one path. Practitioners should align those ownership lines before incidents force the issue.

What this signals

DNS resilience belongs in the same governance conversation as service availability. For eCommerce, the first user experience question is whether the domain resolves reliably under load and during provider failure. That means security and platform teams should treat authoritative DNS as a continuity control, not a peripheral network choice.

Resolution latency is a practical trust signal. When customers wait for name resolution, they experience the delay as site slowness, even if the application itself is healthy. The programme implication is to watch DNS as an upstream dependency that can silently erode conversion, not just uptime.

Redundancy has to be tested, not assumed. Secondary DNS and failover only reduce risk if synchronized zones and fallback behaviour are validated in advance. Teams that do not rehearse the failure path often discover that their recovery design exists only on paper.

For practitioners

• Map DNS into customer access risk Add DNS lookup latency and availability to the same service assurance view you use for customer login and checkout paths. This makes the dependency visible when teams review user-facing failures.
• Require redundancy at the authoritative layer Ensure every critical eCommerce domain has secondary DNS and a tested failover path so one provider outage does not become a full storefront outage.
• Review provider outage history before selection Use documented outage history, not just average response time, when comparing authoritative DNS providers for high-volume retail traffic.
• Validate zone synchronisation and failover behaviour Confirm that primary and secondary zones stay synchronized and that failover actually answers queries the way your continuity plan assumes.

Key takeaways

• DNS performance and resilience affect whether an eCommerce store is reachable at all, so the issue belongs in operational trust and continuity planning.
• The article ties slow resolution, outage history, and redundant authoritative services to business impact, not just infrastructure preference.
• Teams should evaluate authoritative DNS providers for latency, redundancy, and outage behaviour together, then test failover before an incident forces the issue.

Key terms

• Authoritative nameserver: An authoritative nameserver holds the official DNS records for a domain and answers queries with trusted zone data. In a redundant setup, multiple authoritative nameservers can serve the same records, which improves resilience when one provider or location becomes unavailable.
• Secondary DNS: A secondary DNS setup uses a second authoritative provider for the same domain so queries can still be answered if the primary service fails. It improves availability by reducing dependence on a single provider, but it still requires accurate zone synchronisation and change control.
• DNS failover: DNS failover is the practice of switching resolution to an alternate path when the primary DNS service becomes unavailable. It reduces outage duration by predefining the backup route, but it only works when the alternate provider, records, and monitoring are tested and kept current.
• Resolution Latency: Resolution latency is the time between a vulnerability being identified and a safe fix being merged into production code. It is a useful governance metric because it captures how long exposure remains active after discovery, which is often more important than the scanner that found it.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.