DNS Research

So you're probably here because we emailed you. If you feel that the email we sent was spam, please enter your email below and we will not send you any more emails.

(Note: we cannot account for email forwarding on your end. If several addresses all forward to the same end user, each pre-forwarded address must be blacklisted. If you wish to blacklist an entire range of IP addresses (represented as CIDR ranges), then please email us directly.

We'll never share your email with anyone else. If you're interested in how we got your email see usernames and domains.

If you're interested what we're trying to accomplish and why keep reading

Goals

In response to the spread of cache poisoning attacks, many DNS resolvers have gone from being open to closed resolvers, meaning that they will only perform queries on behalf of hosts within a single organization or Internet Service Provider. As a result, measuring the security of the DNS infrastructure has been made more difficult. Closed resolvers will not respond to researcher queries to determine if they utilize security measures like port randomization or transaction id randomization. However, we can effectively turn a closed resolver into an open one by sending an email to a mail server (MTA) in the organization. This causes the MTA to make a query on the external researchers' behalf, and we can log the security features of the DNS resolver using information gained by a nameserver and email server under our control. The goals of this experiment are

  1. To measure the security of closed DNS resolvers using Email
  2. To measure the relationship between MTAs and DNS resolvers that make queries on their behalf
  3. To measure what DNS queries are made as a result of sending an email under several different spam-prevention measures

Email Spam Prevention and DNS

Mail servers cause several DNS queries to be made as anti-spam measures. This experiment measures the DNS queries caused by sending an email

  1. by itself
  2. under several different Sender Policy Framework (SPF) configurations
  3. with DomainKeys Identified Mail (DKIM) and Domain Message Authentication Reporting & Conformance (DMARC)

We have found instances where SPF records are checked such a in a way that allows us to craft an infinite chain of DNS lookups. Such an attack could be the injection vector for a Kaminsky DNS cache poisoning attack. We will determine how many systems are vulnerable to such an attack

Overview

We send emails to MTAs, encoding information about the MTA in our sending address. We then measure what queries were made to our nameserver, and from what IP addresses. This enables us to determine which DNS resolver makes queries for which MTA, and by looking at repeated queries, we determine whether the resolver has security features like transaction id randomization and port randomization.

There are five phases to this experiment:

  1. Do an Internet-wide port scan on ports commonly used for SMTP (25, 465, 587, and 2525)
  2. For each IP address in the scan, send an email to a recipient served by that MTA with a sending address that encodes the IP address of the MTA.
  3. The MTA will ask its DNS resolver to do some anti-spam checks on the given email address
  4. The resolver asks our nameserver about the email address we sent from
  5. Log all queries to our nameserver, they tell us:
    1. The IP address of the DNS resolver makes queries on behalf of this MTA
    2. What anti-spam protection this MTA had implemented
    3. Whether the DNS resolver had implemented security measures against cache poisoning, like port randomization or transaction id randomization

Each of these steps must be done quickly to ensure that the public IP addresses of the MTAs and DNS resolvers do not change.

Username and Domain Collection

We use publically accessible information to guess the username and domain of an IP address that we collected by port scanning. Using the IP, we do

  1. Reverse DNS lookup to get a domain
  2. Do a Whois lookup on the IP address and record usernames and domains from the whois record.
  3. Use the domain from the smtp 220 response

To see more