Snooda

    由于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了。

    在使用自有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是否生效。

    台湾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， 成功了。

    由于一快一慢搭dns靠谱程度不高，只能再搞一个速度比较快的vps来当dns服务器，没啥好选择，对国内靠谱的线路也就东亚这几个地方的：日韩港台。日韩的有语言障碍，价格也相当牛叉，于是还是搞香港的，今天入了一个试试。

    香港是众所周知的小水管，今天试了一下名不虚传，网站测速测一个wp的首页才6k的数据就惨不忍睹，测一个380k的图片，单线程稳定1.4M，应该是限速了。多线程直接各种超时，并且遇到一个从来没遇到的情况：测速时由于带宽跑到限制，ssh输入都挂了，无响应，停止测速才恢复。。。。小水管真是名不虚传。

    观察了一下稳定性，也非常一般般，波动不小。

    用台湾vps和香港vps搭了一对dns试了一下，刚开始设置所有记录均不缓存，发现我自己的电脑上每次都稳定在500ms左右，非常奇怪，因为到任意一台机器都只需要几十ms，解析时指定dns确实也只需要几十ms，后来把ns记录设置了缓存一分钟，发现在缓存期内延迟降到了几十ms，看来是由于不缓存ns记录时需要去一级域dns那里查顶级域名的ns记录导致的，不过奇怪，难道一级域dns给出的ns记录缓存时间是由顶级域dns里的ns设置决定的么？搞不懂。不过我把ns记录设置成缓存1小时时，发现监控宝的dns监控时间还是稳定在500ms左右，没有下降，ft。并且四个监控点还总有一个报获取不到记录。

   dns的性能测试实在是不好搞，设置成不缓存的话不太好同条件对比，因为dns商不会允许这么设。设缓存的话结果又往往取决于缓存dns服务器的性能。对于大站的话由于访问人数多，所以dns一定是被缓存住的，倒不用考虑dns问题，对于小站，每个访客都要从头解析一下域名，dns的速度就很重要了。

   不过通过今天的观察发现自己建dns性能也不如预想的那么好，不过毕竟定制性好。

    本来想用自建dns，设置两条ns记录，其中速度较快的dns服务器排在前面作为主dns，比较慢的放在后面做备份。

    结果发现实践中两条记录是随机顺序返回的，查了下需要rrset-order参数来指定方式，有如下三种：

fixed 以它们在域文件中的顺序排序
random 以随机顺序被返回
cyclic 以环顺序被返回

    显然对于我的需求是使用fixed模式，结果启用了后提示我默认不开启此模式，查了下原来从bind9开始默认编译不启动这个选项了，除非编译的时候手动加参数打开，而我用apt安装的bind9，所以该选项未开放，即使我这里支持了，上级域的dns也不能设置这个选项，很可能是随机返回结果的，悲剧。看来之前的设想满足不了，dns也要木桶原理了。

    现在很多比较大的站点会把访问顶级域的请求都url重定向到www子域上，主要是为了网站权重统一的考虑。google站长工具里面也提供了将搜索结果统一到www子域或顶级域上，但为什么大的站点都是从顶级域统一到www子域而不是相反呢，最近看dns，也写写从域名解析角度看统一到哪个比较好。

  如果请求访问顶级域，则顶级域的a记录是由顶级域dns指定，而顶级域dns由上级域dns的ns记录指定，这个ns记录的缓存时间是不可控的，有可能会比较短，而访问www子域的话，a记录由顶级域ns记录指定的dns解析，这个ns记录是可以自己控制的，可以设置成比较长的值，并且如果用户访问过其他子域，那么会缓存子域dns地址，这样的话访问www子域直接找子域dns服务器解析即可，无需了解顶级域dns服务器，而如果访问顶级域，就需要查顶级域dns地址了，很有可能要去请求上级dns，像com等域名dns很多同时是由根dns解析的，而根dns均在国外（虽然通过anycast技术可能有国内节点，负载也是不小的）。所以总体来说统一到www子域较好

    五一节在家看rfc看的比较晕，rfc的英文貌似都比较晦涩，组织不够有条理，表述也比较模糊，很难了解到详细的东西，昨天公司同事推荐了DNS & BIND（DNS and BIND）这本书，大致浏览了一下，豁然开朗，写出一些总结。

    之前有一个二级域是自己解析的，而顶级域是用一些dns商提供的域名解析服务，最近各个dns提供商的服务都不太靠谱了，国外的老是访问不了，国内的dnspod又很不稳定（高峰期动辄就几s的解析时间），于是开始考虑自建dns了。

    自建dns首先要考虑的问题就是稳定性，毕竟vps稳定性比服务器还是要差一点，并且出了故障的恢复可能也没有那么及时，这样就需要研究在在线率只有99.5%这个级别的vps上如何搭建一个稳定性较高的dns服务。

    经过研究dns的实现原理，发现dns从设计上就是一个高可用性的架构。

    首先dns要求域名最少要有两条ns记录（我之前自己的二级域就设了一个貌似也没啥，但顶级域要求最少设置两个），以保证服务的稳定性。如果只有两台dns服务器，则设置成一主一从即可，从dns周期性从主dns获取最新结果，同步参数由SOA记录指定。如果dns比较多，可以设置多主dns，不过需要维护各个zone文件的统一性（可用rdist），每个域名受限于udp包的大小，最多设置10个左右的ns记录（从该书看到的，未详细考证）。

    对于多个ns记录，windows的客户端和ubuntu的客户端会首先查询第一个记录，如果失败或超时，则查询下一个。对于某些客户端则会随机挑选一个。

    这样的话需要把速度比较优秀的dns服务器放在第一个位置上，把备份服务器放在后面，这样即使第一个dns挂掉，后面的服务器一样能提供服务，只是速度会慢一点而已。但对于随机选ns的客户端就比较蛋疼了，会选到比较慢的服务器，不过这个还是待考证的，可以先搭建一下试试，看看比例如何。

    
    另外搞清了上篇文章所说的域名自身ns记录的问题。很多顶级域的dns都会有@域的ns记录指向自己，之前理解有误，其实这些ns记录是对二级域生效的。这样设置是表示二级域和顶级域由相同的ns服务器负责解析。即使不设置这个记录，顶级域dns服务器也是可以解析子域的，但顶级域的ns记录缓存时间是不可控的（设置时没有ttl），有可能很快过期，这样的话解析二级域时就需要多次去com域dns上查询，而有了ns记录，可以自己控制ttl，在ttl没有过期的时间内，查询时可以直接命中ns记录去查询二级域，有效提高速度。

