Azure's 2021 DNS Cache Defect Made Retry Amplification

Summary

Between 21:21 UTC and 22:00 UTC on 1 April 2021, Azure DNS experienced a service availability issue. Microsoft said the majority of dependent services had recovered by 22:30 UTC. Its contemporaneous community notice used an approximate 21:30 to 22:30 impact window, while independent monitoring reported an alarm around 21:20. These are different observations, not necessarily contradictory clocks. [1][2]
Microsoft described an anomalous surge in DNS queries from around the world targeting a set of Azure-hosted domains. It did not publicly identify an attacker, intent, botnet or confirmed distributed denial-of-service campaign. The initiating surge must remain unexplained beyond Microsoft's description. [2][4][5]
Microsoft said a particular event sequence exposed a code defect that reduced the efficiency of Azure DNS Edge caches. The public record does not disclose the code path, cache key, hit ratio, affected edge population or backend work created by each miss. [2][4][5]
As the DNS service overloaded, clients retried requests more frequently. Microsoft said the volumetric spike mitigation system considered those retries legitimate and therefore did not drop them. This supports a retry-amplification feedback loop, but not a precise packet-level reconstruction. [2][4]
Microsoft said monitoring detected lower availability, engineers engaged and the DNS service automatically recovered by 22:00 UTC. It acknowledged that the recovery time exceeded its design goal. It then changed mitigation logic to protect against excessive retries and listed a cache-defect repair plus better anomalous-traffic detection as next steps. [2][4][5]
The incident affected a network control plane rather than one application. Users had intermittent difficulty resolving names used by Azure, Dynamics, Xbox Live and other Microsoft services. A correct service record was not enough when the running authoritative path did not return dependable answers. [1][3][6]
Current Azure documentation describes a global anycast DNS network, reliability features and customer controls. Those materials explain architecture and responsibility, but they cannot be used as proof of the exact 2021 implementation or of remediation completion. [7]-[13]
DNS standards separate authoritative service from recursive resolution and document how caching, non-response and retries shape load. RFC 4697 is especially relevant because resolver retry behavior can impose excessive work on authoritative servers. The standards do not show which clients or resolvers contributed what share during this incident. [14]-[22]
Responsibility follows control. Azure DNS engineering controlled cache code, edge capacity, traffic shaping, mitigation classification and recovery automation. Microsoft service teams controlled shared DNS dependencies. Resolver and client operators controlled retry and cache behavior. Customers controlled some monitoring and delegation choices but could not inspect or repair Azure's internal defect.
A credible repair requires time-bound evidence: cache-hit ratios by query class, retry rates, edge saturation, anycast catchment changes, mitigation-rule behavior, known-valid resolution probes, per-service recovery and recurrence tests. None of those should be inferred from a status label alone.

The timeline contains several clocks

Incident reports often become cleaner as they age. The Azure DNS record should resist that cleanup where it erases useful distinctions.

Microsoft's later incident narrative put the Azure DNS service availability issue between 21:21 UTC and 22:00 UTC on 1 April 2021. It said the majority of services recovered by 22:30 UTC. Exoprise reproduced that account and reported that its own DNS and server monitoring raised an alarm around 21:20. [2] A Microsoft employee's contemporaneous community notice, posted while the response was still unfolding, described customer impact between approximately 21:30 UTC and 22:30 UTC. A later Microsoft employee update on the same page said Microsoft DNS servers had seen a traffic spike and that resilient DNS capabilities had been engaged.

[1]

Those timestamps measure different things:

an external monitor's first failure observation;
the provider's later start time for the DNS service condition;
the time at which the provider considered DNS automatically recovered;
the period in which customers experienced intermittent access;
the time by which a majority of dependent services recovered.

The Register's contemporaneous report quoted the approximate 21:30 UTC start and said Microsoft had rerouted traffic to resilient DNS capabilities while investigating. It described effects across major geographic regions, while excluding Microsoft's government cloud and China services from the reported scope. [3] TechCrunch separately reported failures reaching multiple Microsoft products and quoted Microsoft acknowledging an Azure Portal and Azure services issue. [6]

The public evidence does not establish one universal recovery moment for every name, resolver, region or service. DNS caches can make failure and recovery appear at different times. A resolver with a warm answer may continue serving a name after authoritative availability declines. Another resolver with a cold cache may fail immediately. When authoritative service improves, negative or failed state at clients and intermediate resolvers can still delay visible recovery. Microsoft itself distinguished DNS automatic recovery at 22:00 from majority-service recovery at 22:30. [2]

