网络
openvpn不小心多开的挽救手段-iptables的使用
[
| 
2016/12/07 20:17]
| 2016/12/07 20:17]
今天写了一个自动拉起脚本，调试的时候出了点状况，导致启动了很多个openvpn实例，并且还在不断启动中。对于使用同证书的实例，默认会后面的踢掉前面的，所以网络就陷入了还没连上就被踢掉的循环，无法登陆，也就失去了控制。
首先尝试打开server端的duplicate-cn支持。这样每个连接都会分配到一个单独ip，不会互相踢掉。但由于进程太多，每个进程连接上后都试图刷新路由表，导致路由表不停变更，网络依然不能连通。
这时就需要从server端限制：只能有一个客户端连接上。首先调研了下是否支持只接受第一个连接上的实例而忽略掉后面的连接请求，发现是没有这个特性的。因为如果正常使用中客户网络闪断，这种情况下就不得不等待很久session超时后才能连上，用户体验太差。
对于网络层面的控制，iptables是个很有效的利器。于是采用了如下的方式：
1，首先设置DROP掉指定机器所有入包 iptables -I INPUT 1 -p udp -s xxx.xxx.xxx.xxx -j DROP
这时候所有连入请求都会timeout。
2，然后使用tcpdump host xxx.xxx.xxx.xxx
查看所有连入请求的来源端口，选取其中一个。
3，执行 iptables -I INPUT 1 -p udp -s xxx.xxx.xxx.xxx --source-port yyyyy -j ACCEPT
为这个实例单独开一个入口。
等待几秒，等待其重试连接，这时候只有这一个实例可以连入。成功恢复连接。
这里需要注意，第一步应使用DROP而不是REJECT，因为前者会让请求方重试的时间间隔更长一些，为后续操作赢得更多时间。
首先尝试打开server端的duplicate-cn支持。这样每个连接都会分配到一个单独ip，不会互相踢掉。但由于进程太多，每个进程连接上后都试图刷新路由表，导致路由表不停变更，网络依然不能连通。
这时就需要从server端限制：只能有一个客户端连接上。首先调研了下是否支持只接受第一个连接上的实例而忽略掉后面的连接请求，发现是没有这个特性的。因为如果正常使用中客户网络闪断，这种情况下就不得不等待很久session超时后才能连上，用户体验太差。
对于网络层面的控制，iptables是个很有效的利器。于是采用了如下的方式：
1，首先设置DROP掉指定机器所有入包 iptables -I INPUT 1 -p udp -s xxx.xxx.xxx.xxx -j DROP
这时候所有连入请求都会timeout。
2，然后使用tcpdump host xxx.xxx.xxx.xxx
查看所有连入请求的来源端口，选取其中一个。
3，执行 iptables -I INPUT 1 -p udp -s xxx.xxx.xxx.xxx --source-port yyyyy -j ACCEPT
为这个实例单独开一个入口。
等待几秒，等待其重试连接，这时候只有这一个实例可以连入。成功恢复连接。
这里需要注意，第一步应使用DROP而不是REJECT，因为前者会让请求方重试的时间间隔更长一些，为后续操作赢得更多时间。
dns缓存nscd原理及相关知识
[| 2016/06/12 15:05]
| 2016/06/12 15:05]
由于sshd是支持包转发的。所以最近配置了一些规则，将指定uid的包转发到指定目标。通过统计包数量，发现tcp的数据是正常的，但dns请求包不生效，还是走原路径。tcpdump抓包发现确实是发到系统配置的resolver那里去了。看了眼sshd的代码，是使用了libc里面的res_query方法来做域名解析的。像gethostbyaddr也是使用的这个方法。考虑到可能是这里发生的问题，于是用strace抓包看了一眼。发现该方法是先去连接/var/run/nscd/socket。如果成功，则发送域名解析请求，然后由nscd服务进行dns解析。所以按uid来抓包会失效。
nscd是一个缓存服务。会缓存passwd、hosts、resolv三类信息。和dnsmasq类似。先试图停掉nscd服务再进行尝试，果然进程在试图连接/var/run/nscd/socket失败后，转为连接resolv.conf里指定的server，可以成功被iptables转发。
定位了具体问题原因后，开始寻找更多解决方案。停掉nscd固然最简单，但会导致整个系统都失去dns缓存，对性能还是有一定影响的。于是寻找优化一些的方案。思路是对于指定进程绕过nscd机制。
研究了一下。发现nscd为了避免自己的请求发送给自己导致死循环，调用了一个__nss_disable_nscd方法。调用该方法后即可关闭nscd机制。于是改动了一下sshd源码，重新编译了一个。再次重试。果然ok了。
nscd是一个缓存服务。会缓存passwd、hosts、resolv三类信息。和dnsmasq类似。先试图停掉nscd服务再进行尝试，果然进程在试图连接/var/run/nscd/socket失败后，转为连接resolv.conf里指定的server，可以成功被iptables转发。
定位了具体问题原因后，开始寻找更多解决方案。停掉nscd固然最简单，但会导致整个系统都失去dns缓存，对性能还是有一定影响的。于是寻找优化一些的方案。思路是对于指定进程绕过nscd机制。
研究了一下。发现nscd为了避免自己的请求发送给自己导致死循环，调用了一个__nss_disable_nscd方法。调用该方法后即可关闭nscd机制。于是改动了一下sshd源码，重新编译了一个。再次重试。果然ok了。
linux下l2tp客户端拨号配置（xl2tpd)
[| 2016/01/09 16:53]
| 2016/01/09 16:53]
最近由于需要拨号到l2tp vpn服务器上。弄了一下linux下的客户端xl2tpd
其实xl2tpd既可以当服务端。又可以当客户端。在本文里只介绍客户端相关的功能
安装比较简单。apt-get或者yum直接搜xl2tpd，装上即可。没有自己编译也很简单。
注意依赖了/dev/ppp设备。如果不存在，需要
mknod /dev/ppp c 108 0
创建一下。
配置文件/etc/xl2tpd/xl2tpd.conf
[lac myvpn]
name = 'myvpn'
lns = myvpn
pppoptfile = /etc/ppp/peers/myvpn.l2tpd
ppp debug = yes
配置文件 /etc/ppp/peers/myvpn.l2tpd
remotename myvpn
user "xxx"
password "ooo"
ipcp-accept-local
ipcp-accept-remote
refuse-eap
require-mschap-v2
noccp
noauth
noipdefault
mtu 1410
mru 1410
usepeerdns
debug
lock
connect-delay 5000
然后就可以启动xl2tpd。然后echo "c myvpn" > /var/run/xl2tpd/l2tp-control
来连接了。
注意ppp的配置里有：noipdefault 选项。
其他很多资料都没有这一项。包括阿里云的官方文档。但在debian系里面。不加这个且机器有内网网卡时，是不太好用的。
连接的ppp0设备会自动使用内网ip。导致很多奇葩的事情发生。
noipdefault这个选项表示不使用本地默认ip分配策略。直接用服务器分配的。如果不要求每次拨号都使用固定ip的话，建议加上该参数
其实xl2tpd既可以当服务端。又可以当客户端。在本文里只介绍客户端相关的功能
安装比较简单。apt-get或者yum直接搜xl2tpd，装上即可。没有自己编译也很简单。
注意依赖了/dev/ppp设备。如果不存在，需要
mknod /dev/ppp c 108 0
创建一下。
配置文件/etc/xl2tpd/xl2tpd.conf
[lac myvpn]
name = 'myvpn'
lns = myvpn
pppoptfile = /etc/ppp/peers/myvpn.l2tpd
ppp debug = yes
配置文件 /etc/ppp/peers/myvpn.l2tpd
remotename myvpn
user "xxx"
password "ooo"
ipcp-accept-local
ipcp-accept-remote
refuse-eap
require-mschap-v2
noccp
noauth
noipdefault
mtu 1410
mru 1410
usepeerdns
debug
lock
connect-delay 5000
然后就可以启动xl2tpd。然后echo "c myvpn" > /var/run/xl2tpd/l2tp-control
来连接了。
注意ppp的配置里有：noipdefault 选项。
其他很多资料都没有这一项。包括阿里云的官方文档。但在debian系里面。不加这个且机器有内网网卡时，是不太好用的。
连接的ppp0设备会自动使用内网ip。导致很多奇葩的事情发生。
noipdefault这个选项表示不使用本地默认ip分配策略。直接用服务器分配的。如果不要求每次拨号都使用固定ip的话，建议加上该参数
更换了泛域名证书
[| 2015/01/22 00:26]
| 2015/01/22 00:26]
之前搞的单域名ssl证书要到期了，最近正好搞了个泛域名证书，换上了。
好久没更新blog了，比较忙。刷一下新文章。
好久没更新blog了，比较忙。刷一下新文章。
dns glue record的查看与校验
[| 2013/03/31 21:23]
| 2013/03/31 21:23]
在使用自有dns服务器时，一般会使用glue record。即使用ns01.snooda.com作为snooda.com的dns服务器，这样就会遇到一个先有鸡还是先有蛋的问题。为了解决此问题，会使用glue record，即由com域dns服务器提供ns01.snooda.com的ip地址。一般这个记录在域名注册商那里修改。但怎么查看是否修改成功了呢？这里dig就派上了用场。
使用dig +trace +nosearch +all +norecurse snooda.com
在返回的结果里，我们会在com域dns返回的结果中，看到一个”ADDITIONAL SECTION“，里面提供了两个a记录。这就是glue record。由于我们试图解析snooda.com，所以先从com域dns服务器获取snooda.com的dns服务器地址，com域dns判断结果是一个snooda.com的子域，所以是glue record。所以不但返回了dns地址，还返回了对应的a记录。
用这个方式就可以检验设置的glue record是否生效。
使用dig +trace +nosearch +all +norecurse snooda.com
在返回的结果里，我们会在com域dns返回的结果中，看到一个”ADDITIONAL SECTION“，里面提供了两个a记录。这就是glue record。由于我们试图解析snooda.com，所以先从com域dns服务器获取snooda.com的dns服务器地址，com域dns判断结果是一个snooda.com的子域，所以是glue record。所以不但返回了dns地址，还返回了对应的a记录。
用这个方式就可以检验设置的glue record是否生效。
net-speeder网速优化/加速器（适用于高延迟不稳定链路加速）
[| 2013/03/24 23:23]
| 2013/03/24 23:23]
当使用国外服务器时，经常会发现，下载速度只有十几k。平时可能不太注意，认为服务器带宽不足，或者自己使用的宽带不给力，其实很有可能原因并不在此。
由于光速的局限性，延迟会比较高（即使光沿直线传播，太平洋一个往返也要一百多毫秒）。并且由于距离较远，途径路由跳数较多，并且网络拥堵的原因。经常会发生丢包的情况。
对于平时使用最广泛的TCP协议来讲，发送端发出包后，接收端会回复ACK，表示自己收到了。用这种机制来保证可靠性。但对于高延迟链路来讲，如果每发送一个包都等待应答，那么大部分时间都在等待数据包到达，而链路则空置了。为此一般会采用滑动窗口技术。即在窗口满之前，发送端一直发送包，然后收到应答后将确认收到的包从窗口中移除。这样可以提高链路利用率。
TCP还有一个特性则是拥塞控制。当发送端检测到链路发生丢包时，则会主动缩小窗口大小以减慢发送速度，避免拥塞。不过对于跳数较多的链路来讲，只要有一个路由不够稳定丢包，就会被发送端判断为拥塞，从而影响网络速度。
为了解决丢包问题，最简单粗暴的方法就是双倍发送，即同一份数据包发送两份。这样的话在服务器带宽充足情况下，丢包率会平方级降低。
这种方式下，直接优点是降低丢包率，直接缺点是耗费双倍流量。一些延伸影响是更容易触发快速恢复逻辑，避免了丢包时窗口缩减过快。一定程度也能提高网络速度。
最近比较忙，空闲时间做了一个最简单的程序，试用效果很好，在一台VPS上测试后发现，未开启时单线程下载、ssh管道速度在十几K级别。开启后可以达到平均300KB+的速度。效果非常明显。但对于不加速就可以跑满带宽的类型来讲（多线程下载），开启后反而由于多出来的无效流量，导致速度减半。所以对于多线程/高速链路，这个方案是不适合的。
目前版本是最简单的逻辑，未来会进行细化（主动触发快速恢复、快速重传等），降低流量浪费，提升加速效果。
目前程序起名net-speeder，相对于修改协议栈来讲，由于后者需要重新升级编译内核，使用用户态程序部署更方便，稳定性更高，兼容性更好。缺点则是性能开销稍大和自由度有损失。总体比较起来，个人使用还是使用用户态程序更合适一些，特别是在虚拟机中使用（OpenVZ，LXC等虚拟机无法自己定制内核）。
项目托管地址：http://code.google.com/p/net-speeder/
https://github.com/snooda/net-speeder
关注微信公众号随时接收最新开发进度。近期将会推出加速效果体验ssh/pptp账号
由于光速的局限性，延迟会比较高（即使光沿直线传播，太平洋一个往返也要一百多毫秒）。并且由于距离较远，途径路由跳数较多，并且网络拥堵的原因。经常会发生丢包的情况。
对于平时使用最广泛的TCP协议来讲，发送端发出包后，接收端会回复ACK，表示自己收到了。用这种机制来保证可靠性。但对于高延迟链路来讲，如果每发送一个包都等待应答，那么大部分时间都在等待数据包到达，而链路则空置了。为此一般会采用滑动窗口技术。即在窗口满之前，发送端一直发送包，然后收到应答后将确认收到的包从窗口中移除。这样可以提高链路利用率。
TCP还有一个特性则是拥塞控制。当发送端检测到链路发生丢包时，则会主动缩小窗口大小以减慢发送速度，避免拥塞。不过对于跳数较多的链路来讲，只要有一个路由不够稳定丢包，就会被发送端判断为拥塞，从而影响网络速度。
为了解决丢包问题，最简单粗暴的方法就是双倍发送，即同一份数据包发送两份。这样的话在服务器带宽充足情况下，丢包率会平方级降低。
这种方式下，直接优点是降低丢包率，直接缺点是耗费双倍流量。一些延伸影响是更容易触发快速恢复逻辑，避免了丢包时窗口缩减过快。一定程度也能提高网络速度。
最近比较忙，空闲时间做了一个最简单的程序，试用效果很好，在一台VPS上测试后发现，未开启时单线程下载、ssh管道速度在十几K级别。开启后可以达到平均300KB+的速度。效果非常明显。但对于不加速就可以跑满带宽的类型来讲（多线程下载），开启后反而由于多出来的无效流量，导致速度减半。所以对于多线程/高速链路，这个方案是不适合的。
目前版本是最简单的逻辑，未来会进行细化（主动触发快速恢复、快速重传等），降低流量浪费，提升加速效果。
目前程序起名net-speeder，相对于修改协议栈来讲，由于后者需要重新升级编译内核，使用用户态程序部署更方便，稳定性更高，兼容性更好。缺点则是性能开销稍大和自由度有损失。总体比较起来，个人使用还是使用用户态程序更合适一些，特别是在虚拟机中使用（OpenVZ，LXC等虚拟机无法自己定制内核）。
项目托管地址：
https://github.com/snooda/net-speeder
关注微信公众号随时接收最新开发进度。近期将会推出加速效果体验ssh/pptp账号
curl耗时长问题-Expect: 100-continue
[| 2013/01/22 17:17]
| 2013/01/22 17:17]
最近发现有个问题，一个自制的webserver在应答前端请求时，总是要处理1s以上，似乎是由于哪里等待了1秒。研究了下发现：Expect: 100-continue这个东东。
100-continue这个状态码之前是很少遇到的。这个是http1.1协议为了提高效率设置的。当客户端要POST较大数据给webserver时，可以在发送http头时带上Expect: 100-continue，服务器如果接受这个请求，应答一个HTTP/1.1 100 Continue，那么客户端就继续传输正文，否则应答417，客户端就放弃传送剩余的数据了。这样就避免客户端吭哧吭哧传了一大堆数据上去，结果服务端发现不需要的情况。
libcurl在不同版本里逻辑不同，有的版本libcurl会在POST数据大于1024字节的时候发送100-continue请求，有的版本则不会。我们用到的libcurl版本会发送，而自制webserver不会应答这个请求，客户端等待1s钟没有收到肯定或否定的应答，还是继续传输了正文，虽然逻辑上并没有问题，但速度上就慢了下来。
加了下逻辑，对100-continue进行应答，速度马上提高很多。
100-continue这个状态码之前是很少遇到的。这个是http1.1协议为了提高效率设置的。当客户端要POST较大数据给webserver时，可以在发送http头时带上Expect: 100-continue，服务器如果接受这个请求，应答一个HTTP/1.1 100 Continue，那么客户端就继续传输正文，否则应答417，客户端就放弃传送剩余的数据了。这样就避免客户端吭哧吭哧传了一大堆数据上去，结果服务端发现不需要的情况。
libcurl在不同版本里逻辑不同，有的版本libcurl会在POST数据大于1024字节的时候发送100-continue请求，有的版本则不会。我们用到的libcurl版本会发送，而自制webserver不会应答这个请求，客户端等待1s钟没有收到肯定或否定的应答，还是继续传输了正文，虽然逻辑上并没有问题，但速度上就慢了下来。
加了下逻辑，对100-continue进行应答，速度马上提高很多。
互联网是如何连通的/路由是怎么生成的/网络代理加速的原因
[| 2012/10/14 01:35]
| 2012/10/14 01:35]
最近一直苦于没有什么话题来写博，今天终于找到一个。 有人疑惑为什么使用fq代理后访问某些网站反而快了，疑问是不是某防火墙在捣鬼。 世界上一共40亿个ipv4地址，ipv6就更多了，为啥访问任意一个地址就能访问的到？是谁维护了这40亿个地址的分布？从这个ip到那个ip途径的路由是谁来指定的？
从我们电脑的上网来讲，接入网络就能上网，这个是很稀松平常的事，但如果同时接入两个网络呢？比如一根有线一根无线，那么流量是怎么走的呢？这个时候电脑里的路由表就发挥了作用，运行route print命令，可以看到一行行的规则，每个网络包都会从上到下匹配这些规则，如果匹配上，就按规则指定的端口转发出去。一般同一时间段内流量只从一个网卡流出。
进一步讲，家里多人上网的话会有路由器，对于家里电脑间传送文件和访问公网网站，流量是分发到不同端口的，路由器的路由表规则就不再是简单的向某一个端口分发，而是针对不同的ip段走不同的分发规则，一般内网ip流量分发至对应内网端口，公网流量统一从公网端口发送。
对于公网上的流量，一样是按照路由表指示的路径行进，路由表是如何生成的呢？
首先不会是每个ip一条记录，因为数据量太大，这里就用到了ip的分块，最早是用a,b,c三类来划分，后来由于粒度太粗，后来改用子网掩码的形式，子网掩码规定的范围是ip段的网络名，其余部分是可用地址范围（不全是，本文内容不做涉及），这样，路由表的尺寸就能缩减不少。
互联网是网状的，每个路由都会于1个或多个其他路由进行连接，连接可能断开，可能阻塞，可能新建，所以路由表也会不断更新，一个路由器如何得知互联网上其他路由间的连接状态从而更新自己的路由表，就需要用到路由交换协议，比如RIP，路由器将自己所知道的路由信息广播给周边路由，这样网络连通信息就能不断扩散至全网。
不过网络上的路由器成千上万，如果所有路由都按照这种方式，效率非常低下。
现实中，网络划分为了不同的自治系统：AS，AS的编号由ICANN管理，成为一个AS需要有多线路的连通能力，像电信、联通都是AS，一些较大的网络服务商也可以申请AS号和自己的地址空间。每个AS系统内部维护自己地址空间的路由信息，AS系统间的边界路由器使用BGP协议交换各自地址空间，这样，发往一个AS的网络流量只需要发给对应AS的边界路由即可。不过如果AS间网络带宽较小或者不稳定，就会有“跨网络互通问题”，就像国内电信和联通间访问效果不佳。
早期国内主机解决网络互通问题会使用双ip的方案，同时接入一个电信ip和一个联通ip，再搭配智能dns，可以较好的解决了互通问题。但还是有浪费ip地址、智能dns解析不够准确的问题。
后来就有了多线主机有的也叫bgp主机，只有一个ip，但同时接入多个线路，有双线、三线、甚至五线。对于接入的线路，均可以实现较好的访问效果。原理就是机房同时实现和多条线路的互通，将ip广播至每条线路。
对于服务器可以通过接入多线的方式提高接入性能，对于上网者来说也一样。但同时开通两条甚至多条宽带的成本是比较高的，这样我们就可以借助多线服务器来提高网络访问速度。比如辽宁教育网用户访问辽宁联通，需要绕行至东北教育网节点甚至中国教育科研网节点，但如果借助一台部署在辽宁、同时接入教育网线路和联通线路的服务器中转。网络速度就能大大提高。对于访问国外站点也是一样。
资料：
查看全球bgp路由表：http://www.ris.ripe.net/bgpviz/
telnet：route-views3.routeviews.org
从我们电脑的上网来讲，接入网络就能上网，这个是很稀松平常的事，但如果同时接入两个网络呢？比如一根有线一根无线，那么流量是怎么走的呢？这个时候电脑里的路由表就发挥了作用，运行route print命令，可以看到一行行的规则，每个网络包都会从上到下匹配这些规则，如果匹配上，就按规则指定的端口转发出去。一般同一时间段内流量只从一个网卡流出。
进一步讲，家里多人上网的话会有路由器，对于家里电脑间传送文件和访问公网网站，流量是分发到不同端口的，路由器的路由表规则就不再是简单的向某一个端口分发，而是针对不同的ip段走不同的分发规则，一般内网ip流量分发至对应内网端口，公网流量统一从公网端口发送。
对于公网上的流量，一样是按照路由表指示的路径行进，路由表是如何生成的呢？
首先不会是每个ip一条记录，因为数据量太大，这里就用到了ip的分块，最早是用a,b,c三类来划分，后来由于粒度太粗，后来改用子网掩码的形式，子网掩码规定的范围是ip段的网络名，其余部分是可用地址范围（不全是，本文内容不做涉及），这样，路由表的尺寸就能缩减不少。
互联网是网状的，每个路由都会于1个或多个其他路由进行连接，连接可能断开，可能阻塞，可能新建，所以路由表也会不断更新，一个路由器如何得知互联网上其他路由间的连接状态从而更新自己的路由表，就需要用到路由交换协议，比如RIP，路由器将自己所知道的路由信息广播给周边路由，这样网络连通信息就能不断扩散至全网。
不过网络上的路由器成千上万，如果所有路由都按照这种方式，效率非常低下。
现实中，网络划分为了不同的自治系统：AS，AS的编号由ICANN管理，成为一个AS需要有多线路的连通能力，像电信、联通都是AS，一些较大的网络服务商也可以申请AS号和自己的地址空间。每个AS系统内部维护自己地址空间的路由信息，AS系统间的边界路由器使用BGP协议交换各自地址空间，这样，发往一个AS的网络流量只需要发给对应AS的边界路由即可。不过如果AS间网络带宽较小或者不稳定，就会有“跨网络互通问题”，就像国内电信和联通间访问效果不佳。
早期国内主机解决网络互通问题会使用双ip的方案，同时接入一个电信ip和一个联通ip，再搭配智能dns，可以较好的解决了互通问题。但还是有浪费ip地址、智能dns解析不够准确的问题。
后来就有了多线主机有的也叫bgp主机，只有一个ip，但同时接入多个线路，有双线、三线、甚至五线。对于接入的线路，均可以实现较好的访问效果。原理就是机房同时实现和多条线路的互通，将ip广播至每条线路。
对于服务器可以通过接入多线的方式提高接入性能，对于上网者来说也一样。但同时开通两条甚至多条宽带的成本是比较高的，这样我们就可以借助多线服务器来提高网络访问速度。比如辽宁教育网用户访问辽宁联通，需要绕行至东北教育网节点甚至中国教育科研网节点，但如果借助一台部署在辽宁、同时接入教育网线路和联通线路的服务器中转。网络速度就能大大提高。对于访问国外站点也是一样。
资料：
查看全球bgp路由表：http://www.ris.ripe.net/bgpviz/
telnet：route-views3.routeviews.org
bind9发送notify通知slave dns主动更新
[| 2012/08/31 00:47]
| 2012/08/31 00:47]
台湾vps已经不靠谱了。于是开始迁移至香港，台湾vps决定放弃。这时遇到了问题，就是dns又变成了单点。
所幸服务商提供了slave dns功能，这个还是很少见的，不过这个功能对于我来说实在太有用了。
估计也是这个服务太过小众，服务商的功能也是bug多多，发了无数ticket才搞定。
首先是管理页面就有问题，添加slave dns记录后刷新页面，记录就消失了。也不生效。通知他们修正了下，搞定了。
然后发现添加记录倒是成功了，但没有slave dns来拉取记录。而这时我操作太激进，把ns记录都切换过来了，结果导致落到slave dns上的请求都返回空记录了，发现后急忙切换回来。发ticket通知他们，告诉我要在allow-transfer里把所有的服务器ip都加上，试了下，似乎nslookup - slave dns ip 使用指定dns后还能成功了。很高兴。
但过了一会发现请求还是落到了主dns上，并且有很大概率的失败，于是再次联系客服。客服说在添加slave dns记录时我的master dns ip没有记录上，重新添加不行，后来客服搞了一下，可能修复了bug，可以了。
然后发现slave似乎不支持notify请求，我用rndc reload更新记录时没有slave来请求。
先是添加also-notify，通知所有slave dns，因为默认是通知所有ns记录里的服务器，不过我并没有用到全部slave server，所以要手动添加其他服务器收到通知。
发现还是无效，猜测可能是出口ip不对，于是添加notify-source指定了notify时的来源ip。
重启bind9， 成功了。
所幸服务商提供了slave dns功能，这个还是很少见的，不过这个功能对于我来说实在太有用了。
估计也是这个服务太过小众，服务商的功能也是bug多多，发了无数ticket才搞定。
首先是管理页面就有问题，添加slave dns记录后刷新页面，记录就消失了。也不生效。通知他们修正了下，搞定了。
然后发现添加记录倒是成功了，但没有slave dns来拉取记录。而这时我操作太激进，把ns记录都切换过来了，结果导致落到slave dns上的请求都返回空记录了，发现后急忙切换回来。发ticket通知他们，告诉我要在allow-transfer里把所有的服务器ip都加上，试了下，似乎nslookup - slave dns ip 使用指定dns后还能成功了。很高兴。
但过了一会发现请求还是落到了主dns上，并且有很大概率的失败，于是再次联系客服。客服说在添加slave dns记录时我的master dns ip没有记录上，重新添加不行，后来客服搞了一下，可能修复了bug，可以了。
然后发现slave似乎不支持notify请求，我用rndc reload更新记录时没有slave来请求。
先是添加also-notify，通知所有slave dns，因为默认是通知所有ns记录里的服务器，不过我并没有用到全部slave server，所以要手动添加其他服务器收到通知。
发现还是无效，猜测可能是出口ip不对，于是添加notify-source指定了notify时的来源ip。
重启bind9， 成功了。
腾讯qq邮箱和企业邮箱的区别
[| 2012/07/22 23:16]
| 2012/07/22 23:16]
之前经常拿来备份数据的企业邮箱满了，而qq为了赚钱不让企业邮箱扩容了，所以没办法，准备换成可自动扩容的qq邮箱。但发现一些大邮件无法收到，查看mail.log后发现发送超时。错误信息：
dsn=4.4.2, status=deferred (lost connection with mx3.qq.com[119.147.6.81] while sending message body
而用企业邮箱的时候从来没有这个问题，排查了下，把postfix发送超时设长，无效，还是发送一分钟后就超时，看来是qq的mail服务器设置了1分钟超时，如果1分钟内邮件发送不完就断开连接。
tracert了一下到两个邮件服务器的路由，前若干跳都是一样的，但后续设置了禁ping，无法得知具体路径。
看来我的机器到qq邮箱mail服务器速度比较慢，而到企业邮箱速度快，有可能是qq邮箱设置了速度限制之类的东东，只能给企业邮箱开自动转发，把邮件中转一下了。
dsn=4.4.2, status=deferred (lost connection with mx3.qq.com[119.147.6.81] while sending message body
而用企业邮箱的时候从来没有这个问题，排查了下，把postfix发送超时设长，无效，还是发送一分钟后就超时，看来是qq的mail服务器设置了1分钟超时，如果1分钟内邮件发送不完就断开连接。
tracert了一下到两个邮件服务器的路由，前若干跳都是一样的，但后续设置了禁ping，无法得知具体路径。
看来我的机器到qq邮箱mail服务器速度比较慢，而到企业邮箱速度快，有可能是qq邮箱设置了速度限制之类的东东，只能给企业邮箱开自动转发，把邮件中转一下了。
