[date: 2018-02-07 23:31] [visits: 16]

一次邮件服务器故障定位-Domain not found

2月6日公司业务部门反馈:“内部搭建的邮件服务器无法使用”,影响到业务使用,需紧急处理,本文记录本次邮件服务器故障定位与修复的主要过程。

由于2月5日依照阿里云要求,做了一次机器迁移,推测故障原因跟这次迁移有关系。

问题在我接手之前,IT小哥通过提工单与阿里的售后工程师沟通,已经分析了一些现状,做了一些尝试:

经过上述几种尝试后,邮件服务器发件功能可用,收件功能依旧异常,然后由我接手继续排查故障。

迁移

迁移带来的变化是重点关注对象,这次迁移是阿里云内部要求的,具体内容包括:

这些变化虽是重点关注对象,但接手后并不是第一时间去分析变化可能带来的影响,而是从服务器内部出发,排查服务器内部原因。

服务器状态

ssh连接到服务器,由于不知道邮件服务器是如何搭建的,做了如下几件事情:

没太多有效信息,跟本次故障可能相关的有:修改/etc/firewalld/zones/public.xml并重启了防火墙、使用telnet smtp.aliyun.com 25测试出方向的25端口是否可用(经过解封已经可用)

机器负载正常

推断上次重启时间:迁移成功后触发的重启

当对一台服务器上所运行的服务不够了解时,这个命令非常有帮助,可以查看监听的端口信息,从而推断出所运行了哪些常见服务,通过该命令了解到端口使用情况:

经过上述几步,大致了解了基本信息,得出以下结论:

定位

经过简单的排查,得到一些基本结论,但是并无法直接推断问题所在,猜测是其中某些服务的业务层原因导致不能接收邮件。

第一步,找日志文件,对于不熟悉的服务,Google一下日志文件默认位置。因为个人捣鼓过一次postfix,知道它主要用来收发邮件,就从postfix开始,日志文件位置:/var/log/maillogtail -f跟一下。

发现很多类似的reject内容:

Feb 6 12:47:59 mail postfix/smtpd
2349
: NOQUEUE: reject: RCPT from unknown
209.85.220.193
: 450 4.1.8 : Sender address rejected: Domain not found; from= to= proto=ESMTP helo=<mail-qk0-f193.google.com>

错误说的很直白:Domain not found,域名无法找到,之前就知道邮件服务器为了防止垃圾邮件,会反向解析IP到域名,只有相符合的话才考虑接收。

临时解决

根据经验推测,这个特性肯定是可以配置的,经过Google,在postfix中的配置文件中,找到对应的配置项smtpd_sender_restrictions,从中删除reject_unknown_sender_domain,然后重启postfix,经测试邮件服务器恢复正常。

寻找根本原因

虽然问题解决,但明显只是临时方案,并且没有发现导致Domain not found的根本原因,所以还需进一步定位问题原因。

在问题服务器上用nslookup反向解析IP-209.85.220.193:

[root@mail ~]# nslookup 209.85.220.193
Server:     100.100.2.136
Address:    100.100.2.136#53

Non-authoritative answer:
193.220.85.209.in-addr.arpa name = mail-qk0-f193.google.com.

Authoritative answers can be found from:
220.85.209.in-addr.arpa nameserver = ns2.google.com.
220.85.209.in-addr.arpa nameserver = ns4.google.com.
220.85.209.in-addr.arpa nameserver = ns1.google.com.
220.85.209.in-addr.arpa nameserver = ns3.google.com.
ns1.google.com  internet address = 216.239.32.10
ns2.google.com  internet address = 216.239.34.10
ns3.google.com  internet address = 216.239.36.10
ns4.google.com  internet address = 216.239.38.10
ns4.google.com  has AAAA address 2001:4860:4802:38::a

返回的信息中能够反向解析出域名mail-qk0-f193.google.com.,与错误日志中的helo=<mail-qk0-f193.google.com>相同,说明域名和IP是能够对应上,服务器网络层是OK的,那么问题出现在哪呢?

猜测是postfix在做IP解析到域名时出现了问题,但迁移之前一直是OK的,而且对postfix内部没有任何了解,瞬时有点束手无策,只能依靠万能的Google,以及postfix、Domain not found、域名解析失败、nslookup解析正确等可能关键词搜索。

经过一系列的搜索,最终找到蛛丝马迹:/var/spool/postfix/etc/resolv.conf,这个文件指定了postfix所使用的DNS服务器地址,查看服务器上该文件的内容,发现其中的DNS地址与/etc/resolv.conf有所差异。

问题已经清楚,再用更贴切的关键词搜索,找到了更贴切的解释:postfix在安装的时候会拷贝/etc/resolv.conf到自己目录下。

阿里云的ECS默认会配置相应的DNS地址,这次迁移由于网络环境变化,/etc/resolv.conf内容也相应发生了变化,但postfix却不会重新拷贝,导致其内部使用的DNS地址不正确,也就出现了Domain not found错误。

彻底修复

找到根本原因后进行彻底修复:

经测试,邮件接收没有问题,问题彻底解决,但关于25端口的封禁问题,只能后续再研究怎么变通,目前了解到的是改为465端口可避免该问题。

总结

对于25端口封禁,最开始理解错误,认为是指不能用25端口向外发送数据包,这是一个由于对计算机原理了解不够深刻,以及处理此类问题太少,犯的低级认知错误。实际上25端口封禁,指的是不能与对方服务器的25端口通信,即TCP或UDP包的目标端口不能为25。如果不能用25端口向外发送数据,那邮件服务器监听25端口是没法与外界通信的,因为通信过程中的包,源端口一定是25。

该问题的第一阶段,发现和修复的非常快,10分钟内就搞定了,但Domain not found花了2-3个小时才排查清楚。作为一个程序员,广度和深度需要全面发展,才能更高效的处理问题,经过处理各种问题,能收获更多的经验,对事物的认知也为更深刻,统一。

后记

在邮件服务器不可用的这段期间,理论上有可能会丢失部分邮件,但不确定是多少,因为对邮件协议不够了解,不知道邮件发送端在失败的情况下,间隔多久重试一次,一共重试多少次,抽空也补一补相关知识。

最后在日志中统计出一份因Domain not found被拒收的邮件收发件人表格,以及邮件服务器故障恢复后,6小时内成功收发件人表格,提供给业务部门作为参考。