理论上顶级域dns只负责解析顶级域自身的a、mx、cname、ns记录等，其他二级域记录需要顶级域的ns记录指定的dns来解析，而一般大家使用dns托管的话，二级域名和顶级域往往是一起管理的，所以ns是指向自身的。

    很久之前有过如下疑惑：比如baidu.com的域名dns设置为ns2.baidu.com。也就是说baidu.com这个域名由ns2.baidu.com解析。但问题是，ns2.baidu.com对应的ip又需要找到baidu.com的解析服务器去解析，这样就陷入一个循环。如何解决这个问题呢？周末看了下相关rfc，原来对于ns记录用到的域名，可以设置一下glue record，用来给这些域名提供解析，显然，这个记录需要由一级dns服务器解析。也就是.com dns服务器。显然，这个记录需要去域名注册商那里设置，我用的域名是godaddy注册的，研究了一下，godaddy将这个记录叫做“summary record”，设置的位置也相当偏僻，在域名管理面板的左下角，有个“Host Summary”框，点击add即可添加相关记录，这个从字面意思上并不太能看出来跟dns有关，找了很多资料才找到这里。

    对于很多dns提供商和服务程序，当添加一个域名时，会默认带有这个域名的ns记录，这个会比较令人疑惑，因为这个记录正常情况下是不会生效的，域名的dns服务器是上级域服务器指定的，在本级指定看起来没意义，不知道有何原因，个人猜测是为了在多ns记录情况下，从任意dns server查询的时候都能获取到所有的ns记录

    今天qa说http请求host字段最后以"."结尾时会有问题，看了下发现lighttpd自动把点号去掉了，试了试nginx，也是这样。查了很多rfc，没找到为什么，跑到群里问，有人说是根域的问题，回想起来配dns的cname记录时，最后必须是有“点”结尾的，于是搜索了下。原来真正完整的域名最后是带点的，com、net、cn这都是顶级域名，点后面的“”是根域名。dns解析最顶部是找到根域，然后再找顶级域。之前以为com就是根域，由跟域名服务器解析。现在看是错的

    最近几天监控频频爆出dns无法解析问题，群里关注了下，发现godaddy的dns服务器现在开始被和谐了，于是决定换一个。dnspod国人用的比较多，不过在国内总感觉比较扯。还是用he的比较可靠一点。

    修改很快，将解析记录都导入he的管理页面后去godaddy切换ns记录，本地nslookup了一下，切换了。

    在此期间注意到godaddy有了DNSSec记录功能，看了下，应该是防止dns欺骗的，暂时用不到，没有搞。