Posts

任何一个服务的规模达到一定量级都会出现各种瓶颈点，传统的IDC内部DNS也不例外。根据多年的实际经验把工作中遇到的点集成到了一个图。主要瓶颈点：1. DNS记录更新瓶颈2. DNS同步瓶颈3. DNS缓存应答瓶颈4. DNS递归瓶颈 到底多大规模的内网DNS系统能称为大？个人定6个9标准：1. IDC数量至少9个。2. 域名全网生效SLA 9s内。3. 一个IDC的DNS数量大于9台。4. 调用DNS API的外部业务系统至少9个。5. 单个机房DNS服务的范围超过9999台服务器。6. DNS系统内的域名zone数量超过99个。 如果你管理的内网DNS系统规模满足一半以上的条件，想必你也会遇到各种奇葩的问题。从上图给出的几个瓶颈点出发几个优化的建议： 控制外部API的调用并发，如果有的系统需要批量更新大量的域名，可以使用合并发送nsupdate操作的模式，注意单个nsupdate报文不要超过65535字节. dns master服务器最好使用SSD服务器，因为nsupdate操作时zone文件的频繁会写非常消耗IO。 master上注意增大serial-query-rate以保证master的notify发送速度，估算值serial-query-rate >=slave规模*同时更新zone数量，实测发送速度可以超过2k/s。 master上增大transfers-out的值，需要>=slave规模*同时更新zone数量， slave上transfers-in transfers-per-ns 需要大于本地zone的数量，否则导致新节点启动时因超过quota值部分zone会延迟半个小时以后再同步；slave 上serial-query-rate 超过本地zone的数量。 salve机器上常备dnstop分析实时流量。 salve服务器上如果有公网IP，务必配置好iptables，放置被当作反射器去攻击他人，并经常会有国安局、公安局领导约谈。

准备干净的vm模版，clone出4台。ip规划如下enp0s3 外网网卡，桥接模式，dhcpenp0s8 内网网卡，bridge到bridge0(192.168.1.1/24) 2. 打通centos-console 到其他几个服务区的信任登陆centos-console 192.168.1.10centos-test1 192.168.1.11centos-test2 192.168.1.12centos-test3 192.168.1.13 3. 在跳板机器创建consul容器，做服务发现docker run --restart=always -d -p 8500:8500 --name=consul progrium/consul -server -bootstrap 4. 创建swarm-masterdocker-machine create --driver generic --generic-ip-address 192.168.1.11 --generic-ssh-user root --engine-registry-mirror=https://wfsgsp6x.mirror.aliyuncs.com --engine-install-url=https://get.daocloud.io/docker/ --swarm --swarm-master --swarm-discovery="consul://192.168.1.10:8500" node-master 5. 创建nodedocker-machine create --driver generic --generic-ip-address 192.168.1.12 --generic-ssh-user root --engine-registry-mirror=https://wfsgsp6x.mirror.aliyuncs.com --engine-install-url=https://get.daocloud.io/docker/ --swarm --swarm-discovery="consul://192.168.1.10:8500" node-woker1docker-machine create --driver generic --generic-ip-address 192.168.1.13 --generic-ssh-user root --engine-registry-mirror=https://wfsgsp6x.mirror.aliyuncs.com --engine-install-url=https://get.daocloud.io/docker/ --swarm --swarm-discovery="consul://192.168.1.10:8500" node-woker2 6. 查看machine[root@centos-console cert]# docker-machine lsNAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORSnode-master - generic Running tcp://192.168.1.11:2376 node-master (master) v1.12.0node-woker1 - generic Running tcp://192.168.1.12:2376 node-master v1.12.0node-woker2 - generic Running tcp://192.168.1.13:2376 node-master v1.12.0 7. 登陆管理docker -H 192.168.1.11:3376 --tlsverify --tlscacert=/root/cert/ca.pem --tlscert=/root/cert/server.pem --tlskey=/root/cert/server-key.pem info enp0s3 外网网卡，桥接模式，dhcp ...

公司内有1个巨老的系统，一直访问着我们提供的老API。当我们的API升级后因为新接手这个老系统的人都没法去升级调用API的接口。因为自己这边负责的API回滚的代价太大，临时在老的服务器上换了1个端口把老的API启动起来。并提供了1个iptables供对方服务器重定向访问的端口。源ip：10.1.1.1API IP：192.168.1.1API port: 8888API port(run old api):2222 iptables -t nat -A OUTPUT -p tcp -d 192.168.1.1 --dport 8888-j DNAT --to-destination 192.168.1.1:22222 让对方在服务器上添加以上的规则，可以让对方机器访问192.168.1.1:8888的请求被重定向到192.168.1.1:22222