That distinction matters for accountability. A provider should not define recovery solely by an internal server metric if users still cannot resolve critical names. Nor should an external alarm be treated automatically as the root-cause start. A reconciled timeline needs at least four tracks: authoritative service health, recursive resolver outcomes, dependent service recovery and user-visible reachability.

An anomalous surge is not a proven attack

Microsoft said Azure DNS received an anomalous surge in queries from across the globe targeting a set of domains hosted on Azure. [2][4] That is a description of volume and target distribution. It does not, by itself, establish who generated the traffic, whether intent was malicious, whether source addresses were forged or whether the event met a particular denial-of-service classification.

Some reporting used attack language. The technical record cited here does not provide a packet sample, attribution report or Microsoft statement naming a DDoS campaign. The future evidentiary standard is therefore narrow:

Confirmed by Microsoft's account: a global query surge targeted a set of Azure-hosted domains.
Confirmed by Microsoft's account: the service's normal caches and traffic shaping were expected to mitigate such a surge.
Confirmed by Microsoft's account: a code defect reduced edge-cache efficiency under a particular sequence.
Unknown: what initiated the surge.
Unknown: whether a coordinated actor intended to deny service.
Unknown: whether traffic was spoofed, reflected, generated by compromised devices, caused by software behavior or combined several sources.
Unknown: the names, query types, rates and geographic distributions involved.

This boundary is not semantic caution for its own sake. The repair depends on the mechanism. Source-address validation can constrain spoofed traffic but does not stop legitimate clients from retrying. A rate limit can suppress high volume but may reject valid resolution. More cache capacity can help repeated questions but may not help a workload dominated by unique names or cache-bypassing query combinations. Better anycast distribution can spread work while also shifting overload among edges.

Calling the surge an attack without evidence would make one explanation appear settled and could direct responsibility outward. Microsoft's own account identifies an internal defect and a mitigation-classification gap regardless of the initiating source. Even if the first traffic was malicious, the service still had to handle the supported failure mode: lower cache efficiency followed by legitimate retries that its volumetric control did not remove.

The cache defect changed the cost of each query

Caching is not merely a performance optimization in authoritative DNS. It can determine how much work an edge performs for repeated questions and how much load reaches deeper service components.

Microsoft said its DNS Edge cache efficiency declined because a code defect was exposed by one specific event sequence. [2][4][5] The phrase is informative but incomplete. It does not say whether affected queries missed an answer cache, bypassed a negative cache, caused repeated backend lookups, contended on shared state, invalidated entries or consumed another scarce resource. It does not identify whether all edges were vulnerable or only a subset reached through particular anycast paths.

The accountable reconstruction should avoid filling in those details. It can still show why efficiency matters.

Assume a simplified edge receives repeated questions. With a high cache-hit rate, most answers are served from already available state. The marginal work per query stays relatively low. If a defect pushes more queries down a slower path, each request can consume more CPU time, memory, synchronization, network work or backend capacity. Latency rises. Clients wait longer or receive no answer. They retry. The retry population then raises the incoming rate even if the original surge stops growing.

This is the core feedback loop supported by Microsoft's narrative:

An anomalous query surge reaches Azure DNS.
A specific sequence exposes a cache-efficiency defect.
More requests require expensive handling or wait longer.
DNS service availability declines.
Clients retry unanswered requests.
The volumetric system treats those retries as legitimate.
Retry traffic adds workload to the already impaired service.

The loop does not require any one client to behave irrationally. A retry can be individually reasonable. The systemic failure comes from aggregate behavior and the operator's inability to classify or shape that work safely.

RFC 1034 and RFC 1035 establish caching as a fundamental part of DNS operation. [17][18] RFC 2308 defines negative caching so that resolvers do not repeatedly ask the same nonexistence question without limit. [19] Later standards such as RFC 8020 and RFC 8198 describe ways to reduce unnecessary negative-query traffic in particular conditions. [21][22] None of those documents proves the Azure defect concerned negative answers. They show only that query reuse, cache state and repeated misses are recognized operational variables.

Legitimate retries can still be unsafe in aggregate

Microsoft's most consequential admission was that client retries were considered legitimate DNS traffic and therefore were not dropped by the volumetric spike mitigation systems. [2][4]

