The 2019 DNS Tampering Alerts Made Registrar Change Control an Accountability Test

Summary

• The public record from 2019 describes a shared infrastructure failure class, not a single proven campaign. CISA issued an operational directive after reported DNS tampering incidents; Mandiant published attributed incident research; ICANN issued a community alert while reporting no indication that its own systems were compromised; and Cisco Talos separately documented Sea Turtle in April and revisited that campaign in July. Their actor, victim, technique, geography and confidence claims must remain attached to the organizations that made them.[1][3][4][5][6]

• CISA’s January directive made the control problem concrete for most US federal civilian executive agencies. It required agencies to audit public DNS records, change credentials for accounts capable of modifying DNS, enable multi-factor authentication where available and monitor certificate-transparency data for certificates associated with agency domains. Those measures did not establish that every covered agency had been compromised. They identified authorization, observation and recovery controls that agencies needed to verify after a class of infrastructure tampering had been reported.[1][2]

• Mandiant reported DNS-record manipulation affecting dozens of government, telecommunications and Internet-infrastructure domains across several regions. Talos separately assessed that Sea Turtle had operated from at least early 2017 through the first quarter of 2019, reporting at least 40 affected organizations in 13 countries and distinguishing primary targets from infrastructure providers used as intermediate targets. Talos expressly separated Sea Turtle from DNSpionage and reported no evidence that root-zone servers were compromised.[4][5]

• A familiar domain name and a certificate accepted by a browser can coexist with unauthorized DNS state because the two checks answer limited questions. DNS tells a client where the currently published infrastructure says a name should lead. A certificate can show that the responding endpoint possesses a certificate valid for that name under the certificate authority’s rules. Neither result, by itself, proves that the registrant intended the preceding registrar, delegation or zone change. Talos reported that certificates helped some redirected services appear valid to users.[5]

• The relevant control path runs from the registrant’s account through a registrar and, for registry-held domain state, an EPP transaction to the registry; from there it reaches the parent-zone delegation, the authoritative DNS service, recursive resolvers and the endpoint selected by the returned records. Certificate issuance and browser or application reliance operate alongside that path. Responsibility therefore cannot be assigned to “DNS” as if it were one administrator: each organization controls a different authorization, publication, detection, evidence or rollback boundary.[13][14]

• NS, A, AAAA, MX, TTL and DS observations are not interchangeable. An NS change may alter which service is authoritative; an A or AAAA change may redirect a host without changing the delegation; an MX change affects mail routing; a TTL influences cache duration rather than destination authority; and a DS record participates in the DNSSEC chain between parent and child. Saying that “DNS changed” without identifying the record, zone, control interface and observation time obscures both the technique and the accountable operator.[15][16]

• Accountability should follow practical control rather than institutional proximity. Registrants control account hygiene and independent approval; registrars control customer authentication, EPP credentials, notifications and support escalation; registries control acceptance and recording of registry-level changes and publication of delegation state; authoritative operators control served zone data and rollback; certificate authorities control issuance under their policies; and relying organizations control monitoring and response.

  Coordinating bodies can recommend or require safeguards, but they do not operate every domain or approve every transaction.[3][7][8]

• This is fundamentally a network-infrastructure argument. Remove DNS provisioning, registrar and registry authorization, delegation publication, authoritative served state, resolver behavior and certificate reliance, and the accountability thesis collapses. What remains would be a generic account-compromise story, which cannot explain how unauthorized state became operational reality for users. The decisive evidence is therefore not merely that credentials were stolen, but which infrastructure accepted a change, what it published, who could observe it and how quickly the intended state could be restored.

The Evidence Boundary Is Narrow by Design

The 2019 reporting should be read as a sequence of public warnings about a category of DNS control failure. It should not be compressed into a single incident narrative. CISA, Mandiant, ICANN and Talos had different roles, evidence bases and intended audiences. CISA directed federal agencies to perform specific defensive actions. Mandiant described incident research. ICANN alerted participants in the domain-name ecosystem and recommended checks. Talos presented campaign-specific findings about Sea Turtle.

Similarities among the reports make comparison useful, but similarity does not prove shared operators, identical victims or a common technical sequence.[1][3][4][5]

That boundary matters because “DNS hijacking” can describe several materially different conditions. Someone may obtain a registrant’s registrar credentials and change delegation data. A registrar’s internal account or EPP credentials may be abused. An authoritative DNS provider account may be compromised while the registrar and registry remain untouched. A malicious or unauthorized operator may alter one zone record rather than the domain’s delegation. Different observers may also see different answers while caches expire. Each condition creates a different evidentiary trail and assigns prevention or recovery power to different parties.

The available public reporting does not supply the complete transaction history for every affected domain. It does not expose every registrar approval, registry event, authoritative-zone revision, resolver cache or certificate-validation exchange. Actor and victim claims must therefore retain their original attribution. Mandiant’s count and geographic characterization are Mandiant’s reporting, while Talos’s campaign dates, organization count and country count belong to Talos’s Sea Turtle assessment.[4][5] Neither can be silently applied to every incident that informed CISA’s directive.

Two negative findings are equally important. ICANN said it had no indication that ICANN’s own systems were compromised.[3] Talos reported no evidence that root-zone servers were attacked or compromised.[5] Those statements prevent an escalation from evidence of domain-level, registrar, registry or provider control failures to an unsupported claim that the global DNS root itself was taken over. They also sharpen the accountability question: serious redirection can occur through narrower operational interfaces without compromising the root or the coordinating institution.

How a Familiar Name Can Lead to Unauthorized Infrastructure

A user can type the correct domain, see the expected spelling and still be directed somewhere the registrant did not authorize. The name entered by the user is only the beginning of a resolution process. A recursive resolver follows the delegation visible in DNS, queries the authoritative service selected by that state and returns the relevant address or mail-routing data. If an unauthorized change has been accepted and published at the controlling layer, normal DNS behavior can faithfully deliver the wrong operational result.

Suppose the parent delegation has been changed to nameservers controlled by an unauthorized party. Resolvers following the delegation will ask those nameservers for answers. Alternatively, the delegation may remain intact while someone with access to the existing authoritative DNS service changes an A or AAAA record. In that case, the registrar and registry might show no change at all, yet users can still be directed to a different endpoint. A third case might involve an MX change affecting mail while the website continues to resolve normally.

The visible symptom depends on the specific state altered, not merely on the broad label “DNS tampering.”

Transport security begins after name resolution has selected an endpoint. A browser typically evaluates whether the endpoint presents a certificate whose identity covers the requested hostname, chains to an accepted trust anchor and satisfies applicable validity checks. That process does not ordinarily consult the registrant’s intended server inventory or ask whether a recent registrar transaction was approved through the organization’s internal change process.

Control over a relevant domain-validation path can therefore create circumstances in which a certificate is issued under a certificate authority’s rules for infrastructure the registrant did not intend to authorize. The resulting certificate may be cryptographically valid and may cause the browser to display an ordinary secure-connection indicator. That indicator says something important about the certificate and encrypted connection, but it does not certify the legitimacy of the earlier DNS change.

Talos reported that Sea Turtle operators redirected traffic after obtaining control over DNS records and, in some cases, used certificates that made the redirected service appear valid to the browser.[5] That finding belongs to Talos’s campaign reporting; it should not be generalized to every incident discussed by CISA, ICANN or Mandiant. CISA’s requirement to monitor certificate-transparency data is nonetheless revealing. Certificate observation can expose a consequence of changed domain control even when the DNS modification itself was missed by an organization’s primary monitoring.[1]

