Dns

大家经常使用bind的时候是划分不同的view的，因为每个view的zone需要单独修改，所以人肉修改是比较麻烦的。这个时候可以使用nsupdate进行批量的操作。只要注意每个view使用正确的记录就行。使用nsupdate需要给每个view都创建一个key，每个view指定允许对应的这个key能更新。views.key文件： key "default" { algorithm hmac-md5; secret "GkbQ6Q2WtVqu9pk8WzPDOA=="; }; key "test1" { algorithm hmac-md5; secret "4qEjC+NgFmRvGdt8DuCRDA=="; }; key "test2" { algorithm hmac-md5; secret "88PUPwk66CbQacWCgFG0kw=="; }; named.conf文件 controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; }; // acl test1 { 10.0.0.0/8; }; acl test2 { 192.0.0.0/8; }; acl slavedns { 192.18.208.31; //ztt dns1 127.0.0.1; }; options { listen-on port 53 { any; }; listen-on-v6 { none; }; directory "/opt/bind/etc/"; dump-file "/opt/bind/var/named/data/cache_dump.db"; statistics-file "/opt/bind/var/named/data/named_stats.txt"; memstatistics-file "/opt/bind/var/named/data/named_mem_stats.txt"; zone-statistics yes; allow-query { any; }; ...

权威DNS的防攻击相对容易一些,对于一般的小公司的话可以使用rrl模块做简单的限速就能取得不错的效果。测试过开启限速后使用queryperf去打，bind的负载基本不会上升的。递归DNS的防攻击会负责很多。如果单纯使用开源的解决方案就只有rrl和rpz这2个东东可以考虑了。值得一提的是在bind9.9.4里把这2个patch合并进去了。现在最新版的bind都是可以使用rpz设置对每个不同的域名做返回策略，rrl也可以限制好单个IP或IP段的频率。编译参数： #/opt/bind/sbin/named -V BIND 9.9.4-P2 (Extended Support Version) <id:3f00a920> built with '--prefix=/opt/bind/' '--enable-rrl' '--enable-epoll' '--enable-threads' using OpenSSL version: OpenSSL 1.0.1 14 Mar 2012 rrl的配置可以参考： rate-limit { responses-per-second 20; nodata-per-second 10; nxdomains-per-second 10; errors-per-second 10; //all-per-second 60; ipv4-prefix-length 32; max-table-size 10000; slip 2; //log-only yes ; qps-scale 50000; window 5; }; 其中ipv4-prefix-length设置掩码为32位，就是对每个IP都独立限速， responses-per-second是对每个客户端响应速度上限。qps-scale是一个系数，比如设置qps-scale 250; responses-per-second 20，当访问的qps是1000的时候，对单个ip的限速就变成了250/1000*20=5。详细的配置可以参考http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html#options [ rate-limit { [ responses-per-second number ; ] [ referrals-per-second number ; ] [ nodata-per-second number ; ] [ nxdomains-per-second number ; ] [ errors-per-second number ; ] [ all-per-second number ; ] [ window number ; ] [ log-only yes_or_no ; ] [ qps-scale number ; ] [ ipv4-prefix-length number ; ] [ ipv6-prefix-length number ; ] [ slip number ; ] ...

最近遇到几次DNS的主备同步问题。 每分钟动态生成反解，然后发现有的slave服务器上不更新。通过日志看到每次都是最后一个slave机器收到notify消息去master上请求传输zone时有报错，提示master服务不可用。后来发现是master上的transfers-out没有单独指定，这个值默认是10，所有可能比较多slave机器请求时就失败了。把这个配置根据实际的情况调整后解决的。 海量的域名同步时，slave查询soa都查不过来。 到底多大是海量？这个自己看看自己机器上的域名总数能占到中国所以域名的几个百分点以上吧。当数量大了后确实是各种问题都出来了，这个我是观察了一下有个serial-query-rate 可以设置soa查询速度的，默认是20/S，对于有海量域名的DNS来说这样显然是跟不上节奏的，直接把这个调整到5W/S，查询速度飕飕的。对于master的压力其实也还好，就当时收到那么点请求。相应地tcp-clients和transfers-in，transfers-per-ns也要做好调整。 SOA的TTL设置问题。 这个其实也不算是什么问题。就是nxdomain的缓存时间是有SOA TTL决定的（如果本地LDNS没有单独设置的话）。有人先把1个域名删除了，接着又有人去解析一下这个被删除的域名，然后之前的人把域名又加上去。。结果所有人在办公网访问不了这个新增的域名。其实这个就是NXDOMAIN的缓存问题。我只有直接把SOA TTL缩短一下。 很多性能上的问题我们需要根据日志来看到底存在的瓶颈是在哪里，然后再去考虑如何优化。没有目的的优化是瞎折腾。

一个域名的权威DNS往往都有多个，有其实域名服务商或者一般的互联网大公司的NS可能非常多。那么我们的local dns做递归的时候是如何选择使用哪个NS呢。一般是根据SRTT算法来做选择。不过的软件的方式有所不同，总的来说有几种：1. 选择RT最短的NS。2. 平均选择RT小于一定阈值的NS。3. 把NS参考RT和一些其他的因素进行排序，按照不同的比例进行选择。 可以参考一下这个PDF。 [PDF](http://www.google.com.hk/url?sa=t&rct=j&q=Name%09%20%20%20Server%09%20%20%20Selec%2Bon%09%20%20%20of%09%20%20%20DNS%09%20%20%20%20Caching%09%20%20%20Resolvers%09%20%20&source=web&cd=1&cad=rja&ved=0CCoQFjAA&url=%68%74%74%70%73%3a%2f%2f%77%77%77%2e%64%6e%73%2d%6f%61%72%63%2e%6e%65%74%2f%66%69%6c%65%73%2f%77%6f%72%6b%73%68%6f%70%2d%32%30%31%32%30%33%2f%4f%41%52%43%2d%77%6f%72%6b%73%68%6f%70%2d%4c%6f%6e%64%6f%6e%2d%32%30%31%32%2d%4e%53%2d%73%65%6c%65%63%74%69%6f%6e%2e%70%64%66&ei=mY6LUuHED8nniAfCrYHYAg&usg=AFQjCNH4TlHk2K_1r4q6ia_NgtMJlTRVmA&bvm=bv.56643336,d.aGc)

这几天有开发同学反馈说是线上的应用dns解析总是失败，我自己测试了连续dig 1000次都是正常的。今天也把合作方的同学一起叫上了。因为之前是看对方有的CNAME设置的TTL是0,造成每次需要重新解析，dns服务器没有办法做cache。 今天排除了很久，后来看了线上的日志才发现问题的本质是业务量非常小，每天就几十笔调用，即便对方把TTL改成60后，实际每次应用服务器查询dns的时候，dns服务器都是需要重新递归一次（每次两三秒），所有可能没有解析出来应用都已经报错了。 这个也没有啥好的解决的方式，要么应用把这个超时时间增大，要么自己另外跑个脚本周期性地访问dns缓存住这样的域名。