Understanding Snort DNS TTL Alerts

While reading a recent Network Computing magazine article, I noticed an interesting discussion of "DNS-based route optimizers." These sounded like the products which confused IDS operators four years ago. I read about it in an earlier NWC article.

This December 2003 article states:

"Handling external Web requests... is accomplished by advertising a low DNS TTL of about 10 seconds. This forces the end user's DNS server to request an updated IP address every 10 seconds... the device will provide the external IP address that will provide the best path through the network."

The whole idea with DNS-based systems is to trick clients into visiting the server that's "closest" to them in Internet space. By "closest" I mean the one offering the lowest latency. It's a performance enhancement for visitors.

NWC's graphic does a nice job explaining the system.

Notice the mention of "probes." The review mentions ICMP and TCP-based "probes" in its product feature list. NSM analysts might see these probes and consider them suspicious, when they're normal and harmless.

This made me think of recent alerts I'd seen in Sguil, based on this Snort rule:

alert udp $EXTERNAL_NET 53 -> $HOME_NET any
 (msg:"DNS SPOOF query response with TTL of 1 min. and no authority";
 content:"|81 80 00 01 00 01 00 00 00 00|";
 content:"|c0 0c 00 01 00 01 00 00 00 3c 00 04|";
 classtype:bad-unknown; sid:254; rev:3;) 

This rule was written to detect intruders responding to a victim's DNS query before the legitimate DNS server does. Whether this is worthwhile is debatable, especially since the rule uses the DNS TTL of exactly one minute. An intruder who uses 59 or 61 seconds evades this rule.

Here is Ethereal's look for one of the DNS responses which triggered this Snort rule. I queried for www.orbitz.com, and the DNS record it returned had a TTL of 1 minute and no authority records. Because the DNS TTL is so low, www.orbitz.com might be using a DNS optimization scheme like that mentioned in NWC.

Compare that to a response for images.amazon.com, where the TTL for the first record is 0, the second has is 5 hours 32 minutes, and the third is 20 seconds. Amazon.com appears to use Akamai extensively:

Finally, keep those responses in mind when looking at the DNS info for a smaller company like Sourcefire that doesn't need to play DNS tricks:

This mini-case study shows how keeping current on Internet infrastructure products helps NSM analysts understand their alerts.