"Legitimate" can mean several things. A packet may have a plausible source. A query may conform to protocol. A client may be authorized to use a recursive resolver. A requested domain may exist. None guarantees that an unbounded aggregate retry stream is safe for an impaired authoritative service.

RFC 4697 documents resolver behavior that can impose excessive query load on authoritative servers. It describes patterns in which resolvers retry too aggressively, query multiple servers or continue work when a more disciplined response would reduce load. [20] The document predates the Azure incident by many years. Its relevance is not that Azure necessarily violated one prescribed algorithm. It establishes that retry amplification at the resolver-authoritative boundary is a known operational failure class.

The Azure record leaves several questions unanswered:

Which clients or recursive implementations retried?
Were retries concentrated in Microsoft-operated service components, public resolvers, enterprise resolvers or end-user devices?
What response or timeout triggered the next attempt?
Were retry intervals randomized or synchronized?
Did clients shift among anycast addresses or repeat toward the same reached edge?
Which query classes generated the highest cost after the cache defect appeared?
Did valid retries become distinguishable from the initiating surge by name, timing, source network or prior response?

Without those measurements, "excessive retries" is a useful category but not a complete diagnosis.

The mitigation challenge is also real. Dropping all retries can lengthen an outage and deny clients whose first packet was merely lost. Allowing every retry can sustain overload. The operator needs bounded admission: protect enough known-valid work to preserve recovery while limiting patterns that consume disproportionate resources.

Microsoft said it updated volumetric mitigation logic immediately after the incident to protect the DNS service from excessive retries. [2][4] A verifiable account would show what signal changed, how the new rule distinguishes a harmless retry from harmful aggregate behavior, what false-positive tests were run and how operators can disable or tune the control if it blocks legitimate names.

Authoritative service and recursive resolution are different control domains

A user's DNS lookup crosses systems operated by different parties.

The stub resolver on a device normally asks a recursive resolver. The recursive resolver may answer from cache. If it lacks a usable answer, it follows delegations and asks authoritative servers for the relevant zone. RFC 1034 and RFC 1035 define those roles and the message exchanges between them. [17][18]

Azure DNS operated the authoritative layer for affected Azure-hosted domains. It controlled the service's edge implementation, cache behavior, capacity, traffic shaping and authoritative responses. Recursive resolvers controlled cached state, server selection, timeout interpretation and retry behavior. Applications controlled whether and how their own calls retried after a name-resolution failure. Access networks and internet routing influenced which Azure edge an anycast query reached.

The same symptom can therefore have different causes:

A resolver can time out because the reached authoritative edge is overloaded.
A path can drop packets even if the edge is healthy.
A resolver can retain a negative result or exhausted retry state after the authoritative service improves.
An application can turn one resolver failure into many parallel retries.
A status page can itself be hard to reach because its hostname depends on the impaired layer.

RFC 8906 explains that a nonresponsive authoritative server can be indistinguishable from packet loss from the resolver's point of view. [16] That ambiguity affects both automated behavior and incident communication. A resolver may reasonably try another authoritative address, but many resolvers making the same decision can move or multiply load.

Accountability should not flatten those roles. Azure cannot control every client algorithm. Resolver operators cannot fix Azure's cache code. Customers cannot inspect internal edge telemetry. But Azure did control the service boundary that accepted queries and the mitigation logic that classified retry traffic. That gives it primary responsibility for demonstrating that the authoritative service could degrade without turning valid recovery behavior into sustained overload.

Anycast distributes queries but does not make every edge equivalent

Current Microsoft documentation says Azure DNS uses a global network of name servers and anycast to direct each query to a close available DNS server. [7] Microsoft's Windows Server anycast guidance explains the general pattern: multiple locations advertise the same service address and routing selects a path. [9]

These documents describe current architecture and general practice. They do not prove the exact 2021 topology, route policy or withdrawal behavior. That temporal boundary should remain explicit.

RFC 9199 explains why large authoritative services commonly use multiple servers, anycast and load balancing. It also warns against assuming one universal deployment model. Resolver placement, routing, peering and catchment shape affect which instance receives traffic. [14]

During a query surge, anycast can distribute load. It can also produce uneven experience:

one catchment may receive a larger share of a targeted workload;
route changes can move both hostile and legitimate queries to another edge;
a node can remain reachable while its application layer is overloaded;
withdrawal can protect one site while concentrating traffic elsewhere;
recursive resolvers in different networks can reach different edges and report different availability.

