DNS is one of the most essential network services - often poorly monitored - and any outages may lead to a major business impact. Let’s take a look how Flowmon is able to monitor DNS protocol and how you can benefit from it.
Flowmon is able to monitor DNS (Domain Name System) traffic for quite a long time (since version 7.04). DNS monitoring is a part of our Flowmon IPFIX Extensions (Flowmon Probe feature) which allows us to monitor variety of application layer protocols and NPM (Network Performance Monitoring) statistics. Application layer visibility provides us with capability to solve various use-cases and makes network troubleshooting easier. In my previous blog I have covered some of the use-cases of DHCP monitoring. Today, we will have a look at DNS monitoring.
Domain Name System Monitoring
Let’s start with a quick recap. DNS (Domain Name System) translates human-readable domain names we use every day to numerical IP addresses, which can be processed by computer services. The DNS is the primary directory service and essential component of most internet services.
There is a lot of reasons and motivations to monitor DNS traffic on application layer and get full visibility into this substantial protocol. Thanks to the DNS protocol visibility we are able to support various auditing, security and operations use-cases.
Figure 1: Sample use cases of DNS monitoring.
Today we will take a look at the auditing and operations use-cases and the next blog post will be security oriented with customer use-case.
DNS Monitoring in Flowmon
Flowmon Probe is the key enabler for DNS traffic monitoring. When the Probe comes accross DNS traffic, it looks not only into network and transport layer, but makes packet inspection and looks into DNS data as well. Probe then enriches the flow record with DNS data and exports it into the collector, where the flows are stored and analyzed.
On the Figure below, we can see example of output in Flowmon Monitoring Center, where each line represents one flow record. The output is customizable by user, so it is possible to show additional information like protocol, number of bytes, packets, etc. if needed. First flow is DNS query sent by client (user “employee” with IP address 192.168.0.22) to DNS server (IP address 192.168.0.1). The client wants to translate domain “email.seznam.cz” (Czech equivalent of Gmail) to an IPv6 address (question type is AAAA). Second flow is response from DNS server to the client providing IPv6 address of the the domain in the query. Note that we are also able to add user identity information to each flow record based on authentication services (more information here).
Figure 2: Example of domain name translation.
Figure 3 shows all DNS parameters monitored by Flowmon. You can use these DNS parameters for Top N statistics, creating report chapters and alerts. Parameters can be used for filtering rules and analysis of the DNS traffic.
Figure 3: List of all monitored DNS parameters.
DNS Monitoring Use Cases
Monitoring and visibility into DNS protocol makes administrators’ life easier while providing a range of benefits. So let’s have a look at them.
DNS Logging and Basic Diagnostics
DNS protocol monitoring can be used for logging of all communications between clients and DNS servers. Regarding the DNS platform and number of DNS servers, Flowmon is the single point of truth where you have all the queries and responses in form of flow records (Figure 2). Flow records can be filtered using all extracted DNS parameters (Figure 3) enabling you to tackle problems very quickly. And to speed the troubleshooting up, flow records are also extended with user identity. To see all flows with DNS traffic, go into Flowmon Monitoring Center / Analysis , select respective time-frame, click on “List Flows” , select “Sort by start time of flows” , select default output “extended-dns” (you can edit or create your own outputs), enter filtering rule “port 53” and clink on “Process” . The result is a table with all parameters defined in output and it can be exported as text or .pdf file or in CSV format.
Figure 4: How to get list of all DNS communications.
You can also use aggregation and statistics to get overview of DNS communications. Click on “Statistics” , select parameter for aggregation (question names, query type, return code, etc.) and click on “Process” . Figure below is example of Top 10 DNS Question Names (1st & 2nd level domain) ordered by packets.
Figure 5: Top 10 DNS Question Names (1st & 2nd level domain) ordered by packets.
You can create report to see such statistics. If you want some inspiration, check out reports and chapters configuration in our Flowmon online demo.
Mail Servers and Reverse DNS Records
Reverse DNS records (in format “reverse_IP_address.in.addr.arpa” ) are used for authorization in e-mail communications. Some of the receiving mail servers validate sending mail server using PTR reverse records and some even do not even accept a message from IP address which does not identify itself this way.
Correct configuration of reverse records can be easily checked in Flowmon. Just use the following rule to filter PTR records and go through the result or optionally add IP address of your SMTP server. Special attention should be paid to flows, where DNS Response Code is NXDomain.
dns-qtype "PTR" and dns-qname "arpa"
Non-existent Domains
Responses with Non-existent Domains (NXDomain) can represent problems with domain translation or even malware infection , especially when there is a high volume of such responses. To get top 10 hosts receiving NXDomain reponses in our network, enter filter “dns-rcode “NXDomain” and dst ctry 0” (dst ctry 0 to exclude our public IP addresses). Special attention should be paid on hosts with a large amount of received NXDomain responses.
Figure 6: Creating filter to see Top 10 hosts receiving NXDomain response.
Sample of top statistic is depicted below. Right-clicking on IP address shows context menu, where you can click on “First Flows” to list individual flow records any see DNS Question Names and other information.
Figure 7: Top 10 hosts receiving NXDomain.
Check out Alerts on our demo to see how you can configure alert, which will automatically alert you on situation, where any hosts in your network starts to receive high amount of NXDomain responses.
Incorrect Host Configuration
Several problems can be introduced when host’s TCP/IP configuration points to public DNS server. It might be in contrary with network operational or security politics. Also host might not find the SRV (Service Locator) records that advertise authentication services like LDAP, Kerberos or other services and thus not being able to authenticate.
To check hosts who use public DNS servers you can use statistic by source IP address ordered by packets and enter following filtering rule:
dst port 53 and not dst ip dns_server_ips
You can also check, if the host reporting the problem with authentication received SRV record using simple rule for filtering flow records:
ip hosts_ip and dns-qtype “SRV”
Conclusion
Monitoring DNS traffic extends your visibility and supports various use cases. Today I have covered some of the use cases to give you an idea how you can use analytical capabilities of Flowmon Monitoring Center and DNS monitoring. If you are interested in how to automate DNS traffic analysis and security use cases, check out Flowmon ADS module and stay tuned for the next blog post. It will be focused on security and I will show real customer’s use case.