↓Skip to main content
  1. Posts/

OSINT from Domain Names Using DNS - An Introduction

·8 mins
Ixonae
OSINT Forensics Privacy
Ixonae
Author
Ixonae
Table of Contents

DNS servers are one of the pillars of the Internet. Among other things, they enable our computers to convert domain names into IP addresses, allowing us to easily connect to services without having to know their IP address.

One other thing DNS servers and domain names are useful for? OSINT. Through various mechanisms, we can get a variety of useful information from them. This article will introduce some ways to get this information, and what we can do with it. First, we will see how to take advantage of the WHOIS protocol, then how to use the dig command to get information from the DNS entries. Finally, we will discuss historical data and list some services that are useful to get it.

This article doesn’t mean to be totally exhaustive, and we made the choice to only speak about some core features and information types. Other things related to domain names such as getting information from SSL certificates, subdomains, or sitemaps might be elaborated in future articles.

WHOIS and Owner’s Information
#

The most known thing to get information about a domain name is likely the WHOIS, which is a protocol that allows querying databases containing websites owner information. WHOIS can be used as a command line (for example whois domain.tld), but there are also multiple utilities online such as viewdns.info (which has plenty of tools available) or who.is that allow to do queries throw webpages.

The result from the whois command is usually quite verbose. The following example, an extract from Facebook’s whois, shows some of the relevant data that is returned.

Domain Name: FACEBOOK.COM
Registry Domain ID: 2320948_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.registrarsafe.com
Registrar URL: https://www.registrarsafe.com
Updated Date: 2020-03-10T18:53:59Z
Creation Date: 1997-03-29T05:00:00Z
Registrar Registration Expiration Date: 2028-03-30T04:00:00Z
Registrar: RegistrarSafe, LLC
Registrar IANA ID: 3237
Registrar Abuse Contact Email: abusecomplaints@registrarsafe.com
Registrar Abuse Contact Phone: +1.6503087004
Domain Status: clientTransferProhibited https://www.icann.org/epp#clientTransferProhibited
Registry Registrant ID: 
Registrant Name: Domain Admin
Registrant Organization: Facebook, Inc.
Registrant Street: 1601 Willow Rd 
Registrant City: Menlo Park
Registrant State/Province: CA
Registrant Postal Code: 94025
Registrant Country: US
Registrant Phone: +1.6505434800
Registrant Phone Ext:
Registrant Fax: +1.6505434800
Registrant Fax Ext:
Registrant Email: domain@fb.com
Registry Admin ID: 
[...]
Registry Tech ID: 
[...]
Name Server: C.NS.FACEBOOK.COM
Name Server: B.NS.FACEBOOK.COM
DNSSEC: unsigned
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
>>> Last update of WHOIS database: 2021-09-22T01:23:51Z <<<

If we were investigating the domain facebook.com, we could make usage of the following information:

  • We know that the domain name is registered at registrarsafe.com. We could use the contact information provided to complain to the registrar if we had reasons to want things related to this domain to be taken down.
  • We know when the domain was created, when it will expire, and when it was updated for the last time. There are also multiple usages for this information. For example, if we try to determine if an email address is legit (i.e., not used for spamming and such), then we might argue that an email belonging to a domain name registered ten years ago is less likely to be spam compared to an email belonging to a domain registered ten hours ago.
  • We know who is the registrant and how to contact him. This field is however something to process with caution. Domain registrars usually don’t perform any check on the registrant identity, so something totally incorrect could be registered. Also, there are a number of registrars that allow customers to hide their information from the registry.
  • We know which servers are hosting the DNS zones (i.e., the servers that will store the various DNS entries for this domain).

One other naive usage of this information could also be to try to prove that two domains are operated by the same entity, having the same information in the whois is one point that would help to support our views.

Using DNS Queries
#

WHOIS requests are great because they can give us general information about the domain owner and where/when he registered the domain, but it is possible to get more information by looking at the DNS entries.

On Linux/macOS, we can use the dig command to help us gathering information. The syntax is quite simple:

  • dig MX domain.tld will show which server(s) are configured to receive emails for this domain.
  • dig MX sub.domain.com @1.1.1.1 will do the same as the previous example, but it will specifically ask the DNS server 1.1.1.1 for this information.

Without going into DNS specifics (Cloudflare has great documentation if you want to know more), there are multiple types of DNS entries that can be configured for various use cases. Some of the most common are the following (this page shows a more exhaustive list of all the exiting types) :

  • A: to get the IP v4 address associated with the domain
  • AAAA: same as A but for IP v6
  • CNAME: to define aliases. For example, if we have a domain.tld with an A DNS entry pointing to 123.123.123.123, we could create a CNAME entry to say that www.domain.tld should point to domain.tld. This way, if we want to change the server we use for our service, we can only edit domain.tld’s entry.
  • NS: to define the name servers in charge of storing the DNS configuration for the domain
  • MX: to get the email server address
  • TXT: to share descriptive text

