UltraDNS's 2014 DDoS Attack Made Authoritative DNS Continuity an Accountability Test

Summary

Confirmed boundary: Distributed monitoring on 30 April 2014 recorded a prolonged degradation of Neustar's UltraDNS authoritative-DNS service. ThousandEyes described alerts from about 08:15 Pacific and observed widespread DNS-resolution failures, increased latency and packet loss on paths toward UltraDNS name servers. Dotcom-Monitor independently recorded DNS errors and continuing instability. [1][3] Those observations establish a serious authoritative-DNS reachability event. They do not prove that every UltraDNS customer, user, geography or application session failed for the same duration.
Provider account: Neustar updates preserved by the SANS Internet Storm Center identified DDoS traffic and described work with Tier-1 providers, the addition of UltraDNS name servers to active mitigation, shifting attack vectors, and intermittent Western US network saturation affecting part of the PDNS1-PDNS6 segment. The updates later described stabilized DNS traffic while proactive mitigation remained active. [2] These statements are important first-party evidence, but they do not disclose complete packet telemetry, the actor, motive, exact route changes or every operational decision.
Infrastructure significance: Authoritative DNS is a dependency that can fail while an application and its hosting environment remain healthy. Recursive caches may temporarily preserve access for some users, while fresh queries fail. A shared authoritative provider can therefore correlate failures across unrelated customer brands and produce a gap between application dashboards and user reachability.
Control boundary: Neustar controlled the UltraDNS service design, routing, capacity, monitoring, mitigation activation, carrier coordination, customer communication and recovery evidence. Tier-1 carriers and mitigation partners controlled filtering and available capacity in their networks. Customers controlled provider selection, secondary-DNS design, TTL policy, external monitoring and application behavior during resolution failure. Resolver and access-network operators controlled caches and user paths. End users controlled none of the hidden authoritative or transit path.
Reality layer: Delegation and zone records identify which servers should answer. They are accountability ledgers, not commands that make packets reach those servers. Running BGP reachability, anycast instances, upstream capacity, mitigation policy and healthy authoritative software determine whether a name resolves. The article's thesis disappears if authoritative DNS, routing, mitigation, shared-provider concentration and restoration evidence are removed.

The event must be reconstructed from multiple clocks

The most useful public account of the 30 April 2014 event does not come from a single status timestamp. It comes from independent monitoring, provider statements preserved by a third party, and observations made from different networks.

ThousandEyes reported alerts beginning at approximately 08:15 Pacific. Its tests showed DNS failures and increased latency for services that depended on UltraDNS, including ServiceMax, RingCentral, Veeva Systems and Salesforce. The report distinguished non-cached DNS tests from application behavior and linked some application symptoms to failures in name resolution. [1] That distinction matters because it describes a network dependency rather than simply listing websites that appeared unavailable.

Dotcom-Monitor separately reported DNS errors and continuing instability. [3] Independent monitoring is valuable because a provider's internal service dashboard can show healthy software or partial capacity while users on particular paths still cannot obtain an authoritative answer. An external probe does not reveal the whole topology, but it records what a user-facing path actually did.

The SANS diary preserved a sequence of Neustar updates. Those updates said the company was handling DDoS traffic, coordinating with Tier-1 providers, refining upstream mitigation and placing UltraDNS name servers into active mitigation. Later statements said the traffic shifted vectors and identified intermittent Western US saturation for customers using part of the PDNS1-PDNS6 segment. The updates eventually described DNS traffic as stabilized while mitigation remained active. [2]

These sources use different clocks. A monitor records when a test begins failing or recovers from a particular vantage point. A provider update records when an internal team decides it has enough evidence to describe the service state publicly. A customer records when its own users can again resolve names and complete application transactions. None is automatically the single start or end of the incident.

An accountable reconstruction therefore keeps the clocks separate:

first external failure detected from each monitoring region;
first internal alert and incident declaration;
mitigation activation at the provider and upstream carriers;
customer-visible degradation by zone, name-server segment and geography;
provider stabilization statements;
independent confirmation of restored authoritative answers;
customer confirmation that application access recovered.

The public record supports a prolonged incident on 30 April. It does not support a precise claim that all customers were continuously unavailable for a fixed number of hours. Treating the longest visible monitoring interval as every customer's outage would convert evidence from selected probes into an unsupported universal claim.

Authoritative DNS can fail while the application remains healthy

