一次DNS重大运营事故教训

2011-07-09 09:06 • 本文约501字，阅读大致需要2分钟 • Postmortem

长久不做SA，所以有些事情变得没有以前那么敏感。昨天终于还是出事了，不过幸亏不是商业系统，如果是的话，我觉得绝对够得上是重大事故。记一笔，留个教训。

简而言之，我自己的一个有邮件服务的域名，在通过GoDaddy的系统修改授权域名服务器的时候出了问题。这个问题应该是GoDaddy的bug导致的，但结果很严重，那个域名的glue记录被全部清空了。事后检查whois记录看到的状态如此：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Domain ID:D104XXXXXX-LROR
Domain Name:XXXXXXXXXX
Created On:XX-XX-XXXX XX:XX:XX UTC
Last Updated On:07-Jul-2011 XX:XX:XX UTC
Expiration Date:XX-XXX-XXXX XX:XX:XX UTC
Sponsoring Registrar:GoDaddy.com, Inc. (R91-LROR)
Status:CLIENT DELETE PROHIBITED
Status:CLIENT RENEW PROHIBITED
Status:CLIENT TRANSFER PROHIBITED
Status:CLIENT UPDATE PROHIBITED
Registrant ID:CR29XXXXX
Registrant Name:Xin LI
[...]
Tech FAX:
Tech FAX Ext.:
Tech Email:XXXXXXXXXXXXXXXXXXX
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
DNSSEC:Unsigned

对邮件系统来说，发生这种情况的后果是极其严重的。根据RFC 5321，邮件系统对于停机问题的容忍时间至少是数个小时，然而当域名解析出现问题时，通常系统有理由立即以4yz回应来拒绝未进入邮件队列的邮件。所幸的是这个问题持续的时间不算太久，而且这个域名只是一个备用的邮件域名。

几点教训：

在修改域名配置之后要仔细检查其结果，对于这个问题，应在确认根zone更新之后检查域名的glue记录是否正常；
修改注册商处的域名配置时应确保前一操作已经完成后再进行下一步操作；
需要对域名服务进行监控。

在线阅读本文并参与讨论 delphij's Chaos https://blog.delphij.net/posts/2011/07/dns-4/