A valid-looking connection can therefore sit at the end of an unauthorized but technically coherent chain. The resolver follows published DNS state. The endpoint presents a certificate accepted for the requested name. The browser encrypts the session. Every component may perform its narrow protocol function while the overall result conflicts with organizational intent. The accountability failure lies in the gap between protocol-valid state and authorized state—and in whether the organizations controlling that state retained enough evidence to identify, contain and reverse the change.

Separate Reporting Streams Across 2019

January: CISA’s Operational Directive

On 22 January 2019, CISA issued Emergency Directive 19-01 in response to a series of reported incidents involving DNS infrastructure tampering. Its binding audience was most US federal civilian executive agencies, not every registrar, registry or private operator worldwide. The directive ordered agencies to audit public DNS records, reset credentials for accounts able to change DNS, enable multi-factor authentication where available and monitor certificate-transparency data for certificates issued in connection with agency domains.[1]

Those requirements reveal the failure model CISA wanted agencies to test. An audit compares intended records with externally visible state. Credential changes address the possibility that existing administrative secrets are no longer trustworthy. Multi-factor authentication adds another authorization boundary, although it cannot guarantee safety against every compromise. Certificate-transparency monitoring offers an observation point outside the registrar and authoritative DNS account.

CISA’s accompanying mitigation material treated the issue as a cross-boundary infrastructure risk rather than as a reason to assume that every agency or every DNS layer had failed in the same way.[2]

The directive is evidence that the threat warranted urgent operational verification. It is not an adjudication of one actor’s responsibility for every precipitating incident. It also does not establish that every covered agency discovered malicious records. Its evidentiary value is narrower and more useful: it identifies the controls that a large public-sector operator considered necessary when trust in DNS administrative state could no longer be assumed.

January: Mandiant’s Incident Research

Mandiant’s January reporting was a separate research stream. The company reported a wave of DNS hijacking involving dozens of government, telecommunications and Internet-infrastructure domains across several regions. It described attackers obtaining access that permitted DNS records to be changed and directing traffic toward infrastructure under attacker control.[4]

Those claims should remain attributed to Mandiant. “Dozens” is not a universal count for all incidents later mentioned by CISA or ICANN, and Mandiant’s geographic characterization should not be transferred to Talos’s separately counted Sea Turtle victims. The report supports the existence of a broad DNS-record-manipulation concern and helps explain why access to registrars, registries or DNS operators could have consequences beyond an ordinary account breach. It does not, standing alone, prove that every organization experienced the same record change, certificate sequence or compromise point.

The difference between Mandiant’s role and CISA’s is substantive. Mandiant described observations and an assessed incident pattern. CISA translated a public risk into mandatory federal actions. Treating the two as one report would blur the distinction between an investigator’s attributed findings and a government authority’s defensive directive.

February: ICANN’s Ecosystem Alert

ICANN’s 15 February alert brought attention to the risk across the domain-registration ecosystem. It referred to CISA’s directive, Mandiant’s research and other public reporting, while stating that ICANN had no indication its own systems were compromised.[3] That sentence is not a footnote to be discarded. It defines the institutional boundary of ICANN’s claim.

ICANN recommended measures including multi-factor authentication for administrative access, checking domain-registration and nameserver records, improving credential hygiene and monitoring important domain state.[3] These recommendations reflected ICANN’s coordinating position, but they did not mean ICANN operated the registrar account, authoritative zone or recovery process for every affected name. A registrar might maintain the customer interface and EPP channel. A registry might maintain the domain object and parent-zone delegation. A separate provider might host the authoritative zone.

The registrant might retain—or fail to retain—the internal approval record needed to show that a change was unauthorized.

Earlier ICANN Security and Stability Advisory Committee work had already discussed domain hijacking, registration-service safeguards, locks, authentication and emergency recovery boundaries.[7][8] Registrant guidance likewise emphasized protective account practices and the importance of documentation when attempting to recover a hijacked domain.[9][10] The February alert therefore did not invent the control problem. It showed that previously recognized registration risks had become urgent enough to require renewed, ecosystem-wide verification.

April: Talos Defines Sea Turtle as a Distinct Campaign

Cisco Talos’s April report described Sea Turtle as a distinct operation active from at least early 2017 through the first quarter of 2019. Talos reported at least 40 affected organizations in 13 countries and separated primary targets from secondary infrastructure providers, including registrars, telecommunications companies, Internet service providers and a registry.[5] Those numbers and classifications are Talos’s assessment of Sea Turtle; they are not totals for every DNS incident discussed elsewhere in 2019.

The distinction between primary and secondary targets is central to infrastructure accountability. A provider may be targeted not because its own public website is the final objective, but because its privileged position can enable changes affecting another organization’s domain. The provider’s role in the attack chain does not erase the registrant’s responsibilities, but it can make provider authentication, transaction records, access logs, notifications and emergency response decisive.

Talos expressly distinguished Sea Turtle from DNSpionage.[5] Similar use of DNS manipulation does not make the campaigns interchangeable. Sea Turtle must also remain separate from the entire set of events behind CISA’s directive and from every incident Mandiant described. Talos further reported no evidence that root-zone servers were attacked or compromised. The campaign’s significance arose from control over narrower but powerful infrastructure dependencies, not from control of the DNS root.

July: Talos Revisits Sea Turtle

Talos returned to Sea Turtle in July in a separate follow-up report.[6] That later publication should be treated as another timestamp in Talos’s campaign-specific reporting, not as permission to combine Sea Turtle with DNSpionage, append unrelated CISA incidents to its victim count or retroactively treat every April observation as a fact established by all other sources.

The April and July reports serve different chronological functions. The April report set out Talos’s principal campaign characterization, scope and infrastructure-provider distinction. The July report showed that Talos continued to track and report the operation after the initial public disclosure.[5][6] Any added observation belongs to that later reporting date and to Talos’s evidence base. Keeping the publications separate preserves when a claim became public, whose confidence supported it and which response decisions could reasonably have relied on it.

The End-to-End DNS Control Path

DNS change control cannot be assessed at one console because the operational path crosses several independently administered systems. The same company may perform more than one role, but the roles remain analytically distinct.

The registrant begins with organizational intent. It decides who may manage the domain, which registrar and DNS providers to use, which nameservers and records should exist, and how changes should be approved. Its strongest evidence includes named administrators, separate recovery contacts, protected credentials, internal approvals and an independently maintained record of expected DNS state. If the registrant cannot establish what it intended, recovery becomes harder even when a provider retains technically complete logs.

The registrar supplies the registrant-facing account and commonly acts as the client that provisions registry-held domain state. Its responsibilities include customer authentication, privilege separation, protection of EPP credentials, transaction logging, change notifications and an escalation path capable of responding when the ordinary account is suspected of compromise. A client-side registrar lock can reduce accidental or unauthorized transfers, but it cannot be assumed to stop an operator who has compromised the registrar’s privileged systems or can legitimately clear the status through the same administrative path.

EPP provides a structured channel through which a registrar can create, update, transfer or otherwise manage a registry domain object. RFC 5731 defines domain-object commands and status semantics; it does not decide whether the human or system initiating a permitted command possessed the registrant’s genuine organizational authorization.[13] Protocol-valid execution is evidence that an accepted command occurred, not conclusive evidence that the underlying decision was legitimate.

The registry records domain-level state for its top-level domain, applies server-side status where appropriate and publishes the parent-zone delegation derived from accepted data. It is an operational ledger and recordkeeper for that layer, not the sovereign judge of every organization’s intended online identity. Its accountability concerns whether changes were accepted through authorized channels, whether stronger restrictions or out-of-band procedures were available, what transaction evidence was retained and how quickly disputed state could be stopped or reversed.

Delegation connects the parent zone to the child domain’s authoritative service. Parent-side NS data identifies the nameservers to which resolvers should turn, while glue addresses may be published when necessary to make those nameservers reachable. DS data, when present, links the parent’s authenticated view to DNSSEC material in the child. These are powerful claims, but they do not contain every record served by the child zone.

The authoritative DNS operator publishes the child zone’s operational answers. It may be the registrar, the registrant or an independent managed-DNS provider. Its system can often change A, AAAA, MX, TXT and other records without any EPP update or registry transaction. That boundary is crucial: an unchanged registry history does not prove that the served zone remained unchanged. The authoritative operator’s access logs, revision history, zone snapshots, approval controls and rollback capability may provide the only direct evidence of a record-level alteration.

Recursive resolvers then retrieve and cache the published answers. Their caches make DNS usable at scale but introduce time into the evidence. Two observers can receive different answers because they query different resolvers, reach different authoritative servers or hold records with different remaining cache lifetimes. A post-incident lookup therefore cannot, by itself, reconstruct exactly what every user saw during the event.

The endpoint selected by DNS participates in a separate certificate and application layer. Certificate authorities decide whether to issue under their validation rules. Certificate-transparency systems create an external observation channel. Browsers and applications decide whether to accept the presented certificate and establish an encrypted connection. Those controls can expose or constrain abuse, but they do not replace registrar approval records, registry transaction evidence or authoritative-zone history.

Every link has a different rollback function. The registrant can withdraw authority and supply evidence of intended state. The registrar can secure the customer account and submit corrective registry changes. The registry can restrict or reverse registry-held state. The authoritative operator can restore a prior zone version. Resolvers generally age out cached data according to applicable TTLs, while urgent interventions may require additional coordination. Certificate authorities can act within their revocation and issuance processes.

No single participant can reliably reconstruct or reverse the complete chain without evidence and cooperation from the others.

Record Types Must Remain Separate Accountability Claims

An incident report that says only “the DNS record was changed” leaves the central control question unanswered. The record type, the zone in which it appeared, the interface used to alter it and the time at which it was observed determine both the operational effect and the likely evidence holder.

An NS claim concerns nameserver authority. Parent-zone NS data can redirect resolution toward a different authoritative service. The child zone also commonly contains an apex NS set, and the two views can differ during error, transition or abuse. Evidence that an observer received an answer from an unexpected nameserver does not automatically prove that the registry was compromised. Investigators must determine whether the parent delegation changed, whether cached data was involved, whether glue changed and whether the expected authoritative provider itself served altered information.

An A claim maps a name to an IPv4 address, while an AAAA claim maps it to an IPv6 address. Either can redirect a web or application endpoint without changing the domain’s delegation. A zone administrator at the authoritative provider may be able to alter those records directly. Evidence of an A-record change therefore cannot be restated as evidence of an EPP transaction, registrar compromise or registry change unless supporting records establish that path. IPv4 and IPv6 observations must also remain separate because clients may select different address families and see different destinations.

An MX claim concerns mail routing. Changing it can direct email toward different receiving infrastructure even while web A and AAAA records remain correct. The destination named in an MX record then requires its own address resolution. A mail-routing incident consequently may involve the MX RRset, address records for the mail host or both. It should not be reported as a website redirection unless the web records also changed.

A TTL claim concerns cache lifetime. TTL does not designate the rightful operator and does not itself point traffic to a destination. It influences how long resolvers may reuse an answer and therefore affects propagation, persistence, observation and rollback. A low TTL may allow changed data to spread and later clear more quickly; a high TTL may leave prior data in caches longer. Neither value, standing alone, proves malicious intent. Historical TTL observations are useful only when tied to a particular RRset, response and time.

A DS claim concerns DNSSEC delegation. DS data in the parent associates the child delegation with DNSSEC key material and helps establish an authenticated chain of trust. RFC 5910 defines how DNSSEC-related data can be represented in EPP, while the core DNSSEC specifications describe how validators authenticate DNS data through the configured chain.[14][15][16] DNSSEC validation can show that an answer is consistent with that chain; it does not establish that the organization intended every provisioning action that created the chain’s current state.

This is why DNSSEC is not a universal answer to compromised provisioning authority. If an unauthorized operator can use a channel that the registrar, registry or DNS provider accepts as authorized, that operator may be able to change delegation or DNSSEC-related state. The resulting trust chain can then authenticate state that conflicts with the registrant’s intent. Operational DNSSEC guidance emphasizes careful key, delegation and rollover management precisely because availability and authenticity depend on coordinated state across administrative boundaries.[17]

Later standards concerning stronger EPP authorization and DNSSEC operations can inform present-day control design, but they cannot be treated as proof that every operator deployed those controls during the 2019 events.[18][21] The historical accountability question remains specific: which interface accepted the disputed change, which system published it, what evidence recorded it, and which party could reverse it?

Finally, delegation is a composite operational claim rather than a synonym for every DNS record. It encompasses the parent’s direction to authoritative nameservers and may include glue and DNSSEC linkage. A malicious A record served from the registrant’s existing authoritative provider is a serious DNS compromise, but it is not necessarily a delegation change. Conversely, a changed delegation can shift control over many child-zone answers without requiring each prior A, AAAA or MX record to be edited individually.

These distinctions determine what can responsibly be concluded. An unexpected address proves an observed answer, not its authorization history. An unexpected nameserver suggests a delegation or authority discrepancy, not automatically a root-zone compromise. A certificate accepted for the name establishes a certificate-layer result, not approval of the DNS transaction. Only a joined timeline of registrar records, EPP and registry history, parent-zone state, authoritative-zone revisions, resolver observations and certificate evidence can show how unauthorized administrative state became the network state users actually received.

The 2019 Alerts Turned Every Control Boundary Into an Evidence Boundary

The 2019 response made clear that “the domain owner” was too imprecise a unit of accountability. CISA directed affected federal agencies to audit public DNS records, reset credentials for accounts capable of changing DNS, enable multi-factor authentication where available and monitor certificate-transparency data.

Its companion guidance placed those measures within a broader effort to detect and limit DNS infrastructure tampering.[1][2] ICANN similarly urged registrants and operators to verify domain and nameserver records, strengthen administrative access and monitor for unauthorized changes, while stating that it had no indication its own systems had been compromised.[3]

Those measures crossed several independently operated systems. A registrant could secure its account but could not inspect a registrar’s privileged support activity. A registrar could authenticate a customer and transmit an EPP command but could not determine what every recursive resolver still held in cache. A registry could record an accepted update and publish a delegation without knowing whether the registrar’s authorization decision reflected the registrant’s real intent. An authoritative DNS operator could restore a zone but could not revoke an unexpectedly issued certificate.

Accountability therefore has to follow practical control, retained evidence, visibility of failure and actual recovery authority.

