早上开始工作时，收到了DO的邮件，非常惊喜。DO更新了各项套餐，增加了一些新套餐，也对老套餐进行了免费升级，真是良心企业。比如原有的“$10/mo”套餐，内存从1G升级到2G，存储从30G SSD升级为50G SSD。
不过默认情况下不会自动升级，需要手工对droplet进行resize。另外需要注意的是，可以只升级CPU和Memory，如果disk也同时升级到更高容量的话，则不支持降级回原有容量。
resize操作非常简单，请参考官方文档：
https://www.digitalocean.com/community/tutorials/how-to-resize-your-droplets-on-digitalocean
网站支持IPv6的步骤比较简单，基本上目前常用的软件，例如Apache、Postfix、dovecot等，都已经支持IPv4和IPv6双栈，只要服务商的设备提供IPv4和IPv6连接，这些软件本身无需为IPv6做特别配置。
需要注意的是服务商处的DNS配置。如果DNS配置不全面，某些服务器在鉴权时会拒绝接受来自IPv6地址的消息。例如gmail服务器在收到 email 消息时，会鉴定DNS和IPv6地址是否匹配，如果不匹配，则视为垃圾邮件直接拒绝，可以看到如下错误警示：
Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines regarding PTR records 550-5.7.1 and authentication.
下面以Linode中的配置做简单介绍（对DO而言也基本如此）。假设IPv4地址是“1.2.3.4”，IPv6地址是“1:2:3:4::5:6”，域名是“demo.com”。
Linode 为每个节点分配的DNS名默认是类似的成员名，例如“1234.members.linode.com”。在 Linux 系统 ping 域名”demo.com”时，首先显示的是”1234.members.linode.com”，然后才是跳转到”demo.com”。某些服务应用会认为是PTR错误。在linode中需要设置“ reverse DNS”记录，将节点的DNS名直接指定为“demo.com”。
具体措施请参考linode的在线文档。
如果同时支持IPv4和IPv6，上述文档里指导的操作需要单独操作两次，分别指定IPv4地址和IPv6地址。
另外一个需要注意的是 MX 记录，即邮件服务器记录。如果我们将 MX 记录设置为“mail.demo.com”，那么在DNS的A和AAAA记录中，要分别对“mail.demo.com”设置IPv4和IPv6地址，例如以下DNS记录结果：
mail.demo.com. 300 IN AAAA 1:2:3:4::5:6 mail.demo.com. 300 IN A 1.2.3.4
仅仅指定一个地址，对端有可能以域名和地址不匹配为由拒绝消息请求。
Linode 默认的TTL是3600秒，建议修改为300秒。TTL 太长太短都不好，要根据自己的实际情况调整，以方便自己网络部署、同时又不增加太多网络负担为准则。
Linode最近13周年庆，直接将内存免费翻一倍，价格保持不变，太劲爆了！
Old Plan New Plan Price Linode 1 GB -> Linode 2 GB $10/mo ($0.015/hr) Linode 2 GB -> Linode 4 GB $20/mo ($0.03/hr) Linode 4 GB -> Linode 8 GB $40/mo ($0.06/hr)
有几点需要注意：
（1）如果节点是Xen架构，则需要先转换成KVM才可以进行内存升级。如果已经是KVM架构，则可以直接升级。我升级了几个节点，爽爽的！
（2）国人非常喜爱的东京数据中心，节点都是Xen架构，而且据说已经没有空闲节点，暂不支持转换成KVM，因此要等待一段时间才行。
过往都是DigitalOcean频繁推出升级或者优惠，然后Linode被迫跟随。这次感觉Linode突袭了一次。
DigitalOcean，你看到了吗？你现在还好吗？加油啊！
BlueHost（以下简称BH）是个老牌的虚拟空间服务商，与其他服务商相比，BH有很好的口碑，当然，也有相对高的价格。我们的小公司自创立以来，就使用BH的空间来支持网站（myvoipapp.com）。虽然随着我们技术水平的发展，越来越多地采用VPS和云计算资源，比如我们的云系统miniSIPServer.com以及我们为客户部署的各类系统，都换用了VPS和各类云系统，但是我们的官网始终保留在BH中。
一方面是考虑到多年数据积累，迁移整个系统是费时费力的事情，比如需要考虑email、web、ftp、论坛、blog、数据库等，想想就觉得很麻烦。另一方面，BH一直以来工作得很好，对于初创企业（尤其是没有太多技术积累的初创企业），BH提供的各类一键式安装和维护，的确省心省力，不会让人太操心，把精力更多地放在自己业务发展上。
然而最近我们终于还是花时间把网站迁移到VPS上了（推荐Linode以及DigitalOcean，两家口碑极好的VPS服务商），告别了使用时间近乎十年之久的BH。下面分享一些我们做决定时的一些动因和思考。
在虚拟空间服务领域存在大量的服务商，坦率地说，绝大部分虚拟空间服务只能做个人blog等非关键应用，少数才能为严肃的商业网站提供服务，而一直以来BH都是其中佼佼者，其基础就是良好的稳定性。这也是我们一直使用BH的根本原因。
然而最近不知道是出什么问题了，也许是BH推出了VPS类业务，调整业务重心，从而忽略了原有的虚拟空间业务。总之，最近一年以来毛病不断，网络故障、主机故障、数据库故障、各类故障层出不穷，以前十年间出的问题加起来都没有最近一年多。
出问题不可怕，如果有良好的技术支持，很多问题是可以被容忍的。然而要命的是，BH的技术支持水平严重下降。很多问题本来是可以避免的，比如擅自修改php配置，居然去掉了mysql的pdo驱动，导致我们的服务大面积中断。
最离谱的是，连续几天awstats居然没有任何统计数据。由于我们以前过于信赖BH自身的工具，没有引入第三方的统计分析工具，以至于我们都无法确认这只是awstats的问题，还是BH的节点出现了严重问题，感觉非常糟糕。
BH新的技术支持人员的专业素养也让人怀疑。比如cpanel的问题、sftp等问题，域名管理配置问题等，简直答非所问，让人吃惊。而且online chat现在居然要三十几分钟的等待才能连接，实在无法理解。遥想当初使用BH的时候，还是个技术小白，几乎什么都不懂，完全是依赖即时的online chat来获得帮助，真是今非昔比。
这里就不说擅自修改商业定价策略和产品包的内容。
BH的初次建站成本比较低，但是续费的时候就比较贵，这点可以接受。然后后续如果需要添加新的服务，比如HTTPS支持，独立IP等，就需要另外付费，综合起来的商业成本，实际上比使用VPS更贵一些。何况，在“lets encrypt”免费提供SSL证书的情况下，对HTTPS进行收费未必合理。实际上，我们切换到VPS后，采用了“lets encrypt”的证书进行HTTPS加密，效果很好，没有任何额外费用。
使用VPS的技术要求门槛高一些，至少要懂一些linux的基础知识，所幸的是我们的技术水平在逐步的成长，这方面已经没有什么障碍。而BH对于初创企业目前来看还是很好的选择，只是在留住资深用户方面，还需要更扎实的服务和更稳定的系统环境。
DNS污染可能是一个比较普遍的问题，主要表现在：（1）DNS查询返回的IP地址根本是错误的。“错误”意思是IP地址要么根本不存在，要么就是个和域名完全无关系的地址。（2）IP地址虽然可能是对的，但是其他参数被莫名修改，例如TTL参数等。
测试了各类DNS服务器，例如阿里DNS、DNSPod（鹅厂）、Google DNS等。无一例外，最终的结果都或多或少被一些看不见的手给修改、甚至屏蔽了。从技术角度上讲，DNS协议本身非常随意、非常粗糙，是典型的互联网蛮荒时代的产物，比如面向UDP、无加密、无鉴权等，因此网络上任何一只手都有可能修改DNS的查询结果。网络进化到IPv6阶段，当然能解决这个问题，不过既然目前绝大部分设备还只支持IPv4协议栈，因此我们还是不得不修修补补来解决这个污染问题。
最根本的解决方法就是加密DNS查询。目前有些DNS服务商提供了私有的加密DNS方式，不过不太通用，需要私有的客户端程序配合。实际上可以不用搞这么复杂，自己建立加密通道，传递DNS消息即可。例如，参考下图的拓扑逻辑：
在这个网络中，有两个关键程序：dnsProxy和dnsAgent。
dnsProxy顾名思义就是个Proxy，本身并不负责DNS协议的解析，也不保存DNS的查询结果等信息，只是单纯地将DNS消息传递给真正的DNS服务器，并返回相应的结果即可。dnsProxy另一个功能是对外提供加密的数据连接，例如TLS、SSL加密等，甚至可以只是简单地对数据包进行自定义的异或运算即可。另外就是对外提供非标准连接接口，这点非常重要。DNS采用标准UDP53接口作为DNS服务器接口，网络上那些看不见的手，往往就是扫描并篡改53接口的数据包。这个小程序跑在境外（大家都懂的）的一台VPS设备上，推荐采用DigitalOcean，专业的云计算服务商，采用SSD硬盘，价格公道，我们一直用TA，如果你有兴趣的话，请点击这里自行了解细节。
dnsAgent是另一个小程序，主要负责建立与dnsProxy的加密连接，接收普通设备的DNS请求并将其传递给dnsProxy，同时返回DNS结果给普通计算设备。对于网内设备而言，dnsAgent就是个伪装的DNS服务器。同样，dnsAgent其实也不需要关心、也不需要解析DNS协议细节。在我的网络中，dnsAgent跑在一台常年吃灰的树莓派上（还是第一代的）。
实现这些仅仅需要一点UDP、TCP的网络知识，甚至不需要了解DNS协议的细节，无需对DNS数据包做修改。完成后可以愉快地打开很多以前打不开的网站。当然，有些网站始终是打不开的，这是另一个与DNS无关的话题了。
过去一直在尝试使用Amazon的EC2云计算环境，并曾经逐步将工作中大量相关资源转移到该系统中。
应该说EC2给我留下了非常深刻的印象，然而结果却并不美好，有各方面的原因，最终导致我放弃了EC2。
最根本的原因是目前从国内访问EC2实在是太慢了。回想起去年我刚接触EC2时，非常惊讶于EC2的速度，无论是虚拟机的运行速度还是网速，都非常让人满意，当时的上传速度轻松就能达到近百KB/s，为此我甚至将VPN环境也转移到了EC2，实在是太方便了。而现在，常常出现连接超时、龟速等让人难以忍受的情况。这个问题不能全部归结于Amazon本身，也与我们猥琐的墙有关（具体原因大家都懂的）。
而最近Amazon本身似乎也有问题。在重新创建instance时，居然只有us-east四个区可选择（？现在的情况是否有改善不得而知）。而恰恰是这四个区今年以来问题不断，要么是连接性问题，要么是API问题，几乎每月都会有。当然这些问题不一定会影响到最终的接入速度或运行状态，但是毫无疑问让人感觉很担忧，尤其是将企业业务运行在这种环境时就显得更严重了。
从一些Amazon的一些新闻判断，Amazon可能将大量EC2或者S3的资源调度给自身的云应用了，例如Amazon视频、Kindle fire等，而留给外部客户的资源自然就少而且差了，这可能也是为什么只有us-east四个区可选择的原因之一。Amazon很有可能不会平等对待外部客户，而以内部应用优先。这对Amazon来说理所当然，但对外部客户而言就需要重新考虑了。
鉴于以上各种因素，最终我们转向了独立VPS提供商。虽然费用比EC2贵些，但是目前至少还没有受到太多的鸟气，感觉比较满意。
最后，再一次Fuck那个众所周知的墙以及它的设计者、制造者和维护者。