其实SYSOP手段也不是万能的，今天被迫动了一下dnsmasq的源码

今天发现电信通拦截DNS请求，把热门流量导向其内部 squid 缓存服务器。今天主要发现有两个，一个是新浪微博的 css 文件所在的域名 timg.sjs.sinajs.cn 被指向了 124.207.162.88 ，另一个是……查看某个视频的时候，浏览器状态栏提示从 124.207.162.83 下载数据，跟新浪微博被拦截的域名指向同一个 IP 段。但是页面里并没有写是从哪个域名下载视频的。于是乎，我想从公司网关的 dnsmasq 上取得数据，却意外的发现 –log-queries 参数无效，开启该参数后，按文档说明发 USR1 信号给 dnsmasq ，syslog 里却没看到 cache dump。

找了一台 Debian 看了看，是可以的。于是我立即习惯性的阴暗的认为是 RedHat 的软件质量问题。找了一套原装正品源码，编译后发现行为也是一样的。无奈了，SYSOP 手段也不是万能的，只好开始看源码。

源码里搜索 log-queries 找到 getopt 这个步骤，找到其内部名字 OPT_LOG。然后在源码文件里找这个，发现了 cache.c 文件里的 cache_dump 函数中，关于 dump cache 功能的逻辑，这一句是这么写的：

if ((daemon->options & (OPT_DEBUG | OPT_LOG)))

回头找一下 OPT_DEBUG，发现是 –no-daemon 参数。也就是说，只有这俩参数同时用，才能 dump cache，这样不符合 manpage 的描述。于是把 OPT_DEBUG 去掉。编译再试，发现还是不行。又

在 src/cache.c 文件的 cache_dump 函数中，发现几句 my_syslog 函数的 log facilty 有问题，改掉，就 OK 了。btw：加语句调试的过程中，觉得这个 my_syslog 长得很像 fprintf。

重新回去放视频，dump cache，终于在日志里看到了这么一句：
[root@dl360g5 log]# tail -f messages|grep 124.207
Nov 16 17:02:39 dl360g5 dnsmasq[24252]: img.uu1001.cn                            124.207.162.83                 4F        Tue Nov 16 17:07:37 2010
已经报了bug。经与作者讨论，发现自己原文中关于 if 语句判断条件的内容是错误的，故修正。真正原因是 dnsmasq 把 cache dump 输出到了 LOG_DEBUG，而 CentOS 的 syslog 默认不记录 *.debug

124.207.162.88