Party	Practical control	Evidence that should be retained	Visibility of failure	Recovery authority
Registrant	Administrative accounts, designated contacts, approval of intended changes, provider selection and internal separation of duties	Account-access history, MFA enrollment and recovery events, contact changes, internal approvals, provider notices and independent snapshots of expected DNS state	Can compare intended configuration with provider dashboards, notices and external observations, but may not see registrar, registry or authoritative-operator internals	Can reset its accounts, replace contacts, revoke internal access and request restoration; it usually cannot directly rewrite registry records, provider logs or CA records
Registrar	Customer authentication, privileged support access, registrar-side locks, EPP client credentials, submission of domain updates and escalation to the registry	Authentication events, support chronology, privileged-access logs, EPP transaction identifiers, before-and-after object values, status history, notices and emergency actions	Can see customer-account and EPP activity, but may not immediately see all authoritative answers, cached responses or downstream certificate use	Can freeze customer changes, reset credentials, restore registrar-managed settings, submit corrective EPP commands and invoke registry emergency procedures
Registry	Acceptance of EPP changes, server-side domain status, parent-zone delegation publication, registry-lock procedures and, where offered, out-of-band confirmation	EPP server records, client and server transaction identifiers, domain-status history, delegation and DS history, lock approvals and publication timestamps	Can see what the sponsoring registrar submitted and what the registry accepted, but not necessarily whether the submission reflected genuine organizational authorization	Can reject or reverse permitted changes, place server-side restrictions, restore recorded state and coordinate exceptional recovery within its technical and policy authority
Authoritative DNS operator	Zone administration, publication of authoritative records, signing operations, logging, version control and rollback	Zone versions, change tickets, administrative and API logs, DNSSEC signing history, response logs where retained, publication timestamps and rollback records	Can see the zone it serves and its own administrative events, but may not see changes at the registrar, registry, certificate authority or recursive layer	Can restore a prior approved zone, rotate compromised operator credentials and validate authoritative service; it cannot alone repair a changed parent delegation or DS record
Certificate authority	Domain-control validation, certificate issuance, revocation and preservation of validation records	Validation method and result, request and issuance timestamps, certificate identifiers, revocation activity and related audit records	Can see whether its validation condition was satisfied, but not whether the party satisfying it had organizational authorization	Can stop, revoke or replace certificates under its procedures; it cannot restore DNS or determine the entire incident’s ownership chain
Relying organization	External DNS and certificate monitoring, application response, session management, credential protection and user communication	Resolver observations, certificate-transparency alerts, application and identity logs, incident notices, resets and post-repair tests	May see user-facing redirection, authentication anomalies or certificate changes before a provider confirms the control-plane cause	Can protect its users and systems, invalidate sessions, reset credentials, restrict affected services and communicate risk; it cannot rewrite another operator’s infrastructure
Public or coordinating body	Directives, recommendations, reporting channels, sector coordination and requirements within a defined mandate	Advisories, notification timestamps, submissions, coordination records and compliance responses	May aggregate reports across organizations but normally lacks complete access to private operational logs	Can coordinate and require bounded action where authorized; it does not operate every registrant account, registrar, registry, name server or certificate authority

This is an operational matrix, not a table of legal liability. The public reports do not disclose every organization’s internal logs, every approval decision, the complete victim set or a final apportionment of cause.

Mandiant’s reporting, the two Talos investigations and the federal alerts described overlapping aspects of a failure class, but they did not establish that every observed incident belonged to one campaign or followed an identical chain.[4][5][6] Talos distinguished Sea Turtle from DNSpionage and reported no evidence that root-zone servers had been compromised.[5] That boundary matters: responsibility should be tested against a party’s actual control and evidence, not assigned collectively to “the DNS.”

Registrant Controls After the January and February Warnings

Registrant accountability begins with the authority the registrant actually possesses. Administrative accounts should not share credentials with ordinary user accounts; personnel who request sensitive changes should not be the only people able to approve them; and recovery contacts should be maintained through channels that do not depend entirely on the domain being protected. Earlier ICANN guidance had already emphasized registrar locks, account protection and accurate contact information, while its recovery guidance stressed the importance of documentation when a hijacked name has to be restored.[7][9][10]

Separation of duties is especially valuable for changes to nameservers, delegation data, DNSSEC material, recovery contacts and account-level security. A second approval does not make a change legitimate by itself, but it creates another opportunity to compare the request with a known business purpose. The approval should be preserved with the requester, approver, time, affected domain, old value, proposed value and channel used. An approval visible only inside the same potentially compromised account is weak evidence.

Recovery design deserves the same scrutiny as login design. MFA enrollment, removal and recovery should produce durable records and independent notices. A support process that can disable MFA after answering weak biographical questions can become a parallel authentication system with lower assurance than the primary login. A recovery address hosted solely beneath the affected domain can also become unreliable when mail routing or delegation is disputed.

ICANN’s registrant and recovery guidance supports maintaining accurate, usable contact and ownership documentation, but the public record does not show which specific victims had adopted those practices before the 2019 alerts.[9][10]

Independent monitoring extends the registrant’s visibility beyond a provider dashboard. A registrant should retain an expected-state record and compare it with authoritative answers and observations from multiple external networks. That does not make the registrant responsible for a registrar’s EPP credentials, a registry’s server-side controls, an outsourced DNS operator’s logs or a certificate authority’s validation decision. It gives the registrant evidence with which to detect a divergence and ask the correct operator to act.

Registrar Change Control Became the Central Accountability Test

The registrar sits at a consequential boundary: it translates customer authorization into changes that may be accepted by a registry. Registrar accountability therefore reaches beyond whether an ordinary customer password was correct. It includes customer authentication, MFA and recovery handling, privileged support access, internal administrative tools, protection of EPP client credentials, change notices and the ability to escalate an emergency.

SAC040 placed authentication, operational security and protection of registration services at the center of anti-abuse measures years before the 2019 events.[8] The 2019 alerts made the evidentiary consequences harder to ignore. If an unauthorized change appeared, investigators needed to know whether it came through the normal customer interface, a recovery process, a support employee, an internal privileged account or a registrar-to-registry channel. A generic audit entry saying that “the account changed” would not distinguish those possibilities.

Every sensitive registrar action should therefore create an immutable or independently protected change history. That history should identify the authenticated principal, the acting privileged account if different, the MFA state, the recovery or support path used, the old and new values, the relevant lock state, the client and server transaction identifiers returned by EPP, and the notices sent to the customer.

EPP’s domain mapping supplies defined update and status semantics, making domain-object changes recordable in a structured way.[13] Where DNSSEC data is provisioned through EPP, its separate extension similarly makes additions, removals and replacements of security data events that can be logged and reconciled.[14]

Privileged support deserves distinct treatment because it often exists to solve exactly the cases in which normal authentication fails. Emergency access may be necessary, but it should not disappear into an undifferentiated help-desk record. The support chronology should show who opened the case, what evidence was presented, who approved any override, what change was made, when the registrant was notified and whether an independent callback or other out-of-band confirmation occurred. Shared support identities and mutable notes frustrate both accountability and recovery.

Customer notices should be specific enough to be actionable. A useful notice identifies the domain, the category of change, its time, the channel that authorized it and where to report a dispute, without exposing credentials. Notices should go to more than the account inbox when a sensitive change affects the very domain carrying that inbox. A notification is not prevention, but it can shorten the interval between an unauthorized change and containment.

The registrar also needs a documented emergency escalation path to the registry and authoritative operator. That path should allow a disputed change to be frozen while records are preserved, rather than encouraging repeated edits that destroy chronology. The registrar should be able to identify the last verified state and associate each attempted repair with its EPP transaction record. None of this establishes that registrar control failed in every 2019 incident; the public reporting does not provide a complete set of registrar logs or internal decisions. It establishes what evidence is necessary to make a bounded finding.

Registry Records: Operational Authority Without Sovereign Ownership

A registry records domain objects, accepts or rejects changes from authorized registrar clients and publishes relevant delegation state into its zone. RFC 5731 defines client- and server-set status values and the semantics of domain updates and transfers.[13] These statuses make an important distinction possible: a registrar-side restriction and a registry-imposed restriction are not the same control, even when both are described informally as a “lock.”

The registry’s record is authoritative evidence of what its systems accepted and published. It is not conclusive evidence that a person or organization genuinely intended the change. An authenticated registrar session may show the route through which a transaction arrived; it does not resolve whether the registrar account, support path or internal privilege was properly used. The registry is therefore a ledger and operational recordkeeper, not the sovereign owner of a domain’s legitimacy.

That ledger role still carries substantial responsibilities. The registry should preserve server-side status history, the sponsoring registrar, accepted transaction identifiers, the prior and resulting delegation, relevant timestamps and any DS changes. If a disputed update is reversed, the reversal should not overwrite the original event. Before-and-after snapshots and an append-only chronology allow investigators to distinguish initial unauthorized state, containment actions and final restoration.

A registry-lock service can add stronger friction by applying server-side restrictions and requiring an out-of-band process before high-impact changes are accepted. The exact implementation varies, so the label alone is not proof of a particular control. The evidence should show which statuses were active, which change categories they covered, who requested release, who confirmed it, through what independent channel and for what time window. A registry lock can still be undermined by weaknesses in enrollment, confirmation, emergency override or privileged operation; no control is infallible.

Registry recovery also has limits. A registry may be able to restrict or restore the domain object and republish delegation data, but it does not automatically control the child zone, cached resolver state, certificates, application sessions or credentials already exposed elsewhere. ICANN’s framework for registry responses provides coordinating context for security threats, but it does not make every registry the universal incident commander.[12] The 2021 DNS Security Facilitation Initiative report offers later retrospective control analysis and must not be treated as proof of controls deployed across registries in 2019.[11]

Authoritative DNS Evidence and TTL-Aware Restoration

The authoritative DNS operator controls what its servers publish from the zone under its administration. That served state is the operational reality seen by resolvers, subject to delegation and caching. Accountability at this layer requires more than a current zone-file export. The operator should retain versioned zone snapshots, administrative and API access logs, change requests, approver identity, publication times, signing events and rollback actions.

Before-and-after record snapshots should cover the records material to the incident and the surrounding delegation context. They should include collection time, vantage, TTL, DNSSEC validation result where applicable and enough provenance to distinguish a provider-dashboard display from an answer actually served by an authoritative system. The purpose is not to assume that every reported incident altered every type of record. It is to document which state changed in the case under examination.

Rollback must be TTL-aware. Correcting an authoritative record does not instantly erase every cached answer. Responders need the prior TTLs, the time at which the repaired state became authoritative and observations made before and after relevant cache intervals. Multi-vantage verification should query from independent networks and distinguish authoritative responses from recursive results. A single successful lookup from the operator’s own environment is weak proof that users elsewhere have recovered.

DNSSEC adds another evidence layer but does not collapse the accountability chain. Its core specifications describe authentication of DNS data and validation through a configured chain of trust.[15][16] Operational guidance explains the care required in signing and key management.[17] If authorized provisioning channels are compromised and delegation or DS state is changed through those channels, the resulting chain may authenticate state that does not represent the organization’s true intent. The recovery record therefore needs both child-zone signing history and parent-side DS history, with timestamps and transaction provenance.

RFC 9364 discusses later automation for DNSSEC bootstrapping; it is later standards context, not evidence that such automation protected the organizations discussed in 2019.[21]

Certificates Could Look Valid Without Proving Organizational Consent

The 2019 response also exposed a limit in what a valid certificate can establish. CISA required agencies to monitor certificate-transparency data, and public incident reporting described cases in which redirected services used certificates that appeared valid to browsers.[1][4][5] That does not mean the certificates were necessarily forged. If a certificate authority’s domain-control validation condition was satisfied while DNS control was unauthorized, issuance could be technically valid under the CA’s process while lacking authorization from the affected organization.

A certificate authority should retain the validation method, evidence received, request time, validation result, issuing account, certificate identifiers and any later revocation or replacement action. Those records answer whether the CA followed its domain-control procedure. They do not, by themselves, answer who inside the registrant intended the request or whether control of the domain was legitimate.

Certificate-transparency monitoring gives registrants and relying organizations an independent detection channel. An alert should be preserved with the certificate identity, observed names, log timestamp, alert delivery time and triage outcome. The alert is not proof that a certificate was malicious or used in an incident; it is a prompt to compare issuance with known organizational activity. Likewise, absence of an alert does not prove that DNS state remained correct.

Relying organizations control a different part of recovery. They can examine resolver, application and identity logs; suspend affected authentication flows; invalidate sessions; reset credentials; warn users; and confirm that services reach the intended systems after DNS repair.

CISA’s current domain-trust taxonomy helps describe the broader risk of adversary-controlled domain infrastructure, but it is present-day analytic context rather than evidence of what any organization detected or deployed in 2019.[20] NIST’s DNS deployment guidance similarly provides operational context; it should not be read as an inventory of controls in place at the time of the alerts.[19]

Registrar Lock, Registry Lock and the Limits of Recovery Channels

“Lock the domain” is useful advice only when the control is named precisely. A registrar lock commonly corresponds to a client-set prohibition on transfer or another registrar-managed restriction. It can reduce unauthorized transfer risk, but a transfer restriction does not necessarily prevent every nameserver, DNS-hosting, contact or DNSSEC change available through a compromised account. The active status values and covered operations must be examined rather than inferred from a dashboard label.[13]

A registry lock generally places restrictions at the registry and can require additional confirmation before the registry accepts specified changes. That additional boundary can remain effective when an ordinary registrar account is compromised, but it is not absolute. Its value depends on enrollment integrity, the range of protected operations, separation of the confirmation channel, privileged override controls and the quality of emergency procedures.

Transfer authorization data presents a related but narrower control problem. RFC 9154 later strengthened the treatment of EPP transfer authorization information. Because it postdates the 2019 alerts, it is useful as later standards context, not evidence that the stronger mechanism was deployed during the reported events.[18] Transfer controls also should not be confused with controls over ordinary updates or delegation publication.

MFA is similarly bounded. It can reduce the chance that one stolen password is sufficient, which is why CISA and ICANN emphasized it in their 2019 response.[1][3] Its effect depends on which accounts are covered, whether privileged support and API access use equivalent safeguards, how enrollment changes are approved and how recovery works. A weak recovery channel can neutralize a strong login factor.

A compromised authenticated session, malicious insider or badly governed emergency override can bypass assumptions that “MFA was enabled.” The relevant evidence is not a present-day checkbox but the enrollment, challenge, recovery and override history at the time of the change.

Reconstructing the Incident From Prevention Through Durable Proof

A defensible response sequence separates six functions that are often compressed into the single instruction to “secure and restore DNS.”

1. Prevention — establish control boundaries before a disputed change.
   The organization should inventory its domains, registrars, registries, authoritative DNS providers, certificate authorities, responsible personnel and emergency contacts. It should define expected nameserver, address, mail-routing and DNSSEC state; apply appropriately scoped registrar or registry locks; protect customer and privileged accounts; separate request from approval; and secure recovery channels. CISA’s 2019 directive concentrated on record audits, credential changes, MFA and certificate-transparency monitoring, while ICANN’s alert and earlier security guidance supplied broader registration-control context.[1][3][7][8] These measures reduce risk but do not prove that no unauthorized change can occur.

2. Detection — compare intended state with independently observed state.
   Monitoring should combine registrar and registry notices, authoritative-zone checks, independent recursive observations and certificate-transparency alerts. Each observation needs a timestamp, vantage, record value, TTL and validation result. Monitoring from multiple networks helps distinguish a local resolver problem, cached data and a broadly published authoritative change. A detected difference should be treated as an anomaly requiring validation, not immediate proof of malicious activity or a particular actor.

3. Containment — stop further change while preserving chronology.
   Once a change is disputed, the relevant operators should restrict further modifications, preserve active sessions and logs where safely possible, disable or reset compromised credentials, and invoke the established registrar, registry, DNS-provider and certificate-authority escalation paths. The response should avoid uncontrolled repeated edits that obscure which action produced which state. Privileged-access logs, support notes, EPP identifiers and copies of notices should be secured before ordinary retention cycles or account resets erase useful context.