The Domain Name System separates the name a user requests from the addresses and services needed to reach an application. Authoritative servers publish answers for the zones delegated to them. Recursive resolvers ask those servers for answers when the information is not already cached. [13][14]

That architecture creates a failure mode that application teams can miss. A web server may be running, a database may be healthy and an internal transaction test may succeed, yet a new user cannot reach the service because its resolver cannot obtain an authoritative answer. Existing sessions may continue if they no longer require a new lookup. Users whose resolvers retain an unexpired cached answer may see no immediate problem. Users making a fresh query may fail.

ThousandEyes described this cache-sensitive behavior in the UltraDNS event. Some active sessions could remain usable while new logins or new resolution attempts failed. [1] The observation is not a generic DNS tutorial inserted after the fact. It explains why different users could report different service states at the same moment.

Caching also complicates restoration. When authoritative service recovers, a resolver that has cached a negative result or reached a retry threshold may not return immediately to normal behavior. Conversely, a long positive TTL can mask an authoritative failure until the cached answer expires. The responsible use of TTL is therefore a tradeoff, not a universal instruction to make values longer or shorter.

For accountability purposes, availability must be measured at several layers:

whether authoritative software accepts and answers queries;
whether the announced addresses are reachable from diverse networks;
whether responses arrive within a usable latency and loss boundary;
whether recursive resolvers receive valid answers;
whether applications complete new transactions that require fresh resolution;
whether customer monitoring distinguishes cached and non-cached tests.

A green process check at the authoritative server proves only one layer. A successful application transaction from one internal location proves only one path. The incident requires evidence that spans the delegation-to-user chain.

Shared authoritative DNS creates correlated dependency

UltraDNS served many organizations that appeared unrelated to their users. A customer could operate its own application, cloud tenancy and corporate network while delegating authoritative DNS to the same provider used by other firms. This arrangement can improve operational quality because a specialist provider can maintain globally distributed infrastructure, expert staff and mitigation capacity. It can also create correlated failure.

The 2014 monitoring record illustrates that correlation. ThousandEyes saw DNS-related effects for several distinct services. [1] The fact that these services shared an authoritative provider helps explain simultaneous reachability problems without implying that every application had identical symptoms or that all of its infrastructure was down.

Concentration is not demonstrated merely by naming a vendor. The operational question is whether apparently separate services share a control plane, route, upstream carrier, mitigation network or name-server segment. Multiple customer brands do not create independence if they depend on the same hidden path.

The customer side can also contain false diversity. Two domain names may use different visible authoritative server names that terminate inside one provider. Two providers may share a transit bottleneck. A primary and secondary service may use the same anycast route origin, mitigation partner or operational team. A contract for a backup service does not prove that the backup can be activated safely under attack.

The provider and customer have different evidence obligations. The provider should know its routing, anycast sites, carrier dependencies, capacity and mitigation state. The customer should know which zones depend on which provider, whether an independently operated secondary is active, how records are synchronized, how TTLs affect failure, and how the application behaves when resolution fails.

End users generally have none of that visibility. A failed login may appear to be an application defect. The user cannot inspect the delegation architecture, choose an alternate authoritative provider or redirect the provider's traffic. Accountability should therefore remain with the parties that select, operate and can test the dependency.

Anycast distributes service but does not prove independence

Anycast allows multiple service locations to announce reachability for the same address, with routing selecting a path according to network policy. It is widely used for DNS because it can place service close to users, distribute normal query load and absorb some localized failure. RFC 4786 describes operational considerations for anycast, including routing, monitoring, reachability and failure behavior. [11]

Neustar had described an anycast design, excess capacity and mitigation-center routing before the event. [7][8] Those materials are relevant to the control model. They show the type of architecture and operational promise that customers could reasonably expect the provider to maintain. They are not incident telemetry and do not prove how every private route or site behaved on 30 April.

Anycast can fail in common mode. Several sites can depend on the same upstream carrier, routing policy, control system or mitigation decision. Traffic can shift toward a site that remains reachable but lacks enough clean capacity. A route can continue to exist while the service behind it is saturated. An upstream filter can protect one path while another path receives harmful traffic.

The Neustar updates preserved by SANS make this boundary concrete. They mention Tier-1 coordination, active mitigation, shifting vectors and intermittent Western US network saturation affecting part of the PDNS1-PDNS6 segment. [2] The account suggests that routing and capacity were part of the operational response. It does not disclose enough detail to determine the exact anycast movement, filter placement or per-site load.

