Salaam!
I've been having a lot of fun with AnalogX's QuickDNS, which has a couple of idiosyncracies ... I run it in the directory containing the DNS cache file, pointing it at log files or other files containing IP addresses it can identify ~ the list of machines infected with the IDA Code Red Worm a couple of years ago, my firewall (Zone Alarm Pro) logs, another DNS cache file, etc. At present my DNS cache file contains 763,415 IP addresses, 208,480 of which are unresolved. I do NOT use QDNS with my Analog config files because it appears unable to find log files from the path and filename in the config files, although it may work better when those log files, config files, etc., are all in the same directory with QDNS.
QDNS fails (at least) two situations:
1. When a DNS returns a url of excessive length ~ around 80+ characters ~ then QDNS truncates the url and adds what appear to be pointers at the end, resulting in an error message at the end of the run saying "The instruction at 0x00402384 referenced memory at 0x74756f7d. The memory could not be read." The second supposed "memory address" varies. QDNS users might want to resolve 66.151.174.204 (105-character url), 66.151.174.205 (107 characters), 66.2.188.14 (82 characters), 67.94.0.46 (86 characters), and 65.45.90.142 (87 characters), all of which caused QDNS to fail. QDNS does not rewrite the DNS cache file in these instances.
The only solution I have found is to split the source file in half and process each half, recursively, until I've isolated the particular IP address causing the failure. A DNS lookup with PCHelp's Network Tracer (or any nslookup utility) resolves the IP, and a truncated version of the url can be added to the DNS cache file by hand (using Programmer's File Editor ~ MetaPad starts to fail when the cache file exceeds about 36 Mb).
Analog will add such a long url to the DNS cache file, at which point QDNS will fail when it encounters it, reporting the same "memory" error.
2. When a DNS cache file contains a bad url ~ one containing a space, for example ~ then QDNS will stop reading the cache file at about that point and report a smaller number of entries than is actually in the file. If allowed to continue, QDNS will then write a new DNS cache file at the end of the run that includes only those entires it read, plus the new resolutions, and that file will be corrupted and possibly unrecoverable. In some instances, it can be unreadable ~ although usually, Analog will simply report corrupted lines and ignore them. The corrupted lines in the new file, however, can be the rest of the file after the corrupted url.
The solution for this is to know exactly how many lines are in the DNS cache file, with entries (i.e., not counting the bottom empty line), and watch QNDS's reporting to see that it reads that many entries. When it does NOT, then it's necessary to immediately shut down QDNS, go to the DNS cache file at approximately the line where QDNS quit reading, look for the corrupted url ~ and fix it. Then QDNS will handle the file properly.
I keep a file, qdns.txt, containing copy-and-paste command lines for a DOS window:
resolve a log file in another directory
qdns.exe /D dns.txt /Y 66.45.212.21 /L D:\Logs\WebLogs\web.log /Z 1
resolve another cache file in the same directory
qdns.exe /D dns.txt /Y 66.45.212.21 /L dnsx.txt /Z 1
resolve a list of IP addresses
qdns.exe /D dns.txt /Y 66.45.212.21 /L list.txt /Z 1
resolve IP addresses in firewall logs
qdns.exe /D dns.txt /Y 66.45.212.21 /L D:\Logs\Web\ZALog.txt /Z 1
I use the "/Z 1" switch to place the new entries at the end of the DNS cache file, as Analog does. It does not appear to have a substantial effect on speed either in QDNS or in Analog.
Once QDNS has (quickly!) added the new IP resolutions to the DNS cache file, Analog goes through the logs like they weren't there ~ so fast, in fact, that I have to open the errors.txt file to find out how many log lines it read ~ the DOS display goes by too fast to read, processing a log file of perhaps five thousand lines.
I have more work for QDNS to do, which I'll address in another post to this list. It seems that over a quarter of the IP addresses in my logs cannot be resolved to canonical names (urls) by my DNS server ... so Analog doesn't know where they are. A big bunch are registered in Paraguay, more in Australia, more in Europe ... I'd like to see them there in Analog's reports instead of in "Unresolved IP addresses."
was-salaam, abujamal +------------------------------------------------------------------------ | TO UNSUBSCRIBE from this list: | http://lists.meer.net/mailman/listinfo/analog-help | | Usenet version: news://news.gmane.org/gmane.comp.web.analog.general | List archives: http://www.analog.cx/docs/mailing.html#listarchives +------------------------------------------------------------------------