4. Rollback — restore the last approved state across every affected layer.
   Restoration should start from a verified baseline, not merely from the most recent dashboard value. The registrar and registry should reconcile domain status, delegation and transaction history; the authoritative operator should restore approved zone content; DNSSEC recovery should reconcile child signing state with parent DS state; and certificate authorities should evaluate unexpected issuance under their procedures. Rollback times should be recorded against the earlier TTLs, followed by authoritative and recursive checks from multiple vantage points. A corrected zone is not yet proof of complete recovery if stale answers, incorrect DS data, unrevoked certificates or exposed credentials remain.

5. Communication — tell each affected party what is known without outrunning the evidence.
   Incident notices should identify the affected service, the observed time range, the state known to have changed, the containment action, any credential-reset requirement and the next verification point. Registrants, providers, relying organizations and public bodies may need different levels of detail. Communications should separate confirmed operational facts from attributed assessments. They should not imply that every customer was affected, that every 2019 report described one actor, or that one control failure explains all harm. Coordinating bodies can request action and aggregate reports, but those functions do not transfer operational control of every domain to them.[2][3][6]

6. Durable proof — preserve a record that survives the repair itself.
   The final evidence set should contain before-and-after DNS record snapshots; EPP client and server transaction identifiers; registrar and registry domain-status history; privileged-access logs; MFA enrollment, removal and recovery events; out-of-band approvals; the complete support chronology; delegation, DNSSEC and DS history; independent DNS observations from multiple vantage points; certificate-transparency alerts; CA validation and issuance records; authoritative-zone and access logs; incident notices; credential-reset records; and post-repair validation results. Each item should carry its source, collection time, integrity information and custodian. Where a record does not exist or was not retained, that absence should be stated rather than reconstructed as certainty.

Taken together, those records can show the difference between intended state, accepted registry state, published authoritative state, cached observations and certificate issuance. They can establish when a failure became visible, which operator possessed recovery authority at each stage and whether repaired state propagated as expected. They cannot automatically reveal unavailable internal logs, undisclosed decision ownership, the complete set of affected organizations or the proportion of harm caused by each contributing control failure. Those questions remain bounded by the evidence actually retained.

What DNSSEC Proves—and What It Does Not

DNSSEC narrows an important question, but it does not answer the whole accountability question. A validating resolver uses signatures, DNSKEY records, DS records and a configured trust chain to determine whether an RRset is consistent with the cryptographic authority represented by that chain. Successful validation supports data origin authentication and integrity within that configuration. It does not establish that a registrant’s executives approved the change, that a registrar followed its internal authorization procedure, or that the published records reflect the organization’s business intent.[15][16]

That distinction matters directly to the 2019 tampering alerts. If an unauthorized party merely substitutes unsigned data while the legitimate DNSSEC chain remains intact, a validating resolver should reject the mismatch as bogus. DNSSEC can therefore make some forms of off-path alteration materially harder and more visible. But that is different from an intruder gaining control of an authorized provisioning channel, a zone-management system or signing infrastructure.

A compromised authorized channel can produce cryptographically coherent but organizationally wrong state. If an intruder can cause the legitimate signer to sign altered address, mail or nameserver records, the resulting signatures may validate because the signing system has authenticated the data it was instructed to publish. If the intruder can use an authorized registrar-to-registry path to replace delegation and DS information, the parent can publish a new chain leading to keys controlled through the compromised process. A validator may then see internally consistent signatures even though the change was not approved by the registrant.

Another variation is removal of a DS record through an apparently authorized change. Depending on caching, timing and resolver policy, that can move a delegation from a validated state toward an insecure one rather than create a directly invalid signature. The transition can be suspicious, and monitoring can expose it, but DNSSEC alone does not decide whether the removal was a legitimate rollover, an emergency repair or an unauthorized downgrade. No compromise of the DNS root is required for any of these narrower failures.

The operational guidance surrounding DNSSEC therefore treats signing as a continuing discipline rather than a one-time security switch. Key generation, storage, activation, retirement and rollover must remain coordinated with DNSKEY publication, parent-side DS state, signature validity periods and resolver caching. RFC 6781 addresses those operational responsibilities, while the later RFC 9364 provides additional DNSSEC context that must not be projected backward as proof of what organizations had implemented during the 2019 incidents.[17][21]

Forensic confidence depends on preserving the transition, not merely observing the final valid answer. Investigators would need time-aligned evidence of the old and new DNSKEY sets, DS submissions and parent publication, signature inception and expiration times, zone-generation events, signing-system activity, registrar instructions, registry transactions and authoritative answers observed from independent networks. A key rollover plan can explain a change; records showing that the plan was executed can substantiate it.

Without those records, “routine rollover” and “unauthorized reprovisioning” may leave similar public traces after caches converge.

The same evidentiary requirement applies to emergency recovery. Restoring yesterday’s zone file is not enough if yesterday’s delegation, DS state or signing keys are no longer authoritative. Responders must know which layer changed, when it changed, which credentials or systems authorized it, and whether parent and child state were restored in a safe order. NIST’s deployment guidance reinforces the need to treat DNS security as an operational system involving authoritative service, resolvers, cryptographic material, monitoring and recovery rather than as a single protocol feature.[19]

CISA’s directive reflected this broader reality by requiring agencies to audit DNS records, reset credentials capable of changing them, enable multifactor authentication where available and monitor certificate-transparency information.[1] Its companion mitigation guidance likewise treated account security, record verification and observation as related controls.[2] Those measures did not assert that DNSSEC was irrelevant. They recognized that authenticated data cannot compensate for an untrustworthy authorization path.

The certificate issue follows the same logic. DNS manipulation can direct a user toward actor-controlled infrastructure while the familiar domain remains in the address bar. If control of the domain-validation path also permits a certificate to be validly issued under the certificate authority’s rules, the browser may display an apparently ordinary protected connection. That does not mean the certificate was forged. It means the surrounding control state allowed a certificate to be issued or used in a context the organization did not intend.

Talos described this kind of valid-looking redirection in its Sea Turtle reporting without asserting compromise of root-zone servers.[5][6]

DNSSEC is consequently evidence about configured cryptographic authority, not a declaration of organizational legitimacy. Its strongest accountability contribution is to make the relevant questions more exact: Which key signed the served RRset? Which DS record connected that key to the parent? Who could alter those objects? Which rollover procedure applied? What did independent resolvers observe before, during and after the incident? Those questions turn “DNSSEC was enabled” from a slogan into a testable account of control.

EPP Status, DNSSEC Provisioning and the Meaning of a Lock

EPP supplies a protocol vocabulary through which registrars and registries manage domain objects. RFC 5731 defines domain commands, authorization information and status values that can prohibit or signal particular operations, including updates and transfers.[13] These terms are important because “the domain was locked” is otherwise too vague to support an accountability finding.

A transfer restriction is not necessarily an update restriction. Preventing an inter-registrar transfer does not by itself prove that nameserver, address or DNSSEC data could not be changed through the existing registrar. A client-side status is ordinarily managed through the sponsoring registrar’s relationship with the registry. A server-side status is imposed at the registry side. The visible status therefore identifies a protocol condition, but it does not reveal whether an attacker could remove that condition, whether an employee override was available, or whether an out-of-band confirmation was required.

This distinction explains why a registrar lock can be valuable without being conclusive. It can stop routine changes or transfers and create an additional action that must occur before modification. Yet if the registrar’s privileged credentials, support process or EPP access are compromised, an attacker may be operating through the same channel permitted to alter client-side status. A registry lock can add separation by requiring registry-side action before specified changes proceed, particularly when release depends on independent confirmation.

Even then, its strength rests on the actual authentication, escalation and exception procedures behind the status value.