An accountability review should therefore ask for evidence rather than infer resilience from the word anycast:

query success and latency by anycast site and external region;
clean and attack traffic by upstream path;
route announcements and withdrawals during mitigation;
capacity headroom before and during the event;
convergence and spillover when one location is protected or saturated;
whether monitoring tests the user-visible service rather than only node health;
whether rollback is available when mitigation changes create new reachability loss.

Anycast is a mechanism. Its accountable value depends on the independence of its paths, the observability of its state and the quality of the decisions made under load.

Multiple name servers are useful only when failure paths differ

DNS standards and operational guidance expect zones to have more than one authoritative server. RFC 2182 emphasizes the placement of secondary servers so that they do not share avoidable network and operational failure modes. [12] The principle remains important because redundancy that exists only in a list can disappear during a real incident.

Several visible name-server labels may still share:

one provider and operational team;
one anycast platform;
one route origin or routing policy;
one transit provider;
one mitigation network;
one deployment pipeline;
one configuration source;
one monitoring and escalation process.

The public record does not establish that all UltraDNS server names in 2014 shared every one of these dependencies. It does establish why the question should be tested. The provider updates referred to a specific PDNS1-PDNS6 segment and network saturation in one region. [2] That language makes segment-level evidence relevant without proving the full private topology.

Customers also need to distinguish active authoritative diversity from a dormant emergency plan. A secondary provider must have current zone data, correct DNSSEC state where applicable, enough capacity, valid delegation and a tested operating procedure. A name server that appears in a zone but is not monitored from outside the primary provider can create a misleading sense of safety.

Independence has costs. Running multiple providers can add synchronization, change-control and DNSSEC complexity. It can create inconsistent answers if records or signing state diverge. The correct accountability conclusion is not that every customer must buy maximum diversity. It is that the chosen design should match the consequence of name-resolution failure and that its claimed continuity should be tested.

For a public-facing service with material dependency on DNS, an evidence package should show which authoritative servers answer from which independent networks, how changes propagate, what happens when one provider is unreachable, and whether users can continue resolving names during a provider-wide exercise.

The DDoS label does not disclose the packet vector

Neustar's contemporaneous statements identified DDoS traffic. [2] That supports describing the incident as a DDoS attack. It does not disclose every vector, packet rate, source population, spoofing pattern, target component or mitigation command.

CISA material explains how direct floods and amplification attacks can exhaust network or service capacity. It also describes the challenge of separating harmful traffic from legitimate use and the value of upstream coordination, flow visibility, filtering, rate limiting and routing-based mitigation. [9][10] RFC 5358 and the ingress-filtering guidance in RFC 3704 and BCP 38 address controls that can reduce the abuse of recursive services and spoofed-source traffic. [15][16][17]

These sources establish a technical control context. They do not prove that UltraDNS experienced a particular amplification protocol or a specific traffic volume on 30 April. Contemporaneous industry reporting describes the broader growth of reflection and amplification attacks in 2014. [18] A retrospective source places the UltraDNS event in that environment. [4] Context must not be turned into event-specific forensics.

The correct boundary is explicit:

DDoS traffic is supported by Neustar's reported updates;
changing vectors are supported as a provider statement;
upstream and active mitigation are supported as response descriptions;
exact vectors, packet rates, botnet composition, actor and motive remain unknown;
general amplification controls are relevant to prevention and mitigation but not proof of the event mechanism.

This distinction is not a technicality. A direct flood, reflection attack, application-layer query flood and route-related saturation can demand different controls and produce different evidence. Claiming a mechanism without evidence can lead readers to evaluate the wrong prevention and remediation measures.

It can also distort responsibility. An attacker initiates harmful traffic, but providers and carriers control architecture, capacity, filtering, detection, routing and restoration. Customers control dependency design and external verification. Identifying the attacker would not answer whether those controls performed as designed.

Provider updates are evidence, not a substitute for measurements

The Neustar updates preserved by SANS are unusually useful because they expose parts of the response process: Tier-1 coordination, active mitigation, shifting vectors, a named segment, regional saturation and eventual stabilization. [2] They give the public more than a generic statement that engineers were investigating.

Even so, a status update is a claim by the operator. It should be tested against internal and external measurements.

A strong incident record would connect each update to:

the alert and service metrics that triggered it;
the regions and name-server segments it covered;
the route, filtering or capacity change already applied;
the percentage of customer zones or query traffic behind mitigation;
the remaining known failure modes;
the tests used to declare stabilization;
the time at which external probes confirmed recovery.

Public disclosure does not need to include sensitive filter rules or exploitable capacity details. It can still state the service classes affected, broad geography, observed cause, mitigation stage and verification method. Customers with operational need can receive more detailed information under appropriate controls. Regulators or auditors can review confidential technical records where required.

The phrase "most customers" also needs a denominator. It might refer to customer count, zones, queries, name-server segments or mitigation enrollment. The public record here does not provide enough detail to choose among them. A responsible article preserves the wording and records the missing denominator rather than supplying one.

The same rule applies to "stabilized." Stabilization can mean lower error rates, restored capacity, completed route changes, or the absence of new alerts. It may not mean that every recursive cache and customer application has returned to normal. The provider should define the operational test, and independent probes should confirm the user-visible outcome.

Responsibility follows the controls each party could exercise

The attacker's responsibility for sending harmful traffic does not eliminate the operational responsibilities of the organizations that run and depend on the infrastructure. Accountability is not a claim that every failure was preventable. It is an examination of who controlled which safeguards and what evidence shows how they performed.

Neustar and the UltraDNS operator

Neustar controlled the architecture and operation of UltraDNS. Its relevant controls included anycast design, authoritative-software operation, network capacity, route policy, monitoring, DDoS detection, mitigation relationships, carrier escalation, customer updates and restoration verification.

The provider therefore owes evidence about detection time, service impact, capacity, mitigation activation, routing decisions, communication and later testing. It does not owe a public map of every sensitive control. It does owe customers enough information to understand the dependency and evaluate continuity.

Tier-1 carriers and mitigation partners

Upstream networks controlled filtering, capacity and route handling in their own systems. Neustar's updates explicitly referenced work with Tier-1 providers. [2] That makes upstream coordination part of the incident record.

Responsibility at this layer depends on actual contracts and technical control, which are not public here. The article cannot apportion legal liability. It can identify the evidence needed: when escalation occurred, what traffic each provider observed, what mitigation was available, which routes changed and whether clean capacity remained sufficient.

UltraDNS customers

Customers controlled provider selection, secondary design, TTL policy, monitoring and application behavior. A customer that treated external DNS as a hidden utility could be unable to distinguish a DNS failure from an application failure. A customer with non-cached external monitoring and a tested independent secondary could detect and limit some effects.

Customer responsibility is bounded by control. A customer could not reconfigure UltraDNS's anycast platform or order an upstream carrier to filter traffic. It could decide whether the business consequence justified provider diversity and whether its own failover design worked.

Recursive resolvers and access networks

Resolvers controlled cache behavior and the paths their users followed. Their state could delay or mask impact. Access networks could experience different reachability to anycast sites.

This layer explains variation without making resolvers responsible for the attack. Evidence from diverse resolvers and networks is necessary to understand scope.

End users

End users had the least control. They generally could not identify the authoritative provider, change the zone delegation or choose the hidden route. Their reports are evidence of impact, not evidence that they had the ability to repair the failure.

Evidence quality determines the strength of the conclusion

The public record contains several evidence classes. Each supports a different conclusion.

First-party provider updates support what Neustar said it observed and did. They are strongest for the provider's declared response and weakest where they omit the underlying measurements.

Independent monitoring supports observed DNS failures, latency and packet loss from particular vantage points. It is strong evidence of user-path behavior but cannot reveal every customer or private route.

Customer and application reports support visible symptoms. They can show concentration and business effect, but they may not identify the exact failing component.

Pre-event architecture documents support the control model. Neustar's materials describe anycast, capacity and mitigation design. [7][8] They do not prove the incident-time configuration or performance.

RFCs and CISA guidance support technical expectations. [9]-[17] They are not incident-specific findings.

Later comparative reports can clarify architectural patterns. ThousandEyes' analysis of a separate 2015 UltraDNS outage is useful for understanding anycast measurement and provider dependency, but the 2015 event must not be merged into the 2014 timeline. [6]

The article's conclusions should follow these boundaries. It can say that authoritative-DNS reachability degraded, Neustar identified DDoS traffic, external monitors observed failures, and provider updates described mitigation and saturation. It cannot state an exact packet vector, universal customer outage, private topology or current remediation outcome without additional evidence.

