The 2018 Route 53 Hijack Made BGP-to-DNS Trust an Accountability

Summary

Cloudflare's contemporaneous routing analysis recorded unauthorized more-specific announcements beginning shortly after 11:05 UTC on 24 April 2018 for /24 prefixes inside Amazon's covering Route 53 address ranges. The observed origin was eNet, AS10297, and some paths propagated through Hurricane Electric, AS6939. The abnormal routing state lasted roughly two hours. [1]
The mechanism was network infrastructure, not metaphor. Networks accepting the more-specific routes sent traffic for part of Amazon's authoritative DNS service toward the wrong origin. Systems reached over that path returned false answers for myetherwallet.com, allowing a legitimate domain query to direct users toward an impostor endpoint. [1]
The incident did not prove that Amazon originated the routes, that all Route 53 customers were affected, or that BGP by itself defeated TLS. Cloudflare reported that the impostor endpoint used a certificate that was not normally trusted. A user had to cross a browser warning for the described credential-theft path to succeed. [1]
Number-resource and registry records associated the address space with Amazon and AS16509, but routers acted on accepted route announcements. Registry truth remained essential evidence while running route state determined packet delivery. That difference is the central accountability surface. [7]-[9][14]
RPKI origin validation can turn an authorization record into an enforceable routing decision. AWS later documented extensive ROA coverage and rejection of RPKI-invalid routes in its network. Those later statements show a repair direction; they do not prove the exact controls deployed on every relevant network in April 2018. [3][4][17]-[19]
DNSSEC can let validating resolvers authenticate signed DNS data. It does not make a BGP route legitimate, restore reachability, or protect a zone that was not correctly signed and validated. The public packet does not establish the complete historical DNSSEC state for the relevant domain, so this article treats DNSSEC as a bounded conditional control. [5][6]
RouteViews, RIPE RIS and RIS Live, CAIDA BGPStream, RIPEstat, router logs, DNS response captures and certificate evidence answer different questions. None alone proves the entire incident, operator intent, every poisoned cache, or every loss. [8]-[13]
Accountability follows practical control over route origination, import filtering, resource authorization, monitoring, authoritative DNS, resolver validation, domain security, incident communication and proof of repair. It cannot be assigned by treating one registry entry, one route collector or one company name as sovereign over the whole path.

Two control planes met in one user-visible failure

The incident joined two systems that users normally encounter only through their results.

The first was interdomain routing. Border Gateway Protocol lets independently operated networks exchange reachability information. A route announcement says that a network can deliver traffic for a prefix through a particular path. BGP does not, by itself, provide a universal cryptographic proof that the origin is authorized to announce that address space. Operators add policy, filters, registry data, RPKI validation, monitoring and business relationships around the protocol. [14][15]

The second was the Domain Name System. An authoritative DNS service answers questions about a domain's records. Recursive resolvers ask authoritative servers, cache answers and return them to clients. Route 53 provided the authoritative server addresses involved in this event. If packets intended for those server addresses are redirected before reaching the legitimate service, a resolver may receive an answer from a system that should never have been authoritative. [1][5][6]

The user saw a domain name and expected the corresponding service. The network first had to decide where the authoritative DNS server addresses were reachable. The answering server then supplied an address for the domain. The browser finally had to decide whether the endpoint's certificate was trustworthy.

Those are separate decisions:

Which network is authorized to originate the DNS server prefixes?
Which route does each transit or access network accept?
Which server actually receives the resolver's query?
Is the DNS answer authentic?
Does the endpoint present a certificate trusted for the requested name?
Does the user or application stop when a trust check fails?

The April 2018 incident crossed each boundary in sequence. That is why describing it as only "a BGP hijack" is incomplete, while describing it as only "DNS poisoning" hides the route-control failure that made the false server reachable.

