DNS changes as incident indicators
During a cyber incident, changes to DNS records can be both a cause and a symptom. A changed MX record can redirect an organisation's incoming mail to an attacker-controlled server as part of a business email compromise. A changed NS or A record can be a sign that a domain registrar account was compromised and the attacker repointed the domain entirely, sometimes to serve malware or a fake login page from infrastructure they control. In other cases, DNS evidence simply helps reconstruct what infrastructure was in use at the time of the incident, without DNS itself being the attack vector.
Building a DNS timeline
Collect DNS records as early as possible once an incident is suspected, since records can be changed back by an attacker or corrected by the legitimate administrator before a full investigation starts. Where available, compare against any earlier snapshot the organisation itself had saved, such as a previous monitoring result or a configuration backup, to identify specifically which records changed and approximately when, using DNS TTL values and any available change-log or registrar audit trail as supporting evidence of timing.
Cross-reference the DNS timeline against other incident evidence: email headers showing when mail started arriving at a different server, certificate transparency logs showing when a new certificate was issued for the domain, and server or application logs showing when traffic patterns changed. DNS evidence is most useful when it corroborates, or conflicts with, these other sources rather than standing alone.
Registrar and registry-level evidence
Beyond the DNS records themselves, RDAP registration data can show whether the domain's registrar, nameservers or registrant contact changed around the same time, which would point toward account-level compromise at the registrar rather than a problem limited to a single DNS zone file. Status codes such as clientTransferProhibited being removed shortly before an unauthorized transfer is a specific pattern worth checking for in registry data.
Documenting for response and recovery
Record every DNS and RDAP observation with its timestamp and source as part of the incident record, since this evidence often needs to be shared with the registrar, the hosting provider, law enforcement or a cyber insurance provider, each of whom may ask for specifics about exactly what changed and when. Restoring correct records is an operational response step and should be documented separately from the evidentiary collection of what the incorrect records were.
- Capture current DNS and RDAP records immediately upon suspicion of an incident.
- Compare against any prior saved snapshot to isolate what changed.
- Cross-reference with email headers, certificate issuance and server logs.
- Check registrar-level status codes and contact changes, not just DNS records.
- Keep evidentiary collection separate from remediation steps.