DNS and Domain Investigation

DNS is a distributed database that answers one core question: what IP address corresponds to this name? But the database holds many record types beyond simple name-to-address mappings, and each type exposes a different facet of how a domain is configured and used. Investigators who understand the full record set can extract far more attribution data from a single domain query than one who only looks at the A record.

The TTL (time-to-live) field on any record is an underused forensic indicator. A legitimate CDN or enterprise domain typically sets TTL values between 300 and 3600 seconds. Fast-flux domains frequently use values of 60 seconds or less because they need resolvers to re-query quickly as the IP pool rotates. When a domain's A record TTL is below 120 seconds and the record changes on every query, that combination is a strong indicator of fast-flux operation.

WHOIS returns the registration record for a domain: who registered it, when, through which registrar, what nameservers it uses, and when it expires. Before May 2018, public WHOIS for gTLDs often included full registrant name, postal address, phone number, and email. After ICANN aligned its policies with the EU's General Data Protection Regulation, most registrars began redacting personal contact data from public responses. The underlying data still exists at the registrar but requires a formal legal request to access.

Even with redacted contact data, WHOIS records remain investigatively useful. The registrar itself, the nameservers assigned, the registration date, and the registrant organisation field (when present) can all serve as pivot points. A cluster of domains registered on the same date, through the same registrar, pointing to the same nameservers is a strong signal of a coordinated campaign, even if the registrant contact is redacted. The RDAP protocol (Registration Data Access Protocol) is the modern replacement for WHOIS and provides structured JSON output that is easier to process programmatically.

Country-code TLDs such as .in, .uk, and .de are administered by national registries with their own WHOIS policies. India's .in domains are managed by the National Internet Exchange of India (NIXI). UK domains under .co.uk are managed by Nominet, which provides a tiered WHOIS service with fuller data available to accredited law enforcement. Investigators must identify the correct registry for the TLD before querying, as a gTLD WHOIS server will not have data for ccTLD domains.

Passive DNS databases are built by organisations that operate large recursive resolvers or that deploy sensors across network infrastructure. Every time one of those resolvers answers a query, the resolution, the domain queried, the answer returned, and the timestamp are stored. Over time, these databases accumulate resolution histories for hundreds of billions of domains. Commercial providers including Farsight Security DNSDB, VirusTotal passive DNS, and RiskIQ (now part of Microsoft Defender) offer investigator access.

The core investigative pivot in passive DNS is the IP-to-domain lookup, also called a reverse passive DNS query. Given an IP address, the query returns all domains that resolved to that IP over the collection period. If a phishing domain resolves to an IP and an investigator reverse-queries that IP, they may find dozens of other domains that used the same host at different times, each potentially part of the same campaign. Conversely, a domain-to-IP query shows all IPs that the domain has resolved to, which may span multiple hosting providers and time periods.

Timeline reconstruction from passive DNS is particularly powerful in cases involving infrastructure migration. Attackers frequently move domains between hosts, either after detection or as a planned rotation. A passive DNS timeline showing a domain at IP A for three weeks, then at IP B, then at IP C, combined with threat intelligence about those IPs, can establish both the duration of a campaign and its operational security patterns.

Three DNS abuse patterns appear repeatedly in cyber investigations and each has a distinct signature in query logs.

Fast-flux networks use DNS TTL values as short as 60 seconds and rotate A records through a pool of compromised hosts, each acting as a proxy for the actual backend server. The technique was widely used by the Storm botnet from 2007 onward and remains common in malware distribution and phishing campaigns. Detection in logs requires correlating short TTL values with high change frequency on the same domain. Double-flux additionally rotates NS records, which means the domain's authoritative nameservers themselves change frequently, making registrar-level takedown more complex because there is no stable NS to target.

Domain generation algorithms produce a deterministic but externally unpredictable list of domain names based on a seed value, often the current date. The Conficker worm (2008) generated 250 domains per day. Later families such as Cryptolocker (2013) and Mushtik generated thousands per day. Investigators detect DGA traffic by analysing DNS query logs for bursts of queries to non-resolving high-entropy domains. Reverse-engineering the malware to extract the DGA seed and schedule allows analysts to predict future domains and apply for pre-emptive sinkhole orders.

DNS tunnelling encodes data in the subdomain label of a query. A tool like Iodine or DNScat will convert a file or a shell session into a series of queries such as aGVsbG8gd29ybGQ.attacker-c2.com, where the base64-encoded string in the subdomain carries the payload. The response carries data back in TXT or CNAME records. Detection indicators include: query length far above the median for the domain (legitimate subdomains rarely exceed 20 characters), high query rate to a single second-level domain, and a high proportion of TXT record queries from a single endpoint.

Attribution in cyber investigations rarely comes from a single record. It comes from building a graph of relationships between domains, IP addresses, nameservers, registrant data, and TLS certificates, and identifying the nodes that connect multiple campaigns to the same actor. This process is called infrastructure pivoting.

A structured pivot workflow begins with the initial indicator, typically a domain or IP from a phishing email, malware sample, or incident report. From that anchor, the investigator queries: (1) all IP addresses the domain has resolved to via passive DNS; (2) all domains that have resolved to each of those IPs; (3) WHOIS registration data for each discovered domain, noting shared registrant email, nameserver, or registrar; (4) TLS certificate transparency logs, which record every SSL certificate issued for a domain and often reveal subdomains and related domains that share the same certificate or the same issuing account. Tools such as Shodan, Censys, and RiskIQ automate parts of this pivot chain.

Certificate transparency logs are a particularly underused resource. Since 2018, all publicly trusted TLS certificates must be logged in public CT log servers before browsers will accept them. When an attacker creates infrastructure for a new campaign, issuing a certificate creates a permanent, timestamped public record. Querying CT logs for a known attacker domain sometimes reveals sibling domains that were not yet known to threat intelligence. Services such as crt.sh provide free access to the consolidated CT log database.

Pivot analysis for attribution is also relevant to the Indicators of Compromise workflow. Domains and IPs discovered through pivoting become IOCs that can be shared with other organisations, ingested into SIEM systems, and incorporated into threat intelligence products. The STIX 2.1 standard supports domain-name and URL objects with relationship links to IP addresses, enabling structured sharing of pivot chains.

DNS evidence takes two main forms: live query results obtained by the investigator, and stored records held by ISPs, registrars, or DNS service providers. Live query results are generally self-obtained and do not require a court order, but the investigator must document the query methodology, the tool used, the timestamp, and the resolver IP to establish authenticity. Stored records held by third parties require legal process in the jurisdiction where those records are held.

In India, DNS query logs held by internet service providers can be obtained under Section 91 of the Bharatiya Nagarik Suraksha Sanhita 2023 (which replaced the Code of Criminal Procedure), which allows a court or an officer in charge of a police station to require production of documents. The Information Technology Act 2000, Section 69, authorises the government to direct interception, monitoring, or decryption of information through a computer resource, and Section 79A designates agencies as Examiners of Electronic Evidence whose reports are admissible under the Bharatiya Sakshya Adhiniyam 2023.

In the US, DNS records held by ISPs are stored communications subject to the Stored Communications Act (18 USC 2701 et seq.). Non-content subscriber records can be obtained with a subpoena; content and more sensitive records require a court order or warrant. In the UK, the Investigatory Powers Act 2016 governs access to communications data held by internet service providers. In the EU, national implementations of the e-Privacy Directive set data retention obligations, though the Court of Justice of the EU has repeatedly constrained bulk retention requirements in cases including Digital Rights Ireland (2014) and La Quadrature du Net (2020).

Cross-border requests use Mutual Legal Assistance Treaties. A domain hosted in the US but accessed by victims in India requires the Indian Central Authority (the Ministry of Home Affairs) to submit an MLA request to the US Department of Justice. MLAT timelines typically range from several months to over a year, which means investigators should pursue all open-source passive DNS and CT log data before or in parallel with formal requests, to avoid delays in building the initial picture.