Microsoft's public RCA does not disclose whether the cache defect affected every edge, whether routes changed, whether resilient DNS capabilities meant catchment movement, or whether some servers had better cache efficiency than others. [1][2]

The phrase "rerouted traffic to our resilient DNS capabilities" appeared in contemporaneous status reporting. [3] It is too broad to establish what changed. A credible technical account would connect the phrase to evidence:

which routes or service endpoints changed;
which catchments moved;
whether cache state moved or warmed;
how answer and timeout rates changed at each step;
whether the change reduced retry volume;
which external probes confirmed recovery.

Anycast is infrastructure, not absolution. Its value is measured by observed continuity under the actual workload.

Serving stale data is an option, not an assumed cure

When authoritative servers cannot answer, a recursive resolver may have an expired copy of a previously valid response. RFC 8767 defines a bounded method for serving stale data to improve resilience under specified conditions. [15]

That mechanism is relevant to continuity but should not be imported into the incident as a missing control. Public sources do not say which resolvers held stale answers, which records were stable enough to serve, whether the responses had expired or whether stale serving was enabled.

Serving stale data involves trade-offs:

It can keep a stable service name reachable during a short authoritative failure.
It can preserve an address the operator urgently needs to change.
It can mask continuing authoritative impairment from some users.
It does not help a first-time query with no cached answer.
It does not repair the authoritative edge or reduce all query classes.
Its usefulness depends on prior cache state and configured limits.

Negative caching has similar boundaries. RFC 2308 reduces repeated queries for known-negative answers. RFC 8020 permits a resolver to stop below a validated NXDOMAIN branch. RFC 8198 allows aggressive use of DNSSEC-authenticated denial records to synthesize additional negative answers. [19][21][22]

These mechanisms can reduce unnecessary upstream work. They do not prove the Azure surge consisted of random nonexistent names or that the exposed defect involved negative caching. They also cannot safely be recommended without knowing the query distribution and DNSSEC state.

The evidence-led question is not "Why did every resolver fail to serve stale?" It is:

Which affected names had usable cached answers?
How much retry traffic came from cold, positive, negative or expired cache states?
Which resilience behavior reduced authoritative work without preserving unsafe stale state?
What application behavior occurred when resolvers returned stale, failed or delayed answers?

Those measurements would turn a general standards discussion into an incident-specific control decision.

Dependency concentration made one DNS fault look like many service failures

The incident was visible through Azure, Dynamics, Xbox Live and other Microsoft services because name resolution sat beneath multiple service paths. Microsoft's Q&A notice named Azure, Dynamics and Xbox Live. [1] Exoprise reproduced a Microsoft 365 communication that listed Teams and a broader set of dependent products. [2] The Register and TechCrunch independently described widespread access complaints across Microsoft properties. [3][6]

The evidence does not show that every underlying application failed. A user unable to resolve a service name experiences an unavailable service even if compute, storage and application processes remain healthy. This distinction matters for both diagnosis and recovery.

DNS is part of network identity. It maps names used by users and software to reachable endpoints. A record can remain correctly stored while the service that answers for it becomes unavailable. The user sees no practical benefit from the correct record if no response arrives.

Shared dependency creates several accountability questions:

Did public status, support, management and authentication paths depend on the same authoritative DNS layer?
Could internal responders reach the tools needed to diagnose and communicate?
Which service teams had independently monitored DNS from outside Microsoft's network?
Which service owners knew their names shared one edge-cache implementation?
Were there static emergency communication paths outside the affected namespace?
Did service recovery depend on resolver caches expiring or refreshing after authoritative recovery?

Exoprise reported difficulty with Azure status pages during the event and described Microsoft directing users to alternate status surfaces. [2] That report should be treated as an independent observation, not proof that every status endpoint failed for the same reason. It still exposes a governance issue: an incident communication channel should not share an unexamined dependency with the service it reports.

The repair is not necessarily a second DNS provider for every name. It begins with an accurate dependency graph and independent observation. Microsoft service owners need to know which names, authoritative paths, recursive resolvers and control-plane actions remain common.

Monitoring detected degradation, but detection is not containment

Microsoft said lower service availability triggered monitoring systems and engaged engineers. [2] Exoprise said its external monitor alerted around 21:20, near the later 21:21 start of the provider's DNS window. [2]

That timing suggests detection was not the only problem. The service automatically recovered by 22:00, but Microsoft acknowledged that the duration exceeded its design goal. The relevant question becomes what operators could do after detection.