Customer continuity requires more than a second provider name

A customer evaluating DNS continuity should begin with the consequence of failure. An informational site may tolerate a period of impaired resolution differently from an emergency, healthcare, financial or communications service. The acceptable design should follow the operational consequence rather than a generic maturity label.

For higher-consequence services, a tested plan may include:

external authoritative monitoring from diverse networks;
separate cached and non-cached tests;
an independently operated secondary provider;
automated and audited zone synchronization;
compatible DNSSEC signing and key procedures;
documented TTL strategy;
application behavior that distinguishes resolution failure from server failure;
an incident communication path that does not depend on the affected domain;
exercises that remove the primary provider from the path.

Each control can fail. A secondary can contain stale data. DNSSEC can prevent an inconsistent answer from validating. A low TTL can increase authoritative query demand. A high TTL can preserve an obsolete endpoint. An emergency communication page can depend on the same DNS provider.

That is why the continuity plan must be tested as running infrastructure. A tabletop discussion can identify owners and decisions. It cannot prove that delegation, signing, synchronization and routing work during provider loss.

Customers also need dependency inventories that are specific enough to act on. A row saying "UltraDNS" is not enough. The inventory should identify zones, name-server sets, provider accounts, secondary relationships, DNSSEC state, monitoring coverage, business services and recovery owners.

The goal is not to eliminate all external dependency. It is to make the dependency visible, proportionate and testable.

Provider remediation should be expressed as observable controls

A provider can improve resilience without promising that no future DDoS attack will cause degradation. The credible claim is narrower: detection, containment, routing, capacity, communication and restoration controls have been changed and tested.

Observable remediation could include:

broader external query monitoring by region and network;
alarms that distinguish authoritative software health from user reachability;
measured capacity and clean-traffic headroom by anycast site;
independent upstream and mitigation paths;
staged route and filter changes with rollback;
exercises that simulate saturation of a name-server segment;
customer notices tied to measurable service states;
post-event reports that separate confirmed facts from unknowns;
evidence that secondary-provider procedures work without creating inconsistent zones.

The public record reviewed here does not establish which later controls Neustar implemented or how effective they are today. That remains an explicit unknown. The article therefore describes a verification standard rather than asserting that the provider is currently resilient or deficient.

The standard is demanding because authoritative DNS is shared infrastructure. A provider may serve customers whose names support communications, identity, commerce and public services. A failure can propagate without changing customer application code. The operational evidence should match that concentration.

Monitoring must distinguish a healthy node from a reachable service

The UltraDNS evidence also shows why internal node monitoring is insufficient for authoritative DNS. A node can have power, a running process and available local capacity while users on an external network cannot reach the announced address or receive a timely answer. Conversely, one probe can fail because of its local access path while most of the service remains reachable.

An accountable monitoring design therefore needs several independent views. Node metrics should show software health, query processing, resource use and local packet loss. Network metrics should show route reachability, traffic by ingress path, saturation and mitigation state. Protocol tests should issue valid authoritative queries from diverse networks and confirm response codes, content, latency and DNSSEC behavior. Customer tests should verify that representative applications can perform new transactions that require fresh resolution.

The tests also need labels that preserve their limits. A probe in one city does not represent a continent. A test through one recursive resolver does not prove behavior through every resolver. A cached answer does not verify current authoritative reachability. A direct authoritative query does not show that the whole application works.

During an incident, these views should be joined by time. Engineers should be able to compare the first query failures with route changes, mitigation activation, carrier escalation, customer notices and recovery. This timeline helps distinguish attack effects from mitigation side effects and from unrelated access-network failure.

Restoration requires an explicit threshold. It might include a sustained success rate across diverse probes, normal latency distribution, stable route announcements, adequate clean-capacity margin and customer confirmation. The exact threshold can remain confidential where necessary, but the operator should be able to demonstrate that recovery was declared from measurements rather than the absence of new complaints.

This monitoring design also gives customers a usable signal. A provider notice that identifies affected regions, service classes and verification status can support a failover decision. A generic notice that engineers are investigating leaves customers to infer whether their zones, users or secondary paths are affected.

The purpose is not to create a larger dashboard. It is to preserve an evidence chain from authoritative node to user-visible resolution. That chain lets the provider and customer assign responsibility accurately, repair the correct control and test whether the repair changed the outcome.

The Heng.lu doctrine separates records from running service

