Dns

参考网上找的资料，写了一个简单的脚本，输入域名可以生成使用iptables封禁dns请求的规则，使用于内部递归dns的一些基本防护。 #!/bin/bas h create_iptables(){ name=$1 string=$( echo $name|awk -F '.' '{for(i=1; i<=NF; i++){printf("|%02x|%s",length($i),$i)}}') string="$string|00|" echo -e "rule for \e[1; 32m $name \e[mquery:" echo "iptables -t raw -A PREROUTING -p udp --dport 53 -m string --hex-string "$string" --algo bm -j LOG --log-prefi x "drop an dns query "" echo "iptables -t raw -A PREROUTING -p udp --dport 53 -m string --hex-string "$string" --algo bm -j DROP" } create_iptables_ex(){ name=$1 declare -A types types["A"]="0001|" types["MX"]="000f|" types["CNAME"]="0005|" types["ANY"]="00ff|" types["AAAA"]="001c|" types["NS"]="0002|" types["SOA"]="0006|" for t in ${!types[@]} do ...

近期内部开发反馈某些合作方的域名无法解析。团内同事分析发现这些域名都是托管在相同的一个域名厂商上,而且都是刷新cache后刚开始能解析，过段时间不能解析。 efly.cc bhc888.net 直接dig的时候返回信息如下 ; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> efly.cc ; ; global options: +cmd ; ; Got answer: ; ; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7761 ; ; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;efly.cc. IN A ;; ANSWER SECTION: efly.cc. 600 IN A 121.9.13.185 ;; AUTHORITY SECTION: efly.cc. 168802 IN NS ns2.eflydns.net. efly.cc. 168802 IN NS ns1.eflydns.net. ...

Domain Name System Security Extensions (DNSSEC)DNS安全扩展，是由IETF提供的一系列DNS安全认证的机制,可参考RFC2535。DNSSEC主要是解决递归DNS到权威DNS直接的信任机制问题，并不能解决终端用户的任何问题。目前在国内企业中使用dnssec的比较少。究其原因有两点：1. 不配置也可以用。2. 配置了意义也不大。在国内绝大部分终端用户都是使用ISP分配的递归DNS，而这些递归dns还指望着对流量较大的域名做缓存加速以便节省网间结算费用，因此不会主动去支持DNSSEC。当这些递归DNS都不支持DNSSEC时，在权威DNS上实时DNSSEC的意义就很小了。DNSSEC本身实施起来不难，以我自己购买的1个域名gnuers.info为例.1. 域名注册在godaddy,支持添加DS记录。2. 域名服务器是自己在阿里云虚拟机上部署的bind，可以支持DNSSEC。当具备了这2个前提条件后，我就可以配置好域名服务器支持DNSSEC实施的步凑如下：1. 在本地生成密钥对 root# dnssec-keygen -a NSEC3RSASHA1 -b 4096 -n ZONE gnuers.info. root# dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE gnuers.info root#:/opt/bind/etc# ls *gnuers.info* Kgnuers.info.+007+15644.key Kgnuers.info.+007+15644.private Kgnuers.info.+007+38841.key Kgnuers.info.+007+38841.private 对zone做签名签名前需要先把公钥添加到zone文件内 $INCLUDE Kgnuers.info.+007+15644.key $INCLUDE Kgnuers.info.+007+38841.key 然后直接签名会生成一个新的zone文件,以.signed结尾。 dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -N INCREMENT -o gnuers.info -t gnuers.info 配置named挑战zone文件为签名过的zone文件，并确认bind内开启dnssec支持。 dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; 在注册商添加ds记录签名zone文件的时候会同步生存ds文件：dsset-gnuers.info.，需要把里面的ds记录在godaddy上加上。 ...

DNS系统中，在大家的直观印象下bind主备的同步都是“实时”的。实际上主备同步的速度有诸多的瓶颈。对于master而言：1. 是否有delay notify消息，这个配置是 notify-delay,默认是5s，有必要的话是需要缩短的。2. transfers-out 限制同时允许区传输的数量，默认是10，如果slave多，zone多需要调大。3. serial-query-rate 对于master而言会限制master给slave发送notify的速度，默认是20,需要调大。对于slave而言：1. transfers-per-ns限制了从单个master同步的并发，默认也是10,需要调大。2. transfers-in 限制了同时从master（可能有多个）同步的总数，默认是10,需要调大。3. serial-query-rate 在slave中会限制slave向mastetr做SOA查询的频率。默认是20,需要调大。 最近在排查主备同步延迟的case上，发现bind 9.9.x，9,10.2都存在bug，serial-query-rate的配置不能生效。主要的原因就是 lib/dns/zone.c内dns_zonemgr_setserialqueryrate这个函数里写死了notifyrate。 fix的方案就是把这2个地方的20改成value即可。 对于单个同步的case，可以从master域名更新、master触发notify，slave收到notify，slave开始同步，slave完成同步几个关键的时间点，查看时间到底消耗到哪里。

