Why were my domain name resolution records modified but my account wasn't stolen? Here's a summary of common reasons.

　　During website maintenance, a situation can cause instant anxiety—the domain suddenly becomes inaccessible, or access is redirected to a completely unfamiliar website. Immediately logging into the domain management backend reveals that the account password hasn't been changed, and the login logs show no unusual activity. Then, opening the DNS control panel reveals that the DNS records have been tampered with, with the A record pointing to an unfamiliar IP address.

　　Many people's first reaction is "account stolen," but security checks show the account is unharmed. This phenomenon of "modified DNS records, but the account is fine" precisely illustrates that the attacker didn't use conventional account theft methods, but rather exploited a more hidden security weakness in the DNS ecosystem.

　　I. Service Provider-Side Security Issues: Attacking the Registrar or DNS Platform, Not You

　　This is one of the most easily overlooked, yet most common, reasons.

　　1. Phishing Attacks on Registrar/DNS Provider Staff

　　A typical case occurred at GoDaddy, the world's largest domain registrar: a customer service employee was phished, granting attackers the ability to view and modify critical customer records and change the DNS resolution IPs of six GoDaddy customers. Among the affected customers was the reseller platform Escrow.com, whose homepage was replaced with a plain text message and whose DNS records pointed to a Malaysian IP address. In this incident, the victim's account showed no abnormalities—because the attack wasn't targeting their account, but rather exploiting the employee's privileges.

　　This type of attack is highly stealthy: attackers use social engineering to deceive the registrar's customer service, requesting assistance in modifying records under the guise of "account loss" or "urgent technical issues." Because the customer service representative has backend access, this tampering doesn't even leave a trace in your account's operation logs.

　　2. Intrusion into Authoritative DNS Servers

　　When authoritative DNS servers themselves are compromised, attackers can directly modify the resolution data at the underlying level. Attackers may exhaust server resources through DDoS attacks, exploit zero-day vulnerabilities to bypass protection, or exploit open vulnerabilities in the DNS protocol itself to poison caches. Once an authoritative DNS server is compromised, the resolution records of all domains it manages may be massively altered, while the domain owners' management accounts remain completely unaffected.

　　It's important to note that while DNSSEC can prevent man-in-the-middle tampering, if the authoritative DNS server itself is compromised, attackers can replace the DNSSEC signature data, partially disabling the verification mechanism. This means that even with DNSSEC enabled, the service provider's security remains the most basic line of defense.

　　3. API Security Vulnerabilities of DNS Service Providers

　　Some low-priced or poorly managed DNS service providers have inadequate API security measures. Attackers can directly add or tamper with resolution records by forging API calls without logging into the user's management console. In this case, because the tampering occurs at the API level rather than the console level, the account's management password and login status may remain intact.

　　II. Leakage of API Keys and Third-Party Integration Credentials

　　This is the most common and easily overlooked attack path in the current cloud-native environment.

　　Many enterprises and developers are accustomed to using APIs to automate DNS record management, such as dynamically updating A records via scripts or using automated certificate tools (such as acme.sh and certbot) to modify TXT records for domain verification. These operations rely on API keys (API Key/Secret), which are often far less secure than account passwords—they might be written into code repositories, pasted into instant messaging chat logs, or stored in unencrypted configuration files.

　　Once an API key is leaked, attackers can directly call the DNS provider's API to modify resolution records without knowing the account password or passing MFA verification. During emergency investigation, the account security log should be checked immediately for unauthorized API call records, and all suspicious API keys should be frozen. If the source is confirmed to be an API attack, further investigation is needed to determine the source of the key leak—whether the code repository is publicly available, whether there are permission vulnerabilities in the CI/CD process, and whether the security of internal collaboration tools meets standards.

　　III. DNS Configuration Defects: CNAME Deprecation and Delegation Configuration Errors

　　1. CNAME Deprecation

　　This is one of the fastest-growing domain hijacking methods in recent years. The principle behind this seemingly simple yet easily overlooked technique is as follows: When a domain's CNAME record points to an external cloud service address, and that cloud service resource is later deleted or abandoned, but the CNAME record remains in the DNS, an attacker can register a resource with the same name on the corresponding cloud service platform, thus "taking over" the traffic of that subdomain.

　　To put it simply: You leave a forwarding address, but you no longer live there; an attacker, after moving into that address, can receive all the mail forwarded to you. The stealth of CNAME abandonment takeover lies in the fact that the domain registrar's account shows no abnormalities, and the DNS record itself has not been "tampered with"—the record is still the original CNAME, only the target resource it points to has been re-registered by someone else.

　　2. Incorrect NS Record Delegation Configuration

