修复 LUG 官方邮箱转发邮件缓慢问题

近一段时间 LUG 官方邮箱(包括技术支持邮箱)向内部成员转发邮件的延迟很高,邮件服务器有大量类似下面的错误日志:

Mar 19 01:36:00 blog postfix/smtp[5702]: 1312CF821BD: to=<lugarchiver@gmail.com>, orig_to=<staff@lug.ustc.edu.cn>, relay=alt4.gmail-smtp-in.l.google.com[173.194.219.27]:25, delay=2144, delays=2141/0.01/3.1/0, dsn=4.7.0, status=deferred (host alt4.gmail-smtp-in.l.google.com[173.194.219.27] refused to talk to me: 421-4.7.0 [128.199.95.148] Our system has detected an unusual amount of 421-4.7.0 unsolicited mail originating from your IP address. To protect our 421-4.7.0 users from spam, mail sent from your IP address has been temporarily 421-4.7.0 blocked. Please visit 421-4.7.0 http://www.google.com/mail/help/bulk_mail.html to review our Bulk 421 4.7.0 Email Senders Guidelines. o61si8882013yhb.37 - gsmtp)

经查,是 DNS TXT 记录配置错误。只有 default view(对应 IPv6 和 IPv4 国外线路)的 TXT 记录正确:"v=spf1 mx a a:ip-list.vpn.ustclug.org ~all",而 chinanet view(对应国内 IPv4 除移动外的线路)和 cmcc view(对应国内移动线路)的 TXT 记录是过时的版本:"v=spf1 mx a a:do2.bojieli.com ~all"

可能是由于近期 Gmail 换用了中国服务器对 .cn 域名进行解析,Gmail 获取到的 TXT 记录错误,导致邮件服务器的 IP 地址无法通过 SPF 校验,转发给内部成员的邮件被 Gmail 服务器拒收。

感谢 高一凡 报 bug。

LUG 网络服务3月9日网络中断说明

由于 全校范围的网络故障,3 月 9 日下午 17:00 ~ 18:00 网络时断时续,3 月 10 日凌晨 0:00 ~ 6:00 大约每半小时断网一次。

昨天的故障和 3 月 5 日持续 45 分钟的故障,原因估计是 近代物理楼某接口发送大量 ARP 包导致核心交换机 CPU 过载,换句话说,就是核心交换机被拒绝服务攻击了。

现代交换机通常是使用 ASIC(专用芯片)或 FPGA 来做绝大部分数据包的转发,只有少数控制包(如 ARP、STP 包)要交给交换机 CPU 做处理,交换机的 CPU 通常计算能力非常有限。例如 MAC 地址学习功能一般是由 CPU 进行的,首先所有 ARP 包被发到 CPU,CPU 把 MAC 地址和物理端口的映射关系写入到 ASIC 或 FPGA 中的二层转发表。如果交换机收到大量 ARP 包,又没有在入站端口对 ARP 包进行限速,就会导致交换机 CPU 忙不过来。

非常抱歉近几天的网络故障给您带来的不便。同时强烈谴责(有意或无意)进行网络攻击的人,对全校师生造成了这么大的麻烦!

LUG 权威 DNS 修复 IPv6

12 月 25 日下午,网络中心把 LUG 权威 DNS 服务器的上游网关设备从西区迁移到了东区,网关的 link-local IPv6 地址和 MAC 地址发生了改变。但由于该服务器的 IPv6 地址是静态配置的,使用了 link-local 地址作为网关,该地址已经不可用,因此权威 DNS 的 IPv6 网关中断。

iface eth0 inet6 static
        address 2001:da8:d800:f001::5353
        gateway fe80::212:44ff:fe66:2000
        netmask 64

获取不到网关 MAC 地址的情况:

boj@dns:~$ ip -6 neigh
fe80::250:56ff:fe9f:4 dev eth0 lladdr 00:50:56:9f:00:04 STALE
2001:da8:d800:f001:250:56ff:fe9f:4 dev eth0 lladdr 00:50:56:9f:00:04 STALE
fe80::72ca:9bff:fece:31a2 dev eth0 lladdr 70:ca:9b:ce:31:a2 STALE
fe80::212:44ff:fe66:2000 dev eth0  router FAILED

现在 /etc/network/interfaces 中修改了 IPv6 gateway 为 2001:da8:d800:f001::1。并执行如下命令(远程机器不要轻易执行 service networking restart,网络起不来就悲剧了):

ip -6 route add default via 2001:da8:d800:f001::1
ip -6 route del default via fe80::212:44ff:fe66:2000

几秒钟后就通过 ICMPv6 协议获取到了网关的 MAC 地址,服务器的 IPv6 连接恢复正常。

boj@dns:~$ ip -6 neigh
2001:da8:d800:f001:225:90ff:fe32:a676 dev eth0 lladdr 00:25:90:32:a6:76 REACHABLE
fe80::250:56ff:fe9f:4 dev eth0 lladdr 00:50:56:9f:00:04 STALE
2001:da8:d800:f001:250:56ff:fe9f:4 dev eth0 lladdr 00:50:56:9f:00:04 STALE
fe80::212:44ff:fe66:2000 dev eth0  router FAILED
fe80::225:90ff:fe32:a676 dev eth0 lladdr 00:25:90:32:a6:76 REACHABLE
2001:da8:d800:f001::1 dev eth0 lladdr 5c:dd:70:91:72:e2 router REACHABLE

此外,之前 /etc/resolv.conf 的内容如下,当 IPv6 不通时,前两个 nameserver 都会解析失败,这导致 LDAP 客户端无法解析 ldap.lug.ustc.edu.cn 的域名,也就是用不了 sudo 了。

search lug.ustc.edu.cn
nameserver 2001:da8:d800::1
nameserver 2001:da8:d800::56
nameserver 202.38.64.1

采用本地账号 sudo,把 nameserver 202.38.64.1 移到了 IPv6 之前,以免 IPv6 再出现不稳定的情况。

12月6日权威 DNS 服务中断 1 小时

12 月 6 日 21:37 至 22:39,除 mirrors 外的 LUG 网络服务中断一小时。原因是权威 DNS 服务器挂掉了。原因又是 bind9 陷入死循环,触发 OOM kill。因此带来的不便,我们深表歉意。

由于我测试环境选择不当(用了挂了一台 LUG VPN 的主机),导致问题刚开始的半个小时没有发现问题根源,以为是 ns.ustc.edu.cn 取消了 LUG 域名的解析,于是给 jameszhang 打电话,过了一会儿 jameszhang 回电说是我们的权威 DNS 服务器挂了…… 当时 LUG 会长、DNS 专家 pudh 在校外,正在往回赶,而我手里没有登录 DNS 服务器的 key。最后是 CTO 崔灏救 LUG 于水火之中,把 DNS 服务器的 bind9 服务启动起来了。

QQ图片20141207001954

日志显示 bind9 是这时候开始陷入死循环的:

Dec  6 18:49:28 dns named[21839]: zone ustclug.org/IN/Default: sending notifies (serial 170002)
Dec  6 18:49:33 dns named[21839]: zone ustclug.org/IN/Default: sending notifies (serial 170028)
Dec  6 18:49:38 dns named[21839]: zone ustclug.org/IN/Default: sending notifies (serial 170054)
Dec  6 18:49:43 dns named[21839]: zone ustclug.org/IN/Default: sending notifies (serial 170080)
Dec  6 18:49:48 dns named[21839]: zone ustclug.org/IN/Default: sending notifies (serial 170106)
Dec  6 18:49:53 dns named[21839]: zone ustclug.org/IN/Default: sending notifies (serial 170132)

死循环在接近四小时后,最终撑爆了内存:

Dec  6 21:37:10 dns kernel: [9683698.772789] named invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Dec  6 21:37:10 dns kernel: [9683698.772793] named cpuset=/ mems_allowed=0
Dec  6 21:37:10 dns kernel: [9683698.772797] Pid: 21840, comm: named Not tainted 3.2.0-4-amd64 #1 Debian 3.2.60-1+deb7u3
...
Dec  6 21:37:10 dns kernel: [9683698.777831] Out of memory: Kill process 21839 (named) score 917 or sacrifice child
Dec  6 21:37:10 dns kernel: [9683698.777977] Killed process 21839 (named) total-vm:1523060kB, anon-rss:927256kB, file-rss:56kB

这个 OOM 的时间恰好是开始收到报警的时间,就是所有 LUG 域名无法解析的时间。

LUG 权威 DNS 服务器故障说明

2014 年 9 月 8 日下午 4 时左右,LUG 权威 DNS 服务器上托管的所有域名均解析失败。

经查,这是 9 月 7 日 15:48 分在 LUG 权威 DNS 服务器上由于未知原因导致 BIND 服务占用大量内存,触发了内核的 OOM Kill 机制,导致 BIND 服务被杀掉。因我们内部监控系统暂不完善,此事件没有被第一时间发现。经过了 24 小时之后, mirrors 上的 Slave DNS 服务器上的记录因超时而失效,从而导致LUG 权威 DNS 服务器上托管的所有域名均解析失败。

9 月 8 日 16:14 分重新启动 BIND 服务之后发现,BIND 服务一直占用接近 100% 的 CPU 资源。在 BIND 的日志中可以看出,在服务器配置的不同 VIew 间数据同步时出现了死循环。这导致 SOA 记录中 Zone 的序列号疯涨。

从 strace 中可以看出,BIND 服务器频繁获取 DNSSec 签名所用的私钥,故初步断定问题由 DNSSec 引起,在关闭 DNSSec 支持后重启 BIND 后,系统负载回归正常,问题解决。

此次事件暴露出了我们服务器内部监控不足的问题,我们会尽快建立起完善的服务监控体制,以便在服务器出现问题时第一时间获得通知。此外,我们正在努力探明数据同步时出现了死循环的触发条件,如有发现我们会在此博客上及时发布。

12月7日DNS故障说明

12月7日晚,Zitian Li同学报告freeshell访问异常。经初步检查得知是DNS服务器出现故障。通过网上的检测工具可以看出,从国内大部分DNS缓存服务器中都查不到我们的域名。

登陆服务器抓包,可以看出bind会给国内的DNS请求返回ServFail,但在本地通过环回地址可以正常得到DNS解析结果。使用ip addr列出服务器IP地址,可见之前手动添加的IP地址消失不见了。再看服务器uptime只有2天,故找到故障原因。

故障原因是服务器启动时没有添加额外的IP地址,BIND的不同view的同步需要这些额外的IP。所以说自启动以来,国内view中的slave zone一直处于同步失败的状态。在经过一个超时时间(约1天)后,BIND认为数据已过期,故对DNS请求返回ServFail,导致故障。

故障处理:

在/etc/network/interfaces中加入相应的规则。添加IP地址。重启BIND服务。

经验教训:

对待网络问题一定要慎重啊……除了确保配置能工作外,还要确保配置能够经过重启的考验。