The first four items of this list can be useful, but the most interesting types are MX and TXT.

MX DNS Entry Types
#

A MX query through the dig command will return something looking as the following example (where I ran a dig MX mozilla.com).

;; ANSWER SECTION:
mozilla.com.		60	IN	MX	5 alt1.aspmx.l.google.com.
mozilla.com.		60	IN	MX	5 alt2.aspmx.l.google.com.
mozilla.com.		60	IN	MX	10 aspmx3.googlemail.com.
mozilla.com.		60	IN	MX	1 aspmx.l.google.com.

There is not a lot of information, but we can extract that Mozilla has multiple servers that can receive emails.

  • aspmx.l.google.com, which has a priority value of 1
  • alt1.aspmx.l.google.com and alt2.aspmx.l.google.com, which has a priority of 5
  • aspmx3.googlemail.com, which has a priority value of 10

The priority is used to determine to which server emails should be sent to. The lower the priority number, the higher the priority. In practice, it means that if you try to send an email to Mozilla, the email provider will first try to contact aspmx.l.google.com, if it doesn’t work alt1.aspmx.l.google.com, and if it still doesn’t work aspmx3.googlemail.com.

The important point here is that this field allows us to get more information about our target. Specifically, which service it is using to receive email. In our example, we can see that Mozilla is making usage of Google Mail. Sometimes, domains have more imaginative configurations (e.g., using multiple providers), which can help linking domain names together.

TXT DNS Entry Types
#

Similarly to the MX entries type, TXT entries are useful because we can get more information about the services used by our target, as it is often used as a way to prove the ownership of a domain name to third-party services.

For example, if we query the TXT entries for google.com, twitter.com, and apple.com, we can see that the following lines are part of the responses (truncated to improve lisibility)

;; ANSWER SECTION:
google.com.		3600	IN	TXT	"docusign=[code]"
google.com.		3600	IN	TXT	"facebook-domain-verification=[code]"
google.com.		3600	IN	TXT	"google-site-verification=[code]"
google.com.		3600	IN	TXT	"apple-domain-verification=[code]"

;; ANSWER SECTION:
twitter.com.		3600	IN	TXT	"google-site-verification=[code]"
twitter.com.		3600	IN	TXT	"adobe-idp-site-verification=[code]"
twitter.com.		3600	IN	TXT	"atlassian-domain-verification=[code]"

;; ANSWER SECTION:
apple.com.		3600	IN	TXT	"adobe-idp-site-verification=[code]"
apple.com.		3600	IN	TXT	"webexdomainverification.8GVC5=[code]"
apple.com.		3600	IN	TXT	"cisco-ci-domain-verification=[code]"

This allows us to learn that Google is likely to use Docusign to sign contracts, that Twitter uses Atlassian (maybe to store code or documentation), that Twitter and Apple use Adobe Enterprise, and finally, that Apple does video-conferences using Cisco Webex.

All these elements help us having a better understanding of what our target is using, and of where we could dig to try and find out more information (or services to try to exploit if we intend to do penetration testing).

Historical Information
#

We now know how to get information for a domain in its current state, but there is one more tool that can be useful when doing an investigation, that is the historical data. Some of the benefits are:

  • Even if the contact information of the WHOIS is hidden now, there is a possibility that the owner did not enable it when he created the domain.
  • If we are investigating multiple domain names and are trying to make a connection, then looking at the historical data for all of them and see that similar data changed at the same time can be a good indicator.
  • It allows us to have an idea of what the domain was used for at a time t.

Historical data being pretty valuable, most of the good services require payment (and they are usually not cheap). Some free options are:

  • spyse.com: pretty extensive history of DNS record entries, and of used subdomains
  • whoisrequest.com: only shows the change of name servers across time
  • securitytrails.com: historical DNS record data and subdomains
  • osint.sh: historical WHOIS data. Also hosts a couple of useful tools
  • viewdns.info: convenient toolbox but little historical data (to some extent, the Reverse Whois lookup which allows searching domains by owner name)
  • whoxy.com: free WHOIS history, with some rate limitation
  • whoisology.com: some free WHOIS history for registered members
  • whoisxmlapi.com: possibility to get some WHOIS history with the demo

In addition, it is possible to take advantages of the WayBack Machine and similar services to query DNS toolboxes. For example, the following link allows to see Facebook’s WHOIS as it was in 2013. One downsize of this method is that it is less likely that domain names that don’t belong to widely used services are less likely to be archived.

Credits:
#