Nsbeta.info的两组DNS服务器：
dwdns1.nsbeta.info.
dwdns2.nsbeta.info.
这个大家可以自己查询到。这2组NS服务器共对应6个IP，其中2个IP位于广东茂名（电信和联通）、2个IP位于广州（电信和联通）、1个IP位于无锡（电信）、还有1个位于郑州（联通）。
这2组NS服务器是工作机，还有一个发布机，属于隐藏的NS服务器。在发布机上，运行着BIND9服务器、MySQL数据库、dnsmapper动态更新程序、DNS API，基于API可以实现Web管理系统及命令行管理程序。在生产机上运行BIND9服务器。架构如下：
Paul Vixie写了一封邮件，通告RRL的新版本发布：
this patch fixes the signed vs. unsigned bit field problem recently discovered by irwin tillman. http://www.redbarn.org/dns/ratelimits has the pointer to the new code, all of which came from vernon schryver.
我之前和Paul打过交道，以为他是局外人士写的这个补丁。他写这封邮件时，用的isc.org的邮件地址，我以为他开始为ISC工作了。于是有了如下会话（蓝色是我的问题）：
发个招聘帖，所在部门招人，职位是普通运维和运维开发。公司位于珠海，是知名的游戏公司。这里环境优美，依山靠海，公司人文和技术氛围都很好，欢迎有想法、有才干童鞋加入。简单描述岗位情况：
普通运维：
运维开发：
有意的同学请联系风河，来信必复。
Paul Vlaar写了一封邮件，描述了RRL的一次DDoS防护效果。RRL发挥作用后将18万每秒的DNS查询量降低了80%，将2.3G每秒的攻击流量降低到70M。如下是邮件全文：
Hi all,
I just wanted to share this graph showing the effect of RRL during an
attack that we were seeing to a node of ours not doing RRL yet on that
particular nameserver.
We're still seeing spikes of up to 180k DNS queries per second, but due
to the RRL we're now at a rather steady rate of 80% query drop. Biggest
percentage I've seen so far. It does appear that for this particular
attack the source (probably spoofed) addresses are a relatively small
subset, so RRL is particularly effective at keeping traction here.
We went from ~2.3Gb/s to less than 70Mb/s on the outbound after we
turned on RRL. We're running BIND 9.8.3-vjs197.16-P4 here, and these are
the RRL config settings:
rate-limit {
responses-per-second 5;
errors-per-second 5;
window 15;
slip 5;
};
Obviously this is a huge improvement for everyone involved.
I hope this is of interest or inspiration to anyone. If anyone wants to
know more details, let me know.
Much thanks goes to the developers!
公司发了两只YY熊，样子傻的可爱。看了下日历，今天是农历11月15日，是我一个亲戚的生日。印象很深刻，2年前的这天，公司还在南软那荒无人烟之处。晚上加班9点多走出那座圆形大楼，外面皓月星空、万籁俱寂，空气有点冷，带着淡淡的凛冽。在浩瀚时空中，人生如此渺小，只能遥祝亲人平安。如今2年转眼过去，还是这个日期，但是不同的心情、不同的地点。
今天在cnBeta看到百度的Mac输入法，下载后在Macbook里装上，感觉还不错。取词准确率、速度这些且不说，至少它有个好处，就是输入状态是根据任务来的。例如，我在word里打开了中文输入，这个中文输入只对当前word有效，在终端里就无效。之前装的是QQ输入法，它的输入状态居然是全局的，在一个地方开启了中文输入，其他任务里都是这个输入状态，这让人很不爽，也很无语。
还有，我的Android手机之前装的搜狗输入法，也早换成了百度的。因为手机比较旧，只有512M内存，搜狗那个输入法内存几十兆，比百度的大很多，趁这点就换掉了。PC电脑还装的搜狗，但不明白的是，一个输入法整天在那里弹窗干什么？你以为是QQ啊！看来迟早也要换了它。
我与百度没有任何关系，从来不使用它那个搜索引擎。但是百度的输入法用户体验真心不错，贴心解决用户需求的产品，就是好产品。
我们有两台API服务器，Webservice是本人写的Apache Handler，数据库是Mysql，操作系统是Ubuntu Linux。看了下，这2个服务器昨天共处理了95万唯一IP的请求，并且请求数还在每日递增中。请求都是动态的，其中60%是写DB，40%是读DB。三台服务器（2台web、1台db）负载非常轻，几可忽略不计。
在晚上高峰期的时候，每台web服务器跑了500多个Apache进程，共打开1000多个到数据库的长连接。之前我意识到连接数会很大，因此把Mysql配置里的如下参数都调整过：
max_connections = 2000
open-files-limit = 2000
这两天在访问高峰时，发现web服务器的错误日志会报错：
Lost connection to MySQL server at ‘reading initial communication packet’, system error: 0
前面的博客介绍过，位于法国的gandi.net是一家不错的注册商，历史悠久，口碑甚好。楼主前几天也在他们家煮了个.me域名，在操纵DNS解析时，却费尽周折，深感他们家的DNS系统不是一般的复杂。在搞定后，写下此教程，经验共享之。
很多DNS系统比如DNSbed.com，都提供泛域名解析。所谓泛域名，就是一个星号表示子域名，例如*.example.com，这个星号可匹配任何不存在的域名，并解析到默认地址。泛域名有些时候很方便，比如你有很多子域名，都指向一个IP地址，那么配置个泛域名解析就行，不用一条一条去添加子域名。
但是，泛域名并不是想象中那么好，我的意见是能够不用就不用。泛域名对SEO不友好，我不懂SEO，因此不做分析。除此外，泛域名的问题包括：
SPF很多人都知道，Sender Policy Framework，用来标识邮件发送身份。例如，gmx.net的SPF记录：
v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 -all
这说明，只有从上述IP地址段发送出去的gmx.net域的信件，才是合法信件。非上述IP段发送的信件，其他MTA可以拒收。
我在之前的博文里写过，个人并不喜欢SPF，它会带来一些问题，一个明显问题就是邮件转发。例如，考虑如下转发情况：
[email protected]发送邮件给[email protected]，pobox转发给[email protected]。如果orig.com设置了SPF，而pobox.com在转发时，仍然使用了[email protected]这个envelope地址，那么如果thrid.com检查SPF，则这封邮件会违背SPF，有可能被拒收。