DNS makes the difference between a record and a running system unusually clear. Delegation records identify the authoritative servers that should answer. Zone records describe names and addresses. Registry and provider records help identify responsibility. These are essential accountability ledgers.

They do not make the service available by declaration.

A correct delegation can point toward addresses that are unreachable from part of the internet. A valid zone can exist on a server whose upstream link is saturated. An anycast announcement can remain visible while the selected instance cannot answer within a usable boundary. A status notice can say mitigation is active while a particular customer path still fails.

The reality layer is observed behavior:

can resolvers reach the announced authoritative service;
do valid answers return within the expected time;
does routing distribute traffic without creating a saturated common mode;
do filters preserve legitimate queries;
does an independent secondary answer current data;
do external probes confirm restoration.

This is not an argument that records are unimportant. Accurate delegation and zone data are prerequisites for recovery and transfer. The principle is that the recordkeeper does not become a sovereign source of operational truth. Running code and observed network behavior determine availability.

The 2014 UltraDNS event belongs in this framework because the public evidence is about the gap between nominal authority and reachable authority. The delegation did not disappear. The path to usable answers degraded.

Legal and contractual conclusions remain outside the public evidence

The sources reviewed here do not establish a court finding, regulator determination, contract breach, negligence standard or customer entitlement. Service terms, customer designs and jurisdictions can differ. The article therefore does not infer legal liability from the severity of the event.

It also does not assume that every customer was promised independent infrastructure or uninterrupted availability. Pre-event architecture and marketing materials can describe capabilities, but the enforceable obligation depends on the actual contract and service terms.

The accountability analysis is operational. It asks which party controlled a safeguard, whether the safeguard was represented as part of the service, what evidence shows how it performed, and whether later remediation is testable.

Financial or social loss is not quantified in the attached public record. A DNS failure can interrupt transactions and access, but converting a monitoring interval into a dollar figure would require customer-specific evidence. The article does not do so.

Security also limits public detail. Providers should not publish information that materially helps an attacker bypass filters or target capacity. That limit does not justify a content-free postmortem. Broad cause, service classes, chronology, restoration milestones, control changes and verification methods can be disclosed without revealing exact defensive thresholds.

A rigorous exercise would test the whole dependency chain

The durable lesson from the event should be converted into exercises.

The first exercise should remove one anycast site or upstream path and observe query success from diverse networks. The goal is to detect whether traffic moves to independent capacity or concentrates on another fragile path.

The second should activate mitigation against representative attack traffic in a safe test environment. The test should measure legitimate-query loss, latency, clean capacity, route convergence and rollback.

The third should isolate part of a name-server segment. It should verify whether remaining servers have independent routes and current zone data.

The fourth should test a customer's independently operated secondary. It should verify delegation, synchronization, DNSSEC, monitoring and application behavior.

The fifth should test communication. The provider should issue a simulated update containing enough scope and service-state information for customers to decide whether to fail over, warn users or preserve evidence.

The sixth should test restoration evidence. Teams should reconstruct the incident from provider metrics, route records, mitigation actions, external probes, customer tests and communications.

An exercise that exposes failure is useful if it produces repair and retest. An untested architecture document is not comparable evidence.

The central lesson is verifiable authoritative reachability

The 30 April 2014 UltraDNS event was not merely a website outage at a DNS company. It was a failure of a shared authoritative layer used to translate names into reachable services.

The strongest public record is bounded. External monitors observed DNS failures, latency and packet loss. Neustar updates identified DDoS traffic, Tier-1 coordination, active mitigation, shifting vectors and intermittent Western US saturation affecting part of a named segment. [1][2][3] The public evidence does not disclose the exact packet vectors, traffic rate, actor, private topology, complete customer scope or current remediation effectiveness.

Accountability follows control. Neustar controlled the authoritative platform and response. Upstream partners controlled filtering and capacity in their networks. Customers controlled dependency design and external verification. Resolver and access networks shaped user paths. End users could report harm but could not repair the hidden infrastructure.

The Heng.lu principle provides the final test. Delegation and zone records identify authority and preserve responsibility. Only reachable routes, healthy authoritative software, adequate capacity, working mitigation, independent paths and external restoration checks prove continuity.

The responsible remediation is therefore not a claim that anycast or redundancy exists. It is evidence that the service remains reachable when one path, site, segment or provider fails, and a record that shows how the system behaved when those controls were needed.