mysql反向解析的机制分析与总结

 来源:http://dev.mysql.com/doc/refman/5.0/en/host-cache.html
[popexizhi]
原文是mysql官网给出的内置host cache的运行机制，这里很好的解释了mysql反向解析的原因。不打算翻译原文了，但是复述一下过程和自己的理解，给这次问题一个阶段性总结，也试着站在mysql的设计者肩上看看问题:)

mysql 在内存中自己维护了一个包含ip,hostname error信息,信息介绍甚至是错误过程的详细log的 叫做host cache的地方；
如果某个客户端首次向mysql server发申请链接，mysql 服务器链接这个客户端前，先向将这个要链接的Ip:A从DNS解析过程中翻译为hostname，在用这个翻译来的hostname 再次通过DNS解析翻译回ip:B，将这个ipB与最开始的ipA进行比较，如果A和B完全一致，mysql就把这个ip和hostname写入自己的host cache中，再次连接时就用这个内容了，直到使用时在hostname中查询无法找到要链接客户端的ip和hostname就再次重复以上过程。
这个过程就是mysql的反向解析。其中两个查询DNS过程特殊提到使用线程安全函数gethostbyaddr_r()和gethostbyname_r();如果操作系统不支持这两个线程安全函数，就使用互斥锁来完成以上过程。无论是哪个这个纠结的过程应该就是为了链接的安全性而设计的，两次查询的过程对比，是防止了DNS包的篡改；查询的时函数要求是 防止查询过程中的内存数据篡改，看来这个机制出现前mysql应该是为应对很暴力的欺骗和篡改者发出的。mysql还将这个过程中如果最后对比失败时，将全部的查询过程message 都存入了host cache，这个位置是为之后分析留下详细证据啊！:)
[doing]有时间了，自己模拟工具，修改DNS包或是修改内存ip试试，看看这个信息的位置和详细内容:),try一下。

文章的下面就是介绍了对这个host catch的更新过程，每次插入如果已满，使用最少试用被替换的原则。这样引起的问题如果host catch过小这个切换过程就太频繁了，默认是HOST_CACHE_SIZE 是128.根据需求可以调整大小的。
mysql安装过程中默认是开启这个dns反向解析过程的，要是手动关闭使用“skip-host-cache”
"The host cache is enabled by default. To disable it, start the server with the --skip-host-cache option."
看来mysql官方是默认发布就提供此位置安全的设置的，很谨慎啊!

对了忘记了这个反向解析的例外：回环地址127.0.0.1不查，uinx sock file 不查，named pipe 不查，shared menory不查。回环不查，好理解，共享内存吗？这个应该是系统安全保障范围，不查也好说，但是命名管道和unix sock 文件系统我不是很了解了，是不是也是系统安全保障啊？回头【go】一下吧。

我的看到的问题是没有外网地址是大量的NBNS包 可以解释了，查DNS的包了。
分析到这里这个事就可以告一段落了，发现每个特殊的需求和设计都会有背后的此起彼伏的现实力量支撑的，你不理解只是你的阅历不够啊！看到这样的设计，似乎都可以意淫一下曾经的硝烟的味道了。:)
总结要做的之后的事:
1.[doing]模拟攻击，修改DNS包或是修改内存ip试试，看看反向解析失败的信息的host catch的位置和详细内容:),try一下。
2.[go]host catch的uinx sock file 不查，named pipe 不查，shared menory不查 的这几个的运行原理，是什么保障安全的。mysql设计上的界限如何画出来的:)

以上只是自己对原文的理解，不保障正确，推荐大家都看看，有疑点我们交流吧！:)