The chain is also why accountability cannot be assigned to one actor merely because its brand appeared in the service name. Amazon controlled its address resources, Route 53 operations, monitoring, communications and later route-security deployment. It did not control every external BGP speaker. The unauthorized origin and its upstream relationships controlled other points. Recursive resolver operators, the domain operator and browser or user behavior controlled later boundaries.

A rigorous account follows capability and evidence across the chain.

What the public routing record establishes

Cloudflare's technical post described BGP announcements observed between approximately 11:05 and 12:55 UTC. It listed five /24 prefixes in Amazon address space and showed paths involving AS10297 and AS6939. The legitimate covering ranges were /23s associated with Amazon, AS16509. [1]

The distinction between a /23 and a /24 is operationally important. Routing normally selects the longest matching prefix. A /24 covers a smaller address block than a /23. When both are available, the more-specific route can attract traffic even if the legitimate covering route remains visible.

That behavior makes an unauthorized more-specific announcement powerful. An attacker or misconfigured network does not necessarily need to erase the legitimate route. It can publish a narrower competing claim. Networks that accept and propagate it may redirect traffic for the smaller range.

Cloudflare's collectors saw Route 53 addresses inside those ranges. During the abnormal routing window, the answering systems served behavior specific to myetherwallet.com, including a false address, while some queries produced failures. Cloudflare also reported that its own 1.1.1.1 resolver was affected in selected locations. A resolver did not have to be operated by a network that directly accepted the bad announcement if its path to the authoritative server crossed a network that did. [1]

The record supports several bounded findings:

The prefixes were more specific than Amazon's covering routes.
The observed origin ASN did not match Amazon's AS16509.
At least one propagation path included AS6939.
The addresses were used by Route 53 authoritative DNS.
False answers for one domain were observed over the diverted path.
The routing state was geographically uneven rather than universally identical.

The same record does not prove:

Who issued every router command.
Whether AS10297 was deliberately compromised, internally misused or misconfigured.
Which contractual relationship permitted each propagation step.
Which networks rejected the routes.
Every recursive resolver that cached a false answer.
Every user who saw an impostor page.
Every financial loss attributed to the event.

This boundary matters because route collectors observe externally visible messages. They are strong evidence of what selected peers heard. They are not cameras inside every network operations center.

RouteViews provides archived update data for April 2018. RIPE RIS and RIS Live document another measurement system for BGP updates. CAIDA BGPStream offers a research platform for analyzing routing events. RIPEstat provides resource and routing views for AS16509 and AS10297. Together, these systems can test whether an account is consistent with public routing evidence. [8]-[13]

Their proper role is corroboration and reconstruction. An article should not turn a collector's limited vantage points into a claim of universal propagation.

Why registry truth did not force packet truth

The relevant address resources were associated with Amazon. That association mattered. It gave operators and investigators a reference against which to judge the unexpected origin.

It did not force every router to reject the announcement.

This is the difference between a record and an enforcement mechanism. A registry can preserve who holds a number resource, which ASN is expected to originate a prefix, and which contact or security metadata is associated with it. Routers still need running policy that consumes trustworthy data and applies a decision.

Without that step, an accurate record can coexist with an inaccurate route.

A sound infrastructure-accountability model treats registries as ledgers and recordkeepers rather than sovereigns. That framing fits the incident precisely. It does not diminish registry value. It locates the value correctly.

The address record supplies evidence. A Route Origin Authorization can supply cryptographically signed origin authority. A validator can classify a received route. Router policy can reject an invalid. Monitoring can alert when an unexpected origin appears. Operational teams can coordinate withdrawal and recovery. The running path emerges from all of those functions, not from a database declaration alone.

This accountability model also places running code above permission theater. An approved resource holder, a correct ticket or a published routing policy does not make packets follow the intended path. The route installed in the forwarding system is the operational fact. The DNS answer returned over that path is another fact. The certificate presented at the endpoint is another.

An accountable operator therefore needs reconciliation, not only registration:

Is every originated prefix covered by the intended authorization?
Does the maximum prefix length permit only intended more-specifics?
Are customer and peer filters generated from current, verified data?
Do routers reject RPKI-invalid origins?
Do monitors compare live origins with resource authority?
Can the team contact the relevant upstream and resource holder quickly?
Does the authoritative DNS service remain reachable from independent networks?

The 2018 event became harmful because the running route and the resource evidence diverged long enough for DNS traffic to reach an unauthorized answering system.

BGP origin validation is powerful and bounded

RPKI provides a way to bind IP prefixes to authorized origin ASNs through signed entities. A Route Origin Authorization identifies which ASN may originate a prefix and the maximum length allowed. Relying parties validate those entities. Routers can receive validated origin data and classify BGP routes as valid, invalid or not found. [17]-[19]

For an event in which a different ASN announces a more-specific prefix, this control is directly relevant.

Suppose Amazon authorizes AS16509 to originate a covering prefix and sets a maximum length that excludes the unauthorized /24. A route from AS10297 for that /24 should be RPKI-invalid. A network enforcing origin validation can reject it.

That is a concrete preventive mechanism. It converts number-resource authority into a routing decision.

It is not a complete account of Internet routing security.

Origin validation evaluates the relationship among a prefix, its length and the origin ASN. It does not authenticate every ASN in the path. A valid origin can still be involved in a route leak. A bad policy can still export routes beyond their intended scope. A stale or incorrect ROA can incorrectly invalidate legitimate routes. A network that does not perform validation can still accept and propagate an invalid route. [15]-[20]

RFC 7908 defines route leaks as propagation beyond intended policy scope. RFC 9234 adds BGP Roles and the Only-to-Customer attribute as a later mechanism for signaling and constraining certain leak patterns. Those controls address path-policy relationships that origin validation does not prove. [16][20]

The historical boundary is equally important.

AWS wrote in 2021 that more than 99 percent of its IPv4 and IPv6 address space was covered by ROAs and that it was dropping RPKI-invalid routes at its points of presence. In 2025, AWS described a broader RPKI implementation with additional safety checks and ongoing work on path authorization. [3][4]

Those statements show what AWS says it later deployed. They do not establish the exact ROA coverage, maximum lengths, external transit enforcement or monitoring configuration on 24 April 2018.

A responsible article therefore uses the later posts as remediation evidence:

AWS recognizes BGP origin hijacking as a material network risk.
It identifies AS16509 as a principal AWS ASN.
It describes ROAs and invalid-route rejection as controls.
It documents safety checks because RPKI errors can themselves affect connectivity.
It acknowledges that routing security requires cooperation across networks.

The article should not rewrite those later controls backward into the incident.

Route filtering remains an operator responsibility

RPKI is one source of authorization data. Operators also control what they accept from customers, peers and upstreams.

RFC 7454 discusses operational practices for BGP security and filtering. MANRS describes actions for preventing incorrect announcements, preventing spoofed traffic, supporting coordination and enabling global validation. [15][22]

The important question is not whether a network had a document titled "routing policy." It is whether the policy running on the relevant session would have rejected the observed announcement.

For a customer or small network, an upstream can maintain an allowlist of expected prefixes and ASNs. Prefix-count limits can constrain unexpected expansion. Maximum prefix-length rules can prevent narrower announcements that the customer is not authorized to export. RPKI validation can add cryptographic origin evidence. Alerts can identify a new origin or unexpected path before manual reports arrive.

Each control has maintenance costs and failure modes.

An allowlist can become stale. A prefix limit can block a legitimate expansion or be set too high to help. A route object can be inaccurate. A ROA can use the wrong maximum length. A monitor can alert without a responder or miss regions outside its vantage points.

That is why accountability asks for evidence of current operation:

The approved customer-prefix set and its source.
The date and owner of the last review.
The compiled filter installed on the router.
A test showing rejection of unauthorized more-specifics.
An alert generated by a controlled unexpected-origin exercise.
A contact and withdrawal path that works outside business hours.

The public record does not disclose every relevant configuration. The absence of that evidence should remain an unknown, not become an accusation. The article can still identify which evidence would distinguish a policy that exists on paper from one that changes route acceptance.

Authoritative DNS amplified the routing error

The diverted addresses were not ordinary web-server addresses. They belonged to Route 53 authoritative DNS infrastructure.

That role amplified the effect.

A recursive resolver seeking an answer for myetherwallet.com first needed to reach the domain's authoritative server. If BGP redirected that server traffic, the resolver could receive a false record. It might cache the response and serve it to clients until expiration or correction. A user whose own access network did not directly accept the unauthorized route could still receive a poisoned answer from a recursive resolver that did. [1]

This creates two geographic maps:

Networks whose routes to the authoritative server followed the unauthorized announcement.
Users whose recursive resolvers obtained and cached answers over those paths.

The maps overlap but are not identical.

That distinction explains why impact reports based only on end-user access networks can be incomplete. A resolver may sit in another network or region. A cached answer can outlive a route change. Conversely, a network may accept the route while a resolver's cache already contains a legitimate unexpired answer.

The accountability evidence should therefore include:

BGP updates and origin state.
Queries sent to the affected authoritative addresses.
DNS responses observed from multiple resolvers and vantage points.
TTL and cache-expiration behavior.
DNSSEC validation results, where applicable.
Certificate observations at the returned endpoint.
Timestamps for route withdrawal, corrected answers and cache recovery.

The event also shows why authoritative DNS is a high-leverage network dependency. A route change affecting a relatively small set of server addresses can influence resolution for domains delegated to those servers. That does not mean every Route 53 zone was affected. Cloudflare observed behavior focused on one domain. [1]

The correct claim is narrower: redirecting authoritative DNS traffic created a path for false answers that could affect users beyond networks directly accepting the bad route.

DNSSEC answers a different trust question

DNSSEC lets resolvers validate that DNS data is authentic within a signed chain of trust. Route 53 documentation describes both domain-registration and hosted-zone signing workflows. It explains that a validating resolver can reject DNS data that does not validate against the chain. [5][6]

That control is directly relevant to false DNS answers.

It is not a BGP control.

DNSSEC does not decide which ASN may announce an IP prefix. It does not make an authoritative server reachable. It does not stop traffic from being diverted. It lets a validating resolver ask whether the DNS data it received is cryptographically authentic.

If the relevant zone was correctly signed, the chain was intact, and the recursive resolver enforced validation, a forged answer without a valid signature should fail. A validation failure may protect integrity by returning an error, but it can still create an availability problem.

If the zone was unsigned, or the resolver did not validate, DNSSEC would not provide that protection.

The source packet does not establish the complete historical DNSSEC state of myetherwallet.com on 24 April 2018. It would be improper to claim that the domain had or lacked a specific configuration without additional primary evidence.

The accountable formulation is conditional:

RPKI can help validate route origin.
DNSSEC can help validate DNS data.
TLS can authenticate the endpoint to the browser.
None substitutes for the others.

The layered design is a strength only when applications stop on failure. A DNSSEC-valid answer sent over a diverted route can still be authentic if it came from the legitimate signer. A DNSSEC-invalid answer should fail at a validating resolver. A valid DNS answer can still point to a compromised application. A correct route can still carry malicious content. A certificate warning can still be ignored.

Accountability requires testing the failure behavior at each boundary.

TLS remained a visible stop signal

Cloudflare reported that the impostor endpoint presented a certificate that was not normally trusted. The domain name appeared correct in the certificate data, but the certificate was self-signed rather than chained to a trusted authority. A browser should display a warning. [1]

This evidence sets an important limit.

The BGP and DNS manipulation could direct a user to the wrong server. It did not automatically give the attacker a trusted certificate. The described theft path required users to proceed despite the warning or to use software that did not enforce the certificate boundary correctly.

That fact does not excuse the routing or DNS failures. Users should not be placed in front of an impostor endpoint. It does prevent an exaggerated claim that BGP made TLS irrelevant.

The incident instead shows layered defense under stress:

Route-origin checks could stop the diversion before DNS.
DNSSEC validation could stop a forged DNS answer for a signed zone.
TLS validation could stop trust in the impostor endpoint.
User-interface and application behavior could stop credential submission.

The remaining safeguard was imperfect. Users can click through warnings. Applications can mishandle validation. Some interfaces make risk difficult to understand. But the public evidence says the warning existed.

An accountability review should preserve defenses that worked while examining why earlier controls failed. Otherwise, the article would punish accurate evidence by flattening every layer into one total failure.

Responsibility follows practical control

The incident involved several actors with different capabilities.

The unauthorized origin and its network operators

The network identified as the observed origin controlled or was associated with the BGP session from which the more-specific routes appeared. Relevant evidence would include router configuration, authentication, account access, change records, customer relationships and incident logs. Public collectors show announcements attributed to an ASN; they do not identify the individual or system that issued them. [1][9]

Propagating upstreams and transit networks

Upstreams controlled import filters, customer-prefix authorization, maximum-prefix settings, origin validation and propagation. A route visible through AS6939 establishes a path observation, not a complete contract or negligence finding. The evidence question is whether the network had current controls that should have rejected the announcement and whether those controls were operating.

Amazon Web Services

AWS controlled the address resource, Route 53 service, public resource records, route-security posture, service monitoring and customer communication. It could publish ROAs, monitor unexpected origins, coordinate with peers and document corrective action. It could not unilaterally program every external router. Its later RPKI posts describe both internal validation and industry cooperation, which reflects that shared boundary. [3][4]

Recursive resolver operators

Resolver operators controlled which upstream paths their servers used, whether they validated DNSSEC, how they cached answers, what telemetry they retained and how quickly they flushed known false data. They did not originate the Route 53 prefixes or sign the domain zone.

The domain operator

The domain operator controlled delegation choices, DNSSEC signing, record management, TLS deployment, user communications and incident response. It did not control global BGP acceptance. The article should not infer the historical DNSSEC configuration without evidence.

Browser and application operators

Browser and client operators controlled certificate validation and warning behavior. Their protection formed a later boundary after routing and DNS had already failed.

Users

Users could stop at a certificate warning, but they did not control route origination, authoritative DNS infrastructure or resolver policy. Assigning primary responsibility to users because some may have clicked through would ignore the upstream controls that created the false path.

The responsibility map is not a formula for equal blame. It is a map of evidence and capability.

Detection should reconcile authorization, route and answer

A useful detection system would not watch only one layer.

Resource monitoring can compare live origin ASNs with ROAs and expected origins. Route collectors can identify a new more-specific announcement and its propagation. Authoritative DNS operators can probe service addresses from multiple networks. Resolver monitors can compare answers and validation status. Certificate monitors can identify unexpected endpoints.

Each signal can be noisy or incomplete.

A new origin may be a planned migration. A more-specific route may be legitimate traffic engineering. A DNS answer can vary intentionally. A certificate can rotate. A route collector may miss a region.

The answer is correlation with change authority:

Is the route covered by a current authorization?
Does the announcement match an approved deployment?
Do multiple independent collectors see it?
Do authoritative DNS probes return expected signed data?
Do resolver answers and certificate chains agree?
Has an accountable owner confirmed the change?

An alert should retain the evidence used in the decision. A transient BGP event can disappear before an investigation starts. RouteViews archives and RIPE RIS provide historical records; local router logs and DNS captures add operator-specific detail. [10]-[13]

Response also needs an authority map. Who can withdraw the route? Who can contact the origin and upstream? Who can update a ROA safely? Who can warn DNS customers? Who can identify and flush false resolver caches? Who can coordinate the domain and certificate response?

A dashboard without a response owner is not a control.

Repair must close the whole chain

Withdrawing the unauthorized route is necessary. It may not complete recovery.

Resolvers may retain cached false answers until TTL expiration or a flush. Users may have active sessions or compromised credentials. Domain operators may need to rotate secrets, investigate transactions and publish warnings. Route holders may need to correct ROAs, filters or monitoring. Upstreams may need to examine why the route was accepted.

The closure record should therefore separate:

Route correction time.
Global propagation decay.
Authoritative DNS answer correction.
Resolver cache recovery.
Certificate and endpoint verification.
User notification.
Credential or asset protection.
Long-term routing-control remediation.

These timestamps answer different questions. Declaring the incident closed when the route disappears can hide residual DNS or user harm. Waiting for every downstream consequence before declaring network recovery can also confuse the record.

A precise closeout says which layer recovered and what remains.

The later AWS RPKI deployment statements offer evidence of one long-term direction. They describe ROA coverage, invalid-route rejection and safety checks. The correct next question is whether current tests show the controls rejecting an equivalent unauthorized more-specific route without blocking legitimate service. [3][4]

For external networks, evidence can include customer-prefix filter generation, RPKI invalid rejection, route-leak detection and contact procedures. For DNS operators, it can include anycast reachability probes, signed-zone validation and resolver cache response. For domain operators, it can include DNSSEC state, certificate controls and a tested incident playbook.

Repair becomes accountable when it is testable.

A practical evidence agenda

Boards, regulators, customers and network operators do not need every private configuration line to ask useful questions. They need evidence tied to the control.

Number-resource authority

Which RIR records cover the address space?
Which ASNs are authorized to originate each prefix?
What maximum lengths are allowed?
Who owns ROA creation, review, expiry and emergency correction?
Are authorization changes independently approved?

Route acceptance

Which prefixes may each customer announce?
What source generates the filter?
How quickly does it update?
Are RPKI-invalid routes rejected?
Are unknown routes accepted under a documented risk policy?
Are maximum-prefix and more-specific limits tested?

Monitoring

Which collectors and internal feeds detect unexpected origins?
What is the alert threshold?
Can an alert distinguish a planned migration from a hijack?
Is there a 24-hour response owner?
Are route and DNS observations retained?

Authoritative DNS

Are service addresses probed from independent networks?
Are zones signed where required?
Do validating resolvers reject false data?
Can operators identify which caches received a bad answer?
Is customer communication independent of the affected DNS path?

Endpoint trust

Does the client reject an untrusted certificate?
Are warnings clear and difficult to bypass accidentally?
Can the domain operator revoke sessions and rotate credentials?
Is transaction monitoring connected to the incident timeline?

Proof of repair

Has an unauthorized-origin exercise been run?
Did filters and validation reject it?
Did monitoring alert before user reports?
Did authoritative DNS remain correct?
Did the response team complete the contact and withdrawal path?
Are exceptions, failures and retests recorded?

This agenda avoids the false choice between publishing sensitive configurations and offering only general reassurance. Evidence can be specific without exposing every private detail.

Why this control chain is specific

The accountability question is not simply whether BGP is insecure. In this event, interdomain routing determined which server answered queries for part of Route 53's authoritative DNS address space. The reached system then returned false DNS data for one domain, creating a path toward an impostor endpoint where TLS supplied a separate warning boundary. That sequence joins number-resource authorization, route acceptance, authoritative DNS integrity, resolver behavior and endpoint authentication. [1][14]

The Route 53 control chain therefore includes:

the targeted prefixes served authoritative DNS;
more-specific routes changed which server answered resolver queries;
false DNS data for one domain created an impostor endpoint path;
DNSSEC and TLS supplied separate integrity boundaries;
resolver cache behavior extended the analysis beyond direct route acceptance.

This is narrower than a generic route-leak analysis. Its specific question is how number-resource authorization and route filtering connect to DNS answer integrity and endpoint trust. The evidence must therefore show not only what route was accepted, but also which authoritative system was reached, what answer it returned, how resolvers handled that answer and whether the client preserved the final authentication boundary.