sysdig是个小巧的系统诊断工具。一方面可以帮助排查应用的瓶颈，另外一方面也可做异常排查的诊断工具观察进程的一些行为。以前一直有个问题困扰着我，大量老机房下线时，基础的DNS服务下线非常麻烦。虽然能在dns服务器上抓包查看client段的ip并刷新client机器的resolv.conf配置，但是很多应用需要重启才能使用新的resolv.conf内的DNS IP，经常是1个机器上跑了各种agent，当前的负责人压根不了解是什么进程发起的。sysdig实际可以解决这样的case sysdig -p"%proc.name %proc.pid %fd.cip:%fd.cport %fd.sip:%fd.sport %fd.l4proto" fd.sport=“53” 另外有时也想看看ntp是否在做同步，可以用类似的方式 sysdig -p"%proc.name %proc.pid %fd.cip:%fd.cport %fd.sip:%fd.sport %fd.l4proto" fd.sport=“123” 附：1. sysdig介绍 http://www.sysdig.org/

默认情况下，连接sftp服务器(openssh内建的sftp server)时在服务器只能留下一个登陆连接的信息。为了便于知晓在一段时间内到底有哪些客户端来访问过本地的文件，可以通过调整sftp的日志。修改/etc/ssh/sshd_config，在sftp配置行添加”-l INFO” 完成配置```bash # override default of no subsystemsSubsystem sftp /usr/libexec/openssh/sftp-server -l INFO 

在使用salt做配置管理的时候，有时希望minion上能自动执行特定sls定义的动作，这个时候可以借助schedule来做。在pillar内定义好schedule的内容 schedule: dnsmaster: function: state.sls args: - dns.dnsmaster seconds: 10 pillar的top.sls里定义某个minion需要这个任务。 base: '*': - dns.alldns 'master1': - schedule 在minion上执行一次pillar数据的同步 salt-call saltutil.refresh_pillar

近期内部的递归服务器上有大量的AAAA查询，因为一些非主流NS的不响应AAAA记录，使得递归服务器上递归量比较大。bind9内开始支持filter-aaaa-v4/v6，主要的作用其实只是对相应的报文里作删除AAAA记录（如有）。单独验证了一下 filter-aaaa-on-v41.1 默认为no如果有AAAA记录会全量返回 AAAA记录如果没AAAA记录返回NOERR＋SOA1.2 设置为yes（Client IP为IPV4）如果有AAAA记录会被删除返回返回NOERR＋SOA如果没AAAA记录返回NOERR＋SOA1.3 设置为yes（Client IP为IPV6）行为不受影响。2. filter-aaaa-on-v62.1 默认为no如果有AAAA记录会全量返回 AAAA记录如果没AAAA记录返回NOERR＋SOA2.2 设置为yes（Client IP为IPV4）行为不受影响。2.3 设置为yes（Client IP为IPV6）如果有AAAA记录会被删除返回返回NOERR＋SOA如果没AAAA记录返回NOERR＋SOA filter-aaaa即便打开，当用户查询AAAA的时候bind也会去递归查询AAAA记录，所以并不能解决bind递归量大的问题。虽然可以通过iptables丢掉AAAA的包，但是也会影响用户的体验。

bind rpz和rrl作为bind 10里默认包含的2个模块，为bind的安全提供了有力的支撑。但实际使用不当会事得其反。 [ response-policy { zone zone_name [ policy (given | disabled | passthru | drop | nxdomain | nodata | cname domain) ] [ recursive-only yes_or_no ] [ max-policy-ttl number ] ; [...] } [ recursive-only yes_or_no ] [ max-policy-ttl number ] [ break-dnssec yes_or_no ] [ min-ns-dots number ] [ qname-wait-recurse yes_or_no ] ; ] 在服务器上配置如下的rpz策略 response-policy { zone “rpz.zone” policy given; } zone "rpz.zone" { type master; file "master/rpz.zone"; }; zone "lala.com" { type forward; forwarders { 8.8.8.8; }; }; rpz.zone内配置如下的内容，请求www.test.fr和*.lala.com都会阻塞很久，因为虽然我们做了策略，实际bind还是会等着取回结果再去操作。 $TTL 30 ...

参考网上找的资料，写了一个简单的脚本，输入域名可以生成使用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 ...

近两年tengine和nginx的在新特性的支持上差距越来越大。处于尝试新事物的好奇，动手升级到nginx-1.9.9。整个过程非常曲折，不再细说。。 主要的配置差异实际很小 listen 443 ssl so_keepalive=on spdy; 改为 listen 443 ssl so_keepalive=on http2; 但是因为之前开启了ssl_prefer_server_ciphers，升级前没仔细看过nginx官方的wiki，所以吃了不少苦头。升级之后页面直接就打不了， chrome 报错ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY。 Note that accepting HTTP/2 connections over TLS requires the “Application-Layer Protocol Negotiation” (ALPN) TLS extension support, which is available only since OpenSSL version 1.0.2. Using the “Next Protocol Negotiation” (NPN) TLS extension for this purpose (available since OpenSSL version 1.0.1) is not guaranteed. 搞定了http2后，另外奇葩的事情是blog打开就是空白的。php-fpm等运行正常，最终发现是nginx官方deb包里的fastcgi_params是错的，该用之前tengine使用的配置搞定。参考：1.http://nginx.org/en/docs/http/ngx_http_v2_module.html