Client Subnet Reporting – Analyze & Optimize 

Security vendors offering DNS-based security services likely all agree most enterprises underutilize the telemetry generated by the Domain Name System. Analyzing DNS queries typically applies to protective DNS solutions (i.e. Recursive resolvers) given this is where blocking is most effective.  However, analyzing the anonymous traffic of the authoritative nameserver can also provide value. Beyond the IP address/subnet originating the query, public DNS data may also be in the form of query volumes, queried hosts (www), associated responses (AAAA), and protocols (UDP). However, most providers will not offer this level of granularity. If you’re using the Registrar’s DNS, there may not be any reporting. The IP addresses in the logs of the nameserver will mostly contain the recursive resolvers’ IP addresses. However, DNS specifications have been expanding the size of several parameters, known as Extension Mechanisms for DNS (EDNS). One component of EDNS is the Client Subnet (ECS), which sends general information from resolvers to name servers about clients’ geographic locations. UltraDNS supports EDNS Client Subnet through its geographic-based responses called Directional records. UltraDNS also offers detailed reporting around the Client IP and subnet that made the query. UltraDNS augments the logs with IP geolocation information. Clients could query their own Geo-IP source and gain even more insight, like the IP address’s registering organization (e.g., whois information). Given this additional context about the source of the queries, organizations may be able to optimize their configuration or infrastructure.

Security issue or misconfiguration?

The security teams will be interested in many types of DNS reports. Inevitably, they will ask, “Where is this traffic coming from?” The source of the traffic is often a leading indicator as to whether the traffic is malicious (e.g. Water Torture) or leakage. Both malicious traffic and DNS leakage usually result in the same response, NXDOMAIN, but look different when viewed over a timespan.

Likely malicious	Likely a configuration issue

In both cases, the requests are typically for hosts that do not have a configured resource record. If an abnormally high percentage of requests result in NXDOMAIN, then knowing the origin helps determine if the problem can be addressed by the organization managing the authoritative DNS. This is usually the result of a split-horizon configuration. It may be possible to change the DNS configuration so laptops that are off-net do not query private IP addresses.

Client IP reporting.

Given the importance of the query source, one UltraDNS report that is extensively used when analyzing traffic anomalies is the Advanced Client IP. The Client Class C is provided, and the geographic location is attached. UltraDNS integrates a geo-IP database mapping the IP address to a location. Most times, this IP address will be a recursive resolver where the query has been forwarded. If the recursive DNS service supports “Client Subnet in DNS Queries” (EDNS0), then it could be the stub resolver (the client that made the original DNS query). From a security perspective, knowing the subnet of suspicious traffic allows association with other subnets. Meaning, if two distinct subnets have similar traffic patterns then potentially there is a relationship. The Vercara UltraDDR detection engine uses a similar methodology. If a nameserver is determined to be suspicious, all zones served by that same nameserver are watched more closely. Registration information can also be obtained using the IP address. There are several free services offering ad-hoc IP address lookups. This registration information may provide clues in a security analysis. In one instance where a customer saw a spike in traffic, the Advanced client IP analysis found that almost all queries were coming from recursive servers in a CDN provider’s network. After working with the CDN provider, they found a misconfiguration in their recursive servers and were able to solve the problem.

Building DNS innovations at Vercara.

Many DNS systems, both managed service providers and on-premises as well as company managed nameservers, lack in reporting due to the performance impact and storage costs. The Product and Engineering teams at Vercara are always evaluating these tradeoffs. The compromise was to create more granular and longer data storage as an option, the UltraDNS Private Data Lake. Given that UltraDNS is an API-first platform, the Client IP logs (and all reports) are accessible via a RESTful interface. This makes it easy to import into a SIEM/SOAR for further analysis. For more information on UltraDNS, please visit our product page.