Metadata Use Case: Using Metadata to Solve the DNS Recursive Lookup Dilemma

The Domain Name System (DNS) problem goes a little like this.

Domain controllers are Windows machines that run a directory and authentication service. For most companies, they also happen to run DNS. When you log into a PC or Mac in a corporate environment, you usually authenticate your username and password against a domain controller, which keeps a copy of your hash, gets you logged in, and decides what files you can see. In short, manages all your permissions.

Now for the tricky (more technical) part.

When you ask for www.gigamon.com, the domain controller looks up the IP address for gigamon.com. But how? In a lot of companies, looking up Gigamon.com doesn’t actually mean the domain controller goes out to the Internet and asks the root server for www.gigamon.com. It almost never works that way. Domain controllers—because they control authentication, passwords, access/right management—are some of the most valuable machines on your network. Therefore, they are also some of your most secure boxes and almost never touch the Internet directly.

For this reason, DNS is designed to use something called recursion when you make a lookup. This means that when you ask for www.gigamon.com, you go to whatever server is configured to look up www.gigamon.com and say, “Hey server, what’s the IP address for Gigamon?” And the the server goes, “Heck if I know. Let me make a recursive lookup.”

In most companies, the next hop for recursion is an Internet-facing server and those are often purpose-built to do only DNS (e.g., an open source DNS server like BIND or DJBDNS). Your domain controller will connect to a DMZ, hit the Internet-connected machine, which, in turn, goes to a root server and asks who the authoritative name server for Gigamon is. It then passes that back to you to look up the record for www.gigamon.com.

If you have thousands of PCs and the domain controller is the first place where DNS is being asked, the domain controller goes out to the Internet-facing server. And when you look in the DNS server logs, the requesting IP is—you guessed it—the IP of the domain controller. As an analyst, what you need is the IP of the computer making the request.

Trickier Still

Until very recently, Microsoft did not design its domain controllers to provide DNS logs. Because of this, the only way to get logs is from the Internet-facing server.

Yes, sure, you could get logs from your domain controller, but the problem with that is when you turn on DNS logging, it crushes the server performance to the point where no one can get DNS requests.

Think about that.

For all the thousands of users behind that domain controller and all the tens of thousands or millions of domains requested in a day, the log file would show your DNS server as the only one requesting all of those different URLs. When you want to look into a URL like Gigamon.com or, perhaps, www.illegalactivities.com, you can’t tell who is going where because the only “person” making requests is your domain controller.

That’s the DNS dilemma. Zero visibility.

The DNS Solution

Gigamon can bring light to the DNS darkness using metadata. With a Gigamon appliance on the network between your domain controllers and your users, you can pull DNS traffic right off the wire—without putting an agent on a box, without doing any configuration changes.

More specifically, in environments where DNS goes through several layers of recursion before connecting out of the network, you can configure the Gigamon appliance to send information about the DNS request to an IPFIX collector or SIEM. This is particularly useful when the endpoint is using Active Directory for DNS requests. The traffic is presented with an easy tag and you can now match endpoint to DNS request.