-- VictorJulien - 09 Dec 2008

David Dagon wrote:

I think in summary I can suggest three categories of DNS module filtering, based on the amount of time they require:

-- rules that do inline per-packet checks (e.g., queries from DNSBL listed hosts; other IP-layer intel); this ideally works at line speed. Some narrow state window, on the order a small multiple of DNS timeouts, should let one do simple checks across DNS conversations. (E.g., a class of SLBs can be found by noting a non-response to AAAA?, and an affirmative response to A?.)

Such rules are IPS candidates, garden-wall capable, etc.

-- rules that can be done inline, but should also be done on subsequent updates of data feeds. (E.g., RRsets can be checked for dom and ip4 BL matches; subsequent updates should be rechecked so one can alert that a host was likely an early infection victim). This works at line speed; a lower priority thread rechecks key records based on updated intelligence feeds, DNSBLs, etc. You might expect DNSBLs will update once every 15-20 minutes; a suitably small time-based LRU structure may let you recheck a window of previously seen DNS traffic.

Similarly, this class of includes rules that would trigger only after active traffic probes complete. (E.g., after witnessing a cautionary RRset, the tool queries for MX, SOA, and triggers only after analyzing the answer.) Assuming one finds heuristics that work and are not DoS? contributors, these rules would need some time--multiples of average RTT times--to complete. So a short window of old traffic is useful; something more than flow bits.

-- rules that require keeping complex state on a DNS conversation, and are therefore much slower. (E.g., delaying analysis of a TC truncated DNS packet, since we later observe the affected host is successfully doing a tcp connection, or edns0 is being used, etc. Counts of NS and other metrics are best done against the larger data).

Machine learning fits here, potentially, but really might be off a span or using dedicated hosts.

I think everything in this thread, even if not yet a mature stand-alone filter, can fall into one of three categories. (Is there a 4th?) This might help you design general properties of the dns detection module. A user would potentially label which rules fire at which stage of decoding: per-packet, per-DNS-conversation, or post-hoc analysis.

We're entering an era where DNS vendors are now building IDS-style security into their offerings; even IPS capabilities. So perhaps the third category (certainly more difficult to code) is a lower priority in your tool. I almost think there's need to create a DNS-specific offering, since traffic aggregation for DNS clusters makes it easy to gather large amounts of traffic. The more traditional tcp and DPI work seems better done elsewhere in the edge. Perhaps your dns module, when run exclusively, would fill that role.