RFC 5910 extends EPP with a vocabulary for provisioning DNSSEC information.[14] It permits the registrar-registry exchange to represent security data associated with a domain, including material used to maintain the parent-child trust relationship. That makes DNSSEC provisioning more structured and potentially more auditable. It does not certify that the human request was legitimate, that the registrar account was uncompromised, or that the registry independently verified the registrant’s intent.

The relevant 2019 question is therefore not simply whether EPP existed. EPP was the established interface through which many registrars and registries exchanged domain state. The question is what controls surrounded each consequential command: who initiated it, how the requester authenticated, whether another person approved it, whether the registry applied a server-side restriction, what notification was sent, and which immutable records survived. Protocol compliance can coexist with authorization failure.

Earlier ICANN security work had already described domain hijacking as a problem involving authentication, registration records, registrar practices, locks, recovery and emergency support.[7][8] Registrant-facing guidance also emphasized account protection and practical safeguards before the 2019 alert period.[9] Separate recovery guidance stressed documentation because restoring a hijacked domain depends on proving prior control and reconstructing the correct configuration.[10] Those materials establish that the control problem was known. They do not prove that every affected organization used each safeguard effectively.

Transfer authorization deserves equally careful treatment. Transfer credentials are intended to authorize movement between registrars; they are not universal approval for every DNS update. RFC 9154 later strengthened the treatment of EPP authorization information used in transfers.[18] It is useful as evidence of how standards work evolved after weaknesses and operational experience had accumulated. It cannot establish that its protections existed in a particular registrar or registry during the January-to-July 2019 reporting window.

The same chronological boundary applies to RFC 9364 and the ICANN DNS Security Facilitation Initiative report issued in 2021.[11][21] They can clarify later thinking about DNSSEC operations, ecosystem coordination and security responsibilities. They cannot be cited as contemporaneous proof that a 2019 victim had a mature rollover procedure, that a registrar required stronger transfer authorization, or that a registry used a particular lock workflow.

ICANN’s framework for registry operators responding to security threats offers another form of control context.[12] It shows how registry-level capability can matter during a security event, but a framework is not evidence that a specific registry received a timely request, took a particular action or could have prevented the initial change. The distinction between available authority and exercised authority remains essential.

For the 2019 incidents, EPP evidence would be especially valuable because it could connect a public DNS transition to an accountable operational event. A transaction record could identify the sponsoring registrar, command type, domain object, timestamp and result. Supporting records could show the authenticated account, source system, approval, lock transition and notification. Without that chain, public observers may see that delegation changed but remain unable to determine whether the registrar account, an internal administrative system, the registry interface or another layer supplied the effective authority.

Status codes and DNSSEC extensions are thus evidence-bearing vocabulary, not automatic security outcomes. They help investigators describe what the system accepted. Responsibility still turns on which organization could impose, remove or override the restriction; which organization retained the corresponding records; and whether the control remained independent of the credentials most likely to be compromised.

Recommendation, Implementation and Externally Verified Result

A bounded assessment must keep three levels separate.

Recommendation

A recommendation states what an organization should do. CISA directed covered federal agencies to audit DNS records, change relevant credentials, use multifactor authentication where available and monitor certificate-transparency data.[1] ICANN urged administrators to verify domain and nameserver configuration, improve credential security and monitor for unauthorized changes while stating that it had no indication its own systems had been compromised.[3] Earlier ICANN publications recommended account safeguards, locks, sound registrar practices and documentation for recovery.[7][8][9][10]

These documents establish notice and describe reasonable controls. They can also shape expectations for organizations occupying similar positions. They do not, by themselves, show whether a named operator had implemented a measure before the incident or whether the measure would have stopped the exact credential path used.

Implementation

Implementation requires evidence that a recommendation became an operating control. For multifactor authentication, that includes which privileged accounts were covered, which methods were permitted, how recovery worked and whether service or support accounts could bypass the control. For locking, it includes the exact EPP statuses, who could remove them and whether registry-side confirmation was independent of registrar credentials. For DNSSEC, it includes signing architecture, DS management, rollover procedure and separation between routine zone editing and key authority.

Implementation also has a temporal dimension. A control enabled after the alert can improve future resilience without proving that it existed before tampering occurred. A written procedure can exist without being exercised. A monitoring service can run without alerting the correct people. A notification can be generated but sent to an account already under hostile control. Evidence must show both configuration and operation at the relevant time.

Externally Verified Result

An externally verified result shows what happened outside the organization’s own assertion. Examples include independently collected authoritative answers, registry history, certificate-transparency entries, time-stamped status changes, observable restoration of delegation and consistent answers from multiple networks. Such evidence can establish that state changed or recovery occurred even when internal motive and credential use remain unknown.

The 2019 public record supports a broad failure class.

CISA described DNS infrastructure tampering and ordered a federal response.[1] ICANN connected the concern to public reporting while preserving the boundary around its own systems.[3] Mandiant reported DNS-record manipulation affecting government, telecommunications and Internet-infrastructure domains across several regions.[4] Talos documented Sea Turtle as a distinct operation involving primary targets and infrastructure providers, then reported that the activity continued.[5][6] Those findings do not amount to a complete, domain-by-domain verification of every recommended control or every remediation result.

Later standards and studies help define stronger questions, not retroactive answers. RFC 9154 can inform an assessment of transfer authorization; RFC 9364 can inform DNSSEC analysis; and the 2021 ICANN study can inform ecosystem coordination.[11][18][21] None demonstrates deployment in 2019. Current CISA taxonomy likewise helps classify adversary acquisition of domain-related infrastructure and accounts, but a taxonomy does not identify the exact path in an earlier case.[20]

The disciplined conclusion is therefore limited. A recommendation can establish what responsible practice looked like. Implementation evidence can establish that a party adopted and operated a control. External observation can establish what state was actually published or restored. One level must not be substituted for another.

The Evidence Boundary the Public Record Does Not Close

The available reporting does not establish a complete victim set. CISA’s directive concerned covered federal agencies and a series of incidents, not every affected domain worldwide.[1] Mandiant described a broader wave but remains an attributed research assessment.[4] Talos reported a defined set of Sea Turtle observations and later activity, not a universal census of DNS tampering.[5][6] Additional victims may have remained undisclosed, misclassified or unknown.

Nor does the record establish one complete actor set. Sea Turtle and DNSpionage must remain distinct because Talos expressly separated them.[5] CISA’s operational directive did not adjudicate all attribution questions, and ICANN’s alert drew attention to a shared risk without merging every report into one campaign.[1][3] Similar DNS outcomes can arise from different actors, access paths and objectives.

Internal knowledge remains unresolved for many organizations. Public DNS history can reveal that records changed, but it rarely shows when a registrar security team first knew, whether a registrant received an alert, whether a registry noticed an anomalous command or whether a certificate authority had enough context to connect issuance with DNS manipulation. Delayed recognition can result from a missing alert, a failed escalation or a correct warning sent to the wrong account. Those are different accountability failures.

Credential paths are similarly incomplete. A public report may state that attackers obtained access sufficient to alter DNS without disclosing whether that access came through a registrant account, registrar administration, compromised support personnel, a DNS provider, an EPP credential or a chained compromise of several systems. CISA’s current domain-trust taxonomy can organize possible acquisition paths, but it cannot fill gaps in incident-specific evidence.[20]

Decision ownership is another missing layer. A change may have been technically executed by an automated service after a human request, approved through an exception process, or accepted because a support representative overrode normal safeguards. Assigning responsibility requires knowing which party designed the control, which party could approve the exception and which party could stop the transaction. Publicly visible DNS state generally cannot answer those questions alone.

