前篇文章中说到为了节省睡后支出，我准备关掉一些几乎闲置的服务器。但是服务器上除了我自己的站和程序以外，还有一些用户站点，如何将用站点平滑的迁移（零DOWN机时间），是很重要的问题，其中影响颇大的就是域名解析相关的问题。

(图源 ：pixabay)

我将操作经验分情况整理如下。

修改DNS

因为我们的服务器上都自建了DNS(域名解析服务）。这样做有个好处就是开通站点以及绑定域名时，不用手工指定各种解析记录(A记录、MX记录、CNAME记录等等），极大的简化了流程以及方便了用户。

如果用户域名也是在我们这里注册和管理，这样操作起来就比较简单了。迁移会把相关的域名解析记录全部迁移到新服务器并自动修改对应记录的指向，数据迁移完成后，我们只需将域名DNS修改为新服务器的DNS即可。

DNS转向

直接修改DNS是最简单的一种情况，但是如果用户是在其它注册商注册的域名，然后域名的NS记录指向我们的服务器，这时候我们是无法直接修改用户域名的DNS的。

当然了，联系用户修改DNS是必须要做的事情，但是有时候用户会由于各种原因没能及时联系上或者没能及时修改DNS。对于一些静态站点，这样并不会造成什么问题，但是对于一些保存一些用户信息的动态站点而言，如果旧服务器上的站点发生了修改（比如新插入一条数据）然后DNS再指向新服务器上的站点，这时候数据就会变得不一致。

所以这时候处理类似情况的最好办法是DNS转向，DNS转向是我自己命名的一个名词。简单来讲假设一个域名的DNS设置为：

ns1.xxx.com
ns2.xxx.com

那么我们可以在ns1和ns2的DNS服务中添加对应的解析记录，比如：

example.com 14400 IN A 1.1.1.1
example.com 14400 IN MX 0 example.com

那么如何让其不修改域名NS的情况下使用ns3以及ns4呢？答案是在域名的解析记录中添加新的NS记录。

example.com 14400 IN A 1.1.1.1
example.com 14400 IN MX 0 example.com
example.com 14400 IN NS ns3.xxx.com
example.com 14400 IN NS ns4.xxx.com

因为域名解析时，NS记录是递归判断的，所以纵然从域名数据库（注册信息）那查询到的NS为ns1/ns2，但是在域名解析时，域名使用的NS为ns3/ns4。

截图是一个DNS转向的实例，解析时，我们从根域名服务器获取NS记录，然后从.cn的解析服务器中获取对应域名的注册NS，再由注册NS获得转向的NS，最后从转向NS中得到A记录。

IP迁移

如果用户域名不再我们这里注册，并且用户不是使用的我们的DNS，而是使用第三方DNS服务通过A记录等直接指向站点的IP，这可咋办？

这种情况略麻烦，当然了喊用户改解析是最好的方法。还有一种方法就是迁移IP，但是这样操作不便成本太高。以SOFTLAYER为例，同一机房的IP可以route到任意的服务器，当然了这个操作需要发起ticket，然后由他们的技术人员操作。

我这边可以在新服务器上添加（绑定）同样的IP，然后将迁移的站点设置到这个相同的IP上，等服务商IP route操作完毕，就可以了。

但是这个操作无法在不同服务商之间完成，也无法在不同机房之间迁移IP（以前似乎可以），并且操作繁琐，所以实际上并不推荐这个操作。

附加DNS

对于DNS转向操作，如果我们迁移完所有的站点，那么还保留着DNS服务器做DNS转向功能，这无疑是对资源的极大浪费。这时候最简单的方法就是将ns1/ns2附加上ns3/ns4的IP上，然后老旧的服务器就可以彻底地关闭了。

附加DNS IP和注册DNS类似（有些服务商支持直接修改），这个没啥含量，不再赘述了。

总结

总的来讲我们有各种方法解决和域名解析相关的问题。不过之所以产生这些问题，还是因为当初的架构设计的不合理，比如当初我设置几台服务器做DNS Cluster，那么至少就不会涉及到改DNS的问题。

另外，尽管我们可以零DOWN机时间迁移站点，但是通知用户还是要做到的，毕竟知情权也是应有的权利。

当然了，说到底还是生意惨淡，否则我弄100台DNS服务器又如何呢？只愁扩张得不够快，哪像现在愁怎么高效快速的收缩呢？

This page is synchronized from the post: 站点迁移时域名解析问题的一些处理经验