Introduction

Have you ever investigated a domain and encountered a generic parking page or a suspension notice, even though you know it was actively resolving to a live site not too long ago? Or perhaps a domain that once had a directly accessible IP address is now hidden behind a reverse proxy service like Cloudflare? These are perfect scenarios to take advantage of what can sometimes be lazy or insufficient system administration of DNS records: by digging the old, previously authoritative nameservers for any lingering records!

How It Works

When you register a domain (let's say example.com), your registrar typically assigns your domain default authoritative nameservers (e.g., ns1.registrar.com and ns2.registrar.com) and may create a default A record (IP address) pointing to a parking page. This makes the domain discoverable throughout the Domain Name System (DNS). For many users, using the registrar's provided DNS hosting service is sufficient. You can add, edit, and remove various DNS records as needed.

Now, let's imagine your needs change. You decide to move your domain's DNS hosting to a new service that offers better security or more advanced features (e.g., a premium DNS provider or a service like Cloudflare). This new service will provide you with a new set of authoritative nameservers (e.g., ns1.new-service.com and ns2.new-service.com). You would then update your domain's registration at your registrar, changing the delegated nameservers from ns1.registrar.com to ns1.new-service.com. Your registrar communicates this change to the TLD (Top-Level Domain) registry (e.g., the .com registry).

As DNS queries for example.com propagate, the .com registry will start directing those queries to ns1.new-service.com. Resolving nameservers around the world will eventually update their caches, removing ns1.registrar.com as the authority and replacing it with ns1.new-service.com. Your new service now provides the IP addresses, mail server details (MX records), and other record types in response to queries.

Here's a simplified illustration of the records:

Records at the old authoritative nameservers (e.g., ns1.registrar.com):

Domain	Type	Value
example.com	NS	ns1.registrar.com
example.com	A	127.0.0.253
example.com	TXT	"Hello world"

Records at the new authoritative nameservers (e.g., ns1.new-service.com):

Domain	Type	Value
example.com	NS	ns1.new-service.com
example.com	A	192.168.0.153
example.com	TXT	"Goodbye world"

In the above examples, our A record changed from 127.0.0.253 to 192.168.0.153 and our TXT record changed from "Hello world" to "Goodbye world".

So, what happens to the DNS records for example.com that were hosted on the old nameserver, ns1.registrar.com? Ideally, a well-maintained DNS hosting system at the old provider might detect the delegation change and automatically purge or disable those old records. However, in reality:

• Many DNS systems are complex, and automating such cleanup might be difficult or not prioritized.
• The business ROI for meticulous cleanup of non-authoritative zones might be low.
• Leaving the old records (which are no longer authoritative in the global DNS) mostly doesn't cause immediate, widespread harm from the old provider's perspective.

Mostly. The presence of nameservers serving outdated, non-authoritative answers for a domain can indeed be problematic and potentially harmful (e.g., for misconfigurations, reconnaissance, or even certain attack vectors). If you'd like to understand the technical issues better, this OARC presentation offers a detailed explanation.

But we're not here today to debate the intricacies of DNS hygiene. We're here because that old record might still exist on the old nameserver. And if it does, we can directly query that old nameserver and ask it for the records it still thinks it has for example.com.

This technique will show you how to (possibly) see 127.0.0.253 and "Hello world" while the rest of the world is being given 192.168.0.153 and "Goodbye world".

WARNING: Operational Security

Be aware of the following before you begin:

• If you are investigating a domain you suspect is malicious, actively Browse to it or clicking related links found via search engines can be risky to your computer's security. Do not proceed with direct interaction if you are not confident in your security measures (e.g., using a sandboxed environment, VM).
• Directly querying nameservers from your home or work network will generate DNS traffic that can be logged and may associate your IP address with the lookups. If attribution is a concern, consider using a VPN (that tunnels all traffic, including DNS), a public Wi-Fi network, or a dedicated virtual machine routed through a non-attributable connection.

Steps to Check Old Nameservers

This technique requires some initial research to identify previously used authoritative nameservers for the target domain.

1. Understand the Domain's History:

   • Use WHOIS tools (like command-line WHOIS, or web services) to check the domain's creation date, last update, and registrar history. This helps determine how old the domain is and provides context for potential nameserver changes. I recommend client.rdap.org for a quick start.
   • Be aware of the domain's lifecycle: was it recently registered, or could it have been dropped and re-registered? This is crucial because nameserver history might reset upon re-registration by a new entity.

2. Collect Potential Old Nameservers: This step is iterative and may require some digging. Try to find as many past authoritative nameservers as possible. Here are some sources:

   • Search Engines (e.g., Google): Use targeted queries. Be cautious with results if the domain is suspect.
     • example.com nameserver
     • NS records for example.com
     • whois history example.com (leading to sites that might list old NS)
   • Specialized Data Sources & Tools: Many security intelligence platforms and DNS tools archive this information.
     • Historic WHOIS Services: Sites like Whoxy, WhoisXMLAPI, or others often record nameserver changes visible in WHOIS history.
     • Passive DNS Databases: Services like VirusTotal (its domain details often include passive DNS data), SecurityTrails, RiskIQ (commercial), Farsight DNSDB (commercial) record DNS resolutions observed over time, which includes nameserver records.
     • Certificate Transparency Logs: Sometimes, subdomains found in CT logs might point to older infrastructure or nameservers.

3. Query the Identified Old Nameservers: Once you have a list of potential old nameservers, you can query them directly.

   • Option A: Command-Line / Terminal (replace example.com with your target domain and ns1.old-nameserver.com with an identified old nameserver):

     • Windows (PowerShell):

       Resolve-DnsName -Name example.com -Type A -Server ns1.old-nameserver.com
       

     • Linux / macOS / Windows with BIND Tools: The dig command is standard. (For Windows, you might need to install BIND tools from ISC's website - BIND9.16.50.x64.zip is one of the last compiles for Windows). A simple query:

       dig A example.com @ns1.old-nameserver.com
       

       For cleaner output, you can add flags (useful for scripting):

       dig A example.com @ns1.old-nameserver.com +short
       

       Or for more controlled, minimal output (as in your original example):

       dig A example.com @ns1.old-nameserver.com +noadditional +noquestion +nocomments +nocmd +nostats
       

   • Option B: Use digwebinterface.com

     1. Enter the target domain (e.g., example.com) in the "Hostnames or IP addresses" textbox.
     2. Select the desired record type (e.g., A, MX, TXT) from the "Type" dropdown.
     3. Optional: Check "Show command" to see the equivalent dig command.
     4. Under the "Nameservers" option, choose "Specify myself" and enter one or more of the old nameservers you found (one per line).
     5. Click "Dig".
     6. Review the results. (And if you find the tool useful, consider making a donation to support its operation!)

4. Iterate with Different Record Types and Subdomains: The examples above use A records for the apex domain (e.g., example.com). Repeat your queries for other common record types like:

• AAAA (IPv6 addresses)
• MX (Mail Exchange servers)
• TXT (Text records, often used for SPF, DKIM, domain verification)
• CNAME (Canonical Names, aliases)
• SRV (Service records)
• ANY It's generally advised to avoid querying for ANY records, as this type is often deprecated, can be used in DNS attacks, and many modern servers do not respond to it or provide limited data.*
• Also, try querying for common or discovered subdomains (e.g., www.example.com, mail.example.com, api.example.com).

5. Analyze Your Findings: Collect and analyze any data returned by the old nameservers.

What to Do with the Results

So, you queried some old nameservers and got some results back. What now? It depends on what you found:

• Old A or AAAA Records (IP Addresses):
  • If these IPs are different from the current live IPs, they might point to previous hosting providers or directly to an origin server if the domain is now behind a CDN/proxy.
  • You could (cautiously, see WARNING) try navigating to the IP address directly in a secure browser/VM to see what content it serves.
  • Use the IP address as a pivot point for further OSINT: Google the IP, check it on services like VirusTotal, Shodan, SecurityTrails, or IP geolocation sites (e.g., iplocation.net) to find other domains historically or currently associated with it. This might uncover related infrastructure or new subdomains.
• Old MX Records: These can reveal previous email providers used by the domain.
• Old TXT Records:
  • Look for SPF records (e.g., v=spf1 ...). These list IP addresses or hostnames authorized to send email for the domain. Old SPF records might point to outdated mail infrastructure.
  • Other TXT records could reveal old domain verification tokens for services like Google Workspace, Microsoft 365, or various SaaS platforms.

Notes & Pointers

• This technique can be "hit or miss." Sometimes old nameservers will have purged records or won't respond. Don't be discouraged if initial queries yield nothing; persistence and thoroughness in finding old nameservers are key.
• Remember that your direct DNS queries can be logged by intermediate servers or the target old nameservers themselves. Adhere to the OpSec advice (VPN, etc.) if attribution is a concern.
• Using third-party websites like digwebinterface.com means the operator of that site can see your queries.
• This technique is most effective when a domain has changed its DNS hosting provider without the old provider cleaning up the zone files on their no-longer-authoritative nameservers.