The condition and retention of logs remain uncertain. Strong evidence would include registrar authentication events, support records, EPP commands and responses, registry status history, zone-management activity, DNSSEC signer records, DS changes, notifications, authoritative query observations and certificate events. If one organization retains only a final database snapshot while another preserves an append-only history, their ability to explain and reverse the same failure will differ sharply.

Pre-event controls are also incompletely documented. The public recommendations support the relevance of multifactor authentication, locks, credential hygiene, record auditing, independent monitoring and recovery documentation.[2][3][7][8][9][10] They do not reveal which victims had those controls, how exceptions worked or whether privileged non-human access remained outside them. Absence of public evidence is not proof that a control was absent; a post-incident claim that a control existed is not proof that it covered the compromised path.

Causal apportionment consequently remains bounded. An initiating credential theft may belong to one organization’s control surface, while an avoidable update, weak registry restriction, missed monitoring signal, delayed certificate response and poor recovery records belong to others. The first failure does not erase later opportunities to detect, limit or reverse harm. Conversely, the presence of several control owners does not justify equal blame when only one had practical power over the decisive state transition.

Remediation effectiveness is not established by an announced credential reset or restored webpage. Investigators would need to confirm that malicious records disappeared, delegation and DS state were correct, unauthorized certificates were addressed, access paths were closed, caches converged and monitoring detected no recurrence. Talos’s July account that Sea Turtle continued operating demonstrates why an initial alert or isolated cleanup cannot be treated as proof that the wider problem was resolved.[6]

Two negative findings must remain explicit. ICANN said it had no indication that its own systems were compromised.[3] Talos said it had no evidence that root-zone servers were attacked or compromised.[5] The documented control problem can be explained through narrower registrar, registry, DNS-operator and organizational access without asserting compromise of ICANN or the root.

The certificate evidence must also remain bounded. A certificate that appeared valid during redirection is not necessarily a forged certificate. It may reflect successful issuance after control of a relevant validation path or use of a legitimately issued certificate in an unauthorized setting. The accountability question is which party could observe suspicious issuance, challenge it, revoke it or correlate it with a DNS change—not whether cryptography itself fabricated organizational intent.

A Practical Test for the 2019 Control Failure

The 2019 evidence can be reduced to four event-specific questions.

1. Prevent: Could the party stop an unauthorized DNS change before publication? Relevant capabilities included strong authentication for privileged accounts, separation between account recovery and routine access, restricted EPP credentials, meaningful update restrictions, registry-side protection for high-risk changes and independently confirmed changes to delegation or DS state. The evidence should identify the control that actually covered the path, not merely a policy that used the same label.

2. Detect: Could the party observe the wrong state independently of the system that produced it? Useful capabilities included comparison with known-good records, observation of authoritative answers from outside the managed environment, alerts for nameserver and DS changes, authentication and EPP anomaly detection, and certificate-transparency monitoring. CISA’s directive made record auditing and certificate observation concrete parts of the response.[1] Detection evidence should show when the signal appeared, who received it and when action began.

3. Limit: Could the party reduce the scope or duration of harm after prevention failed? That depends on credential segmentation, restrictions on which domains or records an account could alter, independent registry controls, rapid suspension procedures, retained safe configuration and communication between registrant, registrar, registry, DNS operator and certificate authority. Limits should be assessed by observed effect: which changes were blocked, which services remained trustworthy and how long malicious state was served.

4. Reverse: Could the party restore the correct delegation, DNSSEC and service state without relying on the compromised channel? Recovery required authenticated emergency contacts, proof of prior control, transaction history, known-good zone and delegation data, safe handling of keys and DS records, and coordinated action across organizational boundaries. ICANN’s recovery guidance emphasizes why documentation is central when the normal account relationship can no longer be trusted.[10]

A party may score differently across these four capabilities. A registrant may have little ability to change registry server status but substantial responsibility for account security and independent observation. A registrar may not operate the authoritative nameservers but may control customer authentication, EPP access and escalation. A registry may not know the registrant’s business intent, yet it may possess the final transaction record and the ability to impose or remove server-side restrictions.

An authoritative DNS operator controls what its servers answer and may hold the most precise zone-publication and rollback evidence. A certificate authority controls issuance and revocation within its rules, while relying organizations decide how rapidly to respond to certificate and DNS warnings. CISA and ICANN could issue directives, guidance and coordination alerts, but neither operated every affected domain. Responsibility should follow those differences in practical authority.

Retained evidence is part of the control, not clerical material left after the incident. An organization that can authorize a high-impact change but cannot later identify the authenticated requester, approved values, transaction sequence or notification history has created authority without adequate accountability. An organization that can observe anomalous state but cannot preserve the observation weakens both remediation and external verification.

The final measure is the state users and resolvers actually encountered. Corporate intent matters when determining authorization, but intent does not route packets, answer DNS queries or establish the delegation seen by a resolver. A familiar domain, a validating DNSSEC chain or an apparently valid certificate can coexist with state the organization never wanted when authorized systems have been turned toward the wrong result.

The 2019 alerts should therefore be understood as a change-control accountability test across several operational boundaries, not as evidence that the DNS root, ICANN or every registry failed. CISA, ICANN, Mandiant and Talos each documented a different part of the public record; Sea Turtle remained distinct from DNSpionage; and later standards describe stronger control context rather than retroactive deployment.[1][3][4][5][6][11][18][21]

Responsibility is strongest where practical control and retained evidence meet. The party able to make a change should preserve who requested it and why it was accepted. The party able to publish it should preserve what was served and when. The party able to detect it should preserve the alert and response. The party able to reverse it should preserve the restored state and the basis for trusting it. Accountability follows the party that could authorize, record, observe or reverse DNS state, and evidence of the state actually served matters more than intent alone.

Sources

1. https://www.cisa.gov/sites/default/files/ed-19-01%20%281%29.pdf
2. https://www.cisa.gov/sites/default/files/publications/CISAInsights-Cyber-MitigateDNSInfrastructureTampering_S508C.pdf
3. https://www.icann.org/news/announcement-2019-02-15-en
4. https://cloud.google.com/blog/topics/threat-intelligence/global-dns-hijacking-campaign-dns-record-manipulation-at-scale/
5. https://blog.talosintelligence.com/seaturtle/
6. https://blog.talosintelligence.com/sea-turtle-keeps-on-swimming/
7. https://www.icann.org/en/ssac/registration-services/documents/sac-007-domain-name-hijacking-incidents-threats-risks-and-remediation-12-07-2005-en
8. https://www.icann.org/en/ssac/publications/documents/sac040-executive-summary-for-measures-to-protect-domain-registration-services-against-exploitation-or-misuse-19-08-2009-en
9. https://www.icann.org/en/blogs/details/do-you-have-a-domain-name-heres-what-you-need-to-know-26-3-2018-en
10. https://www.icann.org/en/blogs/details/documentation-is-key-to-recovering-hijacked-domain-names-14-4-2016-en
11. https://www.icann.org/en/system/files/files/dsfi-tsg-final-report-15oct21-en.pdf
12. https://www.icann.org/en/contracted-parties/registry-operators/resources/framework-for-registry-operators-to-respond-to-security-threats
13. https://www.rfc-editor.org/info/rfc5731/
14. https://www.rfc-editor.org/info/rfc5910/
15. https://www.rfc-editor.org/info/rfc4033/
16. https://www.rfc-editor.org/info/rfc4035/
17. https://www.rfc-editor.org/info/rfc6781/
18. https://www.rfc-editor.org/info/rfc9154/
19. https://www.nist.gov/publications/secure-domain-name-system-dns-deployment-guide-3
20. https://www.cisa.gov/eviction-strategies-tool/info-attack/T1584.001
21. https://www.rfc-editor.org/info/rfc9364/