dns投毒是指攻击者伪造权威DNS的回包,向递归DNS发送查询应答包.因为UDP本身是无状态的.递归dns在发送请求时会随机产生1个ID做标识,当自己发送出去请求包后,如果伪造满足下列条件一个UDP包就可以让递归DNS缓存到自己设置的一个记录:1. 目标IP/端口为递归dns发请求时使用的源IP/端口一致2. 报文里的TXID一致3. 查询的记录一致为了尽量减少缓存投毒可以使用的方案:1. 递归出去的IP和自己的服务IP分开,递归使用一个网段出去,并且把递归源端口范围设置的尽量大.2. 校验权威DNS的TTL(指的是IP包里的TTL,到自己需要经过多少跳路由)3. 递归DNS发请求的时候把查询的记录大小写随机,校验response报文里是否和请求的一致.

前段时间为了测试bind递归时的SRTT算法效果,使用netem模拟了一下到几个NS的任意延迟.简单的脚本如下 tc qdisc add dev eth1 handle 1: root htb tc class add dev eth1 parent 1: classid 1:1 htb rate 100Mbps quantum 40000 tc class add dev eth1 parent 1:1 classid 1:11 htb rate 100Mbps quantum 40000 tc class add dev eth1 parent 1:1 classid 1:12 htb rate 100Mbps quantum 40000 tc class add dev eth1 parent 1:1 classid 1:13 htb rate 100Mbps quantum 40000 tc class add dev eth1 parent 1:1 classid 1:14 htb rate 100Mbps quantum 40000 tc qdisc add dev eth1 parent 1:12 handle 20: netem delay 200ms tc qdisc add dev eth1 parent 1:13 handle 30: netem delay 300ms tc qdisc add dev eth1 parent 1:14 handle 40: netem delay 400ms tc filter add dev eth1 protocol ip parent 1: prio 3 u32 match ip dst xx.xx.3.19/32 flowid 1:12 tc filter add dev eth1 protocol ip parent 1: prio 3 u32 match ip dst xx.xx.5.19/32 flowid 1:13 tc filter add dev eth1 protocol ip parent 1: prio 3 u32 match ip dst xx.xx.7.19/32 flowid 1:14 通过在本机设置到几个NS的不同延迟,对本地的bind发请求,抓包查看Bind到不同NS的请求量,可以对比出不同版本的bind的SRTT行为差异.

常规情况下bind的主备同步是自动增量同步的。但是有些场景下是全量同步，比如自己手动改的zone文件，重新加载进去。一般内部的反解信息是根据所有的zone自动生成的，就会存在PTR记录每次全量同步的量非常大。测试了可以通过打开ixfr-from-differences，在master上自动计算差异，slave就可以做增量同步了。 ixfr-from-differences yes; 上图中可以看到之前没有打开ixfr-from-differences时同步1.9W条记录需要2.6s，开启之后每次增量同步只需要0.02s。开启ixfr-from-differences 时会增加master的CPU、内存开销，所以需要根据实际的情况衡量是否需要打开。

bind 9.10里有个prefetch的特性。文档描述如下 When a query is received for cached data which is to expire shortly, named can refresh the data from the authoritative server immediately, ensuring that the cache always has an answer available. 当DNS递归服务器接受到一个域名的查询请求时，如果这个域名本来已经有cache记录且马上要过期了。named会主动刷新这条记录。实际的逻辑是 假如在0s的时候请求了qq.com，qq.com的TTL是600s。如果设置了 prefetch 5 10; 那么在595-599的这段时间内，再次收到qq.com的查询请求，named会自己主动去递归一次。prefetch接受2个参数，第一个是触发namde主动递归的剩余TTL上限，第二个是只有TTL大于10的才做主动递归更新。 这个可以提高热域名的cache命中率，但是对请求量很小的冷域名的解析提升无用。 参考：1. https://kb.isc.org/article/AA-01122

部署DNS的时候遇到个奇葩的问题，总是提示 couldn’t add command channel 0.0.0.0#953: address in use 实际上系统上并没有进程使用953端口。查询了一下找了原因。就是portreserve的问题，关闭后OK。 原因根本的原因是自己打包了一个bind的RPM，会引入/etc/portreserve/named,这样当portreserve启动的时候就会占着53端口。单独使用/etc/init.d/named启动的时候会执行portrelease 来释放53端口。 portrelease named

上一篇blog简单写了一下使用nsupdate动态更新DNS记录。今天再写一下在多个view的时候如何设置主备的自动同步。多个view的主备同步主要是是主备之间每个view都使用共享key进行消息的签名。master的配置和之前的稍微有点小的改动 include "/opt/bind/etc/rndc.key"; include "/opt/bind/etc/views.key"; // controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; }; // acl test1 { 10.201.0.0/16; }; acl test2 { 192.0.0.0/8; }; acl slavedns { 10.144.149.61; 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; }; recursion config recursion yes; max-ncache-ttl 60; recursive-clients 2000; ...