Posts

近期内部开发反馈某些合作方的域名无法解析。团内同事分析发现这些域名都是托管在相同的一个域名厂商上,而且都是刷新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上加上。 ...

内部有个产品本身是和mysql绑定在一起的。近期同步时出现”the table is full”。在网上搜了一下是一些参数设置问题，修改后重启mysql解决。```bash tmp_table_size = 2048Mmax_heap_table_size = 2048M

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完成同步几个关键的时间点，查看时间到底消耗到哪里。

习惯了linux下的ip命令，在mac下非常不方便。mac下有个python包装的版本可以直接安装使用 brew tap brona/iproute2mac brew install iproute2mac

也忘记从什么时候开始，在linux下连无线路由器变得非常不稳定。当前内核版本：3.16.0-4-amd64无线网卡：intel Wireless-N 2200driver: iwlwifiversion: 3.16.0-4-amd64firmware-version: 18.168.6.1网上查了一圈，可能是驱动的问题，只能通过屏蔽11n来解决。 pm@debian:~$ cat /etc/modprobe.d/iwlwifi.conf options iwlwifi 11n_disable=1

quagga套件内的每个路由进程，都会起1个独立的端口。日常的管理我们可以通过直接telnet 端口登录到相应的路由进程做操作。出于安全的考虑，我们需要对连接到这些路由进程的ip做限制。以只允许本地连接为例，zebra.conf/ospfpd.conf的配置如下 access-list allowed permit 127.0.0.1/32 access-list allowed deny any ! line vty access-class allowed !

在使用quagga的过程中，实际有很多非交互式的场景，比如想批量做路由撤销的操作。从一个系统管理员的角度上看，希望对软路由的控制像直接在linux里写脚本一样简单方便。之前在vtysh里行执行路由撤销命令我是用expect实现的 实际有更简单的方式 这样可以简单对expect的依赖，脚本编写也更简洁。

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行为差异.