A useful detection system should separate at least these signals:

incoming query rate;
cache-hit and miss rate by query class;
cost per answered or failed request;
queue depth and server saturation;
valid-answer rate;
timeout and error rate from external resolvers;
retry volume and retry source distribution;
anycast catchment movement;
service-specific name-resolution success.

An aggregate traffic alarm can miss a change in work per query. A cache defect may turn a familiar query rate into a capacity problem. An availability alarm can fire only after users are already failing. A volumetric detector can classify retries as valid while their aggregate effect prevents recovery.

The public account says engineers prepared additional serving capacity and an ability to answer DNS queries from the volumetric mitigation system if further action was necessary. [2] It does not say whether either step was actually applied before automatic recovery, what threshold would have triggered it, or whether capacity would have broken the feedback loop.

This is a control distinction:

Detection answers whether something is wrong.
Diagnosis identifies the mechanism.
Containment limits the harmful feedback.
Recovery restores valid resolution.
Verification shows that external users and dependent services have recovered.

A fast alarm does not excuse weak containment. Nor does automatic recovery prove that the service could reliably recover from a longer or repeated surge.

Recovery exceeded the design goal

Microsoft's statement that recovery exceeded its design goal is unusually useful because it reveals an internal standard without disclosing the numerical target. [2][5]

The statement raises four questions.

First, what did the design goal measure? It could refer to authoritative answer availability, time to automatic recovery, time to operator intervention, or end-to-end service restoration. Those are not interchangeable.

Second, which mechanism was expected to achieve it? A cache may recover as load falls. An anycast site may withdraw. Capacity may be added. A mitigation rule may change. Without a control owner and trigger, "design goal" remains an aspiration.

Third, was the goal tested against a combined failure? A normal load test may measure query capacity with healthy cache efficiency. A cache test may not include synchronized retries. A volumetric mitigation test may model hostile packets but allow valid retries without limit. The 2021 event joined those conditions.

Fourth, how was the repair validated? Microsoft listed repair of the code defect so requests could be efficiently handled in cache and improvement of automatic detection and mitigation of anomalous traffic. [2][4] A list of work items is not evidence of completion.

The appropriate closeout would bind each measure to a test:

Measure	Required evidence
Cache defect repair	Reproduction test for the triggering sequence, before-and-after cache efficiency, code and deployment identifiers
Retry protection	Controlled retry workload, legitimate answer preservation, false-positive rate, rollback threshold
Anomaly detection	Detection latency across query classes, sensitivity and false-alarm evidence
Edge capacity	Per-edge saturation margin under degraded cache efficiency
Automatic recovery	Repeated fault-injection runs and time-to-recovery distribution
Service recovery	External probes for representative Microsoft and customer names across resolver networks

Without this evidence, readers can know what Microsoft intended to improve but not how much risk was removed.

The SLA is not a substitute for incident evidence

Azure publishes an SLA for DNS zones. The current document defines service availability and potential service credits under specified contractual conditions. [13] It is useful for identifying the legal and commercial boundary today.

It does not establish which 2021 contracts applied, whether a particular customer met the claim conditions, whether the measured downtime crossed a threshold or whether Microsoft had legal liability. The public sources in this packet contain no customer-specific claims, regulator decision or court finding.

An SLA can also measure a narrower entity than customer harm. A DNS availability calculation may not capture delayed application recovery, status-page access, operational labor or transactions lost because a resolver could not obtain an answer. Conversely, a customer report of service difficulty does not automatically prove an SLA breach.

The accountability record should therefore keep three ledgers separate:

Technical availability: what authoritative and recursive systems returned.
Customer impact: which functions failed, for whom and for how long.
Contractual remedy: which terms, measurements and claim procedures applied.

Conflating them either exaggerates liability or minimizes harm. The limits therefore matter more than choosing one measure as the whole incident.

Customers controlled architecture, not Azure's defect

Current Azure reliability guidance describes provider and customer responsibilities. Azure operates the DNS platform, while customers configure zones, records, delegation and some resilience choices. [8][12]

Customers can take useful steps:

monitor critical names from resolvers and networks outside Azure;
inventory which control and user paths depend on Azure-hosted zones;
choose TTLs deliberately;
test application behavior when resolution fails;
preserve emergency access and communication paths;
evaluate authoritative-provider diversity for systems that justify its complexity;
understand DNSSEC and delegation operations if they use them.