　　If a domain's NS record points to a deprecated or controllable DNS server, an attacker can also configure arbitrary DNS records for your domain on that server, achieving a "takeover" effect. This situation is common when switching DNS service providers, where the old provider's NS records are not promptly cleaned up, and the old server account has been closed, but the NS records still point to it.

　　IV. Local Environment Hijacking: The Problem Lies on the User End, Not the Server End

　　Not all "DNS resolution modification" occurs in the DNS management backend. Sometimes, the records in the management console are completely correct, but the user sees incorrect results.

　　1. Router DNS Tampering

　　If the DNS settings of a home or office router are tampered with, all devices connected to the network will be redirected to a malicious DNS server. 360 Security Brain once tracked a large-scale DNS hijacking incident: attackers exploited router firmware vulnerabilities or default weak passwords to remotely log into the router's management interface and tamper with the DNS server address to a malicious address. When a user initiated a domain name resolution request, the malicious DNS server preferentially returned an IP address controlled by the attacker. The malicious DNS server's resolution request volume exceeded 2.37 million times per month at its peak.

　　The typical characteristics of this situation are: all devices on the same network are affected, and switching to a mobile data network restores normal operation; moreover, the attack often manifests as "the first few accesses are redirected, and after multiple refreshes, it returns to normal," forming an intermittent rather than continuous hijacking phenomenon.

　　2. ISP Hijacking and DNS Cache Poisoning

　　Some ISPs may insert fake responses into the DNS resolution process for purposes such as advertising, content censorship, or traffic redirection. When the DNS cache is poisoned, user access will be resolved to incorrect IP addresses. In this case, using a tool like `dig` to directly query the authoritative DNS will return the correct result, but if the resolution differs in some regions, it indicates cache poisoning, not tampering of the administrator's DNS records.

　　V. Domain Name Status Issues: Expiration, Locking, and System Errors

　　1. Domain Expiration

　　Once a domain expires, some registrars will stop all DNS resolution services, or even resolve the domain to advertising pages or parking pages. This situation is easily misjudged as "record tampering," but it is actually an automatic behavior caused by a change in domain status. The domain status can be checked using the `whois` command; if it shows "Redemption" or "Expired," it must be renewed immediately.

　　2. System Failures of Registrars or DNS Platforms

　　Platform-level failures of DNS service providers can also cause resolution anomalies. For example, when the DNS cluster malfunctions, resolution may be delayed, fail, or return incorrect IP addresses. Checking the service provider's status page can quickly confirm whether it's a systemic failure.

　　VI. Troubleshooting Recommendations and Emergency Response Procedures

　　When DNS records are found to have been tampered with but the account has not been stolen, it is recommended to follow these steps to troubleshoot:

　　Step 1: Restore DNS Records. Immediately log in to the DNS management console and check for anomalies in A, CNAME, MX, TXT, etc. records. Restore the correct record values ​​and manually refresh the DNS to accelerate global node synchronization.

　　Step 2: Check API Keys and Operation Logs. Check the account security log for unauthorized API calls. Immediately disable all unauthorized API keys and freeze related permissions. Check the operation audit log for any record modification operations not initiated by you.

　　Step 3: Check Domain Status and WHOIS Information. Confirm whether the domain has expired and whether its status is normal (e.g., abnormal statuses like serverHold, clientHold, etc.). Check whether the email address in the WHOIS registration information is still controllable by you or a current employee of the company.

　　Step 4: Differentiate Between Global Tampering and Local Hijacking. Compare the DNS resolution results using multi-location DNS testing tools, or directly query using `dig @authoritative DNS` to determine if it's cache poisoning or ISP hijacking. If the authoritative DNS returns correct but the resolution differs in some regions, the problem is not in the management backend.

　　Step 5: Check the status of the resource pointed to by the CNAME record. Investigate whether there are CNAME records pointing to obsolete cloud services, CDN resources, or external domains, confirming that the target resource is still under your control.

　　Step 6: Contact the registrar/DNS service provider for confirmation. If the above checks do not reveal any problems, contact the service provider to confirm whether there is a platform-side security incident or system failure.

　　Conclusion: The phenomenon of "DNS records being modified, but accounts not being stolen" is confusing because it challenges our intuitive understanding that "account security = domain security." Real DNS security threats are far more complex than "password being guessed"—they could come from phishing attacks on service provider employees, API keys being exposed in the code repository, a CNAME record pointing to an obsolete resource, or a registration email address left behind by a departing employee.

　　The essence of domain name security lies in the management of the entire DNS resolution chain: from front-end accounts to back-end APIs, from service provider platforms to local network environments, from cloud resource configuration to personnel permission auditing, any oversight in any link can become an entry point for attackers. Establishing a comprehensive protection system and monitoring mechanism covering the entire chain is far more efficient than frantically searching for "who changed my records" after an incident occurs.