DNS tab

DNS has an important role in how end users connect to the internet. Inspecting DNS traffic between client devices and your local or external DNS servers could reveal suspicious activity. This is possible by using specific widgets and thanks to the aggregation capabilites of the Devo application. In order to be available for most of the customers, we decided to use only firewall logs to detect DNS traffic behaviour. 

Using the time travel option at the top, it is possible to apply a time filter to the widgets in the tab in order to inspect activity at an earlier date. You can select a single day by clicking a day in the heat calendar widget. For instance a day with an especially high amount of traffic. Then select Apply interval and all widgets will be updated immediately.

Alternatively, you can select either a single day or a time period using the time travel filter controls. There are buttons for selecting recent periods or calendar controls to select specific dates.

DNS traffic evolution

You can check the DNS traffic history through a heat calendar that shows the daily amount of DNS traffic over the last 12 months. The line chart next to it shows a comparison of traffic using DNS versus non-DNS traffic over the last 30 days.

DNS traffic flow

In a large organization, it is important to know the performance of the DNS servers. Using the Security Insights application and the aggregation capabilites of Devo, it is possible to detect internal servers that might be operating as DNS servers.

For this purpose, we will use a graph cross search wigdet that joins two different queries. The first query detects outbound traffic to internal DNS servers (on the left). The second query detects outbound traffic to external authoritative name servers, or DNS root servers (on the right). The correlation between both queries ensures that the servers shown in the middle are those ones acting as DNS. You can cross-reference these servers with the company DNS list to see if any server is missing, or if any server is acting as a DNS when it shouldn’t, or if a DNS server doesn’t appear to be serving names correctly.

Use case

The normal behaviour of a cache DNS is resolving known addresses of the internal request. When the requests contain unknown sites, the cache DNS resends the request to the authoritative or root DNS servers. They send back the response, and the cache DNS stores the result in its internal list. In this way, the next time an internal IP requests for the same address, it will be stored in the cache list, unless the validation time has expired.

There are several configuration options for a DNS. In the following example, we can see many requests from the internal IPs to the cache DNS, and a few from the cache DNS to the authoritative or roots servers.

You can select any of the DNS servers and then zoom in to check private IPs (at the left) and external DNS servers (at the right).

Other configurations are possible. You may not want to delegate requests to the cache DNS. In this case, cache DNS servers will be in charge of most of the workflow, resending each request to the external DNS (authoritative, root or other external DNS servers) to resolve any domain they are asked for. This situation means that many requests are sent outside the network, and also means that most of these requests to external DNS could be repeated depending on the TTL for each of the domains/servers (a typical TTL could be 3600 seconds).

The above-explained case is represented in the following capture. For this particular network, this is the desired behaviour for the internal cache DNS.

Go to Graph diagram to check all the possibilities that this type of chart offers.

DNS requestors

This Sankey diagram shows the IP addresses that have requested more than 15 different DNS during the selected period, and the table lists the IPs that have requested the most different DNS during the selected time period.