Those controls do not transfer responsibility for Azure's cache defect to customers. A customer cannot inspect the edge implementation, change volumetric classification or add provider capacity. It also should not be told that one architecture is universally correct.

Multi-provider authoritative DNS can reduce one common mode, but it adds zone synchronization, delegation, DNSSEC, access control and failover risks. RFC 9199 emphasizes context rather than one mandated design. [14] A second provider that shares routing, registrar access, automation or operational staff may not be independent in the ways that matter.

The relevant customer decision is a documented risk acceptance:

Which name-resolution failures must the service survive?
Which failure domains are actually independent?
How quickly can delegation or provider state change?
What stale or conflicting state could a failover create?
Who has authority to execute and reverse the change?
What test proves the path works from real user networks?

Customer resilience is a layer of defense. It is not an excuse for an infrastructure operator to leave its own defect and mitigation behavior unmeasured.

Responsibility follows control and evidence access

The public record supports a control-based allocation.

Azure DNS engineering

Azure DNS engineering controlled the authoritative service, cache implementation, edge deployment, traffic shaping, volumetric mitigation logic and recovery automation. It had the best access to query distributions, cache metrics and server state. Its duty was not to prevent every query surge. It was to design and test degradation behavior so that one cache defect did not let valid retries sustain overload, and to retain evidence showing what happened.

Microsoft incident management

Incident management controlled escalation, coordination and public communication. The difference between the preliminary "spike" update and later cache-defect account is reasonable during investigation, provided the record shows what changed. It should preserve a timestamped sequence of hypotheses, evidence and corrective actions rather than present the final narrative as if it were known from the start.

Microsoft service owners

Teams running Azure, Dynamics, Xbox Live, Microsoft 365 and related control surfaces controlled their dependency design and external monitoring. They did not control the DNS defect, but they could identify whether critical names, status pages and recovery tools shared the same authoritative path.

Recursive resolver and client operators

Resolver and client developers controlled retry intervals, cache behavior and failure handling. RFC 4697 shows why retry discipline is a long-recognized shared responsibility. [20] The record does not identify which implementations generated the most traffic, so no specific operator should be accused. A complete postmortem would provide aggregate distributions that allow the ecosystem to repair harmful patterns.

Customers

Customers controlled some zone, TTL, monitoring and provider-diversity choices. Their responsibility depends on the criticality of the service, available contractual options and the feasibility of independent DNS. They did not possess the information or authority needed to fix Azure's edge cache or mitigation classifier.

This allocation is asymmetric because control and evidence were asymmetric. Azure held the central operational evidence and the means to change the failing service.

Counterfactuals show which controls matter

Counterfactual analysis helps separate the trigger, contributing conditions and repair.

If the anomalous surge had occurred without the cache defect

Microsoft said normal caches and traffic shaping would mitigate the surge. [2][4] If that statement is correct, the service should have retained higher cache efficiency and lower work per query. This makes the defect a contributing condition or root-cause candidate, not merely a background bug.

If the cache defect had appeared without a surge

The service might have had enough spare capacity to absorb reduced efficiency. That would make the surge a triggering condition. The public record does not reveal the margin, so the interaction is more defensible than assigning one factor as the entire root cause.

If retries had been bounded immediately

The feedback loop might have weakened. But an overbroad retry filter could have denied legitimate recovery traffic. The correct control would need to preserve representative valid requests and demonstrate a low false-positive rate.

If every resolver served stale answers

Some stable names might have remained reachable, while cold-cache users and changed records still failed. Universal stale serving could also preserve unsafe state. This is not a complete counterfactual repair.

If customers used two authoritative providers

Some names might have retained an independent path, provided delegation, zone data, DNSSEC and health policy were coordinated. Other shared dependencies or resolver behavior could still fail. Diversity is testable architecture, not a slogan.

If more edge capacity had been available

Capacity could have delayed saturation. It would not necessarily remove the cache defect or classify retries. A larger system with the same feedback loop may fail later and at a larger scale.

These counterfactuals support a layered conclusion: the initiating surge triggered the event; the cache defect increased per-query work; retry behavior amplified load; mitigation classification failed to break the loop; dependency concentration propagated impact; and recovery controls took longer than the provider's design goal.

What the public evidence still cannot prove

The sources establish a useful outline but leave the decisive internal record unavailable.

They do not establish:

the source, intent or ownership of the initiating query surge;
whether the surge was a coordinated attack;
query volume, packet rate or query-type distribution;
the domains and records targeted;
the cache implementation or code path that failed;
cache-hit ratios before, during and after the incident;
the number or location of affected DNS edges;
route or anycast catchment changes;
which recursive resolvers or clients produced retries;
retry intervals, synchronization or amplification factor;
the exact volumetric mitigation rule before and after repair;
per-service and per-region impact;
customer loss, SLA credits or legal liability;
the completion date and independent validation of remediation;
whether the same triggering sequence has been tested since.

Current Microsoft documentation cannot fill these historical gaps. It describes today's service and recommended practices. [7]-[13] RFCs define protocol behavior and operational options. [14]-[22] Independent reports preserve statements and symptoms but do not have Azure's internal telemetry. [2]-[6]

The absence of public detail does not prove concealment or negligence. It limits the confidence of any causal or legal conclusion. The strongest finding is that Microsoft's own account identifies an internal cache defect, a legitimate-retry feedback loop and a mitigation gap. The precise distribution of responsibility beyond Microsoft's controlled service remains partly unknown.

A repair should be auditable as a sequence

A verifiable remediation program would preserve a common incident test rather than a list of disconnected improvements.

Reproduce

Create a safe workload matching the relevant query and cache-state sequence. Record the software version, zone shape, record types, cache state and edge topology. Prove that the pre-fix system exhibits the efficiency decline.

Measure

Capture cache-hit and miss rates, per-query cost, response latency, timeout rate, queue depth, edge saturation and retry volume. Separate the initiating traffic from retries where evidence allows.

Contain

Apply bounded retry shaping and anomalous-traffic controls. Test known-valid names, cold and warm cache states, negative answers, DNSSEC responses and multiple resolver behaviors. Measure false positives.

Recover

Demonstrate that authoritative availability returns within the design goal without waiting only for external traffic to fall. Confirm anycast and route behavior across independent networks.

Verify dependent services

Probe representative Azure, Microsoft control-plane and customer names from multiple recursive resolvers and access networks. Distinguish DNS recovery from application recovery.

Roll back

Show that emergency controls have owners, expiry conditions and reversible configuration. A mitigation that remains indefinitely can become a new source of denial.

Retain evidence

Bind the test results to code, deployment and configuration identifiers. Publish a bounded summary with enough measurements to show that the specific feedback loop was removed without exposing sensitive infrastructure details.

This sequence answers the central question: not whether Microsoft added "more resilience," but whether the same cache-and-retry interaction can still cross the failure threshold.

Conclusion

The April 2021 Azure DNS outage was not explained by traffic volume alone.

Microsoft said an anomalous query surge exposed a code defect that reduced DNS Edge cache efficiency. Degraded service caused clients to retry. Those retries were legitimate traffic, so volumetric mitigation did not initially drop them. The service automatically recovered, but not within its design goal. Microsoft then changed retry protection and said it would repair the cache defect and improve anomaly detection. [2][4][5]

That sequence identifies a network-infrastructure accountability problem with several layers:

The surge was the trigger described by Microsoft, not a proven attack attribution.
The cache defect was an internal contributing condition that increased work.
Legitimate retry behavior amplified load across the resolver-authoritative boundary.
Mitigation logic did not initially contain that aggregate valid traffic.
Shared DNS dependency turned one resolution failure into many apparent service outages.
Recovery metrics did not map cleanly to every user's experience.

The responsible conclusion is not that DNS retries are bad, anycast failed or customers should always use a second provider. Each claim would outrun the evidence.

The stronger standard is measurable degradation behavior. An authoritative DNS operator should know how cache efficiency changes under unusual query sequences, how legitimate retries affect capacity, which mitigation protects valid answers, how anycast catchments respond and what external probes prove recovery. Resolver and client operators should bound retries and cache behavior. Service owners should identify critical naming dependencies and preserve independent incident communication. Customers should test the continuity decisions they can actually control.

Records, service descriptions and status notices are part of the evidence. They are not the running service. On 1 April 2021, names could remain correctly configured while users could not reliably resolve them. Accountability begins where those two states diverge.

The final proof is a repeatable test bound to the actual repair: recreate the sequence, measure cache efficiency, induce bounded retries, activate mitigation, preserve known-valid answers, recover within the design goal and confirm results from independent networks. Without that evidence, the public has a plausible narrative. With it, operators can show that the feedback loop has been closed.