Source limitations

Cloudflare's 24 April 2018 post is the central contemporaneous technical source. It includes observed prefixes, times, AS paths, Route 53 address use, DNS behavior and the certificate boundary. Cloudflare was an observer and affected resolver operator, not a neutral court or regulator. Its collectors did not see every router. [1]

Cloudflare's later hijack-detection article explains its monitoring model and uses the same event as an example. It is useful for mechanism and remediation context, not independent corroboration of every 2018 detail. [2]

AWS's 2021 and 2025 routing-security posts are first-party descriptions of later controls. They do not prove the exact 2018 control state or external adoption. [3][4]

AWS Route 53 documentation explains DNSSEC and service behavior as documented later. It does not establish the relevant domain's full historical signing and validation state. [5][6]

AWS IP-range documentation and RIPEstat provide resource context. They do not prove intent or every operational relationship. [7]-[9]

RouteViews, RIPE RIS, RIS Live and CAIDA BGPStream provide public measurement capabilities. Their visibility depends on peers and collection points. They do not expose every private route, router configuration, DNS cache or operator decision. [10]-[13]

The RFCs define protocols, risk classes and recommended mechanisms. They are not evidence that a particular operator deployed a control or owed a particular legal duty. [14]-[20]

ARIN and MANRS documentation explains operational tools and norms. It does not establish compliance by every actor in the event. [21][22]

This article does not establish malicious intent by a named operator, criminal responsibility, negligence, contractual breach, a verified victim count, a verified total loss, complete cache poisoning, or durable remediation across every network. It does not claim that RPKI, DNSSEC or TLS alone would have prevented all harm.

These limitations are part of the accountability record. They identify what a stronger investigation would need.

Conclusion

The 2018 Route 53 hijack showed how a disagreement between number-resource authority and running route state can cross into DNS and user trust.

Registry and allocation records associated the prefixes with Amazon. Routers still accepted more-specific announcements from another origin. Recursive resolvers reached servers over those paths. False answers for myetherwallet.com directed users toward an impostor endpoint. TLS remained a later warning boundary rather than disappearing.

Each layer answered a different question:

Registry data: who holds the resource?
ROA and RPKI: which ASN may originate it?
BGP policy: which route will the network accept?
Route monitoring: what did the Internet announce?
Authoritative DNS: what answer did the reached server provide?
DNSSEC: is the DNS data authentic?
TLS: is the endpoint authenticated?
User and application behavior: does the transaction stop on failure?

Accountability follows the operators who could make those answers accurate and keep them aligned.

The strongest repair is not a claim that the address record was always correct. It is proof that incorrect running state is rejected, detected and contained. Resource holders maintain precise authorizations. Origin and transit networks enforce filters and validation. DNS operators observe reachability and answer integrity. Resolvers validate signed data. Browsers stop on invalid certificates. Incident teams retain a timestamped record from route change through cache and user recovery.

That is the operational reality layer. A registry is indispensable as a ledger. It is not sovereign over packets. Running code and installed policy decide where traffic goes. Number resources need uniqueness, accurate authorization, security metadata and operational continuity because the record must be useful to the systems that enforce it.

The event remains important not because it proves that one company controlled the entire Internet. It proves the opposite. Interdomain routing and DNS are shared systems. A repair that exists only at one entity can reduce risk but cannot guarantee the whole path. The accountable standard is therefore both local and cooperative: control what the operator can control, publish evidence of that control, and make the signals usable by the networks that must act with it.

The final test is operational. Announce an unauthorized more-specific route in a safe exercise. Verify that authorization data is correct, filters reject it, monitors alert, DNS answers remain authentic, clients preserve certificate checks, responders reach the responsible peers, and the retained evidence explains every decision.

If the exercise cannot be shown, the registry entry is still only a promise about the path. If it can, the record has become part of a working control.

The 2018 Route 53 Hijack Made BGP-to-DNS Trust an Accountability Test