DNS lookups with Sagan.

You're likely here because you're seeing the following message in your sagan.log or on the console.

[*] --------------------------------------------------------------------------
[*] Sagan DNS lookup need for backup.att.vistech.net.
[*] This can affect performance. Please see:
[*] https://wiki.quadrantsec.com/bin/view/Main/SaganDNS
[*] --------------------------------------------------------------------------

During log normalization, Sagan is seeing a hostname (ie - "host.example.com") rather than a TCP/IP address for the source. A good example of this happening is running OpenSSH with the "UseDNS" enabled.

Jan 19 12:06:44 ids001 sshd[25197]: error: PAM: Authentication failure for bobuser from host.example.com 

What Sagan would like to see is a log message like (ie - "UseDNS no")

Jan 19 12:06:44 ids001 sshd[25197]: error: PAM: Authentication failure for bobuser from

Why are DNS lookups "bad" with Sagan?

There's actually several reasons. The first and foremost reason is due to performance. When Sagan see's a hostname rather than a IP address, Sagan must take the time to do DNS queries to resolve the TCP/IP address of the hostname. This means that the Sagan engine has to stop processing events and deal with DNS requests. In environments with low log volume, this might not be an issue. However, there are other problems with using hostname -> DNS resolving. I'll get to how to disable this message at the end of this document.

Another reason that DNS lookups are "bad" with Sagan is that you can't always "trust" the lookup you get back. Or, the host your looking up might have multiple DNS entries tied to it. For example, let's say your log entires show a host connecting from "google.com". If we resolve "google.com", we'll get back multiple IP addresses (,,, - in my lookup ). So which IP address do we correlate with the event? We can't reliably say. Sagan will take the first TCP/IP address return and use that for correlation. This of course, is not ideal.

For better correlation and performance, consider finding the offending host sending the logs to your Sagan sensor with hostname information rather than TCP/IP addresses, and switch it to TCP/IP addresses only.

If you find yourself in a situation where this cannot be done, you can disable the DNS warning by adding a "disable_dns_warnings 1" in your sagan.conf file.

If must have DNS lookups, here's what to do...

In some situations, you might not have a choice about doing DNS lookups or not. If that is the case, enable the "disable_dns_warnings" and enable the "syslog_src_lookup" option. This will detect and do DNS lookups when needed and cache the results. This will cause less of a performance hit with Sagan.

-- ChampClark - 2011-01-19

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r3 - 2013